Hi Denis You wrote:
> On 01/04/2013 04:35 AM, Glyn Normington wrote: >> Scott Lewis <[email protected] <mailto:[email protected]>> 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
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
