Just wondering why we can't link Jenkins authentication with gerrit login in this case instead of having two separate login credentials. That way we can retain the audit trail of the jobs and also isolate Jenkins to only run code thats approved (+2ed) over gerrit. With this, any new contributor (whoever has signed up on gerrit) can have access to the jenkins box and we can be sure that they only run the stuff that is approved by committers. Thoughts?
* I'm not totally sure if such an integration is possible but I did a quick search and I got a feeling that shouldn't be difficult. On Wed, Dec 14, 2016 at 1:18 PM, Taras Bobrovytsky < [email protected]> wrote: > I would be more in favor of starting with open access instead of having to > hand out credentials. It's both less work for us and it makes it easier to > contribute. If we notice that this is not working well, or gets abused, we > can switch to what Tim is suggesting. Also, we should be able to see who is > using our Jenkins by looking at Gerrit (because the patch must be uploaded > to Gerrit before starting a build). > > On Wed, Dec 14, 2016 at 10:57 AM, Alex Behm <[email protected]> > wrote: > > > I'm fine with Tim's approach, but it does add some friction to > > contributions. > > > > On Wed, Dec 14, 2016 at 9:57 AM, Tim Armstrong <[email protected]> > > wrote: > > > > > I mean the contributor could email an email address (e.g. a mailing > list) > > > asking for credentials and we could email them privately. > > > > > > Do we know what other Apache projects do for situations like this? > > > > > > On Wed, Dec 14, 2016 at 9:18 AM, Alex Behm <[email protected]> > > wrote: > > > > > > > Can you clarify the "credentials by mailing list" approach? > > > > > > > > If we send out the credentials on a public list, it's pretty close to > > > open > > > > access. > > > > > > > > If we send out credentials to contributors privately, we have an > > > additional > > > > hurdle to contributions. > > > > > > > > On Wed, Dec 14, 2016 at 9:12 AM, Tim Armstrong < > > [email protected]> > > > > wrote: > > > > > > > > > Got it. > > > > > > > > > > I think I'd probably be more in favour of handing out login > > credential > > > to > > > > > contributors on demand (e.g. by mailing a list) rather than having > > > open > > > > > access, just so we have a clearer idea of who's using it. I don't > > have > > > a > > > > > strong objection to the alternative. > > > > > > > > > > On Wed, Dec 14, 2016 at 8:52 AM, Jim Apple <[email protected]> > > > wrote: > > > > > > > > > > > > How isolated is the Jenkins instance? > > > > > > > > > > > > As far as I know, the workers have little access to the > > coordinator. > > > > See > > > > > > here: > > > > > > > > > > > > https://wiki.jenkins-ci.org/display/JENKINS/Slave+To+ > > > > > Master+Access+Control > > > > > > > > > > > > This flag is on and there are no whitelisted exceptions. > > > > > > > > > > > > > Does the jenkins user have many privileges on the VM? > > > > > > > > > > > > They have passwordless sudo on the worker > > > > > > > > > > > > > Could it simply wipe > > > > > > > out the job history to destroy the trail? > > > > > > > > > > > > Job history is stored on the coordinator. > > > > > > > > > > > > > Jenkins also presumably has > > > > > > > credentials to make at least some changes to gerrit - are those > > > > > > privileges > > > > > > > restrictive enough that it couldn't cause problems there too? > > > > > > > > > > > > Those are stored only on the coordinator and cannot be used by > the > > > > > slaves. > > > > > > > > > > > > > > > > > > > > >
