m2e-apt icon indicating copy to clipboard operation
m2e-apt copied to clipboard

Please sign the binaries

Open elharo opened this issue 6 years ago • 11 comments

image

elharo avatar Nov 16 '18 17:11 elharo

Question for @nickboldt

fbricon avatar Nov 16 '18 18:11 fbricon

@elharo so apparently this is not gonna happen, as we have some resource constraints at Red Hat. But if Google is interested in hosting the build and sign the jars, we could maybe work something out.

fbricon avatar Nov 19 '18 15:11 fbricon

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.

elharo avatar Nov 19 '18 15:11 elharo

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?

nickboldt avatar Nov 19 '18 16:11 nickboldt

moving m2e-apt to the EF is one solution of course, but I dread the red tape involved with the move

fbricon avatar Nov 19 '18 16:11 fbricon

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

fbricon avatar Nov 19 '18 16:11 fbricon

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.

elharo avatar Nov 19 '18 16:11 elharo

@rgrunber if we added m2e-apt to orbit, because it's an eclipse.jdt.ls dependency, we'd have to sign it, right?

fbricon avatar Nov 19 '18 16:11 fbricon

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.

rgrunber avatar Nov 19 '18 16:11 rgrunber

I would also be interested in consuming signed binaries of this project... :-)

martinlippert avatar May 27 '19 09:05 martinlippert

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.

mickaelistria avatar Feb 17 '22 20:02 mickaelistria