| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
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. |
Sorry, something went wrong.
…he algorithms actually used, relates to github #2480.
| Back | FazBrowse Home | New Git URL |
the generated RFC 6211 cmsAlgorithmProtect attribute in DefaultSignedAttributeTableGenerator and DefaultAuthenticatedAttributeTableGenerator was guarded with std.contains(oid) where every attribute beside it uses std.containsKey(oid), and Hashtable.contains is the legacy containsValue, so against a table whose values are Attribute objects the condition was never true and the generated attribute always replaced one supplied through the AttributeTable the constructor takes, which left that AttributeTable unable to pin the algorithm identifiers the attribute binds and only a wrapper rewriting the table the generator returns able to, the way NewSignedDataTest.testRemoveAttribute does to drop it; found by turning on the HashtableContains error-prone check that build.gradle currently switches off, and a sweep of every Hashtable-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.