On 2021-08-11 at 13:50:55, Konstantin Ryabitsev wrote: > 2-factor authentication does not make sense in the first three cases (you > already have access to all the objects with 1 and 2, and the git:// protocol > is public and anonymous by design). For the ssh/https scheme, 2fa is already > supported by the underlying protocol, so it does not make sense for git to > implement it again on the application level. To expand on this a little bit, you can absolutely set up a Git server with OpenSSH and require 2FA with OpenSSH. That should work just fine. You could also leverage a custom credential helper for HTTPS to require a 2FA code, send it to a server, which would issue a one-time token for Basic auth. All of this is achievable with existing tooling that we have today or tooling that can be easily built. One note here is that as a practical matter, many people require automated cloning of repositories, such as to use their CI systems. Those systems generally cannot practically use 2FA and the security would not be improved if they did, so some solution that allows for that to work is going to be required. Also, in workflows that require many repositories to be cloned, it can be kind of a hassle to wait for one clone to complete, enter the 2FA code (or touch the YubiKey) for the second clone, wait for it to complete, do 2FA for the third clone, and so on. So while you can do this, it's important to keep in mind that there are some user experience tradeoffs here that need to be considered as well. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
