search

mika / jenkins-debian-glue

Scripts for Debian package/repository handling inside Jenkins
MIT License
131 stars 91 forks source link

let reprepro handle incoming itself #43

Open anarcat opened 11 years ago

anarcat commented 11 years ago

We are getting into a sensitive security issue here. We would like to allow people to create their own build jobs, but not be able to upload packages to all parts of a repository.

Basically, we want Jenkins to behave like a regular uploader: sign its packages and put them in incoming/, then reprepro can pick them up and decide, according to repo-wide policy, whether the upload is allowed.

Our workflow is that we like Jenkins to create automatic packages in testing and unstable, but we want a manual peer review before the package is pushed to stable.

The only way I can think of doing this is making the repository owned by a different user than the jenkins user and allow jenkins to upload only in ./incoming.

It also needs to sign its keys.

How does that idea sound to people here?

anarcat commented 11 years ago

The patch is also in our repo, at:

git://git.koumbit.net/jenkins-debian-glue.git

Commit 49721286.

mika commented 9 years ago

Sorry for not responding in this issue, I'm wondering whether that's a use case more people would like to see support? (I personally don't have this use case and I think most folks who need that implement this in a specific repos/upload job as needed on their own, so I'm unsure whether it's worth supporting it straight from j-d-g.)

Centuriondan commented 8 years ago

For Devuan we need also some way manage our official builds, but our approach is probably going to control who can build the packages for the official release branches using our custom integration with gitlab via devuan-releasebot.

We're also toying with filtering the "release" parameter (we use "codename" in our setup) to drop anything from the first hyphen on, so that we can build a -proposed or -proposed-updates or -updates against the official repository.

Centuriondan commented 6 years ago

One way to do add acl's would be to set an Environment variable in the source job based on gpg signature of the HEAD commit - if it's signed by someone trusted, then set the output to the trusted path, but if it's unsigned or signed by a someone not in the trusted group, send it to the /incoming queue.