Skip to content
This repository has been archived by the owner on Feb 18, 2022. It is now read-only.

Please sign the binaries #70

Open
elharo opened this issue Nov 16, 2018 · 11 comments
Open

Please sign the binaries #70

elharo opened this issue Nov 16, 2018 · 11 comments

Comments

@elharo
Copy link

elharo commented Nov 16, 2018

image

@fbricon
Copy link
Member

fbricon commented Nov 16, 2018

Question for @nickboldt

@fbricon
Copy link
Member

fbricon commented Nov 19, 2018

@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.

@elharo
Copy link
Author

elharo commented Nov 19, 2018

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.

@nickboldt
Copy link
Member

nickboldt commented Nov 19, 2018

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?

@fbricon
Copy link
Member

fbricon commented Nov 19, 2018

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

@fbricon
Copy link
Member

fbricon commented Nov 19, 2018

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

@elharo
Copy link
Author

elharo commented Nov 19, 2018

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.

@fbricon
Copy link
Member

fbricon commented Nov 19, 2018

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

@rgrunber
Copy link

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.

@martinlippert
Copy link

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

@mickaelistria
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants