> On Feb 21, 2023, at 12:59 PM, Nick Dimiduk <ndimi...@apache.org> wrote:
>
>
> Thanks for the write-up Alan. I’ll think about this a bit… it seems odd to
> me that pre-commit should rely on a “system in the middle”. On the other
> hand, GitHub has clearly designed their system of interaction around a web
> service running on the other end of those tokens.
Yup: that’s the core of the problem. When github support was first
added, username/password combos were the authentication method. Those were
obviously permanent. They’ve slowly been changing that to be what it is today
where they want a webservice. It’s obviously more secure but it also makes
things easier for them. If we want to get into the business of providing our
own web app we can certainly do that but that introduces a whole host of new
problems and likely really only fits the needs of a few edge case users. The
flip side is that we could form a new company that could compete with various
other cloud providers and then retire after the company gets acquired. :D
> Just for brain-storming, what if the current use of `GITHUB_AUTH` was
> replaced with a function call? This would give each step in the test-patch
> lifecycle a chance to “call-back” into the auth provider mechanism and
> renew its token. We could provide a “static” implementation that simply
> returns the existing array, and a “refreshing” version that generates a new
> token each call. This would be made intentionally pluggable, so a
> personality or some other robot system could override the behavior as they
> require.
>
> What do you think?
The only big concern I’d have is how messy bootstrapping gets (not that
it is great now haha) since parameters and personalities may not have gotten
loaded in yet. (e.g., robots.d/*) But that can probably be dealt with so long
as a valid token is presented early on and it is strictly renewal since that
doesn’t need to happen until well after bootstrap.
When github broke username/password auth, I looked at what needed to
get done for the various CI systems and noted that _none_ of them had a way to
trigger token renewal in any way that would work for precommit (either didn’t
offer it or was locked away like the Jenkins example). So I gave up on that
and wrote the helper. But if someone is running Github Enterprise on-prem,
they likely have an external auth system anyway where that may be more viable.
It may also be time to do a new survey of the various CI systems and see if
they offer better support. (I think that code was written 2-3 years ago? That’s
forever in Internet Time.)
