Anomalie #1032
fermé
Champ pour identifiant GPG trop court
100%
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.
Mis à jour par Johan Cwiklinski il y a environ 7 ans
- 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.
Mis à jour par Georges Racinet il y a environ 7 ans
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 D010ou ma propre clef (gpg2 --list keys)
pub rsa4096 2017-05-14 [SC]
BF5456F4DC625443849B6E58EE20CA44EF691D39Et 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é…
Mis à jour par Johan Cwiklinski il y a environ 7 ans
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.
Mis à jour par Johan Cwiklinski il y a presque 7 ans
- Statut changé de Nouveau à Résolu
- % réalisé changé de 0 à 100
Appliqué par commit b53b093d9813dbe86e67cae20a41387e61602889.