Projet

Général

Profil

Bug #35584

pycrypto n'est plus maintenu

Ajouté par Éloi Rivard il y a plus de 4 ans. Mis à jour il y a plus de 4 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
26 août 2019
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

Bonjour,
En lançant les tests avec tox (sur tous les environnements), sur une ArchLinux à jour, j'ai une erreur lors de l'installation de la dépendance pycrypto (voir PJ). Plusieurs tickets de bug (https://github.com/dlitz/pycrypto/issues/173) sur la forge du projet font mention qu'il est abandonné depuis longtemps.

pycryptodome (https://github.com/Legrandin/pycryptodome) semble être un fork actuel et maintenu, avec une compatibilité ascendante.

En remplaçant la dépendance à pycrypto par pycryptodome dans setup.py, je n'ai plus l'erreur lors de la création de l'environnement avec tox.


Fichiers

pycrypto.txt (41,9 ko) pycrypto.txt Éloi Rivard, 26 août 2019 16:12
0001-crypto-ensure-that-aes-cipher-salts-are-bytes-35584.patch (1,42 ko) 0001-crypto-ensure-that-aes-cipher-salts-are-bytes-35584.patch Paul Marillonnet, 27 août 2019 12:15
0002-crypto-key-derivation-must-have-at-least-one-iterati.patch (976 octets) 0002-crypto-key-derivation-must-have-at-least-one-iterati.patch Paul Marillonnet, 27 août 2019 12:15
0003-crypto-discard-deprecated-pycrypto-dependency-35584.patch (1,89 ko) 0003-crypto-discard-deprecated-pycrypto-dependency-35584.patch Paul Marillonnet, 27 août 2019 12:15
0003-crypto-discard-deprecated-pycrypto-dependency-35584.patch (1,87 ko) 0003-crypto-discard-deprecated-pycrypto-dependency-35584.patch Paul Marillonnet, 27 août 2019 16:22
0001-crypto-ensure-that-aes-cipher-salts-are-bytes-35584.patch (1,42 ko) 0001-crypto-ensure-that-aes-cipher-salts-are-bytes-35584.patch Paul Marillonnet, 17 septembre 2019 17:09
0002-crypto-key-derivation-must-have-at-least-one-iterati.patch (976 octets) 0002-crypto-key-derivation-must-have-at-least-one-iterati.patch Paul Marillonnet, 17 septembre 2019 17:09
0003-debian-discard-deprecated-pycrypto-dependency-whenev.patch (1,74 ko) 0003-debian-discard-deprecated-pycrypto-dependency-whenev.patch Paul Marillonnet, 17 septembre 2019 17:09
0004-WIP-debian-pull-pycryptodome-from-stretch-backports-.patch (1,63 ko) 0004-WIP-debian-pull-pycryptodome-from-stretch-backports-.patch Paul Marillonnet, 17 septembre 2019 17:09
0003-debian-discard-deprecated-pycrypto-dependency-whenev.patch (1,72 ko) 0003-debian-discard-deprecated-pycrypto-dependency-whenev.patch Paul Marillonnet, 30 octobre 2019 16:07

Révisions associées

Révision 5f35895c (diff)
Ajouté par Paul Marillonnet il y a plus de 4 ans

crypto: ensure that aes cipher salts are bytes (#35584)

Révision 072f3677 (diff)
Ajouté par Paul Marillonnet il y a plus de 4 ans

crypto: key-derivation must have at least one iteration (#35584)

Révision c8ce9fdd (diff)
Ajouté par Paul Marillonnet il y a plus de 4 ans

debian: discard deprecated pycrypto dependency (#35584)

Historique

#1

Mis à jour par Paul Marillonnet il y a plus de 4 ans

  • Assigné à mis à Paul Marillonnet

Merci, je vais regarder ça.

#2

Mis à jour par Paul Marillonnet il y a plus de 4 ans

  • Statut changé de Nouveau à En cours
#4

Mis à jour par Thomas Noël il y a plus de 4 ans

Attention, pycryptodome n'est pas disponible en Debian Stretch (uniquement en backports), aussi je ne sais pas si c'est déjà le bon moment.

#5

Mis à jour par Paul Marillonnet il y a plus de 4 ans

Thomas Noël a écrit :

Attention, pycryptodome n'est pas disponible en Debian Stretch (uniquement en backports), aussi je ne sais pas si c'est déjà le bon moment.

Bien vu. À voir maintenant si on préfère une dépendance non packagée pour la version de Debian que l'on supporte actuellement, à une dépendance obsolète (dernier commit en date : juin 2014).

Est-ce qu'on a déjà une date ou une feuille de route pour le passage de Publik en Debian Buster ?

#6

Mis à jour par Frédéric Péters il y a plus de 4 ans

Comme l'API ne change pas, on peut faire les modifs côté setup.py, laisser le côté debian*/ intact, etc.

#7

Mis à jour par Paul Marillonnet il y a plus de 4 ans

Frédéric Péters a écrit :

laisser le côté debian*/ intact, etc.

Tu veux dire laisser intacte la colonne de droite pour chacun de ces deux fichiers pydist-overrides ?

#9

Mis à jour par Frédéric Péters il y a plus de 4 ans

Tu veux dire laisser intacte la colonne de droite pour chacun de ces deux fichiers pydist-overrides ?

Je veux dire ne rien toucher sous debian/.

#10

Mis à jour par Paul Marillonnet il y a plus de 4 ans

Frédéric Péters a écrit :

Je veux dire ne rien toucher sous debian/.

Alors je ne comprends pas le lien avec le fait que l'API ne change pas, comme tu l'expliques plus haut.

Je ne serais pas pour qu'on laisse des références à pycrypto dans debian/ alors que ce n'est plus une dépendance du projet.

#11

Mis à jour par Frédéric Péters il y a plus de 4 ans

Je ne serais pas pour qu'on laisse des références à pycrypto dans debian/ alors que ce n'est plus une dépendance du projet.

Le projet fait from Crypto import whatever. Pour que cette ligne fonctionne dans une version installée via le paquet debian il faut une dépendance du paquet sur python-crypto, c'est ce qu'il y a aujourd'hui, tout va bien.

Pour que cette ligne fonctionne dans une version installée via pip, dans un environnement où pycrypto ne s'installe pas pour une raison ou une autre (RuntimeError("autoconf error")), il suffit de remplacer la référence dans setup.py à pycrypto par pycryptodome.

#12

Mis à jour par Paul Marillonnet il y a plus de 4 ans

Frédéric Péters a écrit :

il faut une dépendance du paquet sur python-crypto, c'est ce qu'il y a aujourd'hui, tout va bien.

Ok, merci pour ton explication, je comprends mieux ton raisonnement. Mais il me semble que non, cette dépendance du paquet debian à python-crypto n'existe pas (python-authentic2 dépend de python-jwcrypto et de python-cryptography, mais pas de python-crypto).

#13

Mis à jour par Paul Marillonnet il y a plus de 4 ans

Paul Marillonnet a écrit :

Ok, merci pour ton explication, je comprends mieux ton raisonnement. Mais il me semble que non, cette dépendance du paquet debian à python-crypto n'existe pas (python-authentic2 dépend de python-jwcrypto et de python-cryptography, mais pas de python-crypto).

Pardon, au temps pour moi, un apt-cache depends python-authentic2 me prouve le contraire. Je ne sais pas où dans les répertoires debian*/ est introduite cette dépendance (ça m'étonnerait que ce soit la mention du paquet dans les fichiers pydist-overrides qui fasse ça), je chercherai le fin mot de l'histoire dès que j'ai un peu de temps.

#14

Mis à jour par Paul Marillonnet il y a plus de 4 ans

Paul Marillonnet a écrit :

(ça m'étonnerait que ce soit la mention du paquet dans les fichiers pydist-overrides qui fasse ça)

Et bien justement si ☺
Je ne sais plus ce que je me suis imaginé que ça pouvait faire d'autre, hier à la lecture de la page de manuel de dh_python2...

#15

Mis à jour par Paul Marillonnet il y a plus de 4 ans

Et donc je reste campé sur l'idée que faire référence à pycrypto dans pydist-overrides, et non pas à pycryptodome, va casser cette dépendance debian à python-crypto. Je vais utiliser eobuilder pour générer en local un paquet debian, sans toucher à pydist-overrides comme tu le suggères, pour tâcher de vérifier mon hypothèse.

#16

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

Paul Marillonnet a écrit :

Et donc je reste campé sur l'idée que faire référence à pycrypto dans pydist-overrides, et non pas à pycryptodome, va casser cette dépendance debian à python-crypto. Je vais utiliser eobuilder pour générer en local un paquet debian, sans toucher à pydist-overrides comme tu le suggères, pour tâcher de vérifier mon hypothèse.

Dans la mesure où pycryptodome est disponible dans stretch-backports je dirai de simplement le recopier dans notre dépôt stretch pour éviter les soucis de mise à jour chez nos clients non "pupettisés" et de passer complètement à pycryptodome, et aussi d'indiquer de le tirer de stretch-backports au cas où (mise à jour) au niveau du puppet.

#17

Mis à jour par Paul Marillonnet il y a plus de 4 ans

Paul Marillonnet a écrit :

Et donc je reste campé sur l'idée que faire référence à pycrypto dans pydist-overrides, et non pas à pycryptodome, va casser cette dépendance debian à python-crypto. Je vais utiliser eobuilder pour générer en local un paquet debian, sans toucher à pydist-overrides comme tu le suggères, pour tâcher de vérifier mon hypothèse.

Une lecture des sources de dh-python me conforte dans cette idée :
1. la fonction dhpython.pydist.load1 initialise les substitutions aux paquets Debian candidates lors de la construction du paquet.
2. la fonction dhpython.pydist.guess_dependency2 vérifie que les substitutions candidates correspondent bien à des modules python en dépendance du paquet à construire.

1 https://github.com/p1otr/dh-python/blob/master/dhpython/pydist.py#L92

2 https://github.com/p1otr/dh-python/blob/master/dhpython/pydist.py#L134

Et donc, je peux ajouter autant de lignes que je veux dans le fichier debian/pydist-overrides, elles ne seront pas prises en compte si elles ne correspondent pas à des dépendances effectives du module à partir duquel on construit le paquet.

#18

Mis à jour par Frédéric Péters il y a plus de 4 ans

Et donc, si elle ne peut être trouvée, mentionner de manière explicite la dépendance dans le paquet, façon

--- a/debian/control
+++ b/debian/control
@@ -32,6 +32,7 @@ Depends: ${misc:Depends}, ${python:Depends},
     python-tablib,
     python-chardet,
     python-attr (>=17),
+    python-crypto,
     python-atomicwrites
 Breaks: python-authentic2-auth-fc (<< 0.26)
 Replaces: python-authentic2-auth-fc (<< 0.26)

Ou si tu veux,

--- a/debian/control
+++ b/debian/control
@@ -32,6 +32,7 @@ Depends: ${misc:Depends}, ${python:Depends},
     python-tablib,
     python-chardet,
     python-attr (>=17),
+    python-cryptodome | python-crypto,
     python-atomicwrites
 Breaks: python-authentic2-auth-fc (<< 0.26)
 Replaces: python-authentic2-auth-fc (<< 0.26)

Ou faire comme Benjamin notait et copier un paquet dans nos dépôts. (et faire attention à ce que ça soit aussi ok pour jessie, ou virer jessie, etc.).

Bref pour moi pousser ce patch en l'état fera un paquet qui ne s'installera pas.

#19

Mis à jour par Paul Marillonnet il y a plus de 4 ans

Frédéric Péters a écrit :

Et donc, si elle ne peut être trouvée, mentionner de manière explicite la dépendance dans le paquet, façon
[...]
Bref pour moi pousser ce patch en l'état fera un paquet qui ne s'installera pas.

Oui, bien vu, merci. Corrigé ici.

Pour favoriser l'utilisation de pycryptodome dans Stretch, plutôt que de le copier dans nos dépôts,est-ce qu'on ne pourrait pas faire quelque chose dans l'esprit de ce patch 0004-WIP (moyennant de le faire correctement, sans doute dans un dossier à part nommé debian-stretch à la racine des sources a2) ?

#20

Mis à jour par Frédéric Péters il y a plus de 4 ans

Sur 0004, nos serveurs sont déjà configurés pour connaitre les paquets de stretch-backports, il n'y a pas de preferences ou sources.list à ajouter (qui n'auraient pas leur place dans authentic).

#21

Mis à jour par Paul Marillonnet il y a plus de 4 ans

Frédéric Péters a écrit :

Sur 0004, nos serveurs sont déjà configurés pour connaitre les paquets de stretch-backports, il n'y a pas de preferences ou sources.list à ajouter (qui n'auraient pas leur place dans authentic).

Oui, c'est vrai. Reste donc, si j'ai bien compris, à copier ce paquet python-pycryptodome dans nos dépôts, à l'attention des serveurs échappant à Puppet.

(C'est l'occasion pour moi, qui ne connais pas cette procédure d'ajout d'un paquet dans nos dépôts, de lire de la doc (officielle debian, ou interne si elle existe) à ce sujet, et de voir ensuite si je suis en mesure de le faire moi-même.)

#22

Mis à jour par Frédéric Péters il y a plus de 4 ans

Toutes les installations Publik ont stretch-backports configuré.

#23

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

Je disais déjà de passer directement à python-cryptodome vu qu'on utilise déjà stretch-backports pour plein de trucs.

#24

Mis à jour par Paul Marillonnet il y a plus de 4 ans

Ok, je veux donc bien une relecture pour les trois premiers patches (#35584-19).

#25

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

  • Statut changé de Solution proposée à Solution validée

Rebase une branche sur les 3 premiers patchs et si ça build c'est bon pour moi.

#26

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

Benjamin Dauvergne a écrit :

Rebase une branche sur les 3 premiers patchs et si ça build c'est bon pour moi.

Je ne suis pas certain que laisser pycrypto même en alternative soit une bonne idée du moment que pycryptodome est dans le setup.py, tant qu'on utilise pkgresources pour chopper les plugin on a des soucis sur les noms des paquets dont on dépend.

#27

Mis à jour par Paul Marillonnet il y a plus de 4 ans

Et donc sortir complètement python-crypto de debian/control comme fait ici ?

#28

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

  • Statut changé de Solution proposée à Solution validée

Ouaip.

#29

Mis à jour par Paul Marillonnet il y a plus de 4 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit c8ce9fdd0a533fd635ce98adc8f7c9131956390e
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date:   Tue Aug 27 11:41:52 2019 +0200

    debian: discard deprecated pycrypto dependency (#35584)

commit 072f36779ae3fca756163f819884b116c92ec667
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date:   Tue Aug 27 12:09:09 2019 +0200

    crypto: key-derivation must have at least one iteration (#35584)

commit 5f35895c876aa96bc290b14243c3b7239669a47d
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date:   Tue Aug 27 12:03:11 2019 +0200

    crypto: ensure that aes cipher salts are bytes (#35584)
#30

Mis à jour par Frédéric Péters il y a plus de 4 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF