🚲 Tanguy Ortolo a écrit 12690 commentaires

Donc dans ce cas-là, c'est pas mal si j'ai une version qui "stabilisée" pendant quelques jours, avant que je ne fasse des déploiement de mises à jours.

Ce n'est pas vraiment ça non plus. Les mises à jour n'arrivent pas dans testing par paquets tous les dix jours, elles arrivent continument, avec dix jours (ou cinq, la plupart du temps, en fait) de retard par rapport à leur arrivée dans unstable. Ou plus pour les mises à jour boguées, qui n'entrent pas dans testing tant que ça n'a pas été corrigé, parce que tel est le bug de la distinction entre unstable et testing, bloquer les mise à jour qui introduisent des bogues critiques.

Je ne sais pas d’où tu sors ces 10 jours. Mais j’imagine que c’est une moyenne au doigt mouillé.

Pas du tout, ça vient de la Référence du Développeur Debian. Hors période de gel, les paquets envoyés dans unstable y restent un certain temps, qui dépend de la priorité définie par leur mainteneur pour cette mise à jour (10 jours pour un priorité faible, 5 pour une priorité moyenne, 2 pour une priorité élevée).

Ça fait des années que j’utilise Debian et il est évident que ce qui s’apparente le plus à une rolling release c’est unstable. Testing est une sorte de version béta de la prochaine stable (qui remplacera victorieusement son illustre prédécétrice) à destination de ceux qui testent sérieusement.

En ce qui me concerne, ça fait des années que je suis Développeur Debian, et si je suis loin de tout savoir à ce sujet, je suis à peu près au fait du fonctionnement des différentes version (en interne, on parle de distributions, à ne pas confondre avec différentes distributions GNU/Linux...).

Testing est techniquement une distribution à intégration continue différée, hors des périodes de gel. En période de gel, c'est figé en effet.

Unstable est une distribution à intégration continue immédiate, et elle est tout également concernée par le gel, de façon plus subtile : lorsque la testing est gelée, c'est toujours principalement la unstable qui sert recevoir les mises à jour, à ceci près qu'il ne s'agit plus de nouvelles versions mais seulement de corrections de bugs. Par conséquent, on évite d'envoyer de nouvelles versions dans unstable, qui ne seraient en aucun cas acceptées dans testing, et qui bloqueraient les envois de corrections pour des versions antérieures présentes dans testing.

Concrètement, supposons qu'en période de gel, testing contienne autojump 23-2. Arrive autojump version 24, et disons que je l'empaquette pour envoyer un autojump 24-1 dans unstable. On se retrouve alors avec, dans testing, autojump 23-2, et dans unstable, autojump 24-1. Là-dessus, quelqu'un découvre un bug critique sur autojump 23-2, et je prépare un paquet autojump 23-3 corrigeant cela. Problème, je ne peux pas l'envoyer dans unstable, qui contient autojump 24-1 qui est une version supérieure. Ce n'est pas dramatique, je dois alors l'envoyer dans testing-proposed-updates qui est faite pour cela, mais comme c'est un peu agaçant, en pratique on évite ce genre de cas, et, en période de gel, on évite d'envoyer des nouvelles versions dans unstable, préférant utiliser pour cela experimental.

Tout ça pour dire que si unstable est effectivement ce qui s'apparente le plus à une distribution à intégration continue, il ne faut pas non plus s'attendre à ce qu'elle soit toujours mise à jour au même rythme : en période de gel de la testing, son évolution sera également partiellement figée !

Les nouveautés arrivent dans unstable, puis, après dix jours, si aucun bug critique n'y a été détecté, dans testing.

La conséquence évidente, c'est qu'avec unstable, tu as les problèmes et les corrections en direct. Avec testing, tu évites les problèmes qui auront été détectés à temps — pendant les dix jours sus-mentionnés —, mais pas ceux qui ne l'auront pas été, pour lesquelles les corrections seront d'autant plus longues à arriver.

Personnellement, je recommanderais unstable si le but est vraiment de tester Debian pour contribuer à détecter les problèmes (il faut bien que quelqu'un le fasse !), et testing pour un usage quotidien averti (ce n'est pas une distribution stable !), en prenant au besoin des paquets précis d'unstable si ceux-ci apportent des corrections qui ne sont pas encore arrivées dans testing.

Oui mais à la limite, que la personne ne soit pas authentifiée ce n'est pas grave. Ce qui importe c'est que ma société le soit.

Dans ce cas ce n'est pas vraiment comparable à une signature, plutôt à un tampon en fait. Et pour le coup, DKIM répond très bien à ce besoin : si on doit pouvoir fournir une indication fiable, vérifiable a posteriori, que tel message provient bien de ton organisation, une signature DKIM fera très bien l'affaire.

Ce n'est peut-être pas une preuve qui sera acceptée sans argumentation par un tribunal, mais avec une expertise qui va bien, ça devrait être tout à fait concluant.

Est-ce que certains sont passés à Debian 8 mais avec l'init SystemV ?

Moi.

À noter que sur d'autres systèmes, je suis aussi passé à Debian 8 avec systemd sans problèmes particuliers.

Voilà mais là ça dépend aussi du but de la signature. Si c'est pour avoir une preuve légale, mieux vaut une autorité de certification (qui est la garante de la fiabilité, donc la faute retombe sur eux).

Ça tombe bien, c'est faisable avec PGP, dont le modèle est un sur-ensemble de celui de X.509. En fait, n'importe qui peut être autorité de certification, techniquement parlant j'entends. Administrativement, c'est différent, mais toujours est-il qu'il est tout à fait possible pour des autorités de certification ayant pignon sur rue de signer des clefs PGP, en engageant leur responsabilité comme il se doit (et en faisant des vérifications merdiques, parce que ce sont des pros, et que les vérifications sérieuses, c'est un truc d'amateurs).

Après je ne suis pas super spécialiste, mais j'imagine que si ton certificat DKIM est signé par [...]

Non. Il n'y a pas de certificat DKIM, seulement une paire de clefs. La clef publique est publiée comme enregistrement DNS, et si elle doit être certifiée — et elle devrait l'être — ce sera avec DNSSEC.

Dernier point, si tu veux aller plus loin, ton message pourrait inclure une chaîne issu d'un serveur d'horodatage (en gros un timestamp et la signature par ce serveur). J'avoue ne pas savoir qui fournit ce service

Il existe un moyen simple de se prémunir des antédatation — mais pas des postdatations — qui consiste à inclure un extrait des dernières nouvelles provenant de n'importe quel journal.

FUD.

Il y a au moins un contre-exemple majeur : S/MIME est basé sur X.509, dont la sécurité dépend de la fiabilité de l'ensemble des autorités de certification reconnues, or cette hypothèse a plusieurs fois été reconnue non vérifiée. Cela provient principalement d'une limitation précise de X.509, qui est l'impossibilité pour un certificat de porter plusieurs signatures d'autorités de certification, ce qui est précisément l'avantage majeur d'OpenPGP.

Tu en tends quoi par là ? Une table mysql avec mots de passes chiffrés ne suffirait pas ? Il faudrait un engagement de responsabilité sur la chaîne d'administration du serveur ?

Il faudrait surtout que ce soit public. Parce que sinon, en recevant un tel message, tout ce qu'on peut dire c'est : si personne n'a fait d'usurpation DNS, si personne n'a piraté le serveur de l'expéditeur, si celui-ci est bien configuré et utilisé, et si personne n'a piraté le compte de l'expéditeur, ce message vient bien de untel@example.com. Ça ne dit pas que ça provient de M. Truc Untel né le 1970年01月01日T00:00Z à Paris 42e arrondissement : c'est associé à un compte, pas à une personne.

Oui, mais dans ce cas, c'est la faute du signataire. L'idée de chiffrement ou de la signature de bout en bout, c'est que ça ne dépend que de la fiabilité des correspondants, pas des intermédiaires.

Auquel cas, qu'est ce qui manquerait pour avoir légalement la valeur de signature numérique ?

Sans doute une signature associée à la personne qui a rédigé le message. Je doute qu'on puisse qualifier de signature numérique une chaîne de transmissions, si sécurisée qu'elle puisse être contre l'usurpation et la modification.

le nom de domaine de ma société enregistré par mon registrar .com est sensé corresponde à ma société (travail du registrar de vérifier il me semble)

Non, c'est là une supposition farfelue. N'importe qui peut acheter nimportequoi.example, le nom de l'acheteur n'a pas du tout besoin de correspondre à quelque partie que ce soit du nom de domaine.

Le nom indiqué dans le WHOIS est censé être le tien, mais il n'est pas vraiment utilisé en matière de courrier électronique.

est ce que quelqu'un peut me confirmer que cela forme une chaîne d'authentification et de certification de l'émission d'un courriel (au sens le courriel n'a pas été modifié, et à bien été émis par telle personne de telle société) ?

Ça donne des éléments de preuve que le message a bien été émis à partir d'un compte de courrier électronique donné dans ton organisation. Il manque au moins une authentification du DNS contre les possibles usurpations par ce moyen (un attaquant qui ferait en sorte que le destinataire d'un message, lorsqu'il va chercher la clef publique DKIM, récupère la sienne à la place de la votre), ce qui peut se faire avec DNSSEC.

Concernant l'association avec les personnes disposant des comptes de courrier électronique, ce n'est pas possible sans ajouter au moins une sorte de répertoire sécurisé.

À noter que, du point de vue du destinataire, tout cela dépend de la confiance en pas mal d'acteurs : le bureau d'enregistrement et le registre DNS, ton organisation et son système informatique, plus l'expéditeur lui-même (qui aurait pu laisser quelqu'un d'autre utiliser son compte). Ceci est à comparer avec une méthode de signature de bout en bout telle qu'OpenPGP, qui ne dépendra que de la confiance qu'on accorde à la chaîne de certification qui relie l'expéditeur et le destinataire (chaîne qui peut au besoin être réduite à ces deux seuls acteurs, s'ils ont l'occasion de se rencontrer directement).

Par ailleurs, mettre un document en pièce jointe et coller le MD5SUM dans le courriel n'ajoute pas d'information pertinente. Assertion vrai ou fausse ?

Un peu des deux ? C'est pertinent contre les erreurs de manipulations ou de transmissions (tiens, la somme de contrôle ne correspond pas, le fichier a dû être abîmé au passage, ou alors l'expéditeur s'est planté de fichier), pas contre les usurpations effectivement (un attaquant veillerait évidemment a mettre la somme de contrôle de son fichier).

Ah, compris, désolé. Du coup ça m'amuse avec un sérieux retard...

Je comprends bien qu'il s'agit d'une plaisanterie, mais c'est un peu tendancieux, l'association prêtre ↔ extrémiste.

Refais-nous-la avec un imam et un terroriste, pour voir...

Tiens, il me semblait que c'était MORPEUG.

Les gamers, les coders, les dinosaures et quelques autres garderont peut être un ensemble écran clavier, >comme certain écrivains ont une machine à écrire ou un stylo fétiche
mais pour combien de temps ?

Ben, pour longtemps, parce qu'il faut bien des gens pour écrire des livres, et des gens pour coder les trucs qui tournent sur ces autres appareils qui se vendent si bien. Et des écrivains et des développeurs qui travaillent en tapant sur un écran tactile, je n'en ai pas encore vu, et je soupçonne que c'est parce que ce n'est pas adapté.

Ce n'est pas parce que tu ne sais pas configurer le montage automatique sur MATE

Ça n'a rien à voir avec l'automontage. C'est à l'exécution automatique de binaires sur support externes qu'il fait référence.

qu'il faut te croire à l'abri d'une clef USB (ou d'un autre équipement USB) qui se ferait passer pour un clavier le temps d'installer une porte dérobée.

Comme je l'ai déjà fait remarquer, on n'a pas de protection contre cela. Mais encore une fois, ça n'a aucun rapport avec le montage automatique.

Si le poste est sous GNU/Linux (Linux Mint MATE par exemple), tu peux brancher toutes les clés USB que tu veux sans aucun risque.

Non, c'est faux. Tu peux brancher toutes les vraies clefs USB que tu veux sans risques. Mais les fausses clefs USB, qui sont en fait des trucs hostiles, qui peuvent selon le cas balancer une décharge électrique ou se faire passer pour un clavier et envoyer ce qu'il faut pour ouvrir une belle porte dérobée, non.

Il est nominatif, mais l'opérateur n'a pas ton nom.

C'est fou comme ça a l'air intuitif et agréable à administrer, un Windows...

Bravo, c'est vachement lisible... (Bon, on comprend tout de même, mais ç'aurait été mieux en plusieurs lignes quoi)

Ça confirme une chose que j'ai pu constater, chez quelqu'un dont je n'attendais vraiment pas une démarche de migration vers GNU/Linux. En gros, avec ce qu'il avait entendu de Windows 10, plus la politique de mise à jour agressive de Microsoft, son avis, c'était : « Attention, Microsoft cherchent à faire passer en douce une mise à jour vers Windows 10, j'ai des parents qui se sont fait avoir. Il ne faut pas l'accepter, parce que c'est un système qui espionne et transmet ce qu'on fait à Microsoft. » Évidemment, s'agissant de quelqu'un qui est tout sauf spécialiste, c'est un avis très grossier, peu détaillé, mais il faut reconnaître que c'est basé sur des informations exactes, et que si on peut largement le nuancer, on ne peut pas le nier.

Bref, c'était là un boulevard pour une migration, et quelque chose d'assez nouveau à mes yeux.

• Une douche en verre transparente, bien en face dans l'angle de la webcam.

C'est surtout ça qui est bizarre, une douche transparente dans la chambre. Seul dans la chambre, ça n'est pas un problème, encore que ça puisse être gênant malgré tout. Mais si on n'est pas seul, c'est problématique : déjà, les deux occupants de la chambre ne sont pas forcément conjoints, et ensuite, même si c'est le cas, ce n'est pas forcément agréable, de se doucher sous les yeux de son conjoint.

Ça m'étonne beaucoup, mais de toute façon, le droit français impose la reconnaissance de la paternité d'une œuvre si l'auteur le souhaite. Donc s'il reste du code de quelqu'un, il faut le mentionner.

Je ne pense pas que ça implique pour autant de maintenir pour chaque fichier une liste extensive des contributeurs, surtout pour les modifications de faible ampleur, surtout si on utilise un système de gestion de version, où chaque commit peut avoir un auteur identifié ou créditer quelqu'un par un message approprié.

Si, comme l'écrit l'auteur :

Cependant, avec le temps, dans ces fichiers, le code original n'est plus. [...] au final, le fichier ne comporte plus de code issue du projet forké

alors retirer les contributions des auteurs concernés est trivial : il suffit de ne rien faire.