Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integration test failures #20207

Closed
kousu opened this issue Jul 3, 2022 · 4 comments
Closed

Integration test failures #20207

kousu opened this issue Jul 3, 2022 · 4 comments

Comments

@kousu
Copy link
Contributor

kousu commented Jul 3, 2022

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
Copy link
Contributor Author

kousu commented Jul 3, 2022

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

- 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
Copy link
Member

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

@kousu
Copy link
Contributor Author

kousu commented Jul 3, 2022

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
Copy link
Contributor Author

kousu commented Jul 3, 2022

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!

@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants