Hi Greg, Stephen,
I think I do need what Greg said: the bot should be able to commit like I can
now. AFAICT, Maven's release plugin does pushes to Git as it is doing its work
so there isn't a clean way to stop until the RM verifies.
I still don't get why allowing a bot to commit to a Git repo isn't auditable.
The changes should all be text and sent to commits@ and the RMs job is to
verify that those commits are ok before putting the artifacts up for vote. I'd
even try to make an email rule that checks for commits from buildbot and flags
changes to files that are outside of what we expected.
Royale's problem is only partially getting folks up to speed. The issue behind
this request is that the 3 folks we got up to speed still couldn't get Maven to
run without intermittent failures. It doesn't appear to be a Maven issue, it
seems to be a network bandwidth issue, so having a "single computer" that is
known to have good connectivity to Nexus and dist and Maven Central would be a
huge win for us.
Thanks,
-Alex
On 1/7/19, 7:19 AM, "Greg Stein" <gst...@gmail.com> wrote:
On Mon, Jan 7, 2019 at 8:39 AM stephen.alan.conno...@gmail.com <
stephen.alan.conno...@gmail.com> wrote:
> On 2019/01/07 14:35:08, Greg Stein <gst...@gmail.com> wrote:
> > On Sun, Jan 6, 2019 at 10:20 PM Alex Harui <aha...@adobe.com.invalid>
> wrote:
> > >...
> >
> > > All commits, even PR's from non-commiters accepted by a committer are
> > > supposed to be reviewed, AIUI. So if the bot makes a commit to the
> repo,
> > > the PMC is responsible for reviewing it. In Royale's case, the bot
> should
> > > only be changing pom.xml files and making tags and branches, so a bad
> bot
> > > commit should be easy to spot and detection may even be tool-able.
> > >
> >
> > Git does not have path-based authorization, so there is no way to
> restrict
> > a bot from changing *code*. Give it access to pom.xml, and it has access
> to
> > the entire repository. "But the bot won't do that" ... Well, the bot is
> not
> > auditable by Legal Affairs or Infrastructure, so there is no way to
> > validate it is committing Properly.
>
> The bot doesn't need commit access to gitbox... it needs commit access to
> *a* git repo. The RM then pulls the tag from that repo and pushes it
*after
> review* back to gitbox.
>
> And there's your auditability for you ;-)
>
Then make that git repo a local clone, hmm?
If you're talking a public one, then what is the "ask" from Infra for this
repo? Every PMC can self-serve create git repositories as they need them.
So it would seem "do that", then you'd need to ask for some extra authz to
enable the bot for that one repository? And what is the mechanism to
prevent leakage of released code into that repository? Or, say, the bot
adjusting pom.xml to pull in malware from $bad ?
Cheers,
-g
