Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backport #52 to v1.1 #56

Merged
merged 5 commits into from Feb 24, 2020
Merged

Backport #52 to v1.1 #56

merged 5 commits into from Feb 24, 2020

Conversation

aldaris
Copy link

@aldaris aldaris commented Feb 19, 2020

Hi,

A couple of our dependencies are using cryptacular v1.1.x and are not really keen to upgrade to 1.2 (I suppose Java version compatibility concerns is one reason), so I was thinking whether there is a middle ground solution for this, where the older version of cryptacular also gets the security fix (so that cryptacular stops showing up on vulnerable third party library scans).
The original commits I left untouched, all my silly compilation fixes were done in a separate commit. Let me know what you think.
I appreciate that my current solution is not ideal because it introduces a new type immediately with a @deprecated annotation, so I'm keen to hear your thoughts on alternative ways of backporting this change without completely breaking backwards/forwards compatibility. CipherTextHeaderV2#setKeyLookup is a definite API breaking change, and it's difficult to get around...

Thanks for your review.

serac and others added 5 commits Feb 19, 2020
New format does not allocate any memory until HMAC check passes, which
guards against untrusted input. All encryption components have been
updated to use the new header, while preserving backward compatibility
to decrypt messages encrypted with the old format. The decoding process
for the old header has been hardened to impose reasonable limits on header
fields: nonce sizes up to 255 bytes, key names up to 500 bytes.

Fixes #52.
Remove final keyword from variables.
@dfish3r
Copy link
Member

dfish3r commented Feb 19, 2020

@serac take a look at this backport of #52. If it works I can cut a v1.1 release.

*
* @deprecated In newer versions, KeyLookup is replaced by java.util.Function<String, SecretKey> instances.
*
* @author Middleware Services
Copy link
Member

@serac serac Feb 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can credit yourself/your org here if you want.

Copy link
Author

@aldaris aldaris Feb 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, but given that this was mostly derivative work, I'm completely fine just using Middleware Services here.

serac
serac approved these changes Feb 24, 2020
Copy link
Member

@serac serac left a comment

Seems like a reasonable solution for the target problem. The deprecated component concern doesn't bother me too much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants