damccorm commented on PR #22703: URL: https://github.com/apache/beam/pull/22703#issuecomment-1227349339
Thanks @elink21 and @dannymartinm for laying out the options. @kennknowles this would be a good one to get your input on. I think we should probably ignore scenario 3. That's not a real security boundary and is incredibly easy to circumvent (submit a small doc improvement or more general small fix, then do something malicious). So then the remaining question: is scenario 1 actually problematic. I'd argue that its not, or at least its not a regression from our current security standards because right now the same security risk (someone changes code that has access to secrets) exists in Jenkins. Scenario 2 is a tightening of our current security boundarys that IMO imposes too large of a burden on committers to be worth it. With that said, it does mean that we need to be thoughtful about how/when we pass our secrets into our code and how much risk we're willing to take on (in particular we should be tight about how we scope our GitHub tokens so they don't have arbitrary repo read/write power). I'd vote for scenario 1 here, with the acknowledgement that it comes with some risk if we're not careful. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
