So I went and poked around. I had been messing with the idea of a Forge replacement a couple months ago until GUI took most of my time. I had toyed with GitHub token authorization as the mechanism to validate identity. I mean, if saz-ssh comes from github.com/saz, and an admin is there to auth the user (cuz we can just ask him directly), then you accept their access token, and they are now approved for publishing to the forge. This gets onerous when the author count goes up. Using Personal Access Tokens from GitHub seemed a way to go, so I prompted up a forge of my own to auth against GitHub. I built a quick PoC back then. I went ahead and updated all the components, imported as much of the Puppet forge as I had room for (so most recently modified), and deployed to a server for playing with. It's nowhere near ready for primetime, but the GitHub Personal Access Token mechanism works. and it doesn't look half bad. I didn't "SSL-ify" the thing, so it's listed as "Not Secure", but it's what I had in mind at the time. Yes, it's AI. No, I don't care. 😄 It makes a great MVP from which to start in earnest, and the GitHub auth works. voxforge.questy.org When I posed the problem, the rationale for the GitHub mechanism I was given was this (segments copy/pasted due to secrets mechanisms and file locations included in explanation):

Threat model
If VoxForge is the r10k/g10k source of truth, open self-registration as puppetlabs / saz / etc. is a supply-chain MITM risk. Publish rights are now tied to proven identity, not "I picked that username."

Create a GitHub OAuth App with that callback URL, then add the secrets to <filename/location> Until then, github_enabled is false and only password login shows (admin-only registration mode).

Validation / authorization
1. Forge username = GitHub login on OAuth (no arbitrary namespace spoofing).
2. can_publish only after GitHub verification (or admin grant).
3. Authorized namespaces — default = GitHub login; extras via:
   • Admin grant in Members UI, or
   • POST /api/members/claim-namespace with org membership / push access to namespace/repo.
4. Catalog mirrors (forge-sync authors): is_mirror=true, no password, cannot log in or publish until claimed with matching GitHub login. On <http://questy.org|questy.org> now: 493 mirrors, 1 publisher (admin).
5. POST /v3/releases rejects anyone who isn't active + authorized for that owner namespace; claiming a mirror-owned module reassigns ownership to the verified member.

Ops note
Wire GitHub OAuth credentials on the server when you want community self-service. Until then, only admin can publish; everyone else in the catalog is a read-only mirror identity, which is the safe default for a public forge.

I don't expect my stuff to be used directly, but it's a PoC that works and gives us a practical example of a way to keep our forge out of a MITM vulnerable situation