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

[cdslashetc]

• 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:
  • 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

[hahnjo]

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.

[zeripath]

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]

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]

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.