🚲 Tanguy Ortolo a écrit 12252 commentaires

Ce n'est pas cela que je reproche à une zone d'adresse et de recherche unifiée, mais l'impossibilité de rejouer une recherche dans un moteur différent sans avoir à la saisir à nouveau, puisqu'elle aura été remplacée par une URL.

Relis mon second paragraphe, qui répond exactement à ton objection :

Je vois venir une objection évidente : la zone d'URL peut très bien proposer une recherche sur plusieurs moteurs. Sauf que, une fois la recherche effectuée, on se retrouve sur une page dont l'adresse a remplacé les termes de la recherche, et par conséquent, si on s'aperçoit que la carte OpenStreetMap du village de Saint-Mathieu-en-Cambrousse n'a pas les noms des rues, pour rechercher le même endroit sur Yahoo! Maps, on doit saisir à nouveau la recherche. Alors qu'avec la zone de recherche dédiée, pour relancer la recherche, il suffit de retourner dans celle-ci, qui contient toujours les termes de la recherche, et de la relancer sur un autre moteur.

Je ne sais pas quel est le problème chez toi, mais Let's Encrypt émet sans problème des certificats pour plusieurs noms de domaine, même servis par un serveur qui n'a qu'une seul adresse IP publique.

Personnellement je développe des interfaces web, et j'utilise le JavaScript, et pas uniquement pour "embellir" l'interface (ajouter des effets qui améliore l'expérience utilisateur (UX pour les intimes)), mais également pour récupérer des données JSON san devoir recharger toute l'interface.

Pour que ça « aille plus vite » en somme ? C'est amusant, parce qu'en désactivant JavaScript, ça ne va généralement pas plus lentement, plutôt beaucoup, beaucoup plus vite.

Imaginez que le serveurs soit compromis et qu'il usurpe votre page de paiement.

Et bien ? Le certificat n'est pas en cause là-dedans : une autorité de certification ne garantit qu'une chose, un identité, ici un nom de domaine, pas l'usage qu'on en fait ou la sécurité du serveur sur lequel elle est utilisée.

Ah, parce qu'ils n'ont pas utilisé le protocole ACME ? Le boulets…

C'est ce que je dis, c'est l'alternative ordinaire, moins directe, donc plus lente, plus intrusive en matière de respect de la vie privée, et dépendant d'un service privé unique, avec tout ce que cela implique en matière de SPOF et de concentration de pouvoir. Bref, c'est moins bien, donc autant laisser cela aux béotiens.

Pour le moment vous pouvez essayer […] un champ unique fusionnant la barre d'adresse et celle de recherche (Universal Search)

Ça, j'espère vraiment que ce ne sera pas retenu, ou alors de façon facultative, parce que les zones d'adresse et de recherche séparées sont vraiment un avantage de Firefox, particulièrement utile quand on utilise plusieurs moteurs de recherche. Et tout le monde gagnerait à utiliser plusieurs moteurs de recherche, parce que quand on cherche des informations sur la ville de Seattle, il est plus rapide d'aller directement voir la page Wikipédia correspondante, que d'aller demander à DuckDuckGo, pour aller indirectement au même endroit, et ainsi de suite pour la météo à Toulouse (recherche Méteo France), les séances de films à Montpellier (recherche Allociné) ou le plan de la ville de Cannes (recherche OpenStreetMap).

Je vois venir une objection évidente : la zone d'URL peut très bien proposer une recherche sur plusieurs moteurs. Sauf que, une fois la recherche effectuée, on se retrouve sur une page dont l'adresse a remplacé les termes de la recherche, et par conséquent, si on s'aperçoit que la carte OpenStreetMap du village de Saint-Mathieu-en-Cambrousse n'a pas les noms des rues, pour rechercher le même endroit sur Yahoo! Maps, on doit saisir à nouveau la recherche. Alors qu'avec la zone de recherche dédiée, pour relancer la recherche, il suffit de retourner dans celle-ci, qui contient toujours les termes de la recherche, et de la relancer sur un autre moteur.

C'est de la vidéo de courte durée en fait, c'est ça ?

Oui, tout comme Windows Millennium Edition était le dernier de la lignée non NT. Ça ne change rien au fait que Mac OS X succède à Mac OS 9, et constitue, commercialement parlant, la version majeure suivante de la lignée de système d'exploitation Mac OS.

Je ne sais pas trop comment lire ça, vu que ça a l'air à moitié sérieux, mais :

Les nouveaux systèmes d'exploitation, iOS en version 10 et OS X qui serait à l'occasion renommé… MacOS ! Un nom dans lequel on peut voir, outre l'aspect "retour aux sources" (qui renoue avec la glorieuse époque de l'invention du premier système à interface graphique pilotée à la souris), une volonté affichée de se rapprocher encore plus de la convivialité attendue d'un OS grand-public, par la suppression du "X" marquant l'héritage un peu trop lourd et nerdy d'Unix…

Il me semblait que ce système d'exploitation, qui faisait suite à Mac OS 9, se nommait à l'origine Mac OS X, pour Mac OS, 10e version.

Possibilité de feinter un site en changeant le user agent pour tester son design adaptatif.

C'est sans doute utile pour effectuer des tests, mais l'utilisation principale du changement d'User-Agent n'est-elle pas plutôt le contournement des discriminations ?

Le retour en arrière, ça peut marcher, mais ce n'est pas du tout prévu. C'est un peu logique en même temps : si à chaque nouvelle version d'un paquet on veille à ce que tout soit bien migré depuis les versions précédentes, dans chaque version on n'a pas du tout veillé à ce que tout soit bien migré depuis une version future, c'est impossible !

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-01T00: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…