-
Notifications
You must be signed in to change notification settings - Fork 19
Please sign the binaries #70
Comments
Question for @nickboldt |
@elharo so apparently this is not gonna happen, as we have some resource constraints at Red Hat. |
I'd be quite surprised if JBoss/RedHat were willing to give Google access to its private keys to sign these things. On our end it's not hard technically, an engineer week or so, if that. Probably less since we could copy and paste a lot of what we already did. We've done it for our own plugins such as Cloud Tools for Eclipse. However that requires access to some internal systems that aren't available externally. |
I think what Fred is suggesting is that you could build the bits with YOUR key, not ours. All you need from our end is to clone this repo and build it in your own Jenkins, perhaps forking the code to enable signing if it's done like Eclipse.org does it with a maven mojo. The other option would be to contribute m2e-apt to the Eclipse Foundation and build there, on the m2e JIPP w/ the Eclipse jar signing mojo. Other than the annoyance of having to click "Install Anyway", does signing the jars solve any technical problem for you? Is it just a UI nice to have, or something more? |
moving m2e-apt to the EF is one solution of course, but I dread the red tape involved with the move |
actually since m2e-apt is a dependency of jdt.ls, we're probably supposed to sign it from the EF servers anyway. I'll have to look into that |
If we signed with our own key, we'd then have to push our version to the Eclipse Marketplace; and I really don't want to fork or maintain it. Even more importantly, before I signed it, I should be confident in its code. Right now I know nothing about the code, and can't meaningfully vouch for it. |
@rgrunber if we added m2e-apt to orbit, because it's an eclipse.jdt.ls dependency, we'd have to sign it, right? |
Yes, all bundles distributed by Orbit at Eclipse would get signed automatically. However it's rare to host Eclipse plugins. Generally Orbit hosts 3rd party libraries (often lacking OSGi metadata), but it might not be the first time for such an approach. However, @nickboldt is right. You could easily set up a signing service on your build servers. In the past I've used http://codeandme.blogspot.com/2017/04/host-your-own-eclipse-signing-server.html to set up a basic local signing service for testing certain capabilities that required signing. |
I would also be interested in consuming signed binaries of this project... :-) |
m2e-apt's code is now included in https://github.com/eclipse-m2e/m2e-core , please consider reporting issue to https://github.com/eclipse-m2e/m2e-core/issues if it's still relevant. |
The text was updated successfully, but these errors were encountered: