En pratique, cela se matérialise par deux processus qui n'ont rien à voir.
Tu déplaces ton fichier de dossier en sous-dossier, et en toute logique tu vas du plus général au plus précis (si tu as une arborescence du type ~/Documents/Administration/Impôts/2017/Revenus/, par exemple. Et tu ne fais ça qu'une fois ! De plus, quand tu fouilles, cette même arborescence aide beaucoup. Si l'arborescence que je consulte est du type ~/Documents/Administration/Finances/Revenus/2017 , je mettrai exactement le même temps pour trouver mon document.
Avec des tags, je vais devoir taper successivement "documents", "administration", "impôts", "revenus" et "2017", mais il faut aussi que je me souvienne quels tags j'ai mis sur tous les autres documents du même type. Est-ce que j'ai mis "revenus" sur l'année dernière ? ai-je mis "taxes", "dgfip", "IR" ?
Et que faire quand je veux fouiller un peu dans mes documents ? Je liste les tags un par un ? je vais revoir 50 fois les mêmes documents (et ça va exploser avec le tag 2017 ou 2016).
J'ai une liste numérique de tous mes bouquins physiques, qui permet notamment de spécifier le genre littéraire du livre (les infos sont récupérées d'entre autres Amazon, mais le genre est souvent fantaisiste), qui fonctionne par tags. Au final, quand j'ajoute un nouveau livre d'un auteur dont j'ai déjà d'autres livres, je suis obligé, systématiquement, d'aller vérifier quel genre j'ai attribué aux précédents pour avoir quelque chose de cohérent.
Bref, je ne crois vraiment pas aux tags comme unique système de tri, même si ça peut être utile quand c'est déterminé de façon automatique (par exemple en fonction du contenu ou des méta-données — ça fonctionne très bien avec les mp3) et constante (pas de synonyme), ou au moins par vague (appliquer le tag à plein de fichiers d'un coup).
Y a-t-il un engagement contractuel sur l'IP fixe chez BT ?
Il me semble que l'IP est fixe en pratique, mais qu'il n'y a aucun engagement de leur part à ce niveau.
J'ai l'impression que je me suis mal exprimé sur Kerberos/GSSAPI ; c'est du SSO qui n'a rien à voir avec HTTP (enfin, autant que le concept de login/mot de passe).
Quand je me connecte à ma session (Windows/Linux/macOS), que ce soit par carte à puce/Yubikey ou avec un mot de passe, mon ordinateur envoie tout ça au serveur Kerberos de mon employeur qui lui renvoie en échange un ticket valable une journée (on peut également obtenir un ticket n'importe quand avec kinit, après s'être connecté en local sur la session). L'ordinateur ouvre alors la session et garde le ticket pour lui. Ensuite, quand je me connecte à un service quelconque (serveur web, mail, NFS, SSH, imprimante, Jabber, …), mon ordinateur va transmettre le ticket au service qui me reconnaîtra automatiquement, sans que j'ai besoin de rentrer le moindre login ou mot de passe. Bon, en vrai, c'est un chouia plus compliqué, mais ça reste vrai dans les grandes lignes.
Du coup, il n'y a aucun hack à utiliser une authentification Kerberos sur HTTP ou sur SSH (en cherchant des cookies dans le navigateur).
mais si tu respectes certaines bonnes pratiques, ton réseau d'administration est différent de ton réseau de développement, donc ton port 22 n'est pas accessible aux développeurs. Au contraire, 443 a de fortes chances d'être accessible sur le réseau des utilisateurs.
je ne comprends vraiment pas ce que tu veux dire ; en quoi utiliser une clef sans mot de passe est proche de ce que fait HTTPS ? Le fonctionnement de ces deux protocoles est fondamentalement différent :
HTTPS permet l'authentification du serveur très facilement, SSH ne permet que de savoir si tu te connectes toujours au même serveur (sauf si tu mets l'empreinte de sa clef publique dans le DNS, mais ça commence à être compliqué à faire, sans garantie que le client la prenne en compte).
HTTPS permet les connexions anonymes, pas SSH (qui force l'authentification mutuelle)
oui, mais dans ce cas, soit tu acceptes de remplacer du code éprouvé (OpenSSH) par du code très jeune pour l'administration, soit tu as deux services SSH qui tournent sur la même machine (cette option étant de toute façon obligatoire si tu respectes la séparation entre réseau d'administration et réseau de dév.).
je ne vois pas pourquoi tu parles de cookies HTTP, et en quoi ils sont un hack. En tout cas, quand tu fais du git+http, tu n'as absolument pas besoin de cookies…
Ah non, il n'y a pas forcément besoin de gérer toutes les méthodes d'authentification HTTP… qui ne sont d'ailleurs pas forcément si nombreuses que ça côté client (beaucoup sont faites par le site lui-même, pas en HTTP : si tu regardes les pages web, le code renvoyé est toujours 200 et non 401/403). Mais les principales pourraient l'être.
Après, tu peux effectivement faire confiance au proxy (apache ou nginx), qui va (par exemple) ajouter un header HTTP (souvent REMOTE_USER) contenant le nom d'utilisateur. Le serveur applicatif n'a plus qu'à utiliser ce header HTTP, et c'est gagné.
Au passage, SSH connaît d'autres méthodes que les trois que tu cites (notamment Kerberos/GSSAPI) :)
je ne connais pas bien le cloud, mais je n'ai jamais eu de problème à installer un git avec authentification Kerberos en HTTP (y compris en bidouillant gitlab pour le faire sur la version open-source) sur des machines à ma disposition. Ensuite, même si SSH permet de faire plein de choses, je ne suis pas sûr qu'il soit aussi souple que HTTP (ce n'est pas un reproche, ils n'ont pas été conçu pour faire la même chose) :
plein de serveurs HTTP existent pour faire des proxy (reverse ou forward)
pas besoin d'ouvrir de nouveaux ports si le 443 est déjà ouvert (j'aime bien limiter les ports ouverts)
on peut faire des accès sans authentification (sauf si on fait de l'authentification SSL mutuelle, certes), quelque soit le serveur
on peut mettre un certificat SSL sur le serveur (pour être sûr de s'adresser au bon serveur dès la première connexion) — ok, si on a la main sur le DNS, on peut également faire ou un LDAP, ça peut être jouable en SSH… mais c'est bien plus complexe
on peut faire des virtualhost (donc plusieurs sites qui n'ont rien à voir entre eux sur le même serveur)
des milliards de plugins d'authentification sont déjà codés, avec notamment la capacité de bien dissocier la phase d'autorisation et celle de l'authentification (je m'authentifie en Kerberos, mais c'est un serveur LDAP qui m'attribue les droits)
OpenSSH n'est pas franchement pensé pour avoir plusieurs serveurs simultanés (ne serait-ce qu'un tournant root et l'autre avec un utilisateur standard), ce qui est requis pour éviter d'exposer un service root aux utilisateurs
cURL est là pour faire des requêtes en lecture
Je connais essentiellement Kerberos comme authentification (c'est du du SSO), et git sait s'en servir de façon transparente en HTTP (le serveur lui réclame du Kerberos, le client se contente de lui en fournir). J'ai également une Yubikey, mais elle me permet de récupérer mon ticket Kerberos au login, du coup je ne sais pas si on peut faire de l'authent' SSL avec git de façon simple.
En termes d'interface, je ne vois pas trop en quoi ça serait différent par rapport au SSH. cURL propose plein d'authentifications, si tu veux regarder :)
J'ai un peu regardé le projet, et j'ai l'impression que le seul transport est via SSH. Est-ce correct ?
Pourquoi ce choix ? Je trouverais dommage d'abandonner HTTP (ou websocket si on veut un mode connecté).
HTTP permet plein de choses en matière de proxy ou d'authentification
j'aime bien que SSH ne serve qu'à l'administration (donc ouvert uniquement à un sous-réseau dédié), en ouvrant un serveur HTTP (qui tourne avec un simple utilisateur) pour les services.
J'avais vu que le nombre de morts avait globalement diminué dans les mêmes proportions dans tous les pays, ce qui aurait tendance à éliminer les facteurs géographiques comme l'alcool, les contrôles ou les limitations diverses et variées, renforçant l'argument de l'amélioration des voitures. Mais bon, je n'ai plus la source (c'était il y a 5 ou 10 ans…)
Alors je veux bien croire que dans ce contexte, un casque de vélo ne fait pas trop le poids face à un 4x4 de 1.5 tonnes lance a 70. Ça veut pas dire que le casque ne te servira pas dans un contexte un peu moins vélo-hostile.
Bien sûr qu'on trouvera toujours des cas où le casque sera utile. Maintenant, rendre le casque obligatoire est une certaine dépense d'énergie, énergie dont l'utilité doit être optimisée au maximum.
Il faut donc se demander si :
le nombre de vies sauvées (morts ou accidents graves) est important (si la plupart des accidents ont lieu contre un 4x4, comme tu dis, l'intérêt du casque est négligeable),
d'autres mesures plus efficaces ne pourraient pas être mises en œuvre à la place (pour consommer différemment cette énergie),
s'il est pertinent de n'appliquer le casque qu'aux cyclistes (après tout, les traumas crâniens existent également chez les automobilistes et les piétons).
En effet, il y a un mot-clef important : numpy, qui est une bibliothèque de calcul scientifique pour Python, mais qui sous le capot utilise du C.
Du coup, quand on utilise numpy au mieux de ses capacités, le code Python ne sert que de ciment à des appels de code C ; tout le boulot est fait par du C optimisé.
Fait : Les SSD sont infiniment moins gênées par des données non-séquentielles, car ils ne sont pas des disques durs. Ce qui rend la défragmentation inutile.
Ton implication est fausse. La défragmentation est donc moins utile. Tout est de savoir dans quelle mesure !
Fait : Le support de stockage utilisé par les SSD ont un nombre limité d'écritures avant d'être kapout. Ce qui rend la défragmentation dangereuse.
Ton implication est encore fausse : pour ça, il faudrait savoir de combien elle réduit la durée de vie du SSD. Si c'est de 0,001%, on peut la considérer comme indolore.
Fait : Un contrôleur SSD essaie de gérer la durée de vie ses blocs de manière uniforme. Pour éviter que certains deviennent kapout alors que d'autres étaient "comme neufs". Donc évidemment, les données vont être fragmentées.
Ton implication est encore fausse. La fragmentation du SSD n'a pas lieu au même niveau.
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…
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.
[^] # Re: Pourquoi ?
Posté par flan (site web personnel) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 3.
tu peux faire du XMPP via HTTP(S) (cela s'appelle BOSH)
[^] # Re: A quand une IHM révolutionnaire ?
Posté par flan (site web personnel) . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 7. Dernière modification le 02 octobre 2017 à 23:02.
Oui, c'est vrai, en théorie…
En pratique, cela se matérialise par deux processus qui n'ont rien à voir.
Tu déplaces ton fichier de dossier en sous-dossier, et en toute logique tu vas du plus général au plus précis (si tu as une arborescence du type ~/Documents/Administration/Impôts/2017/Revenus/, par exemple. Et tu ne fais ça qu'une fois ! De plus, quand tu fouilles, cette même arborescence aide beaucoup. Si l'arborescence que je consulte est du type ~/Documents/Administration/Finances/Revenus/2017 , je mettrai exactement le même temps pour trouver mon document.
Avec des tags, je vais devoir taper successivement "documents", "administration", "impôts", "revenus" et "2017", mais il faut aussi que je me souvienne quels tags j'ai mis sur tous les autres documents du même type. Est-ce que j'ai mis "revenus" sur l'année dernière ? ai-je mis "taxes", "dgfip", "IR" ?
Et que faire quand je veux fouiller un peu dans mes documents ? Je liste les tags un par un ? je vais revoir 50 fois les mêmes documents (et ça va exploser avec le tag 2017 ou 2016).
J'ai une liste numérique de tous mes bouquins physiques, qui permet notamment de spécifier le genre littéraire du livre (les infos sont récupérées d'entre autres Amazon, mais le genre est souvent fantaisiste), qui fonctionne par tags. Au final, quand j'ajoute un nouveau livre d'un auteur dont j'ai déjà d'autres livres, je suis obligé, systématiquement, d'aller vérifier quel genre j'ai attribué aux précédents pour avoir quelque chose de cohérent.
Bref, je ne crois vraiment pas aux tags comme unique système de tri, même si ça peut être utile quand c'est déterminé de façon automatique (par exemple en fonction du contenu ou des méta-données — ça fonctionne très bien avec les mp3) et constante (pas de synonyme), ou au moins par vague (appliquer le tag à plein de fichiers d'un coup).
[^] # Re: Si votre disque dur a cramé à la reconstruction, c'est peut-être que [...]
Posté par flan (site web personnel) . En réponse au journal RAID is no Backup!. Évalué à 4.
Avec le RAID 6, tu perds 2 disques (en termes d'espace utilisable) sur le total.
Avec le RAID 10, tu perds la moitié des disques.
Bref, dès que tu as plus de 4 disques, le RAID 6 est plus rentable.
# engagement de Bouygues
Posté par flan (site web personnel) . En réponse au journal Bouygues et IP fixe... qui change (où l'on parle aussi de fake MX). Évalué à 5.
Y a-t-il un engagement contractuel sur l'IP fixe chez BT ?
Il me semble que l'IP est fixe en pratique, mais qu'il n'y a aucun engagement de leur part à ce niveau.
[^] # Re: Transport via SSH
Posté par flan (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2.
J'ai l'impression que je me suis mal exprimé sur Kerberos/GSSAPI ; c'est du SSO qui n'a rien à voir avec HTTP (enfin, autant que le concept de login/mot de passe).
Quand je me connecte à ma session (Windows/Linux/macOS), que ce soit par carte à puce/Yubikey ou avec un mot de passe, mon ordinateur envoie tout ça au serveur Kerberos de mon employeur qui lui renvoie en échange un ticket valable une journée (on peut également obtenir un ticket n'importe quand avec kinit, après s'être connecté en local sur la session). L'ordinateur ouvre alors la session et garde le ticket pour lui. Ensuite, quand je me connecte à un service quelconque (serveur web, mail, NFS, SSH, imprimante, Jabber, …), mon ordinateur va transmettre le ticket au service qui me reconnaîtra automatiquement, sans que j'ai besoin de rentrer le moindre login ou mot de passe. Bon, en vrai, c'est un chouia plus compliqué, mais ça reste vrai dans les grandes lignes.
Du coup, il n'y a aucun hack à utiliser une authentification Kerberos sur HTTP ou sur SSH (en cherchant des cookies dans le navigateur).
[^] # Re: Transport via SSH
Posté par flan (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2.
mais si tu respectes certaines bonnes pratiques, ton réseau d'administration est différent de ton réseau de développement, donc ton port 22 n'est pas accessible aux développeurs. Au contraire, 443 a de fortes chances d'être accessible sur le réseau des utilisateurs.
je ne comprends vraiment pas ce que tu veux dire ; en quoi utiliser une clef sans mot de passe est proche de ce que fait HTTPS ? Le fonctionnement de ces deux protocoles est fondamentalement différent :
oui, mais dans ce cas, soit tu acceptes de remplacer du code éprouvé (OpenSSH) par du code très jeune pour l'administration, soit tu as deux services SSH qui tournent sur la même machine (cette option étant de toute façon obligatoire si tu respectes la séparation entre réseau d'administration et réseau de dév.).
je ne vois pas pourquoi tu parles de cookies HTTP, et en quoi ils sont un hack. En tout cas, quand tu fais du git+http, tu n'as absolument pas besoin de cookies…
[^] # Re: Transport via SSH
Posté par flan (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2.
Ah non, il n'y a pas forcément besoin de gérer toutes les méthodes d'authentification HTTP… qui ne sont d'ailleurs pas forcément si nombreuses que ça côté client (beaucoup sont faites par le site lui-même, pas en HTTP : si tu regardes les pages web, le code renvoyé est toujours 200 et non 401/403). Mais les principales pourraient l'être.
Après, tu peux effectivement faire confiance au proxy (apache ou nginx), qui va (par exemple) ajouter un header HTTP (souvent REMOTE_USER) contenant le nom d'utilisateur. Le serveur applicatif n'a plus qu'à utiliser ce header HTTP, et c'est gagné.
Au passage, SSH connaît d'autres méthodes que les trois que tu cites (notamment Kerberos/GSSAPI) :)
[^] # Re: Transport via SSH
Posté par flan (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2.
je ne connais pas bien le cloud, mais je n'ai jamais eu de problème à installer un git avec authentification Kerberos en HTTP (y compris en bidouillant gitlab pour le faire sur la version open-source) sur des machines à ma disposition. Ensuite, même si SSH permet de faire plein de choses, je ne suis pas sûr qu'il soit aussi souple que HTTP (ce n'est pas un reproche, ils n'ont pas été conçu pour faire la même chose) :
Je connais essentiellement Kerberos comme authentification (c'est du du SSO), et git sait s'en servir de façon transparente en HTTP (le serveur lui réclame du Kerberos, le client se contente de lui en fournir). J'ai également une Yubikey, mais elle me permet de récupérer mon ticket Kerberos au login, du coup je ne sais pas si on peut faire de l'authent' SSL avec git de façon simple.
En termes d'interface, je ne vois pas trop en quoi ça serait différent par rapport au SSH. cURL propose plein d'authentifications, si tu veux regarder :)
# Transport via SSH
Posté par flan (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2.
J'ai un peu regardé le projet, et j'ai l'impression que le seul transport est via SSH. Est-ce correct ?
Pourquoi ce choix ? Je trouverais dommage d'abandonner HTTP (ou websocket si on veut un mode connecté).
Enfin, peut-être que je me trompe complètement :)
# experts militaires
Posté par flan (site web personnel) . En réponse à la dépêche Open Bar Microsoft/Défense : une rentrée dense en informations. Évalué à 5.
Qui sont les experts militaires qui étaient contre ?
[^] # Re: VW
Posté par flan (site web personnel) . En réponse au journal Vélo vs Voiture : le tro^W^W la controverse s’intensifie. Évalué à 1.
J'avais vu que le nombre de morts avait globalement diminué dans les mêmes proportions dans tous les pays, ce qui aurait tendance à éliminer les facteurs géographiques comme l'alcool, les contrôles ou les limitations diverses et variées, renforçant l'argument de l'amélioration des voitures. Mais bon, je n'ai plus la source (c'était il y a 5 ou 10 ans…)
[^] # Re: VW
Posté par flan (site web personnel) . En réponse au journal Vélo vs Voiture : le tro^W^W la controverse s’intensifie. Évalué à 4.
Bien sûr qu'on trouvera toujours des cas où le casque sera utile. Maintenant, rendre le casque obligatoire est une certaine dépense d'énergie, énergie dont l'utilité doit être optimisée au maximum.
Il faut donc se demander si :
[^] # Re: Apple
Posté par flan (site web personnel) . En réponse au sondage Ce que je suis prêt à laisser aux GAFAM. Évalué à 2.
Que ce sont des revenus générés par des iPhone mais pas par Apple ?
# Pas si choquant que ça
Posté par flan (site web personnel) . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 10.
En effet, il y a un mot-clef important : numpy, qui est une bibliothèque de calcul scientifique pour Python, mais qui sous le capot utilise du C.
Du coup, quand on utilise numpy au mieux de ses capacités, le code Python ne sert que de ciment à des appels de code C ; tout le boulot est fait par du C optimisé.
[^] # Re: pas de FPS libre mono-joueur?
Posté par flan (site web personnel) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 2.
Merci pour le message !
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par flan (site web personnel) . En réponse au journal [Btrfs et openSUSE] Épisode 0 : l’ex‐fs du futur. Évalué à 5.
Ton implication est fausse. La défragmentation est donc moins utile. Tout est de savoir dans quelle mesure !
Ton implication est encore fausse : pour ça, il faudrait savoir de combien elle réduit la durée de vie du SSD. Si c'est de 0,001%, on peut la considérer comme indolore.
Ton implication est encore fausse. La fragmentation du SSD n'a pas lieu au même niveau.
[^] # Re: Oui faut faire du libre
Posté par flan (site web personnel) . En réponse au journal Gentlemen farmers . Évalué à 8.
De la même façon que beaucoup d'ouvriers ont perdu leur travail avec l'apparition des moissonneuses batteuses
[^] # Re: Problème ?
Posté par flan (site web personnel) . En réponse au journal Polémique concernant le recours à Google Analytics sur la page about:addons de Firefox. Évalué à 1.
Sur quoi te bases-tu pour dire qu'ils l'ont toujours fait, surtout vis-à-vis de PDG de boîtes aussi énormes ?
[^] # Re: Attention aux unités…
Posté par flan (site web personnel) . En réponse au journal HOW TO : Bench this SSD. Évalué à 1.
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.
[^] # Re: HTTP remplacent ?
Posté par flan (site web personnel) . En réponse au journal Debian va débrancher ses dépôts FTP. Évalué à 3. Dernière modification le 11 mai 2017 à 22:25.
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.
[^] # Re: HTTP remplacent ?
Posté par flan (site web personnel) . En réponse au journal Debian va débrancher ses dépôts FTP. Évalué à 3.
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.
[^] # Re: HTTP remplacent ?
Posté par flan (site web personnel) . En réponse au journal Debian va débrancher ses dépôts FTP. Évalué à 2.
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.
[^] # Re: HTTP remplacent ?
Posté par flan (site web personnel) . En réponse au journal Debian va débrancher ses dépôts FTP. Évalué à 3.
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…
[^] # Re: HTTP remplacent ?
Posté par flan (site web personnel) . En réponse au journal Debian va débrancher ses dépôts FTP. Évalué à 4.
Tu le dis : HTTPS est plus performant.
Et tous les admin n'ont pas forcément envie d'autoriser du tor.
[^] # Re: HTTP remplacent ?
Posté par flan (site web personnel) . En réponse au journal Debian va débrancher ses dépôts FTP. Évalué à 6.
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.