use containsKey for a supplied cmsAlgorithmProtect attribute - #2480
Closed
rootvector2 wants to merge 1 commit into
Closed
rootvector2 wants to merge 1 commit into
rootvector2 wants to merge 1 commit into
Conversation
Contributor
|
Thanks for the PR. This one I haven't merged although things have been changed after seeing it, it's definitely a bug, but it was actually doing the right thing (accidently) as RFC 6211 sec. 3 requires a receiver to fail validation when the attribute's algorithms differ from the SignerInfo's (or the AuthenticatedData's) so it's not really something that should be overridden at all. We've added a guard against the bug occurring again and also enforced the setting of the attribute. |
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.
the generated RFC 6211
cmsAlgorithmProtectattribute inDefaultSignedAttributeTableGeneratorandDefaultAuthenticatedAttributeTableGeneratorwas guarded withstd.contains(oid)where every attribute beside it usesstd.containsKey(oid), andHashtable.containsis the legacycontainsValue, so against a table whose values areAttributeobjects the condition was never true and the generated attribute always replaced one supplied through theAttributeTablethe constructor takes, which left thatAttributeTableunable to pin the algorithm identifiers the attribute binds and only a wrapper rewriting the table the generator returns able to, the wayNewSignedDataTest.testRemoveAttributedoes to drop it; found by turning on theHashtableContainserror-prone check thatbuild.gradlecurrently switches off, and a sweep of everyHashtable-typed.contains()call in the tree found these two sites and no others, with no generator in the library supplying the attribute so generated output is unchanged.AI tooling was used to help prepare this change.