Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Deploy Key can't be deleted then reused as Profile key #1357
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]
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.
If this issue involves the Web Interface, please include a screenshot
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.
OK my understanding is that the intention is:
We currently don't enforce any of this and multiple repositories access with different permissions doesn't work at all.
That leads to the following constraints:
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.