MYSQL: Database error on installation

[pree]

• Gitea version (or commit ref): 447c9b4
• Git version: 2.1.4
• Operating system: Debian
• Database (use [x]):
  • PostgreSQL
  • 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/Schizopriest/d6ccdad0170812dfb5bc510f8c283d76

Description

Getting the following Database Error when installing on a empty Database.
Database setting is not correct: Error 1170: BLOB/TEXT column 'key_id' used in key specification without a key length

MySQL-Server Version: 10.0.30-MariaDB-0+deb8u1

Screenshots

[lunny]

We haven't tested on Mariadb although it should be the same as MySQL.

[cez81]

Just tested this on a fresh install of prebuilt 1.1.0 with 10.0.29-MariaDB-0ubuntu0.16.04.1 on Ubuntu 16.04. InnoDB as engine.
It installs without any errors for me. Been using MariaDB on my production setup without any problems.

Edit:: But 1.1.0+38-gf1d2f16 fails...

[Diablofan]

I can confirm this happening with MariaDB as well. Tried using the docker image 81f5b797cd07 (latest as of March 16 at 5:41 PM EST), and I was getting this error when trying a fresh install of gitea. Trying with the image tagged 1.1.0 works just fine.

[lunny]

Oh, maybe it's effected by GPG PR. Let me check.

[lunny]

This is the bug here. A text column should not be a index. https://github.com/go-gitea/gitea/blob/master/models/gpg_key.go#L23 @sapk what's the max length of a key_id?

[sapk]

From https://tools.ietf.org/html/rfc4880#section-12.2 "The Key ID is the
low-order 64 bits of the fingerprint." So in hex 64/4 = 16 char

[sapk]

and in fact it's not even usefull to be a index since. I don't use the keyid to find key.

[gzsombor]

Changing from "INDEX TEXT NOT NULL" to "TEXT NOT NULL" solves the problem - at least for me.

[lunny]

@sapk so maybe we change the tag from INDEX TEXT NOT NULL to CHAR(16) NOT NULL to resolve this?

[sapk]

it should but I can't test right now.

[lunny]

I will send a PR to fix this.

[sapk]

In fact we could even use a uint64 ?

[sapk]

I have found maybe a optimization for validating more "quickly" since keyid is in signature but not I will have to test it a lot. So repassing #1150 in WIP

[sapk]

I use string because I use it as a string but the value is a uint64 even for primaryId. @lunny you can PR the change proposed CHAR(16) NOT NULL I will test it more of we can optimize DB for validation in #1150

[lunny]

OK

[sapk]

To be more simple it will stay in string format for DB since it will limit format at display but I will use https://github.com/golang/crypto/blob/master/openpgp/packet/public_key.go#L705 the same func to transform uint64 of the keyid store in sign to search only for the good key and not pass over each key of user.