So from a technical perspective - we can not limit access to specific branches. There isn't much granularity in the ACLs for Github - essentially we have to give away write access to the repo.
Our site building tools, which we've written only write to a specific branch - but that's a tool that we control, as opposed to the CI tools. But again - the prohibition on write access to repos is not a technical or policy position of Infrastructure, it's one that's set by VP, Legal. --David On Tue, Feb 4, 2020 at 3:51 AM Dave Fisher <[email protected]> wrote: > > Hi David, > > Does the idea of having a branch that does the CI like ash-site help out in > this situation. > > If these workflows write into a branch that is always copied to and never is > merged back then we would be good. It seems like we can track all “3rd party” > commits in the gitbox and have a chance to see about the source of changes > and flag anything questionable. > > Regards, > Dave > > > On Feb 3, 2020, at 6:37 PM, David Nalley <[email protected]> wrote: > > > > Hi Alex, > > > > So this was explored. It creates some problems - first double the > > administration overhead - most of that is automated, but it means that > > our API usage doubles, and we're already hitting limits from Github. > > > > Second - at least one CI vendor thanked us for not doing that exactly > > - because the 'best' way to do it is to create an org per project or > > org per repo - and then the free tier is dedicated to that org. Except > > that's essentially abusing their free tier. > > > > Finally - from a practical perspective, if everyone submits PRs and > > does testing against this apacheci org - that has become the de facto > > repo - it's where everyone is doing their work, and it makes > > provenance tracking. > > > > As an aside - the mandate for no write access is not an infrastructure > > policy, it's a legal affairs requirement - we're merely implementing > > it. > > > > --David > > > > On Tue, Feb 4, 2020 at 3:24 AM Alex Harui <[email protected]> wrote: > >> > >> Moving board@ to BCC. Attempting to move discussion to builds@ > >> > >> I’m fine with the ASF maintaining its position on stricter provenance and > >> therefore disallowing third-party write-access to repos. > >> > >> A suggestion was made, if I understood it correctly, to create a whole > >> other set of repos that could be written to by third-parties. Would such > >> a thing work? Then a committer would have to manually bring commits back > >> from that other set to the canonical repo. That seems viable to me. > >> > >> A concern was raised that the project might cut its release from the > >> “other set”, but IMO, that would be ok if the release artifacts could be > >> verified, which should be possible by comparing the canonical repo against > >> the “other repo”, at least for the source package, and if there are > >> reproducible binaries, for the binary artifacts as well. > >> > >> Thoughts? > >> -Alex > >> > >> From: Greg Stein <[email protected]> > >> Reply-To: "[email protected]" <[email protected]> > >> Date: Monday, February 3, 2020 at 5:17 PM > >> To: "[email protected]" <[email protected]> > >> Subject: Re: [CI] What are the troubles projects face with CI and Infra > >> > >> On Mon, Feb 3, 2020 at 6:48 PM Alex Harui > >> <[email protected]<mailto:[email protected]>> wrote: > >>> ... > >> How does Google or other non-ASF open source projects manage the > >> provenance tracking? > >> > >> Note that most F/OSS projects don't worry about provenance to the level > >> the Foundation worries. That affords them some flexibility that our > >> choices do not allow. Those projects may also choose to trust tools with > >> write access to their repositories, hoping they will not Do Something > >> Bad(tm). We have chosen to not provide that trust. > >> > >> IMO, I do not think the Foundation should relax its stance on provenance, > >> nor trust in third parties ... but that is one of the key considerations > >> [for the Board] at the heart of being able to leverage some third party > >> CI/CD services. > >> > >> Cheers, > >> -g > >> >
