Content signed with an expired certifcate after the expiration date is considered unsigned #363
Comments
|
is there already a new cert available? |
|
Hello, I will assume this means we will have to rebuild all projects currently contributed to the simrel, even those which didn't plan new versions? Laurent |
|
No, I believe the new cert is not yet available. No, not all projects need to rebuild. It's perfectly find to have a jar signed with an expired signature as long as the siganature itself was produced within the certificates validity range. This is why I mentioned that some artifacts are in strikeout but some are not. I will collect a list of affected projects ASAP. Please look for your artifacts in this list: |
|
This is the impact on the users:
|
|
The certificate expired yesterday, so anything built and signed before should be valid. There is ongoing work to update the certificate. However, this update is not routine because the secret key must now be stored on an HSM, a new requirement from the code-signing CA. |
It does not include |
|
I think you already noticed that I provided the platform-specific report here:
The Platform's M3 contribution was last Friday, so that content is not a problem; the Platform's own pend RC1 candidate content is a problem. |
|
I wonder is it possible for simrel verification to fail if contributed artifacts contain bad signature? |
|
Shouldn't signing itself fail if the certificate is expired? |
|
If possible, of course, that'd be nice. |
|
Right now the verification only uses the p2 planner to ensure there is a solution. Checking all the artifact signatures could be done by the aggregation step, which takes much longer. Right now actual testing of signatures is done by Oomph's repository analyzer as done by this job: https://ci.eclipse.org/simrel/job/simrel.oomph.repository-analyzer.test/ Unfortunately that didn't send me an email because it didn't actually fail. 😞 The Platform's content verification sent me an email this morning so that's what I noticed first. Of course I check the report before promoting the content so that's what I noticed second. Several factors contributed to this problem. Proactively updating the certificates would prevent all these problems. The signer verifying that the artifact is really properly signed would help catch that oversight when that proactive update hasn't taken place. Projects using the Oomph analyzer themselves would also catch this problem. And finally my complacency also contributed. That's because the aggregation builds PGP signs everything that is unsigned thanks to Tycho's support for PGP signing with |
|
Thank you for all this information! Very instructive! |
|
FYI, I added this content to the start of this issue: Here is a (hopefully correct) short list of affected projects:
|
What about Platform? |
|
I answered that here: 😱 |
OK, so this ticket is for all projects except platform? |
|
The Platform's own build is affected, i.e, the current RC1 candidate has bad signatures. In fact all projects using the CBI jar signing service yesterday and today are affected. The intent of the list is for the SimRel participants who will need to rebuild yet another new contribution once the new signing certificate is available for the CBI jar signing service. As such, the Platform will need to respin RC1 before contributing that to SimRel on Friday as currently scheduled. |
Do you plan to provide cross-project notification so that we all know that we can start rebuilding Ed @merks ? |
|
Yes, I will break my own rule and send an email when folks can respin. I've seen no updates here: https://www.eclipsestatus.io/incident/373129 As you've probably seen on cross-projects, M3 is canceled so no one needs to lose sleep or hair over this. |
|
FYI, there is currently no ETA for the incident: |
|
so the jar signing service is operational again. We are still working on bringing back the authenticode signing service for windows executables, but it would be great if people can already test the jar signing service and report if everything works as expected. |
I kicked off a CDT build https://ci.eclipse.org/cdt/job/cdt/job/main/400/ - but if the windows signing is still offline the build will probably fail as CDT contains a handful of dlls that need to be signed. |
|
The build is running still (take a long time) but jar signing is happening and windows signing is running without error. I'll try to find time to test and report back once the build is finished later today |
=> looks good |
|
the windows / authenticode service has also been redeployed and should be working again, please test and report. |
|
Thanks @netomi and the IT team! I will close this issue after I've verified that the staging repository no longer contains content signed with the expired certificate. |
|
EMF Parsley should also be fixed now. |
|
Prior to #369 and after so EclEmma should also be fixed now. |
|
I contributed a new build for JGit/EGit: #385 |
|
FYI, I have a little analyzer hacked tougher to read the test output and then produce output like this:
I compare that to the state of the checked items at the start of this issue so I can easily and accurately track the process. I also see all PRs being created and merged, so I know when to check content again. 😁 |
|
It seems this is not fully solved for eclipse RCP 2024-06 The certificate associated to "eclipse.exe" RCP v2024-06 for windows,downloaded from eclipse.org is ok , expiring in 2026-06-21 But when we build an app with tycho v4.0.8 and the Is there a workaround to this problem? thanks |
|
@titou10titou10 I think you are seeing something slightly different. The eclipse.exe discussed in jmstoolbox/jmstoolbox#173 was signed with a valid certificate, and the screenshots show that that the digital signature is ok. I'm not sure what we can do about that unfortunately. Can you ask your user to share the details of the error they are seeing? I'll follow on your issue to see if I can help and if we find something generally useful we can report it back here. |
@jonahgraham I'm not sure to understand your point It is the same if I build, for example DBeaver, another RCP based app (https://github.com/dbeaver/dbeaver) (sorry for the bad quality of the picture)
To be clear, in french: |
|
I don't understand why the screenshot in jmstoolbox/jmstoolbox#173 (comment) is showing valid, but your screenshot is showing invalid. As @mbarbero said in jmstoolbox/jmstoolbox#173 (comment) the thing that matters is when it was signed, not today's date. Your screenshot shows it was signed on 7 May, and that is within the validity dates. When I check the launcher I see the same file size as you, and Windows reports certs as valid. Here is what I checked: Can you check that nothing in your build process is modifying anything after the executables are extracted? |
|
Honestly the build process is very straight forward:
Maybe it is tycho that is modifying the final exe? If you download the artefacts from the action build from github, the JMSToolBox.exe has the same "problem", ie "The digital signature is not valid" : https://github.com/jmstoolbox/jmstoolbox/actions/runs/9598536715 |
|
(Conversation moved back to jmstoolbox/jmstoolbox#173 because the issue is unrelated to #363) |
|
I added some comment in the referenced ticket, I strongly believe the expired signing certificate is just a red herring, the signature of the file is invalid due to a digest mismatch due to the changed icon. This is unrelated to the problems we have been facing with the expired signing certificate to which this issue relates. |
I will edit this description with additional details as they become available.
This issue affects all projects that sign jars, not just SimRel projects.
This issue directly related to the problem is already opened:
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4662
Here is a (hopefully correct) short list of affected projects:
The signing certificate expired May 21, 2024:
Any content signed with this certificate after that date is considered unsigned, e.g.,
We see SimRel staging is badly affected by this:
Note that some shown with strikeout and some are not. That's because some artifacts were signed by the certificate when it was still valid while others are signed by the certificate after is expired.
Here are JUnit-style test results:
https://ci.eclipse.org/simrel/job/simrel.oomph.repository-analyzer.test/lastCompletedBuild/testReport/
The text was updated successfully, but these errors were encountered: