U2F authentication fails with the message "Could not read your security key. An unknown error occured. Please retry." #2964

New Issue

GiteaMirror · 2025-11-02T04:55:28-06:00

GiteaMirror commented

2025-11-02 04:55:28 -06:00

Originally created by @mporrato on GitHub (Feb 23, 2019).

Gitea version (or commit ref): 1.7.1
Git version: 2.20.1
Operating system: Debian 9.8 (stretch)
Database (use [x]):
- PostgreSQL (version 9.6.11)
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist: https://gist.github.com/mporrato/251450f7786075a887ad21a1728a5407

Description

After upgrading the firmware of my U2F token, Gitea's U2F auth stopped working, showing the message "Could not read your security key. An unknown error occured. Please retry.".

The message in the log seems to refer to the token counter which is correctly defined as uint32 in the data model in dfad569e40/models/u2f.go (L20)
Looking at the table in the PostgreSQL database the field is defined as integer (which is a 32 bits signed value) instead:

gitea=# \d u2f_registration 
                                    Table "public.u2f_registration"
    Column    |          Type          |                           Modifiers                           
--------------+------------------------+---------------------------------------------------------------
 id           | bigint                 | not null default nextval('u2f_registration_id_seq'::regclass)
 name         | character varying(255) | 
 user_id      | bigint                 | 
 raw          | bytea                  | 
 counter      | integer                | 
 created_unix | bigint                 | 
 updated_unix | bigint                 | 
Indexes:
    "u2f_registration_pkey" PRIMARY KEY, btree (id)
    "IDX_u2f_registration_created_unix" btree (created_unix)
    "IDX_u2f_registration_updated_unix" btree (updated_unix)
    "IDX_u2f_registration_user_id" btree (user_id)

gitea=# select 4278190365::integer;
ERROR:  integer out of range

Workaround

After manually changing the counter column type to bigint, Gitea started accepting my U2F token again:

gitea=# alter table u2f_registration alter column counter type bigint;
ALTER TABLE
gitea=#

This is not a fresh install of 1.7.1 so the problem could be related to the database schema upgrades from previous versions, but from the git blame it looks like the model definition of that table hasn't changed since U2F was introduced in Gitea, so I believe it's more likely to be a problem with the
ORM Gitea is using (sorry, I don't know anything about Gitea internals).

Originally created by @mporrato on GitHub (Feb 23, 2019).  - Gitea version (or commit ref): 1.7.1 - Git version: 2.20.1 - Operating system: Debian 9.8 (stretch) - Database (use `[x]`): - [x] PostgreSQL (version 9.6.11) - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant - Log gist: https://gist.github.com/mporrato/251450f7786075a887ad21a1728a5407 ## Description After upgrading the firmware of my U2F token, Gitea's U2F auth stopped working, showing the message "Could not read your security key. An unknown error occured. Please retry.". The message in the log seems to refer to the token counter which is correctly defined as `uint32` in the data model in https://github.com/go-gitea/gitea/blob/dfad569e40edf86346a10d11bc68c98c12bca30d/models/u2f.go#L20 Looking at the table in the PostgreSQL database the field is defined as `integer` (which is a 32 bits *signed* value) instead: ``` gitea=# \d u2f_registration Table "public.u2f_registration" Column | Type | Modifiers --------------+------------------------+--------------------------------------------------------------- id | bigint | not null default nextval('u2f_registration_id_seq'::regclass) name | character varying(255) | user_id | bigint | raw | bytea | counter | integer | created_unix | bigint | updated_unix | bigint | Indexes: "u2f_registration_pkey" PRIMARY KEY, btree (id) "IDX_u2f_registration_created_unix" btree (created_unix) "IDX_u2f_registration_updated_unix" btree (updated_unix) "IDX_u2f_registration_user_id" btree (user_id) gitea=# select 4278190365::integer; ERROR: integer out of range ``` ## Workaround After manually changing the `counter` column type to `bigint`, Gitea started accepting my U2F token again: ``` gitea=# alter table u2f_registration alter column counter type bigint; ALTER TABLE gitea=# ``` This is not a fresh install of 1.7.1 so the problem could be related to the database schema upgrades from previous versions, but from the git blame it looks like the model definition of that table hasn't changed since U2F was introduced in Gitea, so I believe it's more likely to be a problem with the ORM Gitea is using (sorry, I don't know anything about Gitea internals).

GiteaMirror added the type/bug label 2025-11-02 04:55:28 -06:00

GiteaMirror closed this issue

2025-11-02 04:55:28 -06:00

GiteaMirror commented

2025-11-02 04:55:29 -06:00

@0x5c commented on GitHub (Feb 25, 2019):

Anything in the xorm logs?

@0x5c commented on GitHub (Feb 25, 2019): Anything in the xorm logs?

GiteaMirror commented

2025-11-02 04:55:29 -06:00

@mporrato commented on GitHub (Feb 26, 2019):

Nothing meaningful to me in xorm.log: I've updated the gist with an extract from xorm.log.
In the meantime I created a working patch here: 4b533be3c1 : the schema it creates has the counter column defined as bigint. Doesn't look a clean fix to me, but It's the best I can think of since PostgreSQL doesn't have unsigned integer types.
I think xorm is at fault here: it shouldn't assume the database's integer type can hold an uint32.

@mporrato commented on GitHub (Feb 26, 2019): Nothing meaningful to me in xorm.log: I've updated the gist with an extract from xorm.log. In the meantime I created a working patch here: https://github.com/mporrato/gitea/commit/4b533be3c1e4155ce4e5dfc49a68d5ffb640fde7 : the schema it creates has the counter column defined as bigint. Doesn't look a clean fix to me, but It's the best I can think of since PostgreSQL doesn't have unsigned integer types. I think xorm is at fault here: it shouldn't assume the database's integer type can hold an uint32.

GiteaMirror referenced this issue

2025-11-02 12:16:52 -06:00

[PR #2999] [MERGED] Document updated proposal process #16708

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#2964