gitea
gitea copied to clipboard
go-gitea
Allow pushmirror to use publickey authentication
- Adds the option to use let the pushmirror use publickey authentication for push actions instead of using user:password authentication. The Publickey algorithm uses for this is ed25519, and is saved in OpenSSH's format so it can be used directly with git.
- Resolves #18159
This PR only uses vanilla javascript, in order to show for https://github.com/go-gitea/gitea/issues/18302 it's possible to only use vanilla javascript.
The code is still using Fomantic UI, which requires jQuery.
About frontend plan (a little off-topic): If there is no clear agreement about how to refactor all the code, in the end, Gitea will become a monster with Go-template, Fomantic UI, jQuery, Vue2 and vanilla JavaScript and maybe home-made frameworks, everything mixed together. Current Gitea community situtaion is: no one can stop new code written in Fomantic UI and jQuery, no one helps to review and refactor them.
@wxiaoguang I've changed my comment to reflect a more accurate representation. Sorry for the confusion.
No need to say sorry .... 😊 I just hope most people can realize the fact, and make Gitea frontend get rid of the current nobody-cares situation.
Ready for review... I'm not sure how to handle the UI to display the long ssh key.
Codecov Report
Merging #18835 (801741d) into main (a3d55ac) will increase coverage by
0.01%. The diff coverage is60.87%.
@@ Coverage Diff @@
## main #18835 +/- ##
==========================================
+ Coverage 46.93% 46.95% +0.01%
==========================================
Files 977 979 +2
Lines 135302 135609 +307
==========================================
+ Hits 63508 63672 +164
- Misses 64012 64132 +120
- Partials 7782 7805 +23
| Impacted Files | Coverage Δ | |
|---|---|---|
| cmd/dump.go | 0.67% <ø> (ø) |
|
| models/repo/pushmirror.go | 78.00% <ø> (ø) |
|
| modules/context/package.go | 48.27% <0.00%> (-8.49%) |
:arrow_down: |
| modules/lfs/content_store.go | 74.66% <ø> (+4.66%) |
:arrow_up: |
| modules/packages/container/metadata.go | 76.92% <ø> (ø) |
|
| routers/web/org/setting.go | 0.00% <0.00%> (ø) |
|
| routers/web/repo/packages.go | 0.00% <0.00%> (ø) |
|
| routers/web/repo/setting.go | 16.70% <0.00%> (-0.23%) |
:arrow_down: |
| routers/web/user/setting/account.go | 25.65% <0.00%> (-0.12%) |
:arrow_down: |
| routers/web/user/setting/profile.go | 35.36% <0.00%> (-0.44%) |
:arrow_down: |
| ... and 48 more |
Help us with your feedback. Take ten seconds to tell us how you rate us.
@silverwind Could you give some input for the UI? I've tried some designs now in order to display the Public SSH Key, but I haven't been able show it nicely within the design, it was always too short or too long + fucking up the 2 button.
I'm not able to get any kind of neat and clean UI while still showing the public key. Changed it to be behind a copy button(updated PR message with updated screenshot).
Assume users have 100 push mirrors, then he has to add 100 public keys in target forge website?
Assume users have 100 push mirrors, then he has to add 100 public keys in target forge website?
Well if the user is going to create multiple push mirrors and wants to use the deploy keys functionality yes.
But this PR is for users that wants to use SSH based authorization, so they can on the target forge add them to the repo's deploy keys and thus limits the access a SSH keypair has. That's the current use case that this PR is fixing: #18159.
Commenting to follow updates. Trying to mirror-push to sr.ht for my public repositories.
Looks like this is close to approval! Very excited to see it sometime soon!
Commenting to follow updates.
Please use the subscribe button to follow an issue/PR silently.
Fixed up conflicts and also accidentally pushed some code in that commit to actually be able to parse [email protected]:gitea/gitea URLs(which was somehow still in a stash).
More conflicts appear.
Will take a look at UI later.
One question: What if the remote only supports RSA key or maybe it's HTTPS only? Is it something that can be supported, maybe later?
One question: What if the remote only supports RSA key
If some Forge only support some older type of Public-key cryptography, then I'm happy to hear about it and implement a RSA version. But so far I don't know of any and don't really take it into account therefor.
or maybe it's HTTPS only?
Huh? This PR only adds the ability to use pushmirror over SSH, the normal HTTPS option is still there.
7. Because this error appears: Where am I supposed to enter the SSH key? Or does Gitea automatically take one of my verified keys? Or how is that handled? The current UI absolutely confuses the user because he has to make a lot of assumptions without knowing if they are correct. That should be changed.
The suggested tooltip should now take care of this confusion, feel free to add suggestions.
@delvh https://github.com/go-gitea/gitea/pull/18835/commits/86fec2defe312aa21d3f3cbe8075e41a34f28802 should fix your panic, I had LFS disabled.
Do we want to display this warning?
Do we want to display this warning?
Yes, but we might want to trim the Warning: Github.com has been added ... path. IIRC this error popup was explicitly added so users could debug why synchronizing has gone wrong, which does its job now.
- Why does it copy it including a trailing
\n? (Hopefully, providers will trim whitespace, but we can't be certain of that…)
Weird, shouldn't do that. But it's due to this LOC https://cs.opensource.google/go/x/crypto/+/bc19a97f:ssh/keys.go;l=294
@Gusted Is this PR abandoned? Do you need any help finishing up the merge conflicts?
@Gusted Is this PR abandoned? Do you need any help finishing up the merge conflicts?
No, the merge conflicts aren't the problem. Rather that I forgot that Git-LFS exists, which is way harder to support with SSH. I'm not knowledgeable enough about LFS to even try add support for it.
No, the merge conflicts aren't the problem. Rather that I forgot that Git-LFS exists, which is way harder to support with SSH. I'm not knowledgeable enough about LFS to even try add support for it.
Would it be possible to implement push mirrors without support for Git-LFS and leave that feature for the future? There are a fair number of repositories that doesn't require it, so the implementation would not be wasted.
@Gusted Are you still willing to work on this PR? I think this feature would be a great addition even without Git LFS support. I see that you suggested to force HTTP auth for LFS-enabled repos - I think this would be an acceptable approach.
If you still want to continue with this PR, please resolve merge conflicts and maybe we could merge it soon.
