flan a écrit 1830 commentaires

Il y a une subtilité : un Byte est la plus petite unité adressable, alors qu'un octet est un groupe de 8 bits. En l'occurrence, ce sont des bytes de 10 bits.

C'est exactement ce que je dis (« soit récupérer un certificat valide »), ce qui peut être compliqué si tu restreints la liste des AC acceptées ;)

À nouveau, tout comme Groumly, je n'ai jamais prétendu que le HTTPS était suffisant en soi ; simplement que ça apporte de la sécurité supplémentaire et qu'à ce titre, c'est une mauvaise idée de s'en passer.

Si, au moins partiellement : si tu as une faille dans la signature GPG (ce qui était justement le cas, cf. le lien supra), il suffit de faire du MITM pour infecter l'ordinateur. Avec du HTTPS, ce n'est plus possible : il faut soit casser le HTTPS, soit récupérer un certificat valide, soit trouer le serveur.

D'où l'idée de multiplier les couches de sécurité : une seule faille dans l'un des composants n'est pas suffisante, il faut une faille dans chaque composant de sécurité simultanément. D'où le principe de défense en profondeur, avec plusieurs lignes de défense concentriques.

Et s'il y a une faille dans la vérification de la signature ?
Le problème est arrivé avec Ubuntu (cf. plus haut), c'est exactement la même chose. C'est un peu le principe de la défense en profondeur…

Tu le dis : HTTPS est plus performant.
Et tous les admin n'ont pas forcément envie d'autoriser du tor.

Sauf que s'il y a une faille dans APT, on pourrait faire installer des paquets APT modifiés.
Bien sûr, c'est impossible… ah bah en fait, si, c'est même déjà arrivé : https://www.ubuntu.com/usn/usn-3156-1/

Bref, ce sont deux sécurité qui sont totalement indépendantes et qui permettent (entre autres) la même chose (empêcher la corruption de paquets lors du transfert) : cela permet de pallier une faille sur l'une des deux sécurités.

sûrement un script pensé pour Python 2 et exécuté avec Python 3.

En Python 2 :
"toto" est une string de bytes (et quand tu la parcours, tu obtiens "t", "o", "t", "o"), avec interdiction d'utiliser des accents
u"toto" est une string de caractères unicode (et quand tu le parcours, tu obtiens u"t", u"o", u"t", u"o") , et tu peux utiliser des accents
Tu peux aussi faire "to" + u"to" == u"toto", "to" + u"tô" == u"totô", mais pas "tô" + u"to" (UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128))

En Python 3 :
"toto" est une string de caractères unicode (et quand tu le parcours, tu obtiens "t", "o", "t", "o") , et tu peux utiliser des accents
b"toto" est une string de bytes (et quand tu la parcours, tu obtiens les codes ASCII : 116, 111, 116, 111), avec interdiction d'utiliser des accents
Tu ne peux pas mixer les deux.

Merci, je me posais sensiblement les mêmes questions que toi. J'y vois beaucoup plus clair maintenant !

non, non, ces bombardements n'étaient pas étalés dans le temps ; par exemple le bombardement sur Tokyo qui a fait plus de 100 000 morts (les chiffres varient) a bien eu lieu en une seule nuit, avec quelques centaines de bombardiers. Parfois, le bombardement pouvait durer plus d'une journée (le temps de faire défiler tous les bombardiers, en gros), mais sans plus.
Ça n'a rien à voir avec les grandes batailles de la Première Guerre Mondiale (comme Verdun), qui ont fait des centaines de milliers de morts, mais sur plusieurs mois.

Les bombardements massifs sont du pipi de chat par rapport à l'arme atomique. Il faut des semaines de bombardements pour un résultat similaire à l'arme atomique, entre temps la population a largement de quoi faire pour fuir ou résister.

Ce n'est pas si évident que ça.
Les bombardements d'Hiroshima et de Nagasaki étaient dans la norme de ce qu'endurait le Japon à peu près tous les jours, et le bombardement le plus meurtrier n'est pas atomique mais classique (Tokyo, 185 000 morts de mémoire). Les gens n'avaient pas spécialement le temps de s'enfuir, vu qu'il s'agit à chaque fois d'un seul raid.
Bien sûr, c'étaient des petites bombes atomiques (15 kT), on ne sait pas ce que donneraient les têtes modernes (qui font généralement dans les 150 kT) des grands pays.

On l'a bien vu avec la Seconde Guerre Mondiale : les premiers à avoir frappé (le Japon en 1931 ou 1937, selon le point de vue, et les Allemands) ont brillamment gagné la guerre :)

Sinon, les Belges n'ont pas encore choisi le F-35 Lightning II (le Raptor est le F-22), même si ça reste possible sinon probable.

Faire partie de l'OTAN oblige à adopter les standards de l'OTAN dans tous les domaines.
Ça peut avoir énormément de conséquences sur la façon de faire la guerre (la guerre à l'américaine est normalement assez différente de la guerre à la française, qui a la tradition de faire avec moins de moyens), mais également beaucoup de conséquences sur l'industrie.

Imaginons un scénario : un industriel américain travaille sur un nouveau protocole de communication radio tactique dans son coin. Hop, le protocole est adopté par l'OTAN. À partir de là, les pays doivent s'équiper, et donc soit demander à leurs propres industriels (quand ils en ont) d'abandonner les travaux en cours et de repartir sur ce nouveau protocole de communication, soit d'acheter le seul qui soit disponible sur le marché…

Non, la capacité de projection française est insuffisante.
D'une part, il manque un porte-avions afin d'assurer un minimum de redondance.
D'autre part, les capacités de transport lourd et de ravitaillement en vol sont vraiment insuffisantes. On est obligé de louer des avions russes (les An-124, et probablement l'An-225) afin de palier notre insuffisance. Sans les ravitailleurs américains, on serait également bien embêtés.

Jusqu'il y a peu, notre action était également limitée par les avions qu'on avait : le Mirage 2000 et le Super Etendard ont des capacités assez faibles à distance (la plus grande partie de leur capacité d'emport est prise par le carburant supplémentaire). Heureusement, c'est beaucoup moins vrai pour le Rafale.

En générale, il n'y a pas autant de fautes dans une brochure promotionnelle.

Merci, j'allais poster sensiblement la même chose, mais en moins bien :)

Un vote qui n'est pas fait dans l'isoloir ne peut aucunement garantir cette absence de pression.

Par contre, je ne suis pas d'accord avec ta première remarque : peut-être que l'informatique est maintenant comprise par pas mal de personnes, mais qui est capable de garantir que le programme qui est réellement exécuté par une machine correspond bien au code source fourni ?
Qui est capable de garantir qu'un code source (un poil complexe) n'a aucun bug ?

Un vote par urne classique (et bien fait, évidemment) reste le seul moyen de garantir les propriétés requises.

merci pour l'info

graphite (et ses sous-projets) me semble un peu abandonné, malheureusement. Il reste notamment planté en Python 2 (dont j'aimerais bien me débarrasser définitivement).

Oui, sauf qu'une bonne partie de l'installation d'un des est faite par l'OS (copie des fichiers, par exemple) : les scripts seront donc plus courts et généralement limités à quelques opérations simples (création d'utilisateur, par exemple).

Autre point : un paquet peut être signé et on peut noter sa signature. Si on l'installe plus tard, on peut vérifier la signature (ou le hash) du .deb pour vérifier qu'il n'a pas été modifié.
Avec un script bash, on peut vérifier que le script n'a pas été modifié, mais on ne sait pas si le script vérifie la signature de ce qu'il télécharge…

C'est bien dommage.
* on n'a aucune idée de ce que fait le bash en question (un .deb est plus facile à évaluer),
* on n'a aucune garantie de pouvoir réinstaller le logiciel en question deux jours après (si le miroir est tombé, si le lien change, etc.),
* on ne pas installer sur un réseau déconnecté,
* souvent rien n'est fourni pour désinstaller le logiciel,
* on ne sait pas comment se passent les mises à jours,
* le système est incapable de lister ce qui a été installé à la sauvage,
…

j'oublie certainement beaucoup d'autres problèmes éventuels.

(tu peux entrer au Ministère de la Défense après avoir fait des études dans le civil, tu peux y entrer en restant civil, tu peux également bosser pour eux sans en faire partie, …)

Si ton emploi d'un portable ne résiste pas à un problème de chiffrement de disque, c'est qu'il y a de toute façon un énorme problème : que fais-tu si tu perds l'ordi ? si tu te le fais voler ? si le disque meurt sans prévenir ?

Avant de déconseiller le chiffrement intégral (toujours une bonne idée, surtout pour un portable), il vaudrait mieux résoudre le vrai problème : l'absence de sauvegarde pour pallier un souci matériel sur l'ordinateur.

Ceux qui ne font pas n’importe quoi, en général : 1) ne croient pas en la sécurité par l’obscurité

Cela veut dire que la protection ne doit pas se baser le secret de la méthode employée. Mais maintenir le secret de la méthode employée ne nuit pas forcément, et ça ne veut pas dire que le logiciel n'a pas été revu (s'il est qualifié par l'ANSSI, c'est qu'il a été revu par cette institution, par exemple).

Si je stocke un fichier non-chiffré sur un support hors-ligne, il sera aussi bien protégé que s’il était chiffré avec ACID Cryptofiler.

Bien sûr que non. Va dire ça aux Iraniens, dont les machines (centrifugeuses nucléaires) ont été infectées alors qu'elles étaient hors-ligne… Croire qu'il suffit que ton réseau soit hors-ligne pour qu'il soit protégé est une grosse erreur.

En gros, tu veux faire une nation européenne, parce que tu n'aimes pas l'idée de nation.

C'est un peu étrange, comme façon de penser…

J'ai toujours entendu de snake_case plutôt que de lowercase_with_underscore.