You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SSH agent forwarding can be part of the solution here (both ssh and gpg can be forwarded over ssh). There is also changes that need to be made with the .gitconfig (gpg/ssh)
This is certainly advanced but its needed for these projects which are becoming more common.
Describe the solution you'd like
I think this is part of a larger re-envisioning of git credentials. In the Daytona config (global, profile, etc). I should be able to say, I want to use ssh or oauth. In a commercial setting, ops is likely to want to mandate you have to use ssh or oauth. If I choose ssh, do I also want to setup for signed commits, great plumb that through all the way. SSH agent forward, gitconfig with the right settings, etc. Similarly, do I have gpg and do I want to forward it? Plumb that through.
This is also related to Yubikey support. Yubikeys can act as ssh/gpg hardware which could add complexity (or perhaps that is solved by general ssh forwarding). Someone would need to do more research.
The text was updated successfully, but these errors were encountered:
As we fixed agent forwarding in v0.11.0, you can help us out by trying to set up SSH key signing in one of your projects.
We can definitely include some sort of options for the user to configure that automatically.
I would suggest keeping this issue as a discussion issue for both SSH and GPG signing and then opening separate implementation issues once we gather enough info.
Is your feature request related to a problem? Please describe.
An increasing number of projects are requiring verified / signed commits. https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits
For GitHub there are two general approaches to commit signing:
SSH agent forwarding can be part of the solution here (both ssh and gpg can be forwarded over ssh). There is also changes that need to be made with the
.gitconfig
(gpg/ssh)This is certainly advanced but its needed for these projects which are becoming more common.
Describe the solution you'd like
I think this is part of a larger re-envisioning of git credentials. In the Daytona config (global, profile, etc). I should be able to say, I want to use ssh or oauth. In a commercial setting, ops is likely to want to mandate you have to use ssh or oauth. If I choose ssh, do I also want to setup for signed commits, great plumb that through all the way. SSH agent forward, gitconfig with the right settings, etc. Similarly, do I have gpg and do I want to forward it? Plumb that through.
This is related to #369.
Describe alternatives you've considered
This is also related to Yubikey support. Yubikeys can act as ssh/gpg hardware which could add complexity (or perhaps that is solved by general ssh forwarding). Someone would need to do more research.
The text was updated successfully, but these errors were encountered: