Repository navigation
Test that the Composite obfuscator runs its stages in order [patch] - #175
Merged
Merged
Conversation
The Composite tests only checked round-trips, which a pipeline run backwards in both directions would still pass while producing different bytes from earlier versions. Compare its output with an order-sensitive [Base64, Reverse] pair applied one stage at a time, on the span, stream and async paths, in both directions. Fixes #174 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017vfJW5LkA4KtEKYNbjk5tz
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #174
Summary
The Composite tests only checked round-trips. A Composite that ran its stages last-to-first when obfuscating, and first-to-last when deobfuscating, would still undo itself and pass every one of them. Its output bytes would differ, though, so data persisted by an earlier version would no longer deobfuscate. This PR adds the stage-order tests that consolidation spec §4 asks for. The library code is unchanged.
Changes
Essentials.Tests/ObfuscationProviderTests.csgets seven tests built on a[Base64, Reverse]pipeline:Obfuscation_Composite_ChosenStagesAreOrderSensitivechecks thatReverse(Base64(x))differs fromBase64(Reverse(x)), so the chosen pair really does detect order.B.Obfuscate(A.Obfuscate(x)).A.Deobfuscate(B.Deobfuscate(y)).CLAUDE.md's description of the test file now mentions the stage-order coverage.I tried
[Xor, Reverse]first, as the issue suggested. The default Xor key is a single byte, so that pair commutes, and the order-sensitivity guard caught it.[Base64, Reverse]is the other pair the issue named.Tests
To check the new tests catch the bug, I temporarily made
CompositeObfuscationProviderrun both directions backwards:That confirms the gap the issue describes. The library change was then reverted.
Obfuscation slice: 60/60.
Full suite before the final pair change: 1351 passed, 1 skipped. The only failure was the order-sensitivity guard rejecting the original
[Xor, Reverse]pair.Generated by Claude Code