gouttegd a écrit 1805 commentaires

mais seulement des conditions qui font qu'il est acceptable que ce projet, y compris ses sources, soit diffusable par l'école.

Sauf que ce courrier ne nous dit pas grand’chose puisqu’on ne sait pas pourquoi il n’aurait pas été acceptable, sans cette autorisation, que le projet soit diffusé.

Je peux tout-à-fait comprendre que ce n’est pas une question simple¹, mais ce n’est pas une raison pour ne pas la poser, si ?

--
¹ J’ai eu à me pencher sur ce genre de question à propos de mon propre code, développé dans le cadre de mon travail à l’université : le code en question m’appartient-il (et donc puis-je décider de le publier sous la licence de mon choix) ou appartient-il à l’université (dont le service IP est donc seul autorisé à décider de ce qu’on fait du code) ? Réponse : « Ce n’est pas une question simple… »

Pour héberger et diffuser le projet sur le serveur de l'école, oui, il fallait l'autorisation du directeur.

Donc si les auteurs avaient voulu diffuser le projet sans utiliser le serveur de l’école (ce qui je le conçois était sans doute plus difficile il y a 20 ans qu’aujourd’hui), ils auraient pu se passer de cette autorisation ?

J'ai un peu (beaucoup) l'impression que tu extrapoles beaucoup à partir d'une lettre qui n'est qu'une lettre technique et qui ne dit rien de plus et de façon argumentée que le directeur autorise la diffusion du logiciel sur le serveur de l'école.

Mais qui n’explique pas pourquoi c’était nécessaire, d’où le fait que j’ai envie d’en savoir plus. Savoir si une école a par défaut la propriété intellectuelle des productions de ses étudiants me semble vaguement intéressant.

Je ne suis pas sûr de comprendre pourquoi l’accord du directeur était nécessaire, si c’était un projet des étudiants…

Cela signifie-t-il que par défaut, les droits sur le code écrit par les étudiants de cette école appartiennent à l’école elle-même et non aux étudiants ? Si oui, c’est courant comme pratique ça ?

Par ailleurs, le communiqué de VideoLAN dit que le projet émane d’une association des étudiants de l’école, ce qui ne me semble assez différent d’un projet « réalisé dans le cadre de leurs études » (je ne sais pour cette école, mais perso dans les associations d’étudiants que j’ai connues ce qu’on y faisait était indépendant de nos études, même si l’université était impliquée) — et du coup ça me semble encore plus bizarre que la propriété intellectuelle d’une production de l’association revienne à l’école…

Par ailleurs (bis), en quoi autoriser la diffusion sous licence libre était « une décision risquée » pour l’école ? C’était quoi le risque encouru ? Des problèmes avec les ayants-trop-de-droits sur la question du décodage des DVD, ou quelque chose dans le genre ?

Quelle solution de chiffrement (libre/open-source) avec une communauté toujours active conviendrait le mieux pour ce cas de figure? Cryptsetup, LUKS, Veracrypt, dm-crypt, autre ?

Alors en gros, cryptsetup, LUKS, et dm-crypt, c’est plus ou moins la même chose, ou plus exactement ça désigne différents composants d’un même système.

dm-crypt, c’est la couche au sein du noyau Linux qui s’occupe du chiffrement des volumes.

LUKS (Linux Unified Key Setup) est une sorte de « surcouche » à dm-crypt. En gros c’est un volume dm-crypt associé à un en-tête contenant la clef de chiffrement du volume, l’en-tête étant lui-même chiffré par un ou plusieurs mots de passe. Le principal intérêt de LUKS est ainsi de séparer le chiffrement proprement dit du volume de la gestion des mots de passe : on peut ainsi par exemple changer de mot de passe sans toucher au volume chiffré et utiliser plusieurs mots de passe pour un seul et même volume.

cryptsetup, c’est l’outil en espace utilisateur permettant de créer et manipuler des volumes dm-crypt ou LUKS.

Donc en l’espèce, le choix est entre :

• le chiffrement de volume natif de Linux (dm-crypt, avec ou sans l’extension LUKS — en pratique je ne vois pas de raison d’éviter LUKS qui est très pratique — et mis en place avec cryptsetup) ;
• le chiffrement de volume par une solution tierce comme VeraCrypt.

L’utilisation de VeraCrypt peut être pertinente pour un volume externe (clef USB ou assimilé) que l’on souhaite utiliser à partir de plusieurs systèmes différents (VeraCrypt est portable et un volume VeraCrypt créé par exemple sous GNU/Linux est déchiffrable avec VeraCrypt sous Windows). Pour un volume système, je ne vois pas de raison de ne pas utiliser le chiffrement natif (dm-crypt donc).

Reste que j'aimerai bien avoir une explication cohérente au pourquoi du comment d'un tel écart à cause d'une demi-dose de différence, ça doit rendre fou pas mal de chercheurs ce genre de résultat…

Les mystères de l’immunologie… :)

Une des hypothèses serait qu’une première dose trop élevée (i.e. la dose « normale ») provoquerait une réponse trop forte contre le vecteur (l’adénovirus de singe modifié pour exprimer la protéine S du SARS-CoV-2) ; du coup, lorsque la seconde dose est injectée, le vecteur serait éliminé trop efficacement (par les anticorps développés suite à la première dose) avant que le système immunitaire ne développe une réponse solide contre la protéine S.

En gros et si je peux me risquer à une analogie, le système immunitaire s’en prendrait au messager (le vecteur) plutôt qu’au message (la protéine S du virus porté par ce vecteur) ; et la solution serait d’envoyer un premier messager qui gueule un peu moins fort. :D

AstraZeneca, c'est pas eux qui ont un vaccin efficace à 50 % si 2 fois une dose, et de 90 % si une demie dose puis une dose ?

Si. Plus précisément et si je me souviens bien, ~65% avec le régime « normal » de deux doses, et ~90% avec un régime d’une demi-dose suivi d’une dose normale.

Le problème, c’est que le test du régime demi-dose/dose normale n’a été fait que sur un échantillon relativement faible (< 3000 personnes) — et pour cause, tester un tel régime n’était pas prévu, c’est la conséquence d’une erreur lors de l’administration de la première dose.

AstraZeneca a lancé un nouvel essai de phase 3 pour tester ce régime modifié dans des conditions correctes et en avoir le cœur net.

Il y a quelques mois, j’ai parlé en détails de la génération de nombres aléatoires sous GNU/Linux, et notamment de l’utilisation par le noyau de l’instruction RDRAND que l’on trouve sur les processeurs x86 récents.

Il se trouve que systemd fait un usage assez intensif de RDRAND quand cette instruction est disponible. En fait, il l’utilise chaque fois qu’il a besoin d’un nombre aléatoires pour autre chose que de la cryptographie, par exemple pour générer des UUIDs.

Sur certains processeurs, l’instruction RDRAND produit malheureusement des nombres pas si aléatoires que ça, de sorte que systemd peut se retrouver avec plusieurs UUIDs identiques, ce qu’il n’apprécie pas du tout.

Question sérieuse, combien sont concernés par cela?

Juste ce qui me passe par la tête :

• Quiconque a des droits de commit sur le dépôt d’un logiciel libre. Bonus si le logiciel en question est une petite brique obscure à laquelle personne ne pense mais qui est utilisée partout.

• Quiconque émet une opinion politique sur un sujet qui excite et, partant, se met à dos les excités du camp d’en face. Je rappelle qu’on vit dans un monde où énoncer un fait établi par la littérature scientifique (genre « l’hydroxychloroquine ne fonctionne pas contre le coronavirus ») est considéré par certains comme un acte politique et peut suffire à attirer des menaces de mort à ton encontre, alors ça ne me paraît pas déraisonnable d’imaginer que ça puisse aussi attirer des tentatives de piratage.

• Quiconque à un handle Twitter jugé « intéressant ». Je n’ai plus de lien sous la main, mais je me souviens vaguement de l’histoire d’un journaliste américain dont l’ordinateur et les comptes mails avaient été piratés juste parce que le pirate voulait mettre la main sur son handle Twitter à trois caractères.

c'est encore plus solidement ancré à la machine, qui doit être sous *nix, et dont il faut en plus être administrateur (cryptsetup)

On peut faire quelque chose de similaire sans utiliser cryptsetup et sans avoir besoin des droits administrateurs.

Perso j’utilise une image disque

• formattée en FAT32,
• chiffrée au format OpenPGP ;
• montée sous GNU/Linux avec udisksctl.

C’est portable (FAT32 est universellement supporté, des implémentations d’OpenPGP sont disponibles sur toutes les plate-formes courantes et même des moins courantes) et sous GNU/Linux monter un volume avec udisksctl ne nécessite pas de droits administrateurs. Après j’avoue que je ne sais pas comment on fait pour « monter » une image disque sous Windows ou Mac OS X, je n’ai jamais eu besoin d’essayer.

mais est-ce que vraiment des gens vont trouver un fichier planqué sur votre ordi?

Ça dépend si on parle d’une attaque « aveugle », qui cherche juste à toucher le plus de monde possible, ou d’une attaque ciblée qui te vise toi en particulier.

Par exemple, on peut imaginer une attaque aveugle qui exploiterait une faille quelconque pour exfiltrer automatiquement (sans intervention manuelle de l’attaquant, le but est de faire ça sur des milliers voire des millions de machines) un petit nombre de fichiers bien précis à des emplacements connus d’avance (par exemple l’emplacement par défaut des fichiers de données des gestionnaires de mots de passe les plus connus). Face à une telle attaque, le simple fait de stocker ses mots de passe dans un endroit « non-standard » (même si c’est bien en vue à la racine du dossier personnel) sera suffisant.

Par contre, si quelqu’un veut s’en prendre à toi et pour ce faire réussit d’une manière ou d’une autre à pénétrer dans ta machine, tu peux bien planquer ton fichier de mots de passe au fin fond de ton disque dur, un attaquant motivé le trouvera.

C’est un peu comme changer le port par défaut d’un serveur SSH : ça suffit amplement à déjouer tous les scans naïfs qui sont juste à la recherche de machines vulnérables quelles qu’elles soient, mais ça n’arrêtera absolument pas un attaquant décidé à s’en prendre à ce serveur.

Et puis même s’il a un smartphone sous la main d’ailleurs : quelqu’un¹ peut préférer visiter le lien depuis son ordinateur plutôt que depuis son smartphone, et pour ce faire pourrait apprécier de ne pas avoir à utiliser son smartphone pour déchiffrer le QR code tout ça pour devoir ensuite recopier le lien décodé sur son ordinateur.

---

¹ Bon d’accord, je parle de moi.

Sinon, on peut aussi ajouter une légende, mais ça duplique l'info, en effet.

Je ne voudrais pas être celui qui dit « explique-moi ton besoin, je te dirai comment t’en passer », mais dans le cas présenté, je pense qu’avoir le lien « en clair » en-dessous ou à côté du QR code est une bonne chose.

Si quelqu’un obtient une version « papier » du document mais n’a pas de smartphone sous la main (si si, ça peut arriver de ne pas avoir de smartphone sous la main, même en 2021), ce quelqu’un sera sans doute bien content d’avoir l’option de saisir « manuellement » le lien sur son ordinateur, plutôt que d’avoir à scanner le document pour le faire passer à la moulinette d’un logiciel lecteur de QR codes.

le premier con qui sait aligner 3 lignes de python peut fabriquer ce genre de vaccin

Euh, non. Le premier con qui sait aligner 3 lignes de Python peut fabriquer in silico la séquence d’un tel vaccin. De là à obtenir le produit injectable dans un patient, il y a une grosse marge. :)

À part ça, sur « l’optimisation des codons » que le deuxième billet mentionne rapidement :

Certains codons sont rares dans l’ADN humain ou dans certaines cellules. Il se peut que certains codons soient remplacés par d’autres simplement parce qu’ils sont plus couramment utilisés par certaines cellules.

C’est vrai mais il faut savoir que ça peut être casse-gueule.

À la base, l’idée derrière l’optimisation des codons était d’essayer d’utiliser autant que possible les codons les plus abondants dans les cellules de l’organisme cible, de manière à ce que l’ARN messager soit traduit plus rapidement (les ribosomes n’ont pas à « attendre » un ARNt présent en faible quantité dans la cellule) et donc à augmenter l’expression de la protéine.

Bonne idée sur le papier, sauf que… on s’est rendu compte depuis que pour certaines protéines, ce n’est pas nécessairement une bonne idée de jouer sur la vitesse de traduction : la vitesse avec laquelle la protéine en cours de production sort du ribosome peut influer sur la manière dont elle se replie (exemple), ce qui est crucial pour sa fonction. En optimisant les codons pour produire la protéine plus rapidement, on peut obtenir à l’arrivée une protéine non-fonctionnelle, ce qui est ballot. :D

Je me demande comment il gère son emploi du temps, et s'il arrive à vivre de tout ça, ou s'il a un boulot à plein temps (il me semblait qu'il enseignait à Nice à un moment). D'ailleurs si tu nous lis Gee, peut-être que tu peux répondre directement.

Il répond à ce genre de questions sur son blog, avant même qu’on les lui pose. :)

Notamment :

• ce billet où il explique qu’il consacre 20% de son temps à ses diverses activités personnelles.
• ce billet bilan de 2020 où il rend compte compte de ce qu’il a fait sur ces 20%.

Je cherche la config sur serveur mail et le code qui va avec…

Il n’y en a pas apparemment. Les mails reçus sont lus par un humain qui ajoute manuellement les commentaires en bas de chaque page (cf. commentaire #54 de la page about.html)

Du coup, le code est par là, si tu veux. :p

Une des raisons : Produire des protéines est beaucoup plus compliqué que produire des ARN.

La synthèse d’acides nucléiques (qu’il s’agisse d’ADN ou d’ARN) est un problème aujourd’hui non seulement résolu mais même complètement industrialisé. Bert n’exagère pas quand il parle « d’imprimante à ADN ». :)

Produire des protéines in vitro, on sait faire, certes, mais on n’en est pas encore à pouvoir saisir la séquence d’une protéine à une extrémité d’une machine et récupérer la protéine produite à l’autre extrémité.

On aime plein d'évolution dans GTK, mais parfois pour certaines évolutions, on en vient à se demander si on est la seule vraie grosse application complexe par rapport à certains choix.

Intéressante remarque, à mettre en relation avec ces propos de Matthias Clasen (développeur GTK) en 2013 selon lesquels GTK n’est explicitement pas conçu pour les « grosses applications comme Gimp ou Inkscape » :

Finally, he said, people ask whether GTK+ is focused on creating "small apps" or "large applications," and his answer is "small apps." In other words, GTK+ widgets are designed to make it easy and fast to write small apps for GNOME: apps like Clocks, rather than GIMP or Inkscape.

(ce que je trouve assez ironique compte tenu de l’origine de GTK, mais il est évident que les projets évoluent et que le G de GTK ne signifie plus Gimp depuis longtemps.)

A-t-il sa propre signature (self-signed) et un champ d'extension avec la signature d'une autre autorité ?

Non. En fait, ce qu’on appelle un certificat cross-signé est en réalité deux certificats distincts, chacun signé avec deux clefs différentes.

Dans le cas du certificat ISRG Root X1, il y a une version signée par la clef privée correspondant à la clef publique du certificat (c’est-à-dire, auto-signée), et une version signée par la clef privée du certificat racine d’IdenTrust.

La raison pour laquelle ça marche est qu’un certificat contient, entre autres informations, l’empreinte de la clef qui l’a signé (c’est le champ X509v3 Authority Key Identifier). C’est cette empreinte que le navigateur utilise pour trouver le certificat « parent » et ainsi remonter la chaîne des certificats intermédiaires jusqu’à un certificat racine de confiance. Or cette empreinte ne dépend que de la clef elle-même et pas du certificat qui la contient.

Par exemple, le certificat intermédiaire de Let’s Encrypt (Let’s Encrypt R3) contient l’identifiant de la clef ISRG Root X1. À partir de cet identifiant, le navigateur peut remonter à n’importe lequel des deux certificats ISRG Root X1 (celui auto-signé et celui signé par IdenTrust), parce que les deux ont la même clef publique (ils ne diffèrent que par leur signature, qui n’a aucune incidence sur l’empreinte de la clef publique).

Ben oui, puisque ça n’a été pris en charge qu’à partir de Gimp 2.10…

La différence entre le travail en présentiel et à distance c'est uniquement le "tuyau entre ton ordinateur et le lieu de stockage ; c'est ce tuyau qu'il faut adapter

Ah OK, maintenant je comprends.

Oui, perso c’est exactement ça que j’aurais voulu, comme je le disais au début du journal :

À noter, mon dossier utilisateur sur ma machine professionnelle est en fait un montage réseau, donc en réalité mes fichiers sont déjà stockés sur un serveur sur le réseau local de l’institut. Du coup, tout ce qu’il aurait fallu c’est trouver un moyen de rendre d’une façon ou d’une autre ce serveur accessible depuis l’extérieur du réseau local, après authentification appropriée bien entendu.

le vrai problème est de mettre en place des outils différents pour travailler en présentiel et à distance. […] mais les outils du quotidien doivent devraient rester les même. S'ils ne sont pas adaptés au travail à distance, pourquoi le seraient-ils pour travailler en présentiel ?

Pas sûr de comprendre, là.

Les « outils du quotidien » que j’utilise désormais sur ma machine perso pour travailler sont les mêmes que ceux que j’avais fait installer sur ma machine pro.

Le problème n’est pas que ces outils ne seraient « pas adaptés au travail à distance », mais que ces outils ne servent à rien si on ne peut pas accéder aux fichiers de travail — et ça ce n’est pas du ressort des outils en question.

Ok donc je les aurais harcelé un peu plus quite à passer pour le "chieur de service".

À quoi bon. Il était manifeste à cette époque (mars 2020) qu’ils étaient complètement débordés, ce qui est d’ailleurs aisément compréhensible — un institut entier qui passe subitement au télétravail, alors que précédemment ça ne concernait qu’une toute petite poignée d’utilisateurs, forcément ça met une pression monstre sur les sysadmins. Encore une fois, j’ai une idée suffisamment bonne de leur travail pour le savoir.

Nous avions tous des choses plus importantes à régler à ce moment-là, aussi bien les sysadmins que les chercheurs.

À ma connaissance, tous mes collègues ont eux aussi simplement fait une croix sur le Citrix Workspace. Ils ont récupérés leurs fichiers sur un disque dur externe (eux aussi fournis par le service IT, ce n’est toujours pas quelque chose qu’ils ont fait dans le dos des sysadmins) avant de partir en confinement et travaillent avec ça sur leurs propres machines. Ma solution personnelle est juste un poil plus évoluée. :)

Au final, je ne connais personne dans l’institut qui utilise ce Citrix Workspace. :D C’est ça le point du journal, une solution inutilement complexe qui ne répond pas au besoin et qui du coup a été mise en place pour rien du tout.

Genre installer un client windows, pour récupérer un fichier de conf, me parait être une démarche alambiquée.

Ah mais je suis d’accord, mais en l’absence de tout support pour GNU/Linux c’est la seule démarche que j’ai trouvé.

S'il est fourni et supporté officiellement par le service informatique, si c'est du d'accord on vous laisse acheter ça et on vous offre un support "au mieux" ou si c'est un truc que vous avez acheté dans leur dos et connecté au réseau sans leur accord et comment ce cas de figure est connu/accepté/déclaré auprès de la direction.

Tous les postes professionnels sont fournis par le service IT. Au début de mon contrat on m’a simplement demandé « Windows ou Mac » — j’ai répondu Mac en pensant que s’agissant d’un Unix-like, je devrais être plus à l’aise là-dessus que sur un Windows (grossière erreur au passage, Windows et Mac OS X me sont en fin de compte tout aussi étranger l’un que l’autre) —, après c’est le service IT qui se charge de l’acquisition et de l’administration.

Donc non, le cas où le bureau auquel on tente de se connecter est un bureau Mac OS X ne pouvait pas venir comme une surprise pour les sysadmins, qui devaient bien savoir qu’au bas mot la moitié de leur parc est constitué de Mac qu’ils ont eux-mêmes installés. :)

J’aimerais ajouter que contrairement à ce que prétend molotov plus bas, j’ai la prétention d’être particulièrement respectueux des administrateurs systèmes, parce que j’ai au moins une vague idée de leur travail (même si j’admets volontiers ne rien savoir de ce que représente l’administration d’un parc de plusieurs milliers de machines et dizaines de milliers d’utilisateurs, moi qui gère 4 machines et demi).

Jamais je n’ouvrirais un ticket simplement pour dire « ça marche pas ». J’ouvre un ticket auprès du service IT de la même manière que je rapporte un bug sur la liste de discussion d’un logiciel libre : en présentant clairement le problème ; en explicitant clairement ce que je voulais faire, le résultat attendu, le résultat obtenu ; en séparant clairement la description du problème de mes hypothèses sur ce que pourrait être la cause, si jamais j’en ai ; et de manière générale en fournissant autant d’informations que possible ; et toujours en concluant « je suis à votre disposition si vous avez besoin de plus de détails ».

Alors ceux qui me prennent pour un chouineur qui vient faire chier les sysadmins, ben franchement je vous emmerde. Continuez à mépriser vos utilisateurs et à vous étonner que certains vous méprisent en retour.

Ce n'est pas bien compliqué de faire une liste de logiciel nécessaire à son activité.

Ticket fermé, problème résolu par le fait que les logiciels en question ont tous été installés sur le poste professionnel, « auquel vous pouvez vous connecter avec le client Citrix en suivant les instructions données ici » — en réponse à un ticket ouvert précisément pour signaler que ces logiciels ne sont pas présents sur le bureau virtuel auquel le client Citrix me donne accès… Je veux bien que mon anglais ne soit pas nécessairement parfait, mais quand même…

Ah, et je précise que ce n’est pas lié au fait que je me connecte depuis une machine GNU/Linux (dont j’aurais pu éventuellement foirer la configuration vu que j’ai du me démerder pour configurer le client moi-même), parce que c’est exactement pareil quand je me connecte depuis une machine Windows en suivant exactement les « instructions données ».