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: