🚲 Tanguy Ortolo a écrit 12360 commentaires

les clefs USB normales ("mass storage"),elle sont déjà dangereuses

Non, seulement sur des systèmes mités.

vous devriez vous méfier plus que ça...

Non, ici on utilise des systèmes conçus autrement qu'avec les pieds.

(j'en ai déjà vu qui utilisaient le autorun pour installer)

Merci, mais l'autorun sans confirmation, c'est une aberration réservée aux systèmes pour neu².

je te trouve juste ignoble à juger une personne sur son physique

Juger quelqu'un sur son physique, c'est mal, sauf dans un cas : quand la personne en question fait en sorte qu'on le fasse. Par exemple, se moquer de quelqu'un de pas très grand, c'est mal, sauf s'il porte des talonnettes afin qu'on le remarque.

des A6 pour liseuses

Ça reste très, très dégradé par rapport à de l'ePub. Une liseuse, normalement, ça permet de choisir la fonte, la taille de caractère, l'orientation de l'écran, la présence ou non d'un en-tête et d'un numéro de page…

Si seulement ça pouvait tuer des majors ! Ça ferait un super slogan, non ?

« La contrefaçon tue des majors : tipiakez ! »

On pourrait même en faire une jolie affiche, je pense.

Je n'ai pas parlé de clavier… L'intérêt d'un livre papier ou d'une liseuse électronique, c'est que c'est plus confortable pour les yeux qu'un écran rétro-éclairé, mais ça n'implique pas d'être loin de son clavier et de son écran pour autant.

Mais les PDF se lisent très bien quand même, c'est juste pas le mieux. Mais c'est très bien quand même.

Félicitation si tu arrives à lire des pages de PDF A4 réduites en A6, moi j'ai moins de 15/10 d'acuité visuelle et j'en suis donc incapable…

Ces livres électroniques électroniques sont compilés en PDF. C'est dommage, cela montre que leurs auteurs n'ont jamais vu de liseuse électronique, et cela implique qu'ils sont inutilisables sur liseuse électronique, justement. Les seules utilisations possibles de ces livres, c'est de s'exploser les yeux en les lisant sur écran, ou de les imprimer intégralement…

Et quand on voit les nouveautés des bureau libres, ce n'est pas beaucoup mieux.

Tu étais où quand KDE 4 et GNOME 3 ? Je ne sais pas ce qu'il te faut…

Qu'est-ce qui ne va pas à ce système pour ne pas l'utiliser ? Pour moi ça me semble plus simple, et plus générique.

Plus générique, oui, et c'est d'ailleurs ce qui se fait en général lorsque le développeur amont ne fournit pas de dépôt de versions, grâce à des outils faits pour automatiser cela, mais pas plus simple. L'historique amont m'est utile pour diverses raisons, par exemple :

• pour rétroporter des correctifs ;
• pour prendre en compte une nouvelle version — un simple git merge, opération à laquelle je suis habituée.

Non, si je dois maintenir moi-même un contenu de dépôt semblable au tarball, cela ne me pose pas plus de problème que ça, je trouve juste cela dommage, mais je le ferai avec une branche parallèle basée sur celles de ton dépôt.

pour que les éditeurs se mettent d'accord entre eux pour ne pas trop se marcher sur les pattes

Ils ne pourraient pas. Le jour où une entreprise développant LibreOffice choisira de supprimer la fonctionnalité d'export PDF parce que cela nuit à leur partenaire Adobe, cette fonctionnalité sera remise en place par la communauté, au moyen d'un fork si nécessaire. Il n'y a pas de place pour les fonctionnalités négatives (antifeatures) dans le logiciel libre.

Pour ceux qui opposeraient qu'un réseau de confiance est trop compliqué à construire, je rappellerai que de tels systèmes n'ont rien de moins que le système pyramidal X.509, mais uniquement une caractéristique de *plus* : la possibilité d'avoir plusieurs signatures sur un certificat.

Par conséquent, un système de réseau de confiance permet de faire tout ce qu'un modèle pyramidal permet. En particulier, il est tout à fait possible d'implémenter un modèle pyramidal ou hybride à partir d'un système de réseau de confiance.

Un réseau de confiance à la PGP ?

Je ne sais pas comment est construit un paquet DEB, mais je ne pense pas que beaucoup de distribs ont besoin d'avoir dans Git l'équivalent du tarball.

Comme je l'ai détaillé plus haut, Debian non plus, mais il est pratique de pouvoir le faire, et c'est considéré comme une bonne chose.

Par contre ce que je ne comprends pas, c'est de vouloir avoir dans Git l'équivalent du tarball.

Ah, c'est vrai que j'avais oublié d'expliquer cela. Ce n'est effectivement pas une nécessité, tout comme il n'est pas non plus nécessaire d'utiliser un gestionnaire de version d'ailleurs. C'est simplement pratique : nous disposons d'un outil nommé pristine-tar qui permet de stocker les informations nécessaires à la reconstruction du tarball exact dans le gestionnaire de versions, ce qui permet de tout mettre dedans et simplifie d'autant la gestion du paquet.

pristine-tar fonctionne en stockant dans une branche détachée — c'est à dire sans origine commune avec quelque autre branche — quelques informations : un commit d'origine proche du contenu du tarball, la compression utilisée et un delta binaire entre le tarball ainsi généré et l'original. On essaie de minimiser ce delta en utilisant un commit d'origine aussi proche que possible du contenu du tarball : un fichier de trop, tel un .gitignore ne posera pas de problème, mais plusieurs gros fichiers produiront un gros delta, ce qui n'est ni élégant ni efficace.

Indépendamment de la gestion de version, un paquet Debian source est constitué grosso modo de deux fichiers : le tarball d'origine et une archive contenant les fichiers spécifiques au paquet Debian. Lors de la décompression de ce paquet source, le tarball d'origine est simplement extrait, et les fichiers spécifiques à Debian sont placés dans un répertoire debian/, pour former ce que j'appellerais un répertoire de travail de paquet Debian. Lorsqu'on choisit de travailler sous contrôle de version, on y stocke le plus souvent tout le contenu du répertoire de travail, comprenant donc le contenu du tarball d'origine et le répertoire debian/.

Le dépôt de contrôle de version contient donc de quoi travailler, mais pas de quoi reconstruire le tarball d'origine, donc a fortiori pas de quoi reconstruire le paquet source qui comprend ce tarball d'origine. pristine-tar pallie cela, en versionnant également de quoi reconstruire ce tarball.

Alors, le VHD, ça a l'air équivalent à une image brute de n'importe quoi, donc aucun problème à monter ça en lecture-écriture du moment que le système de fichiers qui est dessus est approprié.

Je ne crois pas que le système de fichiers ISO 9660 ait jamais été conçu pour être utilisé en écriture : tout comme SquashFS, il me semble plutôt fait pour être généré puis utilisé en lecture seule.

En revanche, il existe un système de fichiers qui a été conçu entre autres pour cela : UDF. Et il n'y a aucun problème à monter une image UDF en lecture-écriture.

Monkeysphere. Dommage qu'il nécessite de laisser tourner un agent Monkeysphere.

Très bien, sauf que ces mécanismes ne répondent absolument pas au problème principal de sécurité, qui est la corruption d'une autorité de certification, qui est présenté ici.

Je vois, c'est une contrainte pénible de GNOME, donc. Eh bien, ça revient simplement à déplacer et à multiplier ce travail sur chaque distribution utilisant Git, tant pis…

Si tu peux faire le calcul attendu, hors éléments secrets, je ne vois pas ce qui pourrait empêcher ton attaquant de renvoyer les bonnes valeurs

Pire : l'attaquant peut tout simplement faire sauter le code de vérification, c'est beaucoup plus simple.

Bah, l'attaquant n'aurait qu'à remplacer ce code JavaScript par du rien…

Il ne faut pas compter sur le contenu transmis pour garantir quoi que ce soit, puisque ce contenu n'est garanti que s'il n'y a pas d'attaque.

Acronym overflow.

que le site web envoie un js

Lapin compris.

que le navigateur envoie des informations au serveur pour vérifier le certificat

Aucun intérêt : si le serveur n'est déjà pas le bon mais celui d'un intercepteur, il répondra sans aucun doute ce que ton navigateur attend.

Un article qui analyse les problèmes du modèle SSL : http://lair.fifthhorseman.net/~dkg/tls-centralization/

Je soupçonne des accords entre sociétés, parce qu'implémenter trop de fonctionnalités utiles nuirait aux éditeurs des logiciels qui comblent ces manques.

(un problème que les Libre n'a pas, d'ailleurs)

Et la possibilité de produire du PDF dans leurs logiciels ? Et un gestionnaire de volumes logiques, fonctionnalité indispensable pour tout serveur de fichiers (entre autres) qui se respecte ?

Je soupçonne des accords entre sociétés, parce qu'implémenter trop de fonctionnalités utiles nuirait aux éditeurs des logiciels qui comblent ces manques.