Project

General

Profile

Anomalie #1032

Champ pour identifiant GPG trop court

Added by Georges Racinet almost 2 years ago. Updated about 1 year ago.

Status:
Fermé
Priority:
Bas
Category:
Base de données
Target version:
Start date:
05/29/2017
Due date:
% Done:

100%

Estimated time:
Version utilisée:
Vote:

Description

Bonjour,

c'était une bonne surprise de voir un champ pour stocker les identifiants GPG, mais les 8 caractères sont trop courts pour les empreintes GPG2 et les 8 caractères ne sont plus du tout sûrs. Le fait que les collisions soient faciles à obtenir sur 8 caractères a fait pas mal de bruit récemment.

Les empreintes modernes, comme produites par GPG2 font 40 caractères (et plus si on ajoute des espaces comme on voit souvent)
Pour moi, on est quelque part entre l'anomalie (mineure) et l'évolution. Je comprendrais bien qu'on n'aie pas envie d'un script de migration SQL dans les versions 0.8 pour ça.

Associated revisions

Revision b53b093d (diff)
Added by Johan Cwiklinski about 1 year ago

Fix gpg ID field size; fixes #1032

History

#1

Updated by Johan Cwiklinski over 1 year ago

  • Target version set to 0.9.1

Du coup, quelle serait la taille à retenir ? 50 caractères semblent suffisants ; mais on peut aussi directement tabler sur 100.

#2

Updated by Georges Racinet over 1 year ago

Bah, difficile de prédire quelle sera la taille préconisée dans gpg3 ou gpg4. Je dirais donc que 50 seraient en effet suffisants (ou 40 à la rigueur).
Cela dit, ce que je recommanderais, c'est de normaliser en supprimant les espaces avant de stocker.

Exemple de sortie avec espaces (apt-key list sur une Debian) :

pub   rsa4096 2014-11-21 [SC] [expires: 2022-11-19]
126C 0D24 BD8A 2942 CC7D F8AC 7638 D044 2B90 D010

ou ma propre clef (gpg2 --list keys)

pub   rsa4096 2017-05-14 [SC]
BF5456F4DC625443849B6E58EE20CA44EF691D39

Et comme remarque finale, j'ajouterai qu'en PostgreSQL, varchar(length) n'est jamais que la même chose que text avec une contrainte en plus. Ça n'a pas d'incidence sur le stockage et donc n'est utile que pour l'applicatif, et non pour la base elle-même (je crois que c'est différent avec d'autres SGBD). Si jamais il y a moyen d'éviter des contraintes non souhaitées applicativement sans nuire à l'uniformité…

#3

Updated by Johan Cwiklinski over 1 year ago

Georges Racinet a écrit :

Bah, difficile de prédire quelle sera la taille préconisée dans gpg3 ou gpg4. Je dirais donc que 50 seraient en effet suffisants (ou 40 à la rigueur).
Cela dit, ce que je recommanderais, c'est de normaliser en supprimant les espaces avant de stocker.

Cela ne nuira-t-il pas à la "lisibilité" ?

Et comme remarque finale, j'ajouterai qu'en PostgreSQL, varchar(length) n'est jamais que la même chose que text avec une contrainte en plus. Ça n'a pas d'incidence sur le stockage et donc n'est utile que pour l'applicatif, et non pour la base elle-même (je crois que c'est différent avec d'autres SGBD). Si jamais il y a moyen d'éviter des contraintes non souhaitées applicativement sans nuire à l'uniformité…

Ha tiens, je ne savais pas... En MySQL ; il me semble que ce sont deux choses bien distinctes... Mais bon ; je ne pense pas qu'on en soit encore aujourd'hui à regarder à l'octet près en ce qui concerne la base ; il serait donc envisageable de passer ce chmp en text ; et ne plus avoir de problème de limité à l'avenir, oui.

#4

Updated by Johan Cwiklinski about 1 year ago

  • Status changed from Nouveau to Résolu
  • % Done changed from 0 to 100
#5

Updated by Johan Cwiklinski about 1 year ago

  • Status changed from Résolu to Fermé

Also available in: Atom PDF