Could not read your security key #8433

@veita commented on GitHub (Jan 31, 2022):

Probably same problem as here:

+ wget https://dl.gitea.io/gitea/1.16.0/gitea-1.16.0-linux-amd64
--2022-01-31 08:10:20--  https://dl.gitea.io/gitea/1.16.0/gitea-1.16.0-linux-amd64
Resolving dl.gitea.io (dl.gitea.io)... 2606:4700:3036::6815:3c07, 2606:4700:3034::ac43:bad3, 104.21.60.7, ...
Connecting to dl.gitea.io (dl.gitea.io)|2606:4700:3036::6815:3c07|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 105989848 (101M) [application/octet-stream]
Saving to: ‘gitea-1.16.0-linux-amd64’

gitea-1.16.0-linux-amd64           100%[================================================================>] 101.08M  1.31MB/s    in 87s     

2022-01-31 08:11:47 (1.16 MB/s) - ‘gitea-1.16.0-linux-amd64’ saved [105989848/105989848]

++ wget https://dl.gitea.io/gitea/1.16.0/gitea-1.16.0-linux-amd64.asc
--2022-01-31 08:11:47--  https://dl.gitea.io/gitea/1.16.0/gitea-1.16.0-linux-amd64.asc
Resolving dl.gitea.io (dl.gitea.io)... 2606:4700:3036::6815:3c07, 2606:4700:3034::ac43:bad3, 104.21.60.7, ...
Connecting to dl.gitea.io (dl.gitea.io)|2606:4700:3036::6815:3c07|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 833 [text/plain]
Saving to: ‘gitea-1.16.0-linux-amd64.asc’

gitea-1.16.0-linux-amd64.asc       100%[================================================================>]     833  --.-KB/s    in 0s      

2022-01-31 08:11:47 (8.41 MB/s) - ‘gitea-1.16.0-linux-amd64.asc’ saved [833/833]

++ gpg --verify gitea-1.16.0-linux-amd64.asc gitea-1.16.0-linux-amd64
gpg: Signature made Sun 30 Jan 2022 06:58:00 PM UTC
gpg:                using RSA key CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: BAD signature from "Teabot <teabot@gitea.io>" [unknown]
+ echo 'ERROR Bad signature'
ERROR Bad signature
+ exit 1

@veita commented on GitHub (Jan 31, 2022): Probably same problem as here: ``` + wget https://dl.gitea.io/gitea/1.16.0/gitea-1.16.0-linux-amd64 --2022-01-31 08:10:20-- https://dl.gitea.io/gitea/1.16.0/gitea-1.16.0-linux-amd64 Resolving dl.gitea.io (dl.gitea.io)... 2606:4700:3036::6815:3c07, 2606:4700:3034::ac43:bad3, 104.21.60.7, ... Connecting to dl.gitea.io (dl.gitea.io)|2606:4700:3036::6815:3c07|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 105989848 (101M) [application/octet-stream] Saving to: ‘gitea-1.16.0-linux-amd64’ gitea-1.16.0-linux-amd64 100%[================================================================>] 101.08M 1.31MB/s in 87s 2022-01-31 08:11:47 (1.16 MB/s) - ‘gitea-1.16.0-linux-amd64’ saved [105989848/105989848] ++ wget https://dl.gitea.io/gitea/1.16.0/gitea-1.16.0-linux-amd64.asc --2022-01-31 08:11:47-- https://dl.gitea.io/gitea/1.16.0/gitea-1.16.0-linux-amd64.asc Resolving dl.gitea.io (dl.gitea.io)... 2606:4700:3036::6815:3c07, 2606:4700:3034::ac43:bad3, 104.21.60.7, ... Connecting to dl.gitea.io (dl.gitea.io)|2606:4700:3036::6815:3c07|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 833 [text/plain] Saving to: ‘gitea-1.16.0-linux-amd64.asc’ gitea-1.16.0-linux-amd64.asc 100%[================================================================>] 833 --.-KB/s in 0s 2022-01-31 08:11:47 (8.41 MB/s) - ‘gitea-1.16.0-linux-amd64.asc’ saved [833/833] ++ gpg --verify gitea-1.16.0-linux-amd64.asc gitea-1.16.0-linux-amd64 gpg: Signature made Sun 30 Jan 2022 06:58:00 PM UTC gpg: using RSA key CC64B1DB67ABBEECAB24B6455FC346329753F4B0 gpg: BAD signature from "Teabot <teabot@gitea.io>" [unknown] + echo 'ERROR Bad signature' ERROR Bad signature + exit 1 ```

GiteaMirror commented

@techknowlogick commented on GitHub (Jan 31, 2022):

@veita this is an issue re:webauthn validation, and not gpg validation of the binaries

@techknowlogick commented on GitHub (Jan 31, 2022): @veita this is an issue re:webauthn validation, and not gpg validation of the binaries

GiteaMirror commented

@veita commented on GitHub (Jan 31, 2022):

That's weird. The same script works with 1.15.10:

++ wget https://dl.gitea.io/gitea/1.15.10/gitea-1.15.10-linux-amd64
--2022-01-31 09:07:21--  https://dl.gitea.io/gitea/1.15.10/gitea-1.15.10-linux-amd64
Resolving dl.gitea.io (dl.gitea.io)... 2606:4700:3036::6815:3c07, 2606:4700:3034::ac43:bad3, 172.67.186.211, ...
Connecting to dl.gitea.io (dl.gitea.io)|2606:4700:3036::6815:3c07|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 106478136 (102M) [application/octet-stream]
Saving to: ‘gitea-1.15.10-linux-amd64’

gitea-1.15.10-linux-amd64          100%[================================================================>] 101.54M  1.25MB/s    in 90s     

2022-01-31 09:08:51 (1.13 MB/s) - ‘gitea-1.15.10-linux-amd64’ saved [106478136/106478136]

++ wget https://dl.gitea.io/gitea/1.15.10/gitea-1.15.10-linux-amd64.asc
--2022-01-31 09:08:51--  https://dl.gitea.io/gitea/1.15.10/gitea-1.15.10-linux-amd64.asc
Resolving dl.gitea.io (dl.gitea.io)... 2606:4700:3034::ac43:bad3, 2606:4700:3036::6815:3c07, 172.67.186.211, ...
Connecting to dl.gitea.io (dl.gitea.io)|2606:4700:3034::ac43:bad3|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 833 [text/plain]
Saving to: ‘gitea-1.15.10-linux-amd64.asc’

gitea-1.15.10-linux-amd64.asc      100%[================================================================>]     833  --.-KB/s    in 0s      

2022-01-31 09:08:51 (8.76 MB/s) - ‘gitea-1.15.10-linux-amd64.asc’ saved [833/833]

++ gpg --verify gitea-1.15.10-linux-amd64.asc gitea-1.15.10-linux-amd64
gpg: Signature made Fri 14 Jan 2022 08:27:46 PM UTC
gpg:                using RSA key CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: Good signature from "Teabot <teabot@gitea.io>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7C9E 6815 2594 6888 62D6  2AF6 2D9A E806 EC15 92E2
     Subkey fingerprint: CC64 B1DB 67AB BEEC AB24  B645 5FC3 4632 9753 F4B0
+ echo 'OK Signature verified'
OK Signature verified

@veita commented on GitHub (Jan 31, 2022): That's weird. The same script works with 1.15.10: ``` ++ wget https://dl.gitea.io/gitea/1.15.10/gitea-1.15.10-linux-amd64 --2022-01-31 09:07:21-- https://dl.gitea.io/gitea/1.15.10/gitea-1.15.10-linux-amd64 Resolving dl.gitea.io (dl.gitea.io)... 2606:4700:3036::6815:3c07, 2606:4700:3034::ac43:bad3, 172.67.186.211, ... Connecting to dl.gitea.io (dl.gitea.io)|2606:4700:3036::6815:3c07|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 106478136 (102M) [application/octet-stream] Saving to: ‘gitea-1.15.10-linux-amd64’ gitea-1.15.10-linux-amd64 100%[================================================================>] 101.54M 1.25MB/s in 90s 2022-01-31 09:08:51 (1.13 MB/s) - ‘gitea-1.15.10-linux-amd64’ saved [106478136/106478136] ++ wget https://dl.gitea.io/gitea/1.15.10/gitea-1.15.10-linux-amd64.asc --2022-01-31 09:08:51-- https://dl.gitea.io/gitea/1.15.10/gitea-1.15.10-linux-amd64.asc Resolving dl.gitea.io (dl.gitea.io)... 2606:4700:3034::ac43:bad3, 2606:4700:3036::6815:3c07, 172.67.186.211, ... Connecting to dl.gitea.io (dl.gitea.io)|2606:4700:3034::ac43:bad3|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 833 [text/plain] Saving to: ‘gitea-1.15.10-linux-amd64.asc’ gitea-1.15.10-linux-amd64.asc 100%[================================================================>] 833 --.-KB/s in 0s 2022-01-31 09:08:51 (8.76 MB/s) - ‘gitea-1.15.10-linux-amd64.asc’ saved [833/833] ++ gpg --verify gitea-1.15.10-linux-amd64.asc gitea-1.15.10-linux-amd64 gpg: Signature made Fri 14 Jan 2022 08:27:46 PM UTC gpg: using RSA key CC64B1DB67ABBEECAB24B6455FC346329753F4B0 gpg: Good signature from "Teabot <teabot@gitea.io>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 7C9E 6815 2594 6888 62D6 2AF6 2D9A E806 EC15 92E2 Subkey fingerprint: CC64 B1DB 67AB BEEC AB24 B645 5FC3 4632 9753 F4B0 + echo 'OK Signature verified' OK Signature verified ```

GiteaMirror commented

2025-11-02 08:05:50 -06:00

@zeripath commented on GitHub (Jan 31, 2022):

@grisu48 "An attempt was made to use an object that is not, or is no longer, usable" likely relates to the different format of the "relying party" ID that webauthn expects as compared to U2F.

You would need to set the [u2f] APP_ID to match the old APP_ID format that the security keys would work for. Gitea guesses this is the ROOT_URL but depending on your set-up this may not be correct. TRUSTED_FACETS are not supported in webauthn so if you were depending on these you will need to choose the most important one of these and set it as the APP_ID.

@zeripath commented on GitHub (Jan 31, 2022): @grisu48 "An attempt was made to use an object that is not, or is no longer, usable" likely relates to the different format of the "relying party" ID that webauthn expects as compared to U2F. You would need to set the `[u2f]` `APP_ID` to match the old APP_ID format that the security keys would work for. Gitea guesses this is the `ROOT_URL` but depending on your set-up this may not be correct. `TRUSTED_FACETS` are not supported in webauthn so if you were depending on these you will need to choose the most important one of these and set it as the `APP_ID`.

GiteaMirror commented

@grisu48 commented on GitHub (Jan 31, 2022):

Thank you, that makes sense. Indeed, I don't see a [u2f] section in my app.ini and it is likely that this was introduced after my initial setup. Will update my configuration accordingly.

Feel free to close this issue, with this explanation is seems to be more likely the result of an old config, rather than an actual bug. Thanks for looking into this!

Anyone who ends up here after me, checkout the u2f section of the app.ini.

@grisu48 commented on GitHub (Jan 31, 2022): Thank you, that makes sense. Indeed, I don't see a `[u2f]` section in my `app.ini` and it is likely that this was introduced after my initial setup. Will update my configuration accordingly. Feel free to close this issue, with this explanation is seems to be more likely the result of an old config, rather than an actual bug. Thanks for looking into this! *** Anyone who ends up here after me, checkout [the u2f section of the app.ini](https://github.com/go-gitea/gitea/blob/5e5740af69cb0f44ff0c1576a2387388d75bb4c2/custom/conf/app.example.ini#L438).

GiteaMirror commented

2025-11-02 08:05:50 -06:00

@mscherer commented on GitHub (Jan 31, 2022):

I also faced the same issue. I had a [u2f] and I tried to change it to the ROOT_URL value without luck. So in the end, I also just remove the keys and added them back.

@mscherer commented on GitHub (Jan 31, 2022): I also faced the same issue. I had a [u2f] and I tried to change it to the ROOT_URL value without luck. So in the end, I also just remove the keys and added them back.

GiteaMirror commented

2025-11-02 08:05:50 -06:00

@zeripath commented on GitHub (Feb 1, 2022):

Gitea should be setting the app_id to the root_url already so if it's not working by default the app_id would need to be slightly different from the root_url.

If you do manage to work out what it should be in those cases please do report back - it may well be that we can create a better default.

@zeripath commented on GitHub (Feb 1, 2022): Gitea should be setting the app_id to the root_url already so if it's not working by default the app_id would need to be slightly different from the root_url. If you do manage to work out what it should be in those cases please do report back - it may well be that we can create a better default.

GiteaMirror commented

@grisu48 commented on GitHub (Feb 1, 2022):

I just added the following configuration to my app.ini and it worked without complains:

[U2F]
APP_ID = https://<<REDACTED>>        # Replace with public endpoint hostname

After a service restart, I could login with the already registered Yubikeys. By setting this value explicitly I assume we're safe from here onwards, especially to mitigate the possibility that gitea at some point confuses the internal hostname/ip with the external one (I'm thinking about containers).

@grisu48 commented on GitHub (Feb 1, 2022): I just added the following configuration to my `app.ini` and it worked without complains: ```ini [U2F] APP_ID = https://<<REDACTED>> # Replace with public endpoint hostname ``` After a service restart, I could login with the already registered Yubikeys. By setting this value explicitly I assume we're safe from here onwards, especially to mitigate the possibility that gitea at some point confuses the internal hostname/ip with the external one (I'm thinking about containers).

GiteaMirror commented

@zeripath commented on GitHub (Feb 1, 2022):

Setting the app_id correctly should work for previously registered u2f keys but if your root_url is not your real root URL you may have difficulties registering new keys.

Webauthn requires that the relying party knows its own endpoint. Now this could be taken from the requests requestURI and perhaps in future once context passing is done we could do that but at present Gitea expects the root URL to be right.

@zeripath commented on GitHub (Feb 1, 2022): Setting the app_id correctly should work for previously registered u2f keys but if your root_url is not your real root URL you may have difficulties registering new keys. Webauthn requires that the relying party knows its own endpoint. Now this could be taken from the requests requestURI and perhaps in future once context passing is done we could do that but at present Gitea expects the root URL to be right.

GiteaMirror commented

@mscherer commented on GitHub (Feb 1, 2022):

In my case, the forge is behind a apache httpd proxy, and that was the U2F config (out of ansible, just expanded {{ vhost }} to forge.example.org)

[U2F]

APP_ID = https://forge.example.org/
TRUSTED_FACETS = https://forge.example.org

And ROOT_URL:

ROOT_URL = https:/forge.example.org

I tried moving ROOT_URL to APP_ID, didn't work.

I guess I mixed the / in the wrong order or something in the past. Now, I removed the U2F section. I have backups of my DB, so I can take a look if there is more information needed. The host is using the upstream binaries, tested with firefox and 2 yubikey nano.

@mscherer commented on GitHub (Feb 1, 2022): In my case, the forge is behind a apache httpd proxy, and that was the U2F config (out of ansible, just expanded {{ vhost }} to forge.example.org) ``` [U2F] APP_ID = https://forge.example.org/ TRUSTED_FACETS = https://forge.example.org ``` And ROOT_URL: ``` ROOT_URL = https:/forge.example.org ``` I tried moving ROOT_URL to APP_ID, didn't work. I guess I mixed the / in the wrong order or something in the past. Now, I removed the U2F section. I have backups of my DB, so I can take a look if there is more information needed. The host is using the upstream binaries, tested with firefox and 2 yubikey nano.

GiteaMirror commented

@beedaddy commented on GitHub (Feb 1, 2022):

I also faced this issue after updating to 1.16.0. APP_ID, ROOT_URL etc. was already set correctly. I could login via smartphone (2FA-app) and then I could remove and re-add my Nitrokey FIDO2 usb stick. Afterwards, 2FA with the stick worked again.

@beedaddy commented on GitHub (Feb 1, 2022): I also faced this issue after updating to 1.16.0. APP_ID, ROOT_URL etc. was already set correctly. I could login via smartphone (2FA-app) and then I could remove and re-add my Nitrokey FIDO2 usb stick. Afterwards, 2FA with the stick worked again.

GiteaMirror commented

@svenseeberg commented on GitHub (Feb 3, 2022):

Some of our users face the same issue. I triggered the 2FA reset in the user management for them, however the users are still seeing the error above.

I had to manually remove the old entries from the webauthn_credential SQL table.

@svenseeberg commented on GitHub (Feb 3, 2022): Some of our users face the same issue. I triggered the 2FA reset in the user management for them, however the users are still seeing the error above. I had to manually remove the old entries from the `webauthn_credential` SQL table.

GiteaMirror commented

@zeripath commented on GitHub (Feb 3, 2022):

Honestly - I'd need to know more about your situations in order to advise.

Are these users all using a particular browser? My suspicion is that Firefox has completely switched off U2F support including fallback support.
Are your ROOT_URLs correct? WebAuthn requires that the ROOT_URL exactly matches the real application url?
Were you using TRUSTED_FACETS previously?

WebAuthn is not a one-to-one replacement for U2F. We've tried to migrate and provide backwards support but it relies on the browsers allowing that backwards support.

@zeripath commented on GitHub (Feb 3, 2022): Honestly - I'd need to know more about your situations in order to advise. 1. Are these users all using a particular browser? My suspicion is that Firefox has completely switched off U2F support including fallback support. 2. Are your ROOT_URLs correct? WebAuthn requires that the ROOT_URL exactly matches the real application url? 3. Were you using TRUSTED_FACETS previously? WebAuthn is not a one-to-one replacement for U2F. We've tried to migrate and provide backwards support but it relies on the browsers allowing that backwards support.

GiteaMirror commented

@grisu48 commented on GitHub (Feb 3, 2022):

Honestly - I'd need to know more about your situations in order to advise.
1. Are these users all using a particular browser? My suspicion is that Firefox has completely switched off U2F support including fallback support.

I had this issue in Firefox and in Chromium.

2. Are your ROOT_URLs correct? WebAuthn requires that the ROOT_URL exactly matches the real application url?

Yes, the ROOT_URL is pointing to the publicly available https link of the instance. I didn't had the [U2F] block when the issue arised.

3. Were you using TRUSTED_FACETS previously?

Nope and I could not find this setting in my app.ini (not can i find it on https://docs.gitea.io/en-us/config-cheat-sheet/)

WebAuthn is not a one-to-one replacement for U2F. We've tried to migrate and provide backwards support but it relies on the browsers allowing that backwards support.

@grisu48 commented on GitHub (Feb 3, 2022): > Honestly - I'd need to know more about your situations in order to advise. > > 1. Are these users all using a particular browser? My suspicion is that Firefox has completely switched off U2F support including fallback support. I had this issue in Firefox and in Chromium. > > 2. Are your ROOT_URLs correct? WebAuthn requires that the ROOT_URL exactly matches the real application url? Yes, the `ROOT_URL` is pointing to the publicly available https link of the instance. I didn't had the `[U2F]` block when the issue arised. > > 3. Were you using TRUSTED_FACETS previously? Nope and I could not find this setting in my `app.ini` (not can i find it on https://docs.gitea.io/en-us/config-cheat-sheet/) > > > WebAuthn is not a one-to-one replacement for U2F. We've tried to migrate and provide backwards support but it relies on the browsers allowing that backwards support.

GiteaMirror commented