Integration test failures

[kousu]

Description

make sqlite-test fails for several reasons. So does make sqlite-test#TestGit.

Mostly the failures seem to be because some repos aren't getting initialized at the right time.

Gitea Version

7c1f18a

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/kousu/ffb734722defa5df44f4e796f777a806

Screenshots

No response

Git Version

git version 2.34.1

Operating System

Ubuntu 22.04

How are you running Gitea?

1. I have upstream https://github.com/go-gitea/gitea/ (fetch) as a git remote
2. I do git fetch upstream && git checkout upstream/main
3. I run git clean -xfd
4. I run TAGS="bindata sqlite sqlite_unlock_notify" make build
5. I run make test-sqlite

Database

SQLite

[kousu]

I wondered it there was a surprise dependency that had crept int since point of sqlite-test and test-sqlite-migration are only ever tested together

gitea/.drone.yml

Line 472 in 9d9bf66

- timeout -s ABRT 50m make test-sqlite-migration test-sqlite

But running both as CI runs them doesn't make the failure go away for me: https://gist.github.com/kousu/8b5449bdb222bbe2425fe01ad8a6a636

[techknowlogick]

likely related to #17910. Please open a thread on the forum to discuss more, or hop into discord/matrix.

[kousu]

Is #17910 what you meant to link? That issue is closed and marked duplicate of #17798. And anyway the test failures seem to be about missing repos, not missing permissions.

I'll come ask you about it in matrix.

By the way, I can reproduce this on 1.16.7 as well: https://gist.github.com/kousu/3281e5425e2b4b9276749443723f58e4. Is there something about my testing environment that's causing this? Is there a step I missed? (The docs don't mention anything special))

[kousu]

After examinining it, @techknowlogick seems to have been spot on. I have

kousu@laptop:~/src/gitea$ ssh -V
OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022

with these signature algorithms:

kousu@laptop:~/src/gitea$ ssh -Q sig
ssh-ed25519
sk-ssh-ed25519@openssh.com
ssh-rsa
rsa-sha2-256
rsa-sha2-512
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
sk-ecdsa-sha2-nistp256@openssh.com
webauthn-sk-ecdsa-sha2-nistp256@openssh.com

notably ssh-rsa which is "RSA with SHA1" is missing.

But sqlite.ini commands gitea to load its own internal ssh server, which is golang's x/crypto/ssh which is buggy: it can't

# integrations/sqlite.ini
# [...]
[server]
SSH_DOMAIN       = localhost
HTTP_PORT        = 3003
ROOT_URL         = http://localhost:3003/
DISABLE_SSH      = false
SSH_LISTEN_HOST  = localhost
SSH_PORT         = 2203
START_SSH_SERVER = true
# [..]

There's pretty good writeups about the issue here and here.

I was able to test by starting gitea manually and sshing into it. I had to run make test-sqlite once, which generates sqlite.ini, then mkdir /tmp/abc and edit sqlite.ini to set ROOT = /tmp/abc/integrations/gitea-integration-sqlite/gitea-repositories; after that I could

./gitea -c `pwd`/integrations/sqlite.ini

and I could log in to http://localhost:3003 as 'user2' (using 'password' as the password), to add my own RSA and ED25519 keys to it; then confirm that it's the deprecation that's the problem:

kousu@laptop:~$ ssh -vvvv -o StrictHostKeyChecking=accept-new -p 2203 -i ~/.ssh/id_rsa  git@localhost 
[....]
debug1: Offering public key: ~/.ssh/id_rsa RSA SHA256:XXXXXXXXXXXXXXXXXXXXX explicit
debug1: send_pubkey_test: no mutual signature algorithm
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
git@localhost: Permission denied (publickey).

"no mutual signature algorithm" is the key symptom of #17798. Meanwhile other key types are fine:

kousu@laptop:~$ ssh -o StrictHostKeyChecking=accept-new -p 2203 -i ~/.ssh/id_ed25519  git@localhost 
PTY allocation request failed on channel 0
Hi there, user2! You've successfully authenticated with the key named kousu@laptop, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.
Connection to localhost closed.

The easy workaround is enough for my purposes, which is just adding a new integration test:

kousu@laptop:~$ cat >> ~/.ssh/config <<EOF

# workaround https://github.com/go-gitea/gitea/issues/17798
# which breaks gitea's integration tests due to an incompatibility between openssh
# and golang's x/crypto/ssh (which gitea uses for its internal ssh server)
Host *
PubkeyAcceptedKeyTypes +ssh-rsa 
EOF

kousu@laptop:~$ ssh -o StrictHostKeyChecking=accept-new -p 2203 -i ~/.ssh/id_rsa  git@localhost 
PTY allocation request failed on channel 0
Hi there, user2! You've successfully authenticated with the key named kousu@laptop, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.
Connection to localhost closed.

Thanks for your time!