Switch go-pkcs12 to use LegacyDES encoder#6515
Switch go-pkcs12 to use LegacyDES encoder#6515erikgb wants to merge 1 commit intocert-manager:masterfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
43b4266 to
7394844
Compare
7394844 to
e54e1ea
Compare
There was a problem hiding this comment.
My initial reaction to this was that we should use LegacyRC2 to avoid the chance of a breaking change, but then I saw this line in the docs:
By default, OpenSSL 3 can't decode PKCS#12 files created using this encoder. For better compatibility, use LegacyDES. For better security, use Modern2023.
OpenSSL losing the ability to do RC2 makes me think that defaulting to DES might be a good shout (we definitely shouldn't care about the actual strength of the encryption - this is all irrelevant for security).
It's definitely a breaking change though; there could be tonnes of stuff out there that can do RC2 but not DES. I'd expect there probably isn't tonnes of stuff like that, but it's hard to tell.
I don't know how we could possibly evaluate which is actually going to be better for users, which makes me think that what we should really do is make this an option, which feels like a lot of work for not much benefit but might be the only option.
We might need to discuss this at a biweekly meeting to decide 🤔 I'll add it to next week's agenda.
Yes, that seems to result in the same behavior as we have currently. |
|
Let's start with using |
Signed-off-by: Erik Godding Boye <egboye@gmail.com>
e54e1ea to
84d48b0
Compare
Pull Request Motivation
Our dependency to build PKCS12 keystores, https://github.com/SSLMate/go-pkcs12, has released newer versions that deprecate our current use of the dependency. The recommendation is to switch to the more "modern" encoder, but I am pretty sure this would be a breaking change. For this reason, I suggest migrating to the less secure, but more compatible,
LegacyDESencoder.Related upstream PR: SSLMate/go-pkcs12#48.
Relates to #6511. I am unsure if this PR (without switching to the less compatible
Modernencoder) solves the issue reported in the security audit, but I think compatibility is more important. The JKS and PKCS12 encodings are not secure by just the password anyway.Kind
/kind cleanup
Release Note