🚲 Tanguy Ortolo a écrit 12301 commentaires

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.

ce que je fais moi-même quand j'y suis obligé

Je précise encore une fois que je le fais moi-même si c'est nécessaire, mais j'ai l'impression que ça ne devrait pas être à moi de le faire, pour diverses raisons :

• cela donne l'impression qu'il y a un problème en amont puisque le contenu du dépôt ne correspond pas à ce qui est distribué ;
• ce travail n'est pas spécifique à une distribution, et pourrait donc être mutualisé, or la partie commune, c'est justement le travail amont.

Compris pour Vala. Je me permets donc de suggérer de faire, en amont, ce que je fais moi-même quand j'y suis obligé, comme ici :

master
↓ tarball
  ↓
*
| *  ← tarball/2.2.1
|/|
* |  ← release/2.2.1
| |
* |
| *  ← tarball/2.2.0
|/
*    ← release/2.2.0

À savoir : avoir une branche dont le contenu corresponde exactement aux tarballs distribués, à l'exception éventuelle de fichiers .gitignore, branche sur laquelle aucun développement n'aurait lieu, mais remise à jour à chaque nouvelle version. Une telle branche peut évidemment être séparée en plusieurs en cas de maintenance de version antérieure, par exemple :

*    ← tarball/2.4.0
|
| *  ← tarball/2.2.1
|/
*    ← tarball/2.2.0

La cohérence des étiquettes est le point important, plus que celle des branches elles-mêmes, à vrai dire.

À vélo.

• Texmaker et Kile ne pourrait pas fonctionner correctement sous gnome.

Non, là tu interprètes. LaTeXila est un IDE LaTeX pôur GNOME, point. Kile tourne sous GNOME, mais n'est pas bien intégré, alors que LaTeXila vise l'intégration.

Rah. Bon, eh bien on se passera de documentation, si je n'ai pas moyen de la compiler.

En fait non. On va empaqueter ITS Tool. :-)

C'est une recommandation qui me semble douteuse, du moins associée à celle de GNOME de ne pas stocker sous Git des fichiers générés. Parce que le résultat, c'est des tarballs qui ne correspondent pas du tout au contenu du VCS, ce qui est très désagréable pour un distributeur.

La solution que j'applique en tant que mainteneur de paquet, c'est d'assumer moi-même le travail d'adaptation en construisant les commits manquants. Mais je considère que ce travail ne devrait pas m'incomber (et me décomber).

Je ne pense pas que ITS Tool soit déjà packagé sur Debian. Mais ITS Tool est plus ou moins le successeur de gnome-doc-utils si j'ai bien compris, donc de plus en plus de modules de GNOME l'utiliseront (bien que ce ne soit pas du tout spécifique à GNOME).

Rah. Bon, eh bien on se passera de documentation, si je n'ai pas moyen de la compiler.

Autre chose, j'ai finalement opté pour une seule tarball qui contient le code source C généré (comme avant donc), mais il n'y a plus de commit dans Git qui correspond exactement au tarball, puisque c'est déconseillé de mettre dans Git des fichiers générés.

Ça, ce n'est pas cool, mais au pire, je les ferai moi-même, les commits en question, comme pour les autres paquets que je gère dont les auteurs ont cru bon de produire des tarballs qui ne correspondent pas au source, une habitude détestable à mon avis. Mais la vraie question, c'est : pourquoi fournir les fichiers C générés dans le tarball ? Cela supprime la dépendance à Vala, mais à quoi cela sert-il vu que Vala n'est pas un outil exotique et que LaTeXila dépend déjà d'autres outils qui sont bien plus pointus ? ITS Tool, par exemple…

Je suis en vacances, mais dès que je rentre et que j'ai un peu de temps, je m'y mets : si tout va bien, LaTeXila 2.2 sera bientôt dans Debian unstable.

c'est ça l'avantage d'ARM

Non, c'est ça l'avantage d'ARM pour l'embarqué. Or ARM n'est pas intéressant que pour l'embarqué, mais aussi pour les ordinateurs portables et les serveurs personnels.

Par ailleurs, il me semble tout à fait possible de permettre une personnalisation forte tout en fournissant un système de description du matériel disponible et de la façon de l'utiliser plus flexible que le simple identifiant de machine actuel. Par exemple, une table indiquant : à telle adresse mémoire, j'ai un port SATA utilisable avec le pilote orion_sata, à telle adresse j'en ai un second, à telle adresse j'ai une carte réseau Ethernet Gigabit…