Bugzilla – Full Text Bug Listing
| Summary: | [launcher] Unsigned EXE for Eclipse | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Mike Milinkovich <mike.milinkovich> | ||||
| Component: | Releng | Assignee: | David Williams <david_williams> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P2 | CC: | Andreas.Hoegger, aniefer, daniel_megert, david_williams, gunnar, john.arthorne, kim.moir, Michael_Rennie, mknauer, pwebster, remy.suen, thanh.ha, thomas, tjwatson, webmaster | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | 4.3.1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 319605, 325997, 406157 | ||||||
| Bug Blocks: | 405828 | ||||||
| Attachments: |
|
||||||
Pretty sure this has been raised before but I cna't find the other bug right now. Ya, well it makes us look lame right out of the box IMHO. We have bug 1764339 and 294827 which are about branding vendor information into the exe. I don't recall any bugs about signing the executable. Signing the executable will require support from the foundation. The tools to do this are available from Microsoft, I don't know if this can be done from a linux machine. http://msdn.microsoft.com/en-us/library/aa380259%28v=VS.85%29.aspx#introduction_to_code_signing http://msdn.microsoft.com/en-us/library/aa387764%28VS.85%29.aspx (In reply to comment #3) > We have bug 1764339 and 294827 Sorry, this should be bug 174339 and bug 294827 (In reply to comment #3) > Signing the executable will require support from the foundation. The tools to > do this are available from Microsoft, I don't know if this can be done from a > linux machine. > I opened bug319605 against the foundation to track this. (In reply to comment #5) > (In reply to comment #3) > I opened bug319605 against the foundation to track this. Tom - Looks like webmaster has installed the software and is looking for help to try it out. Are you the guy? (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #3) > > I opened bug319605 against the foundation to track this. > > Tom - Looks like webmaster has installed the software and is looking for help > to try it out. Are you the guy? I have no experience with signing exes. Andrew can you help here. I'm not sure what the next steps are. *** Bug 330929 has been marked as a duplicate of this bug. *** Originally, I was thinking we would just sign the executables at the time they were compiled and put into cvs under the org.eclipse.equinox.executable feature. However, it has been pointed out that branding these executables with an icon would likely break the signature and create a problem for RCP developers. So, I think it is better at this point to just sign the exe in the actual eclipse SDK product. This is the executable contained in the org.eclipse.rcp.configuration_root.win32.win32.x86(_x64)_1.0.0.* binary artifacts which are created by the rc.config/buildConfiguration.xml releng script. Note however that product export without the deltapack will take the launcher from the running eclipse, in that case the exported product would have an invalid signature on the exectuable if it was branded with an icon. We may need to find a way to strip the signature from the executable if possible. Just curious to see if we'll have a signed eclipse.exe for June... Probably not. So any hope of having this looked at for Juno? I haven't' had time to look at this. Priorities right now are 1) Finish Git migration (two repos left) 2) Switch 4.2 build to primary bug 355430 3) Finish getting Eclipse tests running on Hudson The Windows signing service is now available and instructions on how to use it can be found on the wiki at:
http://wiki.eclipse.org/IT_Infrastructure_Doc#Web_service_.28Instant.29
Basically you can push an exe to the service and it'll return the exe signed. Now that the service is available I think this bug can move forward.
Ideally for CBI builds I think we need a Maven plugin which can make use of this service.
The maven plugin would be good, Thanh. Normally, we open a new bug/feature request is there is follow on work to do (hint hint). In fact, I think this is essential, if we are going to do it for Kepler. You would know better than I which "plugin" to "plug in to", but currently we use 3 or 5 plugins to "materialize a product", and we "end up" with the zip. If we had to unzip that, and call the webservice, and put the exe back, re-compute checksums, etc., it'd be a lot of (error prone work). Ideally, I'm sure you know, it'd be nice if the plugin worked "automagically" for windows/mac/linux, etc., without us ever having to think of what was or should be being signed. One issue, that I'm again not very knowledgeable about, if if this effects p2 repos. I _think_ not ... that the exe is never part of the repo ... but others should correct me if I'm mistaken. For the record, I IM'd a bit with Bogdan who confirmed it should be part of the build.eclipse.org build, not part of "his" build before it goes into Git ... otherwise, no one could "customize" the exe with their own icons, or resource strings. (without breaking the signature). Not sure how often people do that ... but ... suspect some do. Thanks Thanh (and Denis?) for providing this service! (In reply to comment #15) > The maven plugin would be good, Thanh. Normally, we open a new bug/feature > request is there is follow on work to do (hint hint). > Or, we could use this same bug ... I thought you closed it as "fixed". But, guess not ... unless I messed that up. (In reply to comment #16) > (In reply to comment #15) > > The maven plugin would be good, Thanh. Normally, we open a new bug/feature > > request is there is follow on work to do (hint hint). > > > > Or, we could use this same bug ... I thought you closed it as "fixed". But, > guess not ... unless I messed that up. I closed bug 319605 which was tracking the service side which is in place now. I think there's at least 2 options for this right now. 1. Use some sort of antrun or similar script to get the exe signed before it's packed. 2. Create a cbi-winsigner-plugin that's similar to the existing cbi-jarsigner-plugin Option 2 is definitely ideal but would need some development time. If we do this for Mac's, for Kepler, could use same "antrun" technique for Windows. There is no way (or at least time) to address Andrew's comment in the last paragraph of comment 9, however. That seems like a fringe case, to me, but perhaps others know better Marking as 4.3 so pros/cons of doing "last minute" can be discussed. Markus, Thomas, adding you for "EPP impact" (if any) ... see also "mac signing" bug 375853. I'm CCing you to see if you know how "EPP Builds" would/could make use of the "executable" from Windows and Mac distributions from the Platform. I know you pull features, etc., from the common repo ... but ... do not think that includes the "executable" per se. So, where's that come from? I'm just thinking ... it does not seem like it does "us" much good to sign these, if they are not used in EPP builds ... so, just wanted to get some confirmation of that, or not, and include you in the discussion. Thanks for any insights. I'm not keen on doing this now in RC2, especially on Windows. It's hard to argue for urgency here when it has always been like this. My main concern is in the intersection of signing and branding. This is not a fringe case, it is anybody building a branded application with Eclipse. If branding is applied to a signed executable the signature will be invalidated. Does an executable with an invalid signature behave any worse than an unsigned executable? Since I believe EPP packages have their own branding, signing just the Eclipse SDK will actually be of minimal benefit because it no longer appears on the main eclipse.org download page and very few people use it directly. In the end it is likely that everyone downstream can adapt to this, but doing it in RC2 gives very little runway. Adding high resolution icons to the executable in M7 last year seemed equally low risk but ended up having impacts that took awhile to fix in PDE and p2. I like the idea of adding this early in Luna (in both Platform and EPP), and then if the roll-out goes smoothly we could consider back-porting to maintenance stream builds. (In reply to comment #20) > I'm not keen on doing this now in RC2, .... I reported this bug in 2010. For three years now it gets ignored until the end of the annual release cycle, and then someone says it's too late for this year. Here we go again. Perhaps we can leave the SDK alone, and include a signed EXE in the EPP packages for Kepler? (In reply to comment #22) > Perhaps we can leave the SDK alone, and include a signed EXE in the EPP > packages for Kepler? Yes the EPP packages are the only thing 99% of users ever download now. There is also much less risk that someone is taking an EPP package as input for a branded product build where signature corruption will become an issue. Ok, I suggest we do this soon in Luna. Perhaps if everything goes swimmingly smoothly, we could back port to Kepler SR1? But, it is essential we coordinate with EPP and other "branders". I have grown increasingly worried about our "hack" to "squeeze this in between" two other steps. Seems fragile and subject to unpredictable behavior. So having an official maven plugin, that is officially "configured" in the right place at the right time in Tycho phases would be much better. As for comment 21 ... you've asked for a lot the past 3 years ... if this is the only thing "ignored" I'd say you have a pretty high success rate :) [We do take it seriously ... I get tired of seeing those little pop-ups too ... the few times I'm not on Linux]. This bug is filed against Platform/Releng and bug 405828 is against EPP. From bug 405828 comment 2 I would have thought that Platform would have maintained two copies of the native binaries -- one signed, one unsigned, and the EPP packages could just consume the signed binary. If Platform doesn't intend on doing any further work here, I suggest we close it as WONTFIX and address the issue purely from the EPP-side of things. I thought EPP was branding the executable with their own icons, but from Markus' comment it sounds like I am wrong. If EPP is consuming our binary directly with no change then it would make more sense (but add some risk) to sign in the Platform build. (In reply to comment #26) > I thought EPP was branding the executable with their own icons, but from > Markus' comment it sounds like I am wrong. If EPP is consuming our binary > directly with no change then it would make more sense (but add some risk) to > sign in the Platform build. They so, at least some branding of icons, etc. (At least the JEE IDE package does) ... but, even if not ... the solution we are talking about here is that we would sign only the executables that went into our platform zipped up packages, not the "binary" that is in the repository ... just for the reason you state. If I understand it right, if we did, then no one could ever "rebrand" the launcher obtained from the repository, which I think is what we wanted to achieve. (In reply to comment #27) > (In reply to comment #26) > > I thought EPP was branding the executable with their own icons, but from > > Markus' comment it sounds like I am wrong. If EPP is consuming our binary > > directly with no change then it would make more sense (but add some risk) to > > sign in the Platform build. > > They so, at least some branding of icons, etc. (At least the JEE IDE package > does) ... but, even if not ... the solution we are talking about here is > that we would sign only the executables that went into our platform zipped > up packages, not the "binary" that is in the repository ... just for the > reason you state. If I understand it right, if we did, then no one could > ever "rebrand" the launcher obtained from the repository, which I think is > what we wanted to achieve. Looking closer at our build code, I should have said, I do not know if the ones in our repository will be signed. Its certainly the intent not to have them signed, so people can make "custom apps", but looking closer at the code I see some of the "repository creation" stuff occurs during "packaging" phase, same as our "hacked in" signing stuff. So, behavior is a little non-deterministic. All the more reason we need a tightly integrated solution with Maven and Tycho, as being discussed in bug 388878 ... anything else is just guessing as to what will happen. David, I think 4.4M3 for MacOS is signed. This is causing troubles down the road in the packages build. Thus, the packages now need to re-sign the binaries. Is this intentional or should the regular Eclipse build not sign launcher? (In reply to Gunnar Wagenknecht from comment #29) > David, I think 4.4M3 for MacOS is signed. This is causing troubles down the > road in the packages build. Thus, the packages now need to re-sign the > binaries. > > Is this intentional or should the regular Eclipse build not sign launcher? Our goal is to sign only the ones in the products we "zip up" and are downloadable from our site ... and not sign the "binary" ones that are in repository or delta pack. I know that was working correctly at one point, but admit didn't check specifically for M3. Let me know if you see signs to the contrary, or if this is just a hypothesis. Not sure why this was never marked as fixed ... even Kepler SR1 was signed. |
Created attachment 173889 [details] Warning dialog on Vista We've invested time in signing all of our plug-ins, but the Eclipse exe is not signed. This results in an annoying dialog when you launch on Vista. Is there a reason why we're not signing our exe?