Salut l'ami,
Pour ce premier journal, je me suis permis un titre un brin provocateur, mais après tout, c'est vendredi, et on se doit d'être bleu métal.
Il y a quelques jour, en recompilant mon projet suite à une mise à jour de Qt dont il dépend, j'ai obtenu avec stupeur l'erreur suivante :
/usr/bin/ld: /usr/lib64/libk5crypto.so.3: undefined reference to `EVP_KDF_derive@OPENSSL_1_1_1b'
/usr/bin/ld: /usr/lib64/libk5crypto.so.3: undefined reference to `EVP_KDF_ctrl@OPENSSL_1_1_1b'
/usr/bin/ld: /usr/lib64/libk5crypto.so.3: undefined reference to `EVP_KDF_CTX_free@OPENSSL_1_1_1b'
/usr/bin/ld: /usr/lib64/libk5crypto.so.3: undefined reference to `EVP_KDF_CTX_new_id@OPENSSL_1_1_1b'
Étonnamment, mes collègues s'étant occupés du bump de Qt n'ont pas eu le moindre souci.
Après investigation, il s'avère que la mise à jour de la lib QtNetwork ajoute une dépendance sur cette libk5crypto.so (il s'agit de Kerberos). Dans notre projet, nous construisons et fournissons nos libs OpenSSL, notamment pour ne pas avoir de soucis de compatibilité sur les distros trop anciennes.
Donc, notre projet link avec notre lib OpenSSL, et la lib kerberos de Fedora, qui ne sont pas binary-compatible, car la lib kerberos dépend d'openssl shippée par Fedora. Pour le "semver", on repassera, car au final la version 1.1.1k de Fedora n'est pas compatible avec notre OpenSSL 1.1.1d.
Quelques recherches plus tard, je ne suis pas le seul à avoir rencontrer ce problème, et il s'avère spécifique à Fedora.
Bon, la raison est plutôt simple, Fedora a décidé de backporter EVP_KDF dans ses libs. Cette feature est pourtant prévue pour OpenSSL 3 : https://wiki.openssl.org/index.php/EVP_Key_Derivation
OpenSSL 3.0 additionally provides Single Step KDF, SSH KDF, PBKDF2, Scrypt, HKDF, ANSI X9.42 KDF, ANSI X9.63 KDF and TLS1 PRF KDF by way of EVP_KDF.
On peut lire également sur cette page :
If compatibility with OpenSSL 1.1.1 is required then a limited set of KDFs can be used via EVP_PKEY_derive.
Je me demande bien quelles sont les raisons qui font que sur Fedora, les mainteneurs aient malgré eu besoin de backporter ça, alors qu'une autre solution est préconisée par OpenSSL. Je suis preneur si tu as des infos là dessus.
Mais ce n'est pas tout, j'ai été un peu effaré de lire ce ticket du bugtracker Redhat : https://bugzilla.redhat.com/show_bug.cgi?id=1829790
On y lit notamment les critiques des mainteneurs sur le fait qu'un logiciel fournisse ses propres libs :
this means those products are using most probably outdated libraries w/o getting CVE bugfixes when the system gets them.
I would open a bug report upstream to stop doing this stupdi library interposing on all systems and do it only where the proper library version is missing (arguably they do this to handle RHEL/CentOS 6 which are stuck on openssl 1.0.2).
Et aussi :
There is nothing to be fixed on Fedora side.
Alors certes, on peut se poser la question du bien-fondé de packager des libs OpenSSL dans un logiciel Linux en 2021. Par contre cette attitude arrogante de la part des mainteneurs Fedora me parait bien osée : ils backportent une feature d'OpenSSL qui est actuellement en version alpha, donc probablement pas ou peu auditée au niveau sécu. Tout en présumant de l'incapacité des autres à maintenir du OpenSSL à jour. Bref.
Je terminerai sur une citation de ce bon vieux Linux, qui me parait appropriée:
We make binaries for Windows and OSX, we basically don't make binaries for Linux. Why? Because making binaries for Linux desktop applications is a major fucking pain in the ass.
Et toi l'ami, qu'en penses-tu ?
# bien-fondé
Posté par Psychofox (Mastodon) . Évalué à 9. Dernière modification le 16 avril 2021 à 09:32.
Les deux points de vues ont du sens mais je ne vois pas vraiment ou est le problème. Tu n'as qu'à linké et fournir aussi ta libk5crypto.so, libQT & Co et problème réglé non ?
Je veux dire, soit tu n'embarque pas de librairie packagée par les distros, soit tu embarques toutes les dépendances que tu as besoin pour que ça fonctionne avec juste une libc. Embarquer juste une lib et pas les autres, c'est faire les choses à moitié et chercher les problèmes.
[^] # Re: bien-fondé
Posté par Kabouin . Évalué à 3.
Certes, une solution potentielle est également de compiler et fournir la libk5crypto. Bon, d'un part on s'expose à tirer une grosse pelotte de libs, et cela illustre aussi le souci plus général de livrer du logiciel sous Linux : ll faut arriver à fournir ce qui est nécessaire, mais sans trop en mettre non plus. Tout en restant compatible avec les distros qu'on souhaite supporter.
Pour le coup, on va plutôt arrêter de shipper OpenSSL, ce qui casse la compat avec Debian 9 pour nous. Mais bon, je crois qu'on peut se le permettre.
L'autre solution pérenne me semble être de livrer des AppImage ou équivalent. Mais je ne connais pas suffisamment ces outils pour en être certain.
[^] # Re: bien-fondé
Posté par paulez (site web personnel) . Évalué à 6.
Les solutions pour livrer un logiciel avec un environnement fixe existent, AppImage comme tu l’as mentionné, Flatpak et Snap.
Livrer ses logiciels avec ses propres versions de lib c’est de la grosse bidouille qui n’a pas lieu d’être à mon avis maintenant que ces solutions existent. Donc je rejoins l’avis du mainteneur Fedora.
Le fait de livrer sa propre version d’OpenSSL ne pose pas problème uniquement pour le protocole SSL, n’importe quelle lib peut-être utilisée comme vecteur d’attaque, comme par exemple exécuter du code avec une vulnérabilité d’une lib PNG.
Au niveau des backports, chaque distro le fait plus moins pour diverses raisons, difficile donc de juger sans plus de contexte.
# Au sujet du backport
Posté par Misc (site web personnel) . Évalué à 7.
Perso, je pense déjà que les soucis de sécurité autour de la crypto sont assez souvent exagérés. Je veux pas dire par la que ça n'existe pas, ni que c'est pas important et qu'il faut s'en foutre. Mais c'est une question de contexte.
L'exemple donné dans le rapport de bug, c'est matlab. Je pense que matlab, c'est pas exactement le soft que quelqu'un va attaquer via une attaque crypto. Pourquoi se faire chier à faire du MITM quand les gens vont sans doute rajouter un module "notamalware.py" de 345 000 lignes de python pour aller plus vite si une réponse sur stackoverflow leur dit de faire ça ?
Par contre, la ou c'est important de garder openssl à jour, c'est pour avoir les nouveaux algos, et donc permettre au reste du monde d'aller de l'avant pour les cas ou c'est plus important. Mais c'est rarement la raison donné, parce que tout le monde s'en fout un peu de la maintenance.
Tu dis aussi que la fonctionnalité n'a pas été audité, c'est faux, le backport est visiblement aussi dans RHEL 8 (cf https://github.com/openssl/openssl/issues/11471 ), et donc a été audité avant backport.
De plus, si on regarde la fonction en question, c'est un algo standardisé de hash (https://wiki.openssl.org/index.php?title=EVP_Key_Derivation). Il peut y avoir des bugs bien sur, mais je pense que tu peux vérifier assez facilement que ça marche comme il faut. Il n'y a pas de communication avec le réseau, pas de traitement complexe d'un format, un résultat déterministe, donc je pense que le risque est assez faible. Si il y a un souci, c'est dans l'algo plus que dans le code, et l'algo est publique.
Maintenant, oui, le versionnage sous Linux, c'est un peu n'importe quoi, et la gestion des ABIs, c'est pas vraiment ça.
Et je comprends effectivement le souci que ça pose à des ISVs qui veulent légitimement avoir 1 seul build pour Linux.
Je suis assez vieux pour me souvenir de la LSB. Je suis aussi assez jeune pour voir que y a pas eu de nouvelles versions depuis 2015.
[^] # Re: Au sujet du backport
Posté par barmic 🦦 . Évalué à 5.
D'une part je pense que considérer le backport d'une version de développement vers une version stable (quand ça n'est pas la logique upstream) comme un processus de mise à jour est discutable. La branche 1.1.1 est en développement actif (dernière version il y a 22 jours version précédente le 26 février), on ne peut pas dire qu'il s'agit d'un legacy.
Debian a prouvé que faire des choses dans son coin était risqué, des fois cela se cache dans les détails, dans la manière dont ils ont vérifier leurs backports. Je trouve bien plus sûr de ne pas tenter de faire des bricolages dans son coin en particulier pour des éléments qui impliquent de la sécurité (sans attaque sur openssl, réduire la solidité de l'entropie qu'il utilise est déjà un problème).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Au sujet du backport
Posté par Toto . Évalué à 6.
Ce qu'il faut voir aussi, c'est que OpenSSL est un soft de crypto, et que de nombreux organismes souhaitent une version certifiée FIPS de leur brique crypto.
Actuellement, il n'existe plus de version FIPS d'OpenSSL. La dernière en date est la 1.0.2, et la prochaine sera la 3.0, qui est toujours en développement.
RH (et Ubuntu (?)) ont fait certifier leur version 1.1.1 d'OpenSSL.
Mon hypothèse (flemme de vérifier :)) est qu'ils aient backporter les modifs importantes de la 3.0 (donc ces fonctions) vers la 1.1.1 pour minimiser les efforts pour créer le dossier FIPS en se basant au maximum sur les documents produits/en cours de productions pour la version 3.0. Cela permet de conserver la version 1.1.1 (stable et supportée) tout en minimisant les coûts de certifications
[^] # Re: Au sujet du backport
Posté par Misc (site web personnel) . Évalué à 5.
D'une part, je trouve que généraliser à partir d'un exemple datant d'il y a 10 ans est méthodologiquement faible.
Ensuite, la personne qui a fait le backport est listé ici:
https://src.fedoraproject.org/rpms/openssl/history/openssl-1.1.1-krb5-kdf.patch?identifier=rawhide
Son compte github est ici:
https://github.com/t8m
J'attire l'attention sur son profil:
"Software Developer at OpenSSL Software Foundation"
Mais à l'époque du patch (y a 1 an), il était encore employé par Red Hat à faire exactement la même chose dans mon souvenir (modulo s'occuper de RHEL).
Je doute qu'il soit parti "dans son coin" si il était déjà dev upstream, et contrairement à l'exemple du patch Debian dont tu parles, il y a eu des revues de code, et quelqu'un payé pour ça à temps plein avec des années d’expériences sur OpenSSL. Et l'état du code est meilleur qu'il y a 10 ans.
Et encore une fois, c'est une fonction de hash.
C'est déterministe par nature, il y a une spécification sous forme d'une RFC et il y a des tests (genre beaucoup de tests: https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/openssl-1.1.1-krb5-kdf.patch#_2476 , genre à vue de nez, 100 à 120 tests ).
[^] # Re: Au sujet du backport
Posté par barmic 🦦 . Évalué à 3.
Justement je ne généralise pas, je dis que sortir du processus de développement standard de la bibliothèque augmente le risque quelque soit la qualité du développeur.
Mais il a fait quelque chose :
Il a, j'en suis certain, de très bonnes raisons, mais pourquoi n'en faire profiter que Fedora et pas tous les utilisateurs d'openssl ?
Après un certains nombre d'années d’expérience, tu apprends que ce sont ces choses simples. Celles qui te font dire « oui mais c'est simple » qui sont de loin les plus dangereuses. C'est un biais humain qui n'est pas particulièrement lié à l'informatique. Les accidents d'escalade de gens d’expérience sont souvent liés à des nœuds mal voir pas fait) ils n'ont rien de complexe, il n'y a pas besoin d'aller vite, c'est juste qu'après l'avoir fais des milliers de fois ça devient machinal, on omet une vérif',…
Ce n'est pas le code de la fonction de hash le danger c'est :
Il a probablement fais toutes les vérifications du monde et tout fais comme il faut et c'est cool, mais il a pris un risque et je ne comprends pas pourquoi.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Au sujet du backport
Posté par Misc (site web personnel) . Évalué à 4.
Vu que le patch est aussi dans RHEL 8 (, je suppose qu'une dépendance en a besoin (exemple, freeipa)).
Par exemple, je vois que Simon Sorce a rajouté le support de SSH KDF:
https://github.com/openssl/openssl/commit/8d76481b189b7195ef932e0fb8f0e23ab0120771
Simo bosse sur GSS et FreeIPA, et le patch pour SSH KDF a aussi été backporté, par ses soins:
https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/openssl-1.1.1-ssh-kdf.patch
Donc je suppose qu'un truc plus haut qu'openssl avait besoin de la fonction, par exemple, un autre standard.
De la, à la place de Simo, tu as 3 choix:
- tu mets la version 3.0 alpha dans la distro (Fedora, RHEL). Faut que tu géres tout, c'est non supporté upstream.
tu mets juste ton patch qui vient d'upstream. Faut le gerer, mais tu as juste 1 fichier à regarder, et ça va pas impacter tout le reste d'openssl
tu attends et tu envoie chier ton chef et tes clients, en disant que Linuxfr ne comprendrais pas
Alors le dernier, c'est en général un assez mauvais plan. Si la raison est "ça va nous faire du travail", quand les gens payent pour ça, c'est pas trop la bonne excuse.
Le premier, c'est pas terrible non plus. On parle de la version 3.0, avec sans doute beaucoup de travail pour porter tout les logiciels, vu que l'API va changer. En plus, c'est encore une alpha.
Donc il reste que le second.
C'est aussi l'analyse de Toto en fait:
https://linuxfr.org/nodes/123979/comments/1849563
[^] # Re: Au sujet du backport
Posté par tisaac (Mastodon) . Évalué à 6.
Tiens, je vais la tenter celle-là. Bon, faudra aussi que je leur explique ce qu'est Linuxfr.
Je trouve que comme argument d'autorité, c'est assez imparable :-D
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Au sujet du backport
Posté par barmic 🦦 . Évalué à 2.
Ah non désolé si c'est ce qui a était compris je m'interroge sur la raison.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Tu te trompe de distro
Posté par Pol' uX (site web personnel) . Évalué à 3.
Fedora n'a pas pour ambition d'être bullet proof. Elle a pour ambition d'être tournée vers le futur. Si tu veux une distro bullet proof tu ne fais pas le bon choix (ou alors tu as une attitude arrogante paraissant bien osée par rapport au projet Fedora).
Adhérer à l'April, ça vous tente ?
[^] # Re: Tu te trompe de distro
Posté par Kabouin . Évalué à 1.
En vrai je veux juste une distro qui marche. Pour mon usage pro et perso. =)
Et si j'apprécie le fait qu'elle soit tournée vers le futur, ce cas là me parait un peu trop futuriste ;)
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Si c'était aussi simple...
Posté par vv222 . Évalué à 8.
Je suis développeur upstream d’un logiciel empaqueté pour plusieurs distributions. Et j’attends de la part des mainteneur qui se chargent de son empaquetage qu’ils commentent et critiquent les choix compliquant la redistribution de ce logiciel.
D’ailleurs ils ne s’en privent pas, et quand leurs critiques sont accompagnées de patchs ceux-ci sont généralement intégrés rapidement.
Les mainteneurs sont mieux placés que les développeurs pour connaître les problématiques liées à la distribution de logiciels, et à leur maintenance au sein d’environnements variés. Ne pas les écouter, c’est se priver d’une opportunité de ne pas répéter des erreurs identifiées depuis longtemps.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Si c'était aussi simple...
Posté par vv222 . Évalué à 3.
Oups, j’avais lu trop rapidement et compris « les logiciels qu’ils ne développent pas ».
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.