Re: [cross-project-issues-dev] cross-project-issues-dev Digest, Vol 84,

[Glyn Normington <gnormington@xxxxxxxxxx>]

Hi Denis

You wrote:

On 01/04/2013 04:35 AM, Glyn Normington wrote:

Scott Lewis <slewis@xxxxxxxxxxxxx <mailto:slewis@xxxxxxxxxxxxx>> wrote:

Hi Folks,

Until recently, (ECF) has been signing our plugins by 'pushing' our

plugins toeclipse.org <http://eclipse.org/>(built on our own builder 

machine...which is

*not* running ateclipse.org <http://eclipse.org/>).   Apparently this 

is not the appropriate

way now...rather what Denis indicated was appropriate was to have an

eclipse.org <http://eclipse.org/>machine 'pull' our unsigned plugins, 

sign them, and then put

the signed versions somewhere.

I assume that other projects do some/all of their build on non-eclipse

systems...and need to do this as well.  Are there ant scripts and/or

documentation on this 'pull' approach for signing?

I'm puzzled by the idea of a machine at eclipse.org 

<http://eclipse.org> pulling from a build machine running, for 

example, behind a corporate firewall. Maybe someone could clarify what 

Denis might have been meaning.

If the remote build machine is behind a corporate firewall, it is not 
accessible anonymously by everyone on the planet and is being actively 
maintained by IT staff, then that gets my two thumbs up. By all means, 
put your committer ID's private key there and push all you want.

Thanks for the clarification. (In the case of Virgo, we use our own machines for building, so security of committer private keys is already a given.)

On the other hand, if your remote build machine is running a publicly 
web-accessible CI system with an open-to-the-world SSH port, I don't 
feel that the private key to your shell-enabled eclipse.org account is 
in a safe location.  This is consistent with my position regarding 
committer private keys on our own publicly web-accessible Hudson instance.

If committers really feel that the our CI system should have the ability 
to push commits to Git and push builds to the downloads area via a 
committer's account (and I agree, this would be immensely convenient), 
then we could perhaps consider closing hudson.eclipse.org to the 
anonymous users, thus requiring a committer account and authentication 
to access Hudson?

Although I can see that some projects might want to use Hudson in this way, I wonder if any non-committers look at Hudson job status to get a feel for the stability of a project and would really miss being able to access that? In that case, if the risk of exposing the ssh port to the world is that someone will run a password cracking tool against it, would it be possible to allow HTTP traffic to Hudson but restrict the SSH access to requiring a committer's private key to authenticate?

Regards,

Glyn