Community
Participate
Working Groups
For example, the following does not contain signed executables: https://download.eclipse.org/eclipse/updates/4.12/R-4.12-201906051800/binary/org.eclipse.platform.sdk.executable.win32.win32.x86_64_4.12.0.I20190605-1800
Ed, have you checked if this is a regression in 4.12?
No, I'd have to go back and find out which one stopped being signed, but I will start that process now.
(In reply to Ed Merks from comment #2) > No, I'd have to go back and find out which one stopped being signed, but I > will start that process now. Thanks Ed. Unfortunately p2/maven is not my field of expertise, so I can't help here.
Indeed, this one was signed: https://download.eclipse.org/eclipse/updates/4.11/R-4.11-201903070500/binary/org.eclipse.platform.sdk.executable.win32.win32.x86_64_4.11.0.I20190307-0500 So yes, this problem is new to 4.12.
Yes, I'm not a Maven/Tycho expert either. :-( So I'm not sure which build step has gone astray...
Dani, Sravan: if this is "just" some missing maven /tyche flag / script change & rebuild, should we consider this for 4.12 final, or is this too late? Sounds like a serious issue.
At least eclipse.platform.releng.tychoeclipsebuilder/platform/pom.xml has a eclipse-sign profile. Apparently this profile is not run (anymore), maybe some missing option when the build is triggered?
(In reply to Ed Merks from comment #5) > Yes, I'm not a Maven/Tycho expert either. :-( > > So I'm not sure which build step has gone astray... IIRC during 2019-03 both Xtext and OCL had a rogue unsigned plugin. Problem went away with a rebuild. Seems like an intermittency somewhere.
Sravan, please have a look.
We need to find out how it actually impacts users and since when this is the case. NOTE: The executable in our downloads, including EPPs are signed.
NB. Previously it was a one-off. Just one plugin in just one build. You need to look at precisely the problem build to see the problem.
Note that on this page currently: https://www.eclipse.org/downloads/packages/ almost 3,000,000 people have downloaded the installer. The most popular package was download about 500,000 times. So most people install using the installer (and on windows that contains an unsigned eclipse-inst.exe) and will end up with an unsigned eclipse.exe for their 2019-06 installations too. Also, people updating their existing installation will end up updating to an unsigned eclipse.exe; the IU containing it has a new version number. As such, if having an unsigned exe is a problem, a majority of the people will have that problem. That being said, my Windows 7 Pro system has never complained that it's running an unsigned executable, so I don't know how much of a problem this really is...
(In reply to Dani Megert from comment #10) > We need to find out how it actually impacts users and since when this is the > case. > > NOTE: The executable in our downloads, including EPPs are signed. The original discussion started on mailing list was about slow startup due MS defender antivirus checks, and there was a suspect that this could be related to not signed executable. Ed, is this possible to replace executable created by Oomph (not signed because from p2 update site) with the signed one from SDK (not sure if p2 will cry because they differ) and check if this would have any effect on startup time?
I've personally seen no indication that would lead me to believe that a signed versus an unsigned executable has a performance impact. My newer installations seem no slower to launch than the older ones. But I have in the past specifically disabled virus checking for some directories to avoid p2 update/director problems, e.g., locking of files that prevent them from being moved. Unfortunately I'm traveling this week (in Ottawa at the Eclipse board meeting) and will be minimally available before next week. So I'm not in a position to run extensive tests on the performance impact... It seems to me that lack of signatures is kind of in and of itself a problem, even if there is no performance impact. But I don't know the real "importance" of signatures to the Windows community...
When I install N-builds or third party software, I have to reassure an Eclipse popup that I really want to proceed with the install. Presumably there is at least a risk that users will have to reassure Eclipse that an unsigned Eclipse is a sound Eclipse.
(In reply to Andrey Loskutov from comment #13) > (In reply to Dani Megert from comment #10) > > We need to find out how it actually impacts users and since when this is the > > case. > > > > NOTE: The executable in our downloads, including EPPs are signed. > > The original discussion started on mailing list was about slow startup due > MS defender antivirus checks, and there was a suspect that this could be > related to not signed executable. Most likely unrelated, see https://www.eclipse.org/lists/platform-dev/msg01728.html.
Created attachment 278991 [details] Signature check log I went through platform build process and I found that platform signs the launcher only while preparing the product (SDK, platform and equinox runtime). Unsigned launcher executables are published in the repo. It is the client's responsibility to sign them. I did a signature check on the executables published from 4.4.2 onward(in the repo) and found none of these are signed. See attached log
Created attachment 278994 [details] Signature check log Updated signature check log
Hmmm, I was pretty sure I found digital signatures in older repos, but now I can't verify that either. They all have the same name, so easily confused with each other. So I suppose it must have been this way for a long time (forever) making it less worrisome. Nevertheless, the repositories are supposed to contain signed content and installations are created from that signed content, so if executables are not signed in the repository, it's not possible to create an installation with a signed executable from that (nor will updates update to contain a signed executable). Of course the client (being the installer or p2 director) is not able to sign the executables that it downloads from a p2 repository so the signature has to come from the original source; that's the whole point of digital signatures. So it seems to me it is necessarily the producer's responsibility to sign the executables also in the p2 repositories. It may well be that this has been overlooked in the past, but that doesn't mean it should therefore be overlooked in the future. That being said, if no one actually cares (no one complained up to now after all), and/or if folks are going to actually argue that it's okay to not have signed executables in the p2 repository (which seems highly suspect to me), there's simply no reason for me to care personally. After all, obviously the neither installer (nor p2 updates and p2 director) can sign them while they're being installed and it can't change any repository's contents so it can't be responsible for whether the executables are signed or not; that must be the repository producers responsibility...
I created a new repo with signed windows launchers. Is it possible for you to test? https://download.eclipse.org/eclipse/updates/4.12/signed-R-4.12-201906051800/
Thanks for investigating! My first attempt installed the wrong thing because the IU version hasn't changed. My second attempt in a completely clean user environment with mirroring disabled failed with this message: ERROR: org.eclipse.equinox.p2.engine code=0 session context was:(profile=D__test-sign_sdk-latest_eclipse, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=). ERROR: org.eclipse.equinox.p2.artifact.repository code=0 Failed to transfer artifact canonical: binary,org.eclipse.sdk.ide.executable.win32.win32.x86_64,4.12.0.I20190605-1800. ERROR: org.eclipse.equinox.p2.artifact.repository code=13 Retry another mirror ERROR: org.eclipse.equinox.p2.artifact.repository code=0 Problems downloading artifact: binary,org.eclipse.sdk.ide.executable.win32.win32.x86_64,4.12.0.I20190605-1800. ERROR: org.eclipse.equinox.p2.artifact.repository code=1203 SHA-256 hash is not as expected. Expected: 26ebb46bd9891901053ba091af6f6384a0e40cc7e027c2b63a0cb14ef50f4cfd and found b231baef80c217b264e163cbfefef781d2d0dcac9d256869392b3327f41be00a. ERROR: org.eclipse.equinox.p2.artifact.repository code=13 Retry another mirror That looks like a mismatch in the artifact metadata's hash and the actual hash...
I updated the metadata now. Can you try again?
@Ed, Since this problem is not a regression, can we release 4.12 today? We will take care of this in 4.13
Yes, I talked to Dani just now too, and given it's been this way for a long time, I see no reason to hold up the release for a long existing problem. I'll will try again and get back to you shortly.
Yes, with that repo the installer now produces an installation with a signed eclipse.exe and an signed eclipsec.exe. During the next release cycle we can investigate how a signed version of these will affect the downstream builds. After all, the eclipse.exe is generally branded, which changes its contents, which I think it implies it needs to be resigned at that step... Thanks again for taking such prompt action!!
Since this is no longer a blocker I am closing this bug and raised Bug 548431 to track windows signing issue.
