-
Notifications
You must be signed in to change notification settings - Fork 369
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
Minor Release 3.6.0 - Available / Fixes CVE-2022-2576 #2040
Comments
The 3.6.0 is released and available on Maven Central and the Eclipse Repository. The tools and actinium are only available on the Eclipse Repository. |
Just to let know that, there is something which looks like a behavior break with this version. The new Note: this is possible to deactivate this check with code but this will trigger a not so elegant |
Thanks!
I don't get this. This adds an additional check to |
Any news/feedback on the reported API break? Did you find it on tests with mismatching public/private keys? Or have I overseen use-cases? |
Short answer I raise this just in case this was not done on purpose. In all case, I strongly advice to remove the Long answer In a general way :
Anyway, I understand why this could also be considered as a bug/ or miss behavior fix. More concretely for Leshan integration :
So for now I just go back to previous behavior in Leshan Client. About 3., I guess we can consider this is a bad behavior of Leshan because this kind of exception should be handled correctly but this is what I called "unexpected problem". I don't try to convince you, I just give more details as you asked. |
Thanks! The
Generally, the checks in (FMPOV, the API contains an Exception for miss-configuration. The API user should consider that. And if so, the "behavior changes" is just a "bugfix".) |
❗❗❗ Important Note: ❗❗❗ This bugfix is required for all users of Californium 3.0.0 - 3.5.0, |
On my local machine (openjdk 17), leshan tests complains about the key (the exact issue pointed by Simon). But I struggle to understand why, the key is generated like this: |
I guess the starting point is broken and we should generate one properly |
Some weeks/months ago, I recognized, that people not common with x509 mix up the private and public key from the certificates. And then report mystic errors. e.g. server's private key, CA's public key. So, from my side the question is: About the System.out, I would like to finish a first version of a coap-to-S3-proxy. Since yesterday the required CQs for the aws-sdk has been resolved, so I will prepare for a initial PR as work-in-progress and a feature branch. My forecast will be something short before the EclipseCon (Mid of October). If you @sbernard31 or @jvermillard see any benefit in a 3.7 without the System.out earlier, let me know, then we can release the 3.7 without the S3-proxy and do that later in a 3.8. |
@boaks , Maybe @jvermillard was not clear but I guess he wanted to mention that he faces this issue but in a particular case : (this is not a complain about regression or something like this but more asking for help just in case you understand / face same kind of issue) I feel that a dedicated issue should have been created because this 3.6.0 annonce issue is probably not the best place.
No urgency for me. |
Is it possible for you to share the affected keys (demo-keys?)? |
This is just RPK (no certificate) and it was created like this : https://github.com/eclipse/leshan/blob/master/leshan-server-cf/src/test/java/org/eclipse/leshan/server/californium/bootstrap/LeshanBootstrapServerBuilderTest.java#L61-L85 |
Just to mention: CertificateConfigurationHelper does the check. I signs with the private key and verifies with the public key. |
And running that with java 11 succeeds and fails with 17? |
Yep 🤷 |
Yep I looked at this but don't get why JDK behave differently for this particular key pairs 🤔 |
I can reproduce the behavior (I added a test for the leshan keys to CertificateConfigurationHelperTest). |
I checked the pair with :
And both seems to work with this key pair. 🤔 |
I also tried with java 15, which has also the new EC implementation and it fails with that. |
OK, my result so far: (Or use |
I hope, it works with the 00 for you as well. |
It seems to work.
My first test seems to show it works 😬, I guess it should not, or ? |
I would have assumed not. If I dump the encoded public key, I get the same bytes, signed or unsigned. (And the private key works even without the 00.) |
From my side: |
I guess this confirms the idea : https://bugs.openjdk.org/browse/JDK-8183666 |
See PR #2058 |
Yes, once on the right trail, the information starts to give the right picture. (I still think, that this verification is a good idea, even if I learned now, that there are some pitfalls.) |
I was planning to dive deeper later, but you two already solved the mystery. Thanks 👍 |
You're welcome. |
For details, please see 3.6.0
The text was updated successfully, but these errors were encountered: