Yes, in terms of security, it would be the same as a separate Jenkins login. But this would be much easier to use/manage IMO, both for contributors as well as admins.
On Wed, Dec 14, 2016 at 2:00 PM, Jim Apple <[email protected]> wrote: > I do not understand the proposed security benefit of using github for > user authentication over using Jenkins permissions directly. Keep in > mind that preventing non-+2ed commits from being run is an orthogonal > question - this can be configured with any user authentication method. > > On Wed, Dec 14, 2016 at 1:52 PM, Bharath Vissapragada > <[email protected]> wrote: > > That was just for configuring the gerrit trigger. Regarding auth > > integration, I read this page. Does it not work? > > > > https://wiki.jenkins-ci.org/display/JENKINS/GitHub+OAuth+ > Plugin#GitHubOAuthPlugin-AboutGitHubAuthenticationPlugin > > > > On Wed, Dec 14, 2016 at 1:50 PM, Jim Apple <[email protected]> wrote: > > > >> I think you're misunderstanding that plugin. It does not associate > >> Jenkins login with gerrit login. > >> > >> On Wed, Dec 14, 2016 at 1:45 PM, Bharath Vissapragada > >> <[email protected]> wrote: > >> > On Wed, Dec 14, 2016 at 1:38 PM, Alex Behm <[email protected]> > >> wrote: > >> > > >> >> That integration sounds like a great idea to me. > >> >> > >> >> Just to clarify the purpose: We'd like external contributors to be > able > >> to > >> >> run private build+test runs during development, and not just run GVO > >> once > >> >> the patch has +2. The hard part is gettig the patch to +2 in the > first > >> >> place and we've seen instances where relying on local test runs only > >> can be > >> >> difficult. > >> >> > >> >> For example, contributors could upload a draft to gerrit and run a > >> private > >> >> build to fix problems before publishing the patch fir review. > >> >> > >> > > >> > As per this [1] link, I think that can be configured. I haven't tried > it > >> > myself, but from the looks of it, it seems plausible. > >> > > >> > [1] > >> > https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+ > >> Trigger#GerritTrigger-TriggerConfiguration > >> > > >> > > >> >> > >> >> On Wed, Dec 14, 2016 at 1:33 PM, Bharath Vissapragada < > >> >> [email protected] > >> >> > wrote: > >> >> > >> >> > 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. > >> >> > > > > > > > > >> >> > > > > > > > >> >> > > > > > > >> >> > > > > > >> >> > > > > >> >> > > > >> >> > > >> >> > >> >
