ssh operations refrain to work since d409d3

[agaida]

• Gitea version (or commit ref): d409d3a
• Git version: 2.11.0
• Operating system: Ubuntu zesty
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • [ x] SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • [x ] Not relevant
• Log gist:

Description

since commit d409d3a Sanitation fix ssh actions hangs

Log

agaida@vmd18926:~$ git clone git@gitea:Test/pyfll p-10
Cloning into 'p-10'...
remote: Counting objects: 7528, done.
remote: Compressing objects: 100% (2441/2441), done.
remote: Total 7528 (delta 5067), reused 7517 (delta 5060)
Receiving objects: 100% (7528/7528), 3.07 MiB | 0 bytes/s, done.
Resolving deltas: 100% (5067/5067), done.
agaida@vmd18926:~$ git clone git@gitea:Test/pyfll p-6 
Cloning into 'p-6'...
remote: Counting objects: 7528, done.
remote: Compressing objects: 100% (2441/2441), done.
remote: Total 7528 (delta 5067), reused 7517 (delta 5060)
Receiving objects: 100% (7528/7528), 3.07 MiB | 0 bytes/s, done.
Resolving deltas: 100% (5067/5067), done.
agaida@vmd18926:~$ git clone git@gitea:Test/pyfll p-4
Cloning into 'p-4'...
remote: Counting objects: 7528, done.
remote: Compressing objects: 100% (2441/2441), done.
remote: Total 7528 (delta 5067), reused 7517 (delta 5060)
Receiving objects: 100% (7528/7528), 3.07 MiB | 0 bytes/s, done.
Resolving deltas: 100% (5067/5067), done.
agaida@vmd18926:~$ git clone git@gitea:Test/pyfll p-2
Cloning into 'p-2'...
^C
agaida@vmd18926:~$ git clone git@gitea:Test/pyfll p-3
Cloning into 'p-3'...
^C
agaida@vmd18926:~$ git clone git@gitea:Test/pyfll p-4again
Cloning into 'p-4again'...
remote: Counting objects: 7528, done.
remote: Compressing objects: 100% (2441/2441), done.
remote: Total 7528 (delta 5067), reused 7517 (delta 5060)
Receiving objects: 100% (7528/7528), 3.07 MiB | 0 bytes/s, done.
Resolving deltas: 100% (5067/5067), done.

This behaviour is reproducible - just branch the current master and hard reset it to some commits before.

[lunny]

@bkcsoft maybe you can take a look this.

[kubatyszko]

Interesting report, I reviewed the sanitization commit and there doesn't seem to be anything that could affect SSH at all, most if not all changes are template/HTML related.

I might be able to upgrade one of my environments to the HEAD and see if I see any SSH issues.

Thanks.

[agaida]

models/repo.go

seems to be worth a look - ok, wild guess, i don't speek go.

[gsantner]

I also couldn't use ssh on current HEAD. Went back to 21290d4 , the problem doesn't exist there.

I turned on SSH/GIT verbose log, and it was hanging at pre-receive.
Maybe useful: 21290d4...master

[kubatyszko]

I just built gitea based on 21290d4 and I'm seeing this error:

Counting objects: 3, done.
Writing objects: 100% (3/3), 202 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
Gitea: Internal error
UpdatePublicKey: near "WHERE": syntax error
To ssh://localhost:2222/kuba/test.git
 * [new branch]      master -> master
error: failed to push some refs to 'ssh://kt@localhost:2222/kuba/test.git'

I am precisely on Gitea Version: 1.1.0+118-g21290d4

This might be some hint to whover has clue what broke with SSH recently.

Other than the warning (and seemingly failing operations) - push/pull actually works.

[kubatyszko]

I reverted to d9db188 and that fixed it (that's one commit before #1466 (I didn't do a full bisect, simply reverted the commit that seemed like it could be causing issues when a SSH key is being used, the error message with the "WHERE" description clearly indicates it's related to some UPDATE operation when using SSH key...

[strk]

What database are you using @kubatyszko ? Can you enable statement logging and check the exact statement being sent ?

[kubatyszko]

sqlite in this case, the statement is:

2017/04/18 16:40:00 [I] [SQL] UPDATE `public_key` SET  WHERE `id`=? [1]

It seems to missing a thing to set between SET and WHERE...

Also, there is no specific field in the table that would store last-used of the key:

sqlite> .schema public_key
CREATE TABLE `public_key` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `owner_id` INTEGER NOT NULL, `name` TEXT NOT NULL, `fingerprint` TEXT NOT NULL, `content` TEXT NOT NULL, `mode` INTEGER NOT NULL DEFAULT 2, `type` INTEGER NOT NULL DEFAULT 1, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL);
CREATE INDEX `IDX_public_key_owner_id` ON `public_key` (`owner_id`);
sqlite>

The only field that could fit the purpose would be updated_unix...

[lunny]

^ Wrong reference.

[tbaschak]

I actually migrated from sqlite to mysql (in a very very manual way) b/c I thought it was an error in the sqlite backend on my end. The error happens in both sqlite and mysql backends. Like @kubatyszko said above theres something missing after SET in the UPDATE query in both.

I did not realize however that push/pull operations actually were successful despite this.

[lunny]

@kubatyszko and @tbaschak I think both your issue has been reported via #1471 and has been fixed by #1474 and merged to master. Your issue is not related with this one.