I am not sure what the goal is, but you can also generate auth keys inside the client. Then send the public key to the canister where it gets signed and returned. To verify, we make a call with the auth keys and the signature - chain. Then the canister can do the chain verification or the IC. Bonus: private key never leaves the client and doesn’t travel through the network.
My motivation for writing this is to figure out if this is a viable authentication method to use for existing Git clients that want to talk to Codebase. Since I don’t control the client at all I’m looking at solutions they support.
It wasn’t much work, and I thought having something concrete to talk to would help move things forward.
For example, @bjoern pointed out:
Also, @oss asked:
This will need max security. Someone being able to inject malicious code into repositories will be pretty dangerous. I won’t mind running a localhost daemon gateway to avoid that. Then a canister will rely on the caller principal for auth.
Of course.
I think it’s been helpful to poke holes in all the ways auth tokens fall short so I can later refer back these points and say “this is why we need to do this other thing instead of what people normally do”
I think running a gateway locally on the developer machine as suggested by @infu may be a great solution, as we can probably expect developers to do such a thing whereas the same may be difficult for arbitrary users. Something like: use a custom protocol between gateway and canister for writes, have the gateway use proper IC ingress/query messages and the canister depend on the authenticated caller principal. The plain HTTP protocol may still be nice for cloning publicly accessible repositories without authentication.
I really love your project @paulyoung and I am sitting on the waitlist, eager to try it out!
The first lines of code I wrote for Codebase were for a local proxy server to serve as a remote for Git to interface with 
I moved on from that once http_request seemed viable.
In addition to helping with authentication there are some other benefits to having a local server such as it being a mechanism to address certain concerns, e.g. limitations with HTTP uploads that sounded like they might get addressed with the help of boundary nodes
There’s definitely a trade-off though; it’s more work for myself and for end users.
With some insight from @domwoe I think Codebase can easily support verifying signed commits. That doesn’t help with authentication in general though.
Yeah … a proxy obviously isn’t ideal since it’s another component that has to be kept functional and there’s again a question of storage of private keys – although here one probably doesn’t have to care too much about backup since there’s always some fallback authentication via the UI.
Unfortunately, a lot of Web2 security is based on (unnecessarily) sending secret stuff from A to B – that has never been a good idea even in Web2 but it really breaks apart fundamentally in Web3.
Here’s where I ended up with this: