Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Push mirror using public key authorization #18159

Open
SamWhited opened this issue Jan 2, 2022 · 8 comments
Open

Push mirror using public key authorization #18159

SamWhited opened this issue Jan 2, 2022 · 8 comments
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@SamWhited
Copy link

Feature Description

Currently the push mirror feature only supports a username and a password for authentication. However, I would like to push to another Gitea instance (that has pull mirrors disabled), so it would be useful if it could also take an SSH key. This way, instead of giving one Gitea instance access to my entire account on the other Gitea instance I could setup a deploy key and use that to authorize access only to the repo that we're pushing to.

Screenshots

No response

@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Jan 12, 2022
@Konsonanz
Copy link

+1, this is also a usecase for me.
I have a scenario where I'm managing packages on the Arch User Repository; I want to maintain the packages on gitea and push-mirror to the AUR. But AUR only allows write operations with ssh authentication.

Slightly related, AUR also only allows pushing to the master branch and to no other refs. Since currently there is no option to push-mirror only from/to selective branches, I wonder if gitea would fail here if not all refs can be pushed, or if at least the master branch would in fact be pushed to...

@Gusted
Copy link
Contributor

Gusted commented Feb 16, 2022

I think this is a nice addition and should be straight forward to implement(just a personal note on how to pass down the ssh key]. I do see a little thing that should be considered, while you're giving essentially a private key to gitea, it should be made clear to only add a deploy key which can be revoked at any time by the destination's push mirror, as we do not want to posses user's private keys.

@SamWhited
Copy link
Author

@Gusted An alternative UI that I had thought might be good is to have Gitea say "if you want us to push somewhere, authorize this public key". Ie. Gitea generates the private key and doesn't give the user access to it (or only does so in some sort of advanced settings interface where you can replace it with your own); this way the user who doesn't have some advanced deployment scheme in mind doesn't accidentally use their own private key without thinking the consequences through.

@Gusted
Copy link
Contributor

Gusted commented Feb 17, 2022

@SamWhited That's pretty handy UI, will see if I can fit this feature in this week

@adamcstephens
Copy link

I'd love to see this feature. Sourcehut doesn't allow pushing over HTTPS, so gitea can't currently push mirror there. Having ssh-based authentication would also allow scoping of access to Github on a per-repository basis, using deploy keys, versus the personal auth token which is given full access to all repos.

@lunny
Copy link
Member

lunny commented Feb 18, 2022

We should have a secret store feature at first.

@Gusted
Copy link
Contributor

Gusted commented Feb 18, 2022

We should have a secret store feature at first.

Why should we have that? Gitea generates the key and has to pass the private key to git anyway. I don't see the particular need of a secret store feature before this can become a thing.

But if such feature is really needed, how should it look like? Because encrypting it would need to be done by a secret key(most likely the one that's generated on startup). Even in such case it isn't really encrypted in my sense - as the gitea adminstrator will still be able see the contents and if a malicious attacker happen to get the files, it would also be able to retrieve the secret key via app.ini

@Gusted
Copy link
Contributor

Gusted commented Feb 20, 2022

I've created a draft PR for this, see #18835

thigg added a commit to thigg/gitea that referenced this issue Jul 24, 2023
silverwind pushed a commit that referenced this issue Jul 25, 2023
related #1635 #18159

This will probably be obsolete at some point, but it should not break
anything and it may help some users
GiteaBot pushed a commit to GiteaBot/gitea that referenced this issue Jul 25, 2023
related go-gitea#1635 go-gitea#18159

This will probably be obsolete at some point, but it should not break
anything and it may help some users
silverwind pushed a commit that referenced this issue Jul 25, 2023
Backport #26096 by @thigg

related #1635 #18159

This will probably be obsolete at some point, but it should not break
anything and it may help some users

Co-authored-by: thigg <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants