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 >>
