Projet

Général

Profil

Anomalie #1032

Champ pour identifiant GPG trop court

Ajouté par Georges Racinet il y a plus d'un an. Mis à jour il y a 11 mois.

Statut:
Fermé
Priorité:
Bas
Assigné à:
Catégorie:
Base de données
Version cible:
Début:
29/05/2017
Echéance:
% réalisé:

100%

Temps estimé:
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.

Révisions associées

Révision b53b093d (diff)
Ajouté par Johan Cwiklinski il y a 11 mois

Fix gpg ID field size; fixes #1032

Historique

#1 Mis à jour par Johan Cwiklinski il y a environ un an

  • Version cible mis à 0.9.1

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

#2 Mis à jour par Georges Racinet il y a environ un an

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 Mis à jour par Johan Cwiklinski il y a environ un an

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 Mis à jour par Johan Cwiklinski il y a 11 mois

  • Statut changé de Nouveau à Résolu
  • % réalisé changé de 0 à 100

#5 Mis à jour par Johan Cwiklinski il y a 11 mois

  • Statut changé de Résolu à Fermé

Formats disponibles : Atom PDF