gouttegd a écrit 1805 commentaires

Pour ce qui relève des noms cités en auteurs, c'est banal. La hiérarchie est presque toujours co-autrice, tous les chercheurs le savent.

Raoult signe tous les papiers qui sortent de son institut de recherche. Contrairement à ce que ses partisans prétendent, ce n’est pas et n’a jamais été une pratique acceptable.

Oui, l’ordre des noms sur un papier reflète typiqument la hiérarchie, celui cité en dernier (le “corresponding author”) étant normalement le plus haut placé de ceux qui ont contribué au papier.

Typiquement, le “corresponding author” est le chef de l’équipe de recherche (en anglais le group leader, on parle souvent aussi de PI pour principal investigator – on utilise parfois aussi ce terme dans les labos français).

Éventuellement, si le papier est une collaboration entre plusieurs équipes (d’un même institut ou non), les chefs de différentes équipes impliquées seront tous co-“corresponding authors”.

Mais il n’a jamais été courant ou acceptable de faire remonter la hiérarchie des auteurs au-delà de l’échelon « équipe de recherche ». Le directeur d’un institut n’a aucune légitimité à signer un papier au seul motif que l’équipe de recherche qui a réalisé les travaux est hébergée dans ledit institut.

En général, le directeur de l’institut est aussi le chef d’une des équipes de l’institut. Dans ce cas, il signe les papiers de son équipe, et pas plus. Il n’a rien à faire dans les papiers des autres équipes.

Alors oui elle synchronize mes photos et vidéos mais plus ou moins quand ça lui chante

J’ai effectivement constaté ça au début, mais je n’ai plus eu ce genre de problèmes, depuis environ un an je dirais.

Pour TLS, c’est à peu prêt pareil, on fera un TLS 1.4 et on migrera.

Euh, non. TLS 1.3 offre toujours l’agilité cryptographique.

La liste des algorithmes utilisables (cipher suites) a été considérablement réduite (en particulier, toutes les suites sans mode AEAD ont été éjectées), mais le principe même d’avoir une liste d’algorithmes dans laquelle choisir ceux à utiliser est toujours là et le protocole est toujours ouvert à l’introduction d’algorithmes non-listés dans le RFC original (par exemple les algorithmes russes GOST).

À ma connaissance le seul endroit où une forme d’agilité a été supprimée est la représentation des points sur les courbes elliptiques. TLS 1.2 autorisait plusieurs formats pour représenter ces points (d’où la nécessité de les négocier entre client et serveur, comme pour les algorithmes eux-mêmes), TLS 1.3 impose un format unique.

Je pense que l’idée est plutôt que le jour où ces algorithmes sont défaillants, on change le protocole pour en forcer d’autres et on laisse la transition à la charge de l’utilisateur.

J’ai déjà dit ce que je pensais de la faisabilité de cette approche. Si le futur me donne tort, je serai le premier à en être content, mais je n’y crois guère.

As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally.

Il s’agirait quand même de ne pas tout mettre sur le dos de l’agilité cryptographique.

Parmi toutes les attaques contre TLS, moi je n’en compte que deux qui ont été permises par l’agilité cryptographique : FREAK et LOGJAM, qui exploitent des failles dans la procédure de négociation des algorithmes pour forcer l’usage d’algorithmes ridiculement faibles.¹

Les autres attaques ? Voyons voir :

• L’attaque théorique de Vaudeney (2002), mise en pratique contre TLS par Canvel et al., 2003, une attaque temporelle (timing attack) ;
• Les attaques contre RC4 ;
• BEAST, une attaque contre le mode de chiffrement CBC ;
• CRIME, une attaque permise par la compression TLS ;
• DROWN, causée par le support continu (et complètement absurde) de SSLv2, un protocole que l’on sait complètement cassé depuis environ le lendemain de sa publication en 1995 ;
• Heartbleed, un bug d’OpenSSL ;
• Lucky13, une évolution de l’attaque de Canvel et al. (2003) (encore une attaque temporelle) ;
• POODLE, une padding attack contre le mode CBC (seulement rendue possible par le support continu de SSLv3) ;
• SLOTH, causée par le support continu de MD-5.
• Sweet32, une attaque contre les algorithmes de chiffrement par bloc opérant sur des blocs de 64 bits ;
• TIME et BREACH, semblables à CRIME mais avec la compression au niveau HTTP ;
• Triple Handshake, une faille dans le protocole d’établissement d’une connexion (handshake) ;

Il est certain que la complexité générale de TLS est à l’origine de certaines de ces attaques. Mais il n’y a pas que l’agilité cryptographique qui rend TLS complexe ! CRIME et Heartbleed par exemple sont dûes à des fonctionnalités accessoires (la compression pour CRIME et l’extension Heartbeat pour Heartbleed) — des fonctionnalités apparemment peu usitées de surcroît, ce qui rend leur présence dans un protocole de cryptographie assez contestables. Et d’autres protocoles que TLS supportent l’agilité cryptographique sans avoir un tel « palmarès » d’attaques (par exemple SSH).

On peut aussi noter que l’agilité cryptographique a permis d’offrir des contre-mesures immédiates à plusieurs de ces attaques, sans devoir attendre une mise à jour du protocole ou des implémentations (et c’est heureux, parce que vous avez vu le temps qu’il faut pour publier une nouvelle version de TLS ou pour avoir des implémentations à jour ? en 2015 on trouvait encore des serveurs et des clients qui ne supportaient pas TLS 1.2, publié en 2008…).

Par exemple, à la publication de BEAST (attaque contre CBC) en 2011, on a pu conseiller aux sysadmins de privilégier RC4 (qui n’était pas vulnérable, s’agissant d’un algorithme de chiffrement en flux). Deux ans plus tard, les attaques contre RC4 ont commencé à se faire un peu trop pressantes, mais ça a donné un répit de deux ans aux développeurs de bibliothèques TLS pour, soit implémenter des contre-mesures contre BEAST, soit (encore mieux) implémenter TLS 1.1+ (qui n’est plus vulnérable à BEAST), soit implémenter d’autres modes de chiffrement que CBC, voire les trois à la fois.

---

¹ Ce qui n’aurait posé aucun problème si serveurs et clients n’avaient pas continué à supporter les algorithmes ridiculement faibles en question, ce qui me ramène à un point avancé dans un autre message : il n’y a aucune raison pour que « agilité cryptographique » signifie forcément « supporter tous les algorithmes possibles et imaginables, même les plus pourris » — on peut être favorable à l’agilité sans pour autant se priver d’exclure les algorithmes cassés ou en passe de l’être.

Fournir aux développeurs une interface simple ne leur laissant pas la possibilité de faire n’importe quoi (ce qui en effet chaudement recommandé par tous les cryptologues aujourd’hui, on sent bien qu’à un moment ils ont en eu marre de se taper la tête contre les murs :D ) ne nécessite pas forcément de renoncer à l’agilité cryptographique et d’imposer un algorithme unique.

La bibliothèque Javascript SJCL par exemple offre l’interface la plus simple qui soit, impossible de l’utiliser de travers : deux fonctions, une pour chiffrer, une pour déchiffrer, prenant en paramètre les données à chiffrer ou déchiffrer et le mot de passe. Tous les choix algorithmiques sont effectuées par la bibliothèque elle-même, sans que le développeur ne puisse s’en mêler et donc faire des bêtises.

Pour autant, la bibliothèque et le format utilisé pour les données chiffrées permettent un minimum d’agilité cryptographique : l’algorithme de chiffrement, le mode d’opération, et les paramètres de l’algorithme de dérivation de clef ne sont pas fixés et peuvent être changés si besoin par les développeurs de SJCL (ou les développeurs d’une implémentation compatible) sans nécessiter un nouveau format ou la moindre rupture de rétro-compatibilité.

Ne pas supporter l’agilité cryptographique est un choix indépendant de la volonté (louable) de ne pas donner aux développeurs de quoi se tirer une balle dans le pied.

Auriez vous un exemple où un algorithme a été cassé du jour au lendemain avec un retour à 0 de la sécurité de l'algorithme ?

J’ai donné l’exemple de OCB2, qui depuis son introduction en 2004 était considéré parfaitement sûr. Puis en 2018, deux attaques coup sur coup : en octobre, une première attaque montre qu’on peut forger des messages (l’algorithme ne garantit pas l’authenticité, contrairement à ce qu’il devrait devrait — en soi c’est déjà une faille énorme, qui aurait été suffisante pour justifier un retrait immédiat de l’algorithme) ; le mois suivant, une autre attaque s’appuie sur la première pour pour casser la confidentialité et permettre de récupérer le texte clair (plaintext recovery attack). Cinq mois plus tard, un papier de synthèse ferme le ban pour ceux qui seraient lents à comprendre : OCB2 est cassé, kaput, les attaques sont praticables et effectives, il ne faut en aucun cas l’utiliser.

(La bonne nouvelle, c’est que quasiment personne n’utilisait OCB2 de toute façon, à cause des brevets qui pesaient dessus…)

Ce qui laisse du temps au développeurs de changer leur fusil d'épaule.

Juste parce que certains algorithmes ont effectivement été lentement érodés avant qu’on ne puisse les considérer comme effectivement vulnérables ne veut pas dire que ce sera systématiquement le cas, et miser là-dessus me semble très risqué.

AMHA, l'agilité cryptographique c'est important, mais seulement sur un set très limité d'algorithme et qui reste limité (genre 3 algos possibles, si un devient moins fiable, on le "deprecate" en le remplaçant par un autre et qui ne peut être utilisé que pour le décodage).

Absolument d’accord. Le problème du rejet de l’agilité cryptographique, c’est qu’on passe d’un extrême à l’autre. Avant c’était la foire et on acceptait 72 algorithmes dans le protocole (y compris des perles comme MD5, RC4, 3DES, etc.), maintenant c’est un algorithme epicétou !

On peut supporter l’agilité cryptographique tout en acceptant seulement une petite poignée d’algorithmes soigneusement choisis.

L’agilité cryptographique (le fait de ne pas lier un protocole à un algorithme donné, mais d’offrir une sélection d’algorithmes) n’a plus trop la faveur des cryptologues de nos jours.

C’est essentiellement dû au fait qu’elle impose un mécanisme de négociation (les deux parties à la communication doivent se mettre d’accord sur les algorithmes à utiliser), et qu’un tel mécanisme est une source de complexité et donc de bogues (y compris des bogues résultant en des failles de sécurité). L’exemple typique avancé par les opposants à l’agilité cryptographique est TLS, qui a eu son lot de failles causées par cette étape de négociation.

(OpenPGP n’a à ma connaissance pas trop été affecté par ce genre de problèmes, mais le fait qu’il s’agisse fondamentalement d’un protocole hors-ligne simplifie pas mal la donne : contrairement à TLS ou SSH, la négociation ne se fait pas « en direct », mais seulement par l’intermédiaire des « préférences algorithmiques » portées par la clef du destinataire.)

Le credo de beaucoup de cryptologues est désormais : « Mettez tous vos œufs dans le même panier et surveillez ce panier comme la prunelle de vos yeux ! »

Pour ce que ça vaut, je ne suis personnellement pas convaincu par cette approche et pense que l’agilité cryptographique reste souhaitable (et je me réjouis que la future version d’OpenPGP n’y renonce pas), pour plusieurs raisons.

• Ça veut dire quoi, « surveiller un algorithme » ? ce n’est pas en « surveillant » en algorithme que l’on va empêcher un cryptanalyste quelque part dans le monde d’y découvrir une faille. On peut bien demander à Matthew Green, Daniel Bernstein, Adi Shamir et Whitfield Diffie de monter la garde autour de la description de X25519 ou de AES, quelle « protection » ça apportera ?

• L’idée est que si une faille dans l’algorithme sanctifié est découverte, on publie une nouvelle version du protocole avec un nouvel algorithme. Comme ça tout le monde bascule d’un coup vers le nouveau protocole et le nouvel algorithme sanctifié, et on ne se traîne pas un algorithme que l’on sait vulnérable. Un simple coup d’œil à l’histoire des transitions protocolaires (ne serait-ce que TLS, justement) me pousse à croire que penser qu’on peut forcer tout le monde à « basculer d’un coup » est complètement irréaliste.

• En filigrane, derrière ce rejet de l’agilité cryptographique j’ai aussi l’impression de voir une très (trop ?) grande confiance dans les algorithmes choisis, comme si cette fois c’était la bonne, oui, on a eu des algorithmes qui se sont révélés mauvais par le passé mais là vraiment, X25519, Chacha20, Poly1305 c’est des bons, on peut vraiment miser dessus, la probabilité qu’on doive les changer un jour (et donc passer par une transition à une nouvelle version du protocole) est très faible. Si c’est le cas (et que ce n’est donc pas que mon impression), je ne suis pas sûr qu’une telle confiance soit opportune. On a justement eu suffisamment d’exemples d’algorithmes que l’on croyait à un moment très sûr jusqu’à ce qu’on réalise qu’ils ne l’étaient pas tant que ça… J’ai déjà évoqué récemment par ici le cas d’OCB2, que pendant près de quinze ans tout le monde pensait complètement sûr (« preuve de sécurité » à l’appui), jusqu’à ce qu’il se fasse démonter en seulement quelques mois…

Full disclosure : L’intérêt que je porte à OpenPGP est, je pense, bien connu et je suis contributeur occasionnel de GnuPG.

Les griefs contre OpenPGP et GPG sont légions

Certes. Et souvent exposés avec une bonne dose de mauvaise foi, et ce billet de Latacora ne fait pas exception. Il daterait d’une quinzaine d’années que je n’y trouverai rien à y redire, mais pour un billet écrit en 2019, difficile de voir autre chose que de la mauvaise foi quand l’auteur ignore délibérément tout ce qui a été fait dans le monde OpenPGP depuis dix ans.

La plupart des points dans ce billets, soit ont déjà été adressés (comme par exemple le fait qu’une clef OpenPGP serait forcément une clef RSA, volumineuse et obsolète, là où Age utilise des clefs X25519, lègères et modernes : les clefs ECC font partie du standard OpenPGP depuis le RFC 6637, en 2012, et toutes les implémentations courantes les prennent en charge — GnuPG le fait depuis 2014), soit sont en train de l’être avec la nouvelle révision du standard en préparation (comme le système d’authentification MDC, qui sera remplacé par un mécanisme AEAD conforme à l’état de l’art).

Certes, l’élaboration de la nouvelle révision du standard prend (beaucoup) plus de temps que ce qui était prévu. Mais c’est aussi le prix à payer quand on se soucie un minimum d’interopérabilité et de compatibilité avec l’existant, au lieu de balayer l’existant d’un revers dédaigneux de la main.

Ah, parce que oui, l’interopérabilité, ça compte, parce que contrairement à ce que prétend l’auteur du billet, non, GnuPG n’est pas la seule implémentation qui existe. Prétendre que « dépendre d’OpenPGP, c’est dépendre de GnuPG », c’est ignorer complètement Sequioa-PGP, OpenPGP.js, RNP, pour ne citer que les implémentations libres les plus importantes. Quand on sait que ProtonMail par exemple utilise OpenPGP.js, ou que Thunderbird utilise RNP, passer ces implémentations sous silence est assez fort de café.

--
Age est un projet intéressant, et un format standard de chiffrement débarrassé des contraintes historiques et du poids de l’existant répond certainement à un besoin. Mais que son auteur ne puisse le promouvoir autrement qu’en colportant des critiques dépassées et de mauvaise foi sur le standard et l’implémentation qu’il espère remplacer, ça me laisse un goût amer.

parce qu'on sait plus facilement où rapporter un bogue

C’est peut-être aussi que, avec un logiciel libre, c’est possible de rapporter un bogue.

Vous avez déjà essayé de rapporter un bogue sur un logiciel propriétaire ? Vous savez où trouver les bug trackers de Microsoft, Apple, ou Adobe ?

J’ai déjà essayé un jour de rapporter un bogue à Microsoft. Ce n’est juste pas possible, en fait. Le seul canal officiel pour ça est une option « Signaler un problème » dans le menu d’aide du logiciel. Option qui était totalement inaccessible pour moi vu que le bogue que je voulais rapporter était, oh presque rien, juste un crash complet et systématique de l’application sitôt celle-ci lancée — ne laissant aucune possibilité d’accéder au menu d’aide…

Par curiosité, j’ai regardé cet après-midi sur Microsoft Office pour Mac. Ce n’est pas mieux. Tout ce qu’on a, c’est une option Feedback dans le menu d’aide. Cette option ouvre une boîte de dialogue où l’on peut choisir entre I like this et I don’t like this, suivi d’une petite boîte de texte où l’on peut saisir ce qu’on « aime » ou « aime pas » à propos de Office. Faut-il s’étonner après que les développeurs ne reçoivent que des messages laconiques et inutiles du genre « Ça marche pô », au lieu de vrais rapports de bogues ?

Ce n’est pas que les utilisateurs de GNU/Linux sont plus enclins à rapporter des bogues ou mieux formés pour écrire des rapports de bogues utiles, c’est plutôt que rien n’est fait pour que les utilisateurs de logiciels propriétaires puissent le faire — et dans certains cas je serais même enclin à dire que tout est fait pour qu’ils ne puissent pas le faire (eh, tu ne veux pas avoir de bugs dans ton logiciel ? Facile, ne laisse pas les utilisateurs te les remonter !).

Pour ce que ça vaut, j’ai récemment acheté ce modèle : Mpow PA071A.

Le connecteur USB est amovible, ce qui permet si besoin de s’en passer et de brancher le casque et le micro directement sur une prise Jack 3.5mm.

En mode USB, il est reconnu d’office par Pulse Audio (sous le nom Unitek Y-247A) et fonctionne out of the box, y compris les boutons Volume Up / Volume Down / Mute sur le connecteur USB.

À noter que le quatrième bouton, qui permet de couper le micro, est lui « invisible » pour l’ordinateur : il n’envoie aucun évènement, il agit directement à l’intérieur du connecteur pour couper l’entrée micro. Du coup il n’est pas possible de ré-assigner ce bouton à une fonction de son choix.

Oui, OpenPGP a un mécanisme de vérification d’intégrité (appelé Modification Detection Code ou MDC) depuis le début des années 2000 et formalisé en 2007 avec le RFC 4880 (§ 5.13).

Et puisque dans le cas d’usage prévu ici on n’a pas besoin de compatibilité avec des implémentations anciennes d’OpenPGP, on peut aussi utiliser un mode de chiffrement authentifié (AEAD) qui fera partie de la prochaine version du standard — et qui dans les faits est déjà supporté par toutes les implémentations majeures.

Indépendamment du mécanisme de vérification d’intégrité utilisé (MDC ou AEAD), il est aussi toujours possible de générer une archive chiffrée et signée, la signature constituant alors une preuve d’intégrité supplémentaire (en plus de prouver la provenance de l’archive).

J'avais aussi pensé à héberger une archive chiffrée, mais il faut des outils spéciaux pour les déchiffrer.

D’où l’intérêt d’utiliser un format standard comme OpenPGP, parce qu’au moins les « outils spéciaux » sont disponibles pour la plupart des systèmes voire même, au moins dans le cas des systèmes GNU/Linux, déjà installés par défaut (je ne connais aucune distribution GNU/Linux qui ne fournit pas GnuPG dans son installation « de base »). Évidemment, Windows et Mac OS sont à la traîne, comme d’habitude…

Je me trompe peut être, mais ça ne peut pas marcher entièrement dans un navigateur?

Une implémentation d’OpenPGP en Javascript existe (openpgp.js), donc en théorie on peut imaginer un espace de stockage en ligne offrant une interface web qui utiliserait openpgp.js pour chiffrer/déchiffrer les fichiers lorsque ceux-ci sont téléchargés vers/depuis le serveur. Je ne connais aucun service de stockage en ligne qui le fasse, cependant.

Nextcloud propose optionnellement du chiffrement côté client (ce qu’ils appellent, incorrectement à mon avis, du chiffrement end-to_end), mais je ne l’ai jamais essayé.

Ma solution personnelle est simplement une archive chiffrée au format OpenPGP. L’archive peut être stockée n’importe où, y compris sur un espace dans lequel on n’a pas confiance, puisqu’elle ne sera jamais déchiffrée à cet endroit : l’archive est créée sur ma propre machine puis envoyée sur le serveur, et lorsque je veux récupérer mes documents, l’archive est récupérée depuis le serveur et déchiffrée localement.

Reste la question de la clef permettant de déchiffrer l’archive. Chez moi, elle est stockée sur un jeton OpenPGP que j’ai toujours avec moi, de sorte que je pourrais déchiffrer l’archive même sur une autre machine que celle que j’utilise habituellement (par exemple si c’est ma machine habituelle que j’ai perdue), dès lors que GnuPG est disponible.

Pour le cas de figure où je perds mon jeton, l’archive est aussi chiffrée symétriquement avec une phrase de passe, de sorte qu’elle peut être déchiffrée sans clef privée si nécessaire.

Certaines administrations qui ont décidé qu’il fallait absolument que les utilisateurs changent de mot de passe tous les trois mois n’hésitent pas à implémenter des règles visant précisément à empêcher ce genre de pratiques.

Dans mon ancienne université par exemple, le nouveau mot de passe ne pouvait pas contenir une séquence de plus de 4 caractères provenant de l’ancien mot de passe.

Du coup mon astuce personnelle était de considérer mon mot de passe comme une séquence de 4𐄂4 caractères, et de permuter les quartets tous les trois mois… Genre si le mot de passe actuel est ABCD EFGH IJKL MNOP (sans espaces, ils sont juste là pour visualiser les quartets), le mot de passe suivant sera quelque chose comme ABCD MNOP IJKL EFGH, celui d’après IJKL MNOP EFGH ABCD, etc.

Ça ne protège pas contre la même chose.

Le chiffrement intégral du système de fichiers, ça protège les données lorsque le système est à l’arrêt en cas de vol ou perte du disque dur (ou de la machine qui le contient). Ça ne protège pas contre une exfiltration des données réalisée pendant que le système est en fonctionnement, puisque le système de fichiers est alors déverrouillé et tous les programmes s’exécutant sur la machine (y compris un éventuel malware) peuvent accéder de façon transparente aux données déchiffrées.

Alors « des années » = « 4 ans » au plus, parce que ce n’était clairement pas possible en 2017 lorsque je me suis désabonné.

En y repensant, une option qui serait déjà appréciable, c’est l’abonnement pour une durée fixe non-tacitement renouvelable. Genre tu t’abonnes pour un mois, trois mois ou un an, et au terme de cette durée, sans action explicite de ta part l’abonnement est automatiquement résilié au lieu d’être automatiquement renouvelé.

Ce serait déjà un bon début, je trouve, et contrairement au paiement à l’article ça ne devrait pas nécessiter de gros changements.

Les sites pornos font ça très bien — enfin d’après ce qu’on m’a dit.

Ça pose problème de devoir payer les gens qui font l'information ?

Ce qui me pose problème, c’est qu’en 2021 l’abonnement soit toujours la seule manière offerte de payer pour l’information.

Si j’avais dû souscrire un abonnement à tous les « journaux » en ligne où j’ai un jour vu passer un article potentiellement intéressant, je serais probablement abonné à une bonne cinquantaine aujourd’hui et j’y consacrerai au minimum 300 euros par mois.

Sans compter que la procédure de désabonnement à chacun de ces journaux est systématiquement plus complexe que la procédure d’abonnement, pour ne pas dire qu’elle est expressément conçue pour décourager le client de se désabonner. Très souvent la procédure n’est même pas réalisable en ligne (contrairement à la procédure d’abonnement, qui se fait en quelques clics). Avec le New York Times par exemple, il faut appeler le service des abonnements (où évidemment un conseiller se fait un devoir d’essayer de te faire changer d’avis). Avec Mediapart, c’est par courrier que ça se passe.

Je suis abonné à une petite poignée de journaux, mais je réfléchis à deux, cinq, voire dix fois avant de m’abonner à un autre.

Merde. Avant, quand on entendait dire qu’un journal auquel on n’était pas abonné avait sorti un papier intéressant, on pouvait acheter le numéro du jour contre 9 francs 50 au kiosque du coin. On repartait avec le numéro qu’on voulait, pas avec un formulaire à remplir pour recevoir tous les prochains numéros chez soi.

(Re)donnez la possibilité de payer au numéro (voire à l’article !) et je me ferai un plaisir de payer pour toutes les informations que je veux lire. En attendant, je me contente de la poignée de journaux sus-mentionnée, et passe mon chemin sur les autres.

Je trouve insensé que l’abonnement soit le seul modèle économique qu’on nous propose aujourd’hui (enfin, avec la publicité, l’espionnage des visiteurs, les subventions à la presse, et les tentatives de faire payer les moteurs de recherche, bien sûr).

On n’a peut-être pas la réponse complète, mais on en a une partie.

Ça a peut-être changé au cours des trois derniers mois, mais dans ce message datant de juin les développeurs en étaient encore à devoir « identifier les coupables »… Il y a avait des pistes, certes, mais rien de vraiment précis — c’est justement là que j’espérais pouvoir aider.

Tant mieux si depuis la liste des suspects a été réduite. :)

En même temps, si même les dévs macOS arrivent pas à compiler, y a un problème à la base.

Il y a méprise ! Il m’arrive d’écrire du code sous Mac OS dans le cadre de mon travail, mais je ne me qualifierai certainement pas de « développeur Mac OS ». :D

Et je n’ai pas particulièrement envie de le devenir d’ailleurs, parce que mon impression est que ce système est particulièrement « hostile » aux développeurs (à part peut-être ceux qui font du « pur Apple » — ceux qui utilisent Xcode, développent en Objective-C, etc.)

trouver un contributeur bénévole de logiciel libre sous mac est une illusion.

Utilisateur (pas par choix) d’une machine Apple dans le cadre professionnel, j’ai essayé de contribuer à Inkscape, dont la version Mac OS aurait bien bien besoin d’un peu d’amour.

Je ne suis pas développeur C++ et je n’espérais pas accomplir grand’chose, mais je pensais pouvoir au moins apporter quelques informations et résultats de tests qui auraient pu servir aux développeurs d’Inkscape — parce que pour l’instant, ils ne savent même pas exactement pourquoi Inkscape est si désespérément lent sous Mac OS.

Sauf que… pour l’instant je n’ai même pas réussi à compiler Inkscape — non pire, je n’ai même pas réussi à installer ses dépendances !

Pas sûr encore de bien comprendre quel est le problème (apparemment GTK3 et les nouveaux processeurs M1 de chez Apple ne sont pas très copains), mais clairement c’est pas demain que Inkscape aura un testeur pour Mac OS…

De plus, je trouve macOS mal fini dans les angles

Tu es gentil. Moi je trouve que c’est une bouse infâme qui n’est seulement rendue vaguement utilisable que par l’existence de MacPorts (dont je salue les développeurs au passage.)

Donc c'est bien que GNUlib ai ça

Ah mais tout-à-fait, je ne voulais pas insinuer le contraire ! Et je n’aurais aucune hésitation à utiliser une bibliothèque codée ainsi. Par contre, je me garderai bien d’essayer d’écrire du code comme ça moi-même, et je pense que je serai même réticent à accepter un patch écrit comme ça, quand bien même l’auteur me démontrerait que ça rend mon programme 76 fois plus rapide…

En gros, en tant que programmeur du dimanche et conscient de l’être, je n’ai aucun problème avec ce genre de code, tant que je ne me retrouve pas à le maintenir moi-même. :D

Ça me rappelle qu’un jour j’étais allé voir l’implémentation de memchr dans la GNUlib (impossible de me rappeler pourquoi…). J’en avais conclu que j’admirais les développeurs capable d’imaginer et d’écrire ce genre de code (sincèrement), mais que je ne voulais pas voir ça dans mes propres projets… Je n’ai pas changé d’avis !

J’aime beaucoup cette phrase de Brian Kernighan :

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as you can, you are, by definition, not smart enough to debug it.

J’essaie de la garder en tête chaque fois que l’envie me prend de jouer au plus malin avec mon code…

Et inversement, le projet GNU en ayant fait en sorte que le noyau linux soit GPL

Euh, ce n’est pas le projet GNU qui a « fait en sorte que le noyau Linux soit [sous licence] GPL », c’était purement un choix de Torvalds.

pourquoi ces véritables descendants d'Unix se sont fait voler la place ? À cause de leur licence ?

C’est plutôt lié au fait qu’à l’époque, le statut juridique des BSD libres était incertain, du fait de leur filiation directe avec le code original d’UNIX (dont au moins une partie appartenait à AT&T).

Le système GNU et le noyau Linux avaient tous deux l’avantage d’être des créations originales, ne contenant que du code nouvellement écrit et non dérivé des unixes historiques. On pouvait donc les utiliser sans risque qu’AT&T ou un autre détenteur de droits sur une partie quelconque d’UNIX ne vienne t’accuser de violer leur propriété intellectuelle¹.

Progressivement, les BSD se sont débarrassés des bouts de code problématiques, mais entre-temps GNU/Linux avait déjà décollé…

---

¹ Du moins en théorie. En pratique, le fait que le code de Linux soit complètement original n’empêchera pas, quelques années plus tard, SCO de prétendre le contraire et d’accuser les utilisateurs de Linux de violer sa propriété intellectuelle…

Slackware, première version le 16 juillet 1993, dernière sortie : 15, avril 2021 (bêta), et passe du système de version à celui du développement continu à partir de là

Non, Slackware est toujours versionnée, la dernière version stable est la 14.2 (2016), et la 15.0rc1 est sortie il y a quinze jours.

Slackware-current est juste une branche de développement (que les utilisateurs qui ne veulent pas attendre la prochaine version stable peuvent utiliser comme une rolling release s’ils le veulent), elle ne remplace pas les versions stables.

Personne ne dit que Debian est une distribution rolling release juste parce que la branche Sid existe, si ?

Je sais, j’ai moi-même mes inquiétudes quant à l’avenir de Passman… Mais les choses semblent aller un peu mieux de ce côté depuis les derniers mois.

Donc une possible évolution de ton client, serait de le rendre compatible avec l'application officier «Password».

À moins que Passman ne soit définitivement abandonné sans espoir de reprise et que je me retrouve donc forcé de passer à Password, il y a franchement peu de chances que ça arrive, pour au moins deux raisons :

• Pendant longtemps Password n’offrait que du chiffrement côté serveur (i.e., le serveur voit les mots de passe en clair), et même si ça a changé récemment j’ai du mal avec l’idée du chiffrement côté client (aka end to end même si à mon avis le terme est impropre ici) ajouté après coup comme un truc optionnel, là où Passman fait ça depuis le début. D’ailleurs aujourd’hui encore le chiffrement côté client est toujours optionnel et non-activé par défaut avec Password.

• L’API de Password est soit très complexe, soit sous-documentée, voire les deux. Le fait est qu’en consultant la « documentation » je n’ai pas la moindre idée de comment je peux utiliser l’API pour faire quelque chose de similaire à ce que je fais avec Passman. Non, chers développeurs de services web, une liste de endpoints ne constitue pas une documentation !

• il a grandement contribué à populariser git
• il a grandement popularisé son propre workflow associé

Dommage que le deuxième point annule presque complètement le premier…

La plupart des gens avec qui je travaille aujourd’hui en bioinformatique savent bien utiliser GitHub mais certainement pas git.

Récemment j’ai expliqué à quelqu’un comment on pouvait étudier localement les conséquences d’une pull request en faisant un check out de la branche correspondante dans sa copie de travail. Ça faisait des années que le type utilisait GitHub, il n’avait pas la moindre idée qu’on pouvait faire ça. Pour lui tout ce qu’on pouvait faire avec une pull request c’était étudier les diffs tels qu’affichés sur GitHub, puis cliquer sur le bouton « merge » si on est satisfait.

Autre truc rigolo : globalement, les pull requests ont remplacé les commits comme unité de base du développement. Les commits ne servent plus à rien, ils n’ont plus aucune logique, plus aucune cohérence, et les messages associés sont complètement non-informatifs (« more work on foo.py », « update makefile », « last changes », voire même simplement « WIP » — work in progress). C’est désormais dans les messages associés aux pull requests que les développeurs expliquent ce qu’ils font, c’est là qu’il faut aller chercher si on veut comprendre l’évolution d’un projet.

Entre autres conséquences, ça produit des pull requests de plus en plus difficiles à évaluer, vu qu’on ne peut plus étudier les changements commits par commits, il faut nécessairement étudier le diff sur la pull request complète. Évidemment, c’est beaucoup plus ardu (surtout quand, comme au-dessus, on ne sait pas faire un check out local). Et ça donne lieu à des fils Twitter lunaires comme celui-ci, où certaines réponses me donnent envie de me taper la tête contre le mur en hurlant « mais apprenez à utiliser git bordel ! »

/rant