Bugzilla – Full Text Bug Listing
| Summary: | Allow hudson to tag builds in git | ||
|---|---|---|---|
| Product: | Community | Reporter: | Marcel Bruch <marcel.bruch> |
| Component: | CI-Jenkins | Assignee: | CI Admin Inbox <ci.admin-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | denis.roy, sewe, stepper, webmaster |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
| Bug Depends on: | 403843 | ||
| Bug Blocks: | |||
|
Description
Marcel Bruch
(In reply to comment #0) > I don't want > my private keys to reside on the build server somewhere. Why not? Well. Your answer implies "you think that eclipse.org is one of the very safe locations on the planet". If that's true I'll create an extra key and put it somewhere on build.eclipse.org :) I went through the settings of the egit plugin but I didn't found a way to specify my key for checking out (and pushing) changes. Currently I use git://git.eclipse.org/gitroot/recommenders/org.eclipse.recommenders.git as git repository url for read-only check out. I may specify an ssh://<username>... url to specify the right identity. But how can I specify the key then? A simple workaround may be to add jenkins public key to my identities on build.eclipse.org - but I guess this is not the intended solution? Is anyone doing something similar already? Thanks, Marcel (In reply to comment #2) > Well. Your answer implies "you think that eclipse.org is one of the very > safe locations on the planet". If that is what was implied, then I apologize. I asked "why not" in an attempt to get you to articulate why doing such a thing would be a bad idea. In reality, I do think that eclipse.org is one very safe location on the planet. However, enabling a mechanism where a web-accessible application such as Hudson (or Bugzilla, for that matter) can write to our most important resource, our source code repo is, in my opinion, a very bad idea. Should the web software contain a defect that may be exploitable, then it opens the door to anyone on the planet potentially writing into you code repo. Further, if your account on git.eclipse.org has shell access, then it could potentially allow anyone on the planet to gain access to your account (and our servers) via a shell. Not good. From there, a root exploit -- a circumstance where a third party has root access on our servers -- is not a far-fetched possibility. That, to me, is the end of the world. I know many non-sysadmins don't believe such a scenario is possible, or even plausible, but it can happen, and it has happened, most recently to kernel.org. Since I don't want this to happen to eclipse.org, I please ask you to not enable Hudson, or any other web app, to modify source code. This is inconvenient for you, and I realize that... however, having our source code or servers compromised is not a pretty alternative. Hi Marcel, I think tagging the sources is something that should be done during the promotion process (the copying from build.o.e to download.o.e). Usually this has to be done under your own user ID, too. We've created a cron job that does all the promotion stuff for us, e.g., copy the build, tag the sources, generate release notes, help center, api reports, etc. Let me know if you're interested in more details... (In reply to comment #5) > We've created a cron job that > does all the promotion stuff for us, e.g., copy the build, tag the sources, > generate release notes, help center, api reports, etc. > > Let me know if you're interested in more details... Yes we are! We are "not that pleased" with our current approach. We have three target platforms (e37, e42, e43) to support and (almost) four releases for each target platform (head, developer, stable, and simrel builds). Our dependencies are scattered over three different update sites (simrel repo, orbit, and our third-party repo). Release notes and such things are not generated but would be nice to have. I wondered how other projects manage all this for their projects - and having more insights in how others do a release would be greatly appreciated. Thanks, Marcel I've added some explanation to bug 339472. I'll be happy to answer questions there... If you request a HIPP instance (see bug 403843) this is now possible. without putting any private keys on the server? +1. we apply. |