github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Deploy Key can't be deleted then reused as Profile key #559

New Issue
Closed
opened 2025-11-02 03:28:08 -06:00 by GiteaMirror · 4 comments
GiteaMirror commented 2025-11-02 03:28:08 -06:00
Owner
Copy Link

Originally created by @cdslashetc on GitHub (Mar 21, 2017).

  • Gitea version (or commit ref): Gitea Version: 1.1.0+1-g1d65291
  • Git version: git 1:2.7.4-0ubuntu1
  • Operating system: Ubuntu 16.04.2 LTS
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
  • Log gist:
    I was able to recreate on try.gitea by doing the following:
    create private repository
    add Deploy Key to repository
    delete Deploy Key
    add same key to user Profile
    attempt to clone repository using the private key

Description

A user added a key as a Deploy Key not realizing it would be read-only. So, he removed the Deploy Key from the repository then added the same key to his user Profile instead since he is trying to use the Jenkins plugin Git Publisher to create a Tag as a post-build action, which needs to merge.

It is possible that he removed the Deploy Key after he had already added it to his user Profile. So, this problem may be related to #938

I told the user to create a new key and that of course worked fine.

In serv.log Gitea still seems to think it's the same Deploy Key rather than a normal user key:

2017/03/21 11:32:40 [...io/gitea/cmd/serv.go:216 runServ()] [F] Deploy key access denied: [key_id: 4, repo_id: 48]
2017/03/21 11:38:26 [...io/gitea/cmd/serv.go:216 runServ()] [F] Deploy key access denied: [key_id: 4, repo_id: 61]

I'd say something is going awry in the process to delete the Deploy Key. I'm not using my normal workstation today, trying to get a database tool installed and working so I can dig around in the database.

It could be sufficient just to prevent users from reusing a Deploy Key, it's a bad idea anyway for security reasons.

Screenshots

If this issue involves the Web Interface, please include a screenshot

Originally created by @cdslashetc on GitHub (Mar 21, 2017). - Gitea version (or commit ref): Gitea Version: 1.1.0+1-g1d65291 - Git version: git 1:2.7.4-0ubuntu1 - Operating system: Ubuntu 16.04.2 LTS - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (provide example URL) https://try.gitea.io/cdslashetc/deploy-key-test - [ ] No - [ ] Not relevant - Log gist: I was able to recreate on try.gitea by doing the following: create private repository add Deploy Key to repository delete Deploy Key add same key to user Profile attempt to clone repository using the private key ## Description A user added a key as a Deploy Key not realizing it would be read-only. So, he removed the Deploy Key from the repository then added the same key to his user Profile instead since he is trying to use the Jenkins plugin Git Publisher to create a Tag as a post-build action, which needs to merge. It is possible that he removed the Deploy Key after he had already added it to his user Profile. So, this problem may be related to #938 I told the user to create a new key and that of course worked fine. In serv.log Gitea still seems to think it's the same Deploy Key rather than a normal user key: 2017/03/21 11:32:40 [...io/gitea/cmd/serv.go:216 runServ()] [F] Deploy key access denied: [key_id: 4, repo_id: 48] 2017/03/21 11:38:26 [...io/gitea/cmd/serv.go:216 runServ()] [F] Deploy key access denied: [key_id: 4, repo_id: 61] I'd say something is going awry in the process to delete the Deploy Key. I'm not using my normal workstation today, trying to get a database tool installed and working so I can dig around in the database. It could be sufficient just to prevent users from reusing a Deploy Key, it's a bad idea anyway for security reasons. ## Screenshots **If this issue involves the Web Interface, please include a screenshot**
GiteaMirror added the type/bug label 2025-11-02 03:28:08 -06:00
GiteaMirror commented 2025-11-02 03:28:09 -06:00
Author
Owner
Copy Link

@hahnjo commented on GitHub (Jan 8, 2019):

I just experienced the same and I definitely first deleted the deploy key and then added it to my profile. Manually removing the key from .ssh/authorized_keys worked, of course.

@hahnjo commented on GitHub (Jan 8, 2019): I just experienced the same and I definitely first deleted the deploy key and then added it to my profile. Manually removing the key from `.ssh/authorized_keys` worked, of course.
GiteaMirror commented 2025-11-02 03:28:09 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 2, 2019):

I've just hit this whilst testing on docker... What happened to me is that I added a key as a deploy key to a repository - archived that repository and then added the key as a public key. No matter what I did I couldn't get the key to disappear from the deploy key table.

@zeripath commented on GitHub (Feb 2, 2019): I've just hit this whilst testing on docker... What happened to me is that I added a key as a deploy key to a repository - archived that repository and then added the key as a public key. No matter what I did I couldn't get the key to disappear from the deploy key table.
GiteaMirror commented 2025-11-02 03:28:09 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 2, 2019):

OK my understanding is that the intention is:

  1. A key can either be an ssh user key or a deploy key. It cannot be both.
  2. If a key is a user key - it can only be associated with one user.
  3. If a key is a deploy key - it can be used in multiple repositories and the permissions it has on those repositories can be different.

We currently don't enforce any of this and multiple repositories access with different permissions doesn't work at all.

@zeripath commented on GitHub (Feb 2, 2019): OK my understanding is that the intention is: 1. A key can either be an ssh user key or a deploy key. It cannot be both. 2. If a key is a user key - it can only be associated with one user. 3. If a key is a deploy key - it can be used in multiple repositories and the permissions it has on those repositories can be different. We currently don't enforce any of this and multiple repositories access with different permissions doesn't work at all.
GiteaMirror commented 2025-11-02 03:28:10 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 2, 2019):

That leads to the following constraints:

  • You should not be able to add the same user key as another user
  • You should not be able to add a ssh user key which is being used as a deploy key
  • You should not be able to add a ssh deploy key which is being used as a user key
  • If you add an ssh deploy key to another repository you should be able to use it in different modes without losing the ability to use it in the other mode.
  • If you delete a repository you need to delete all the deploy keys in that repository.

Only one of which we actually enforce correctly.

OK, now as we haven't been enforcing this - there may be users out there with broken systems. We could be more generous in serv and try matching keys until we get one that allows us to do what we want.

Then maybe we could relax the above constraints somewhat...

However, I'm going to make a PR to actually enforce the constraints above first and then we can consider relaxing things.

@zeripath commented on GitHub (Feb 2, 2019): That leads to the following constraints: - [x] You should not be able to add the same user key as another user - [ ] You should not be able to add a ssh user key which is being used as a deploy key - [ ] You should not be able to add a ssh deploy key which is being used as a user key - [ ] If you add an ssh deploy key to another repository you should be able to use it in different modes without losing the ability to use it in the other mode. - [ ] If you delete a repository you need to delete all the deploy keys in that repository. Only one of which we actually enforce correctly. OK, now as we haven't been enforcing this - there may be users out there with broken systems. We could be more generous in serv and try matching keys until we get one that allows us to do what we want. Then maybe we could relax the above constraints somewhat... However, I'm going to make a PR to actually enforce the constraints above first and then we can consider relaxing things.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#559
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?