Prenons un cas simple : l'auteur et l'utilisateur sont de nationalité française, vivent en France, et le logiciel couvert a été diffusé et utilisé en France. Dans ces conditions, est-ce que tu vois une seule façon d'éviter l'application de la loi française à un éventuel litige? Et, dans le cas contraire, est-ce que tu vois une façon d'éviter la nullité?
Et le problème se produira à nouveau dans toutes les circonstances où, une fois le droit applicable déterminé, le juge constatera que celui-ci impose explicitement la nullité.
En outre même si tout le monde s'entendait pour voir juger les litiges relatif à une licence suivant le Droit belge ou portugais, les risques de conflits d'interprétation sont également élevés.
Certes, mais il y a une grande différence entre un risque d'ordre interprétatif et une nullité noir-sur-blanc, comme ici.
Désolé de te décevoir, mais le droit d'utiliser un logiciel fait partie du droit d'auteur. Code de la propriété intellectuelle, article L122-1 :
Le droit d'exploitation appartenant à l'auteur comprend le droit de représentation et le droit de reproduction.
L'utilisation d'un logiciel, chose étrange, est considérée en France comme relevant du droit de reproduction, à cause de l'obligation de placer une copie du logiciel en mémoire pour l'exécuter. Je sais, moi non plus, ça ne me plaît pas énormément, mais c'est comme ça que les tribunaux ont construit la chose.
Si vraiment la licence logicielle était une transmission de droits d'auteur, alors l'association Videolan, qui gère VLC, n'aurait pas eu à contacter tous les contributeurs en vue du changement de la licence de VLC. Car un auteur à le droit de changement de licence, un utilisateur non.
Holà! Seul la personne investie de l' ensemble des droits d'auteur sur une œuvre a le droit de changer sa licence. Le problème de VLC, c'est qu'il tombait dans la catégorie des œuvres de collaboration, qui sont couvertes par l'article L113-2 du code de la propriété intellectuelle :
L’œuvre de collaboration est la propriété commune des coauteurs.
Les coauteurs doivent exercer leurs droits d'un commun accord.
En cas de désaccord, il appartient à la juridiction civile de statuer.
Lorsque la participation de chacun des coauteurs relève de genres différents, chacun peut, sauf convention contraire, exploiter séparément sa contribution personnelle, sans toutefois porter préjudice à l'exploitation de l’œuvre commune.
La phrase "Les coauteurs doivent exercer leurs droits d'un commun accord" signifie que tous les coauteurs doivent se mettre d'accord sur une licence pour pouvoir diffuser leur œuvre sous celle-ci. Cela ne pose généralement pas de problème dans le monde du logiciel libre, puisque si une personne n'est pas d'accord avec la licence d'un projet, elle n'a qu'à ne pas y participer; et qu'aucun coauteur ne peut tenter de forcer un changement de licence en exerçant son droit de retrait, puisque celui-ci lui est explicitement retiré par l'article L121-7, point 2, de ce même code :
Sauf stipulation contraire plus favorable à l'auteur d'un logiciel, celui-ci ne peut :
[…]
2° Exercer son droit de repentir ou de retrait.
En revanche, pour changer de licence, là, il faut l'accord de tous les coauteurs.
De façon plus générale, il ne faut pas confondre "transmission de droits d'auteur" et "transmission de l'ensemble des droits d'auteur". Un auteur peut très bien ne transmettre qu'une partie de ses droits, par exemple en autorisant la diffusion d'une œuvre, mais non sa modification, ou bien justement dans le cas d'une licence de logiciel libre, où il conserve généralement la propriété de son travail (ainsi donc que le droit de le diffuser sous une autre licence, plus tard, si ça lui chante), mais transmet les droits d'utilisation, de modification et de distribution, dont il serait sans cela le seul détenteur.
Accessoirement, de toutes façons, la transmission de l'ensemble des droits d'auteur est impossible en France, sauf en cas de décès, parce que le droit d'auteur inclut aussi le droit moral, qui est inaliénable et imprescriptible, article L121-1, paragraphe 3, de ce même code.
Clair que les avocats ne se battent jamais, oh grand jamais, sur la signification des mots dans un contrat…
Oui, enfin… Il y a beaucoup de ces batailles qui sont perdues d'avance, et dans lesquelles ils ne se lancent que pour faire gagner du temps à leurs clients. Un grand classique. (J'ai plusieurs avocats dans ma famille).
Enfin, cela dit, tu as raison, ce n'est pas toujours simple, et il faut effectivement y prendre garde. Je ferai spécialement attention à cette clause.
L'idée n'est pas mauvaise, mais juridiquement, je n'en ai pas le droit : le texte en question est lui aussi couvert par le droit d'auteur, je n'ai donc pas le droit d'en recopier une portion quelconque dans ma licence. (Et parmi les juristes, ceux spécialisés dans le droit d'auteur qui ont rédigé ce texte ne sont pas exactement du genre à ignorer leurs propres droits en la matière ;-) ).
Cela dit, le mécanisme employé par le texte que tu cites est intéressant. Je vais m'en inspirer.
(Pour ce qui est de préférer des textes rédigés par des juristes, en fait, ça n'a pas grande importance. Tout ce que les juristes apportent, normalement, c'est deux choses : la clarté (pour permettre l'application des articles 1156 à 1164 du code civil), et l'absence d'erreur de droit. Mais, pour le premier point, ce n'est pas bien difficile de demeurer clair, et pour le second, outre le fait que je ne sois pas trop mauvais en droit, comme tu l'auras sans doute remarqué :-) , lorsqu'on suit les mêmes disposition qu'un de leurs textes, on ne fera pas plus d'erreur de droit qu'eux. Et, oui, ça, c'est parfaitement légal, puisque les idées seules ne sont pas soumises au droit d'auteur.
Bon, après, je suppose qu'au-delà d'une certaine échelle, des accusations de plagiarisme pourraient faire surface, mais pour une seule clause comme ici, c'est sans risque.)
Disons que je souhaite que les utilisateurs puissent disposer du code source de mon logiciel, et je ne suis pas favorable à sa propriétarisation (à mon avis un non-sens dans ce qui touche la sécurité), donc de ce côté-là, je suis plus favorable aux licences de type GPL que BSD.
De plus, de mon point de vue, les licences BSD ont le même défaut que la GPL : pas de délimitation temporelle et spatiale des droits concédés, donc nullité au regard du droit français.
Justement, d'après moi, ma licence est parfaitement libre; et en plus, ce sont les licences habituelles qui sont en réalité non-libres (d'où ma décision de ne pas opter pour l'une d'elles). Si vous trouvez des objections à mon raisonnement sur le sujet, allez-y, cela m'intéresse; malheureusement, je crains qu'il ne soit inattaquable.
Cependant, si vous n'êtes pas convaincus, mais que vous n'avez pas d'arguments juridiques à m'opposer, je peux vous proposer une forme de compromis.
En effet, dans la mesure où j'estime que la GPL est invalide, je n'ai pas d'objection fondamentale à passer mon logiciel sous une double licence "Licence Manux/GPL" : puisque j'estime qu'elle est frappée de nullité, dans une telle approche, de mon point de vue, je ne fournirais en réalité pas réellement de droits supplémentaires.
Je peux donc proposer d'ajouter à ma licence une clause rédigée ainsi :
"La General Public Licence, version 3, dite 'GPLv3', est une licence de logiciel libre rédigée par la Free Software Foundation (FSF), sise [ adresse de la fsf ].
En plus des droits accordés par cette licence, l'utilisateur est autorisé à redistribuer le logiciel sous les termes de la GPLv3, en lieu et place de cette licence-ci, à condition bien sûr que la GPLv3 soit elle-même valide.
Toutefois, l'auteur de cette licence-ci tient à avertir loyalement le licencié que la précédente condition n'est à son avis malheureusement pas remplie, par suite notamment de graves incompatibilités entre la GPLv3 et le droit français. Cependant, il existe dans la communauté du logiciel libre de nombreuses personnes qui ne partagent pas cette opinion, et qui au contraire estiment que, sans la présente clause, c'est la licence Manux elle-même qui serait non-libre. Constatant, d'une part, que le désaccord entre les deux groupes n'a pu être résolu par voie argumentative, et d'autre part, que si l'opinion de l'auteur de la licence était juste, alors l'ajout de la présente clause n'aurait pas d'effet notable, la permission précitée a été ajoutée.
Afin que le licencié ne puisse reprocher à l'auteur de la licence d'avoir agi à son égard de façon traître, en plaçant dans la licence une clause dont il savait par avance qu'elle n'était pas utilisable, ledit auteur a préféré ajouter l'avertissement que vous venez de lire. Le licencié est donc invité à étudier soigneusement le problème avant de faire usage de ce droit."
De la sorte, on préserve les intérêts du loup, de la chèvre et du chou :
Les personnes qui estiment que ma licence n'est pas libre, mais que la GPLv3 est libre, seront satisfaites, tout au plus tristes que je me sois trompé;
Les personnes qui, comme moi, estiment que ma licence est libre, et pas la GPLv3, seront satisfaites aussi, puisque ma licence demeure;
Et moi, enfin, je serai satisfait, puisque je n'aurai pas le sentiment d'être le vilain méchant pas beau qui utilise ses connaissances en droit pour tendre un piège à ses utilisateurs, dans la mesure où je les aurai avertis clairement et loyalement du problème.
Le pire, c'est que ça vient de me revenir : en fait, j'avais déjà repéré le problème, et décidé d'opter pour un répertoire spécial pour ce cas… Mais ça m'était complètement sorti de l'esprit. Honte sur moi /o\ .
(Bon, pour ma défense, c'était il y a plusieurs années.)
un logiciel fait comment pour aller lire dans les dossiers de l'utilisateur pour …
- ouvrir un document, le modifier, et l'enregistrer
- ajouter une piece jointe à un email
En fait, tous les logiciels qui font ce genre de choses font appel à des bibliothèques externes pour le faire; c'est pour ça que, dans LibreOffice par exemple, lorsqu'on fait "ouvrir", on obtient une fenêtre avec un aspect différent sous Gnome et sous KDE (j'avoue que je ne me suis pas penché plus loin sur la question, et je ne sais pas quelle est précisément cette bibliothèque). Tout ce que je ferai, c'est de fournir une bibliothèque de ce type qui appellera un programme externe, lequel aura accès à tous les fichiers de l'utilisateur ainsi que la possibilité de les ajouter à l'arborescence de son appelant; et c'est ce programme qui affichera la fenêtre à l'utilisateur lui demandant quel fichier il veut ouvrir. De la sorte, pour l'utilisateur, ce sera transparent; quant au logiciel appelant, qu'il s'agisse d'un traitement de texte, d'une messagerie électronique, ou d'autre chose, il n'y verra que du feu.
(J'anticipe la question : que se passera-t-il en cas d'exploit jour zéro dans ce logiciel-là? Ma réponse, c'est que comme il ignorera toutes les options de sa ligne de commande, et qu'il ne s'occupera pas du contenu des fichiers qu'il ouvrira, les exploits seront assez peu probables; en tout cas, nettement plus improbables que dans les logiciels appelants. En plus, pour l'exploiter, il faudrait disposer de deux exploits, l'un dans ce logiciel, l'autre dans un de ses appelants, donc ce sera vraiment très compliqué. Mais effectivement, si ça se produit, la sécurité sera abattue. C'est malheureux, mais dans un tel cas, l'OS aura vraiment fait tout ce qu'il pouvait.)
Donc, on pourra ouvrir une page locale, mais les liens vers d'autres pages locales ne fonctionneront pas, ni même les images et CSS externes référencées dans la page.
Ah oui, c'est vrai, il y a ce cas-là. Désolé, vu l'esthétique de mon site, c'est vrai que j'avais oublié ces histoires de CSS.
Autant dire que ça ne fonctionne pas.
Hé, une minute! Le point que tu viens de soulever est intéressant, j'en conviens, mais il est limité au cas particulier des documents qui incluent ou référencent légitimement des fichiers externes qui ne font pas partie des dépendances du logiciel chargé de les ouvrir, ce qui est relativement limité. (Même gcc n'est pas concerné, les #include locaux fonctionnant du fait de la transmission du chemin courant et des -I répertoire . D'ailleurs, comme mon système est déjà auto-hébergé, si ce problème empêchait son fonctionnement, je l'aurais déjà repéré.).
J'admets que, dans le cas de ces fichiers, il va falloir appliquer une solution légèrement différente de celle à laquelle j'avais songé. En pratique, je vais certainement opter pour l'approche la plus simple : créer un répertoire spécifique à ce genre d'opérations, auquel firefox aura simplement toujours accès; à charge pour le développeur qui veut accéder à son site en local de l'y placer.
(Il existe d'ores et déjà une autre solution, en ligne de commande, puisque l'utilisateur a la possibilité d'ajouter l'accès aux fichiers de son choix à n'importe quel logiciel lors de son appel, mais il est évident qu'on ne peut pas raisonnablement attendre que l'utilisateur tente une telle approche.)
De façon générale, la sécurité est une affaire de compromis : mon système d'exploitation accroît la sécurité au prix d'une diminution de l'utilisabilité, Linux (et les autres systèmes d'exploitation) ont fait le choix inverse. Je tente de maintenir mon système aussi utilisable que possible avec ses sécurités contre les exploits jour zéro, mais son utilisation sera toujours légèrement plus complexe que celle d'un Linux.
Mais alors le navigateur ne peut pas enregistrer un fichier PDF ? (pas de droits en écriture ?)
Le navigateur ne peut pas uploader une image ? (pas de droits en lecture ?)
Ni ouvrir un fichier html local quelquonque ?
Pour enregistrer un fichier pdf ou uploader une image, il faudra que le navigateur fasse appel à un programme externe (ou, éventuellement, que l'utilisateur déplace le fichier dans le répertoire du navigateur, ce qui fonctionnerait mais ne serait pas franchement intuitif).
Pour ouvrir un fichier html local, si, pas de problème : il suffira de taper firefox file:///home/me/mon_fichier.html (ou de double-cliquer sur l'icône correspondante, de telle sorte que le shell graphique fasse cet appel pour l'utilisateur), et le tour sera joué. Par contre, en effet, on ne pourra généralement pas l'ouvrir à partir de la barre d'adresse.
ça reste des solutions de limitation, pas d'interdiction totale.
Tout à fait. Mais la présence de /bin/login est habituellement indispensable sur une machine, et pas celle de ssh. En ne plaçant qu'un seul de ces programmes au lieu de deux, on réduit d'autant la probabilité d'une faille. Mais oui, dans le cas particulier du serveur ssh, tu as raison, on ne peut hélas faire que de la limitation.
Si un navigateur web est troué, qu'est-ce qui va interdire l'attaque ?
Rien. Mon système ne peut qu' encaisser les attaques, pas les empêcher. En ce qui concerne le navigateur, s'il est troué, l'attaquant pourra en prendre le contrôle, regarder, modifier et supprimer l'historique de navigation, regarder ce que fait l'utilisateur sur le net… Mais il ne pourra pas accéder aux documents pdfs, LibreOffice, et autres, situés sur la machine. Je pense que c'est déjà bien, comme protection; et de toutes façons, l'OS seul ne peut malheureusement pas en faire plus.
Ensuite, si l'utilisateur (ou sa distribution) a installé deux instances séparées du navigateur, un pour sa banque, l'autre pour sa navigation privée, l'attaquant qui contrôle le site sexy-tabou.com ne pourra pas obtenir les informations sur les comptes de la victime. Ça aussi, ce n'est pas négligeable.
Si un serveur ssh a une faille, qu'est-ce qui va le protéger ?
Tel que les serveurs ssh sont actuellement conçus, rien, et une faille dans un serveur ssh, honnêtement, c'est un peu l'Armaggedon. Mais il est possible de le sécuriser, en séparant le serveur ssh (chargé de la communication réseau) du logiciel d'authentification et de création de session; de la sorte, le serveur ssh se retrouverait incapable d'ouvrir une session arbitraire sans son mot de passe.
Autant dire tout de suite que ce n'est pour l'instant pas implémenté.
Justement, le maintien de forks ne pose pas de problème. D'une part, rien ne s'oppose à la création et au maintien d'un fork complet : dès qu'il est renommé, il n'a plus rien à voir avec le précédent logiciel, et ciao!
Ensuite, en ce qui concerne la création de distributions qui s'entreforkent (joli verbe, ça), ça ne pose pas de problème non plus… puisqu'il suffit de déclarer, exactement comme dans le monde Linux, que les distributions s'appellent MandriHat Manux ou RedCake Manux! Bah oui, ce n'est pas un renommage, ça, c'est une intégration du nom dans un autre nom, ce qu'aucune disposition n'interdit - et tout ce que les règles ont oublié d'interdire est autorisé. Et hop, aucune difficulté, ce n'est même pas regardé comme un fork au regard de ma licence.
(Cela dit, maintenant que j'y pense, c'est peut-être de ma faute, ma licence n'est pas très explicite de ce côté… Dans la prochaine version, je la modifierai pour qu'il soit clair que ce comportement ne constitue pas un renommage.)
En fait, la mémoire partagée sera implémentée dans l'avenir; cependant, comme chacun sait, celle-ci entraîne la création de canaux de communication cachés très importants dans le système. Pour résoudre ce problème, l'administrateur aura le choix entre :
S'il s'appelle super-parano-man, reconfigurer le noyau pour désactiver cette fonctionnalité (après tout, je n'ai pas créé un noyau à patchage dynamique pour rien!);
Si c'est juste parano-man ou un de ses acolytes, il pourra installer les mêmes bibliothèques plusieurs fois, et choisir quels programmes accèdent à quels exemplaires des bibliothèques. Cela donnera un comportement proche de celui des compartiments de Solaris.
d'ailleurs, dans le meme ordre d'idée, comment se passe la communication inter-programmes ?
Cela dépend du mécanisme. Si c'est un simple pipe, pas de problème : il est créé classiquement par le père par pipe(2) avant le fork(2), puis conservé par les fils après l'execve(2). Si c'est un pipe nommé ou une socket du domaine UNIX, il faut recourir à un lien matériel vers le fichier en question pour lui permettre d'apparaître dans les divers chroots. A titre d'exemple, c'est déjà ce qui est fait pour permettre la communication entre init et telinit du paquetage sysvinit.
(Les sockets anonymes du domaine UNIX, qui ne sont au fond qu'une extension Linux, ne seront tout simplement pas implémentées.)
En ce qui concerne les segments de mémoire partagés, et les autres IPCs system-V, je reconnais que je n'ai pas encore décidé de la façon dont j'allais procéder à leur isolement, mais j'emploierai certainement une méthode de type "espace de noms" comme sous Linux (CLONE_NEWIPC); de même pour les signaux.
Cette article s'applique à quelle partie du monde? Ca me semble un truc franco-français ce truc, j'avoue que je m'en fou un peu de la France. Un article de l'OMC mini?
J'avoue que je ne sais pas ce qui se passe si un français intente un procès à un étranger pour obtenir l'annulation de sa licence au titre d'une disposition du droit français sans équivalent à l'étranger, je ne sais pas dans quelles conditions il peut obtenir l'application du droit français au contrat sans désignation de droit qu'est la GPL. Il faudrait effectivement se pencher sur les règles de l'OMC pour le savoir, mais là, je ne suis plus trop dans ma spécialité.
Cela dit, une licence comportant une clause "si vous vivez en France, vous devez cesser définitivement de distribuer et d'utiliser le logiciel dès la réception d'une simple demande de n'importe quel auteur" serait immédiatement jugée non-libre. Or toutes les licences en question comportent exactement cette clause, en version implicite…
Elle sont tellement entachée de nullité que plein de tribunaux, y compris français, les acceptent… (bon, ils demandent parfois une traduction en français certes)
Oui et non… Je me souviens d'un procès, dont je ne retrouve plus l'arrêt, dans lequel le violateur de la GPL avait tenté d'invoquer cette nullité pour s'exonérer de ses fautes. Le juge avait répondu qu'il n'était pas l'un des auteurs, et donc que, si la GPL était invalide, alors il n'aurait pas eu de licence légale du tout, ce qui aurait fait de lui un contrefacteur, et a donc refusé d'examiner l'argument plus avant.
Cette solution était juste, mais force est de constater que c'était passé tout près. La nullité était bien là, mais l'avocat du défenseur n'a pas réussi à l'invoquer précisément parce que ce n'est qu'une nullité relative, et qu'il ne faisait pas partie des personnes protégées par la disposition violée. A contrario, s'il était l'un des auteurs, la nullité aurait vraisemblablement triomphé.
Tu crois vraiment que les juges sont si stupides que ça?
tu crois vraiment que tu es meilleurs analystes que les avocats spécialistes en la matière qui ont fait les licences (surtout la GPL)?
Les juges sont tenus d'appliquer la loi, qu'elle leur plaise ou non. Et quant à ces fameux "meilleurs spécialistes", voyons donc ce qu'ils en disent :
Ah, tiens, ils ont repéré la même nullité que moi?
La liberté de modifier, ça comprend de mixer.
Les logiciels sous licence GPL et CDDL sont non-mixables; cela a beau agacer bien des gens, cela reste des licences libres.
sans compter que je vois en fait mal la réalité de ton délire : je créé un .patch entre ma version et celle de l'époque, je reprend la version en cours et applique mon patch, na, je n'ai pas utilisé de "code futur" puisque je re-forke.
par contre, ca resiste aux mises à jour de la lib (changement des inodes) ?
ou il faut regenerer les links ?
Il faut les regénérer. Cela ralentit l'installation des bibliothèques, j'en suis conscient, mais il n'y a pas d'alternative.
ca donne quoi lorsque plusieurs programmes utilisent les memes libs ?
ca duplique le code, ou ca permet toujours d'utiliser la memoire partagée ?
Alors, euh… Si j'avais programmé la mémoire partagée, alors oui, la mémoire serait effectivement partagée entre les différents logiciels situés dans des chroots différents, mais, comme je ne l'ai, euh, pas encore programmé…
Les bibliothèques partagées sont gérées sans problème : elles sont liées matériellement dans la racine de chaque programme qui en a besoin. Lors de l'installation d'un paquetage, c'est l'une des tâches du logiciel de résolution de dépendances.
Pour ce qui est des bibliothèques, aucun souci : au moment de l'installation des dépendances, elles sont simplement installées dans la racine du programme qui en a besoin à l'aide de liens matériels. Résultat, le coût additionnel est nul.
En ce qui concerne les programmes, oui, il y a un ralentissement, mais il est vraiment minime. Les lanceurs sont compilés statiquement sans libc, les appels-systèmes étant simplement réalisés avec asm volatile ("int $0x80" : : ); et les opérations requises sont très rapides. Pour donner une idée, la seule initialisation de la glibc au lancement d'un programme, avant l'appel à main(), prend plus de temps que la totalité des opérations du lanceur.
Non, ce n'est pas libre; Je le défie de faire valider sa licence par l'OSI (plus conciliante que la FSF).
Dans le monde du logiciel libre, la notion de "licence libre" est souvent un point contentieux, des définitions et des analyses différentes pouvant mener à des résultats très distincts. A mon avis, ce sont les licences GPLv2, GPLv3, BSD 2-clauses, BSD 3-clauses, BSD 4-clauses, Apache et MIT qui auraient dû être déclarées non-libres.
Explication (avant que vous ne me preniez pour un troll particulièrement en forme) : aucune de ces licences ne comporte de clause précisant la loi applicable. Cela signifie qu'on peut leur appliquer la loi que l'on souhaite; donc en particulier la loi française.
Prenons donc le code de la propriété intellectuelle, partie législative, chapitre I, article L131-3, premier paragraphe :
La transmission des droits de l'auteur est subordonnée à la condition que chacun des droits cédés fasse l'objet d'une mention distincte dans l'acte de cession et que le domaine d'exploitation des droits cédés soit délimité quant à son étendue et à sa destination, quantaulieuetquantàladurée.
Cela signifie que, pour qu'une licence logicielle soit valide, elle doit comporter, àpeinedenullité, la mention du lieu et de la durée d'utilisation qu'elle couvre. La CeCILL le fait (article 2 : la licence est mondiale, article 4.2 : la licence produira ses effets durant toute la durée de protection des droits patrimoniaux du logiciel); les licences précitées, non.
Résultat, toutes les licences en question sont entachées de nullité. Nullité relative, certes (et heureusement!), mais nullité quand même. (La nullité est relative parce que les dispositions en question visent à protéger les détenteurs du droit d'auteur, pas à sauvegarder l'ordre public : elle ne peut donc pas être soulevée par n'importe quelle partie, uniquement par un auteur qui s'en prétend "lésé").
De ce fait, si l'auteur d'une portion (significative) d'un logiciel quelconque distribué sous l'une de ces licences s'installe en France, puis intente une action en justice parce que, bah, "je n'avais pas prévu que des gens continueraient à utiliser ce logiciel après que j'aie arrêté de le distribuer et que je sois allé travailler dans le privé", il gagnera son procès, et les utilisateurs et distributeurs recevront une gentille mise en demeure de cesser d'utiliser et de distribuer ce logiciel. Bref, comme ces licences ne précisent pas la durée d'exploitation, alors que cette mention est absolument obligatoire, elles seront invalidées dès qu'un détenteur des droits le demandera.
Ah, et inutile d'essayer de plaider la mauvaise foi de l'auteur, la mauvaise foi n'étant pas une défense recevable face à une nullité. (Enfin, façon de parler. Si vous êtes confronté à cette situation, allez-y, plaidez sa mauvaise foi : ce n'est pas interdit, et cela devrait sérieusement réduire, voire supprimer, les dommages et intérêts auxquels vous pourriez être condamné).
Bref, à mon avis, le fait de permettre ainsi à tout auteur de mettre fin au droit d'utiliser et de distribuer le logiciel fait que toutes les licences en question auraient dû être regardées comme non-libres. Cela étant, je conçois que cela pose d'énormes problèmes : il y a énormément de logiciels sous ces licences, il est extrêmement difficile de s'en passer, d'ailleurs, j'en utilise et distribue moi-même. Mais il va de soi que je ne souhaite pas créer un problème de ce type pour mes utilisateurs, donc j'ai choisi de placer mon logiciel sous ma propre licence.
(J'aurais aussi pu choisir la CECiLL, mais elle ne comportait pas de clause d'auto-incompatibilité en cas de renommage, et puis, de façon secondaire, sa clause 13.2 n'est pas en majuscules, ce qui crée des doutes sur sa validité).
La personne veut qu'on tout lui revienne sinon il met des bâtons dans les roues.
Hmmm… Non, ce n'est pas vraiment le problème. Mon seul objectif était de casser la viabilité des forks créés exclusivement pour des motifs bassement mercantiles et anti-communautaires, en les contraignant à faire des forks complets (dont le coût détruirait la viabilité du projet), pas d'embêter les développeurs qui voudraient le modifier de façon "conventionnelle".
D'ailleurs, je me permets de remarquer qu'il y a dans ma licence une sécurité implicite, mais très puissante, contre un tel comportement : aucune règle ne précise dans quelles circonstances le responsable légal désigné est tenu de contraindre un projet concurrent à changer de nom; en particulier, "jamais et en aucune circonstance" est un choix autorisé.
Cela signifie que, si un responsable légal, fût-ce moi-même, décidait de "mettre des bâtons dans les roues" d'un autre projet parce que tout ne lui "revient pas", ledit projet se retrouverait effectivement contraint de faire un fork… Et ensuite, lequel des deux projets se retrouvera avec l'ensemble de la communauté moins un développeur? Hé oui, comme le logiciel est libre, rien n'empêchera le nouveau projet de promettre d'autoriser les usages de leur nom sans restrictions; d'ailleurs, il pourra même s'y contraindre légalement, en publiant un contrat d'usage de sa propre marque dans laquelle il autorise effectivement n'importe quel usage. Résultat, les développeurs le rejoindront, et le responsable qui avait abusé de son droit se retrouvera seul dans son bac à sable.
En pratique, cela signifie qu'il n'est pas possible d'utiliser cette clause pour quoi que ce soit d'autre que son objectif annoncé, parce que tout autre usage sera vécu comme un "coup dans le dos" par la communauté, résultant en un fork, un basculement de la communauté sur le nouveau projet, et voilà tout. Cf. l'aventure de Xfree86, qui avait abusé des droits qu'il détenait sur le logiciel, ce qui a simplement amené la naissance de X.org.
"De plus, le licencié n'est pas autorisé à modifier le logiciel en lui appliquant une modification originaire d'un exemplaire du logiciel portant un nom différent de celui porté par l'exemplaire du logiciel qu'il souhaite modifier" qui le rend non libre.
Je ne vois pas en quoi cela rendrait la licence non-libre. C'est une clause d'auto-incompatibilité inattendue, certes, mais à ma connaissance, aucune règle du logiciel libre ne précise quel degré de compatibilité avec les autres logiciels les licences libres doivent fournir. D'ailleurs, ces incompatibilités peuvent survenir avec d'autres licences, par exemple, si on passe sous GPL un logiciel sous BSD, il sera impossible d'inclure du code originaire du nouveau venu dans son prédécesseur.
De façon plus générale, dans toutes les définitions du logiciel libre, je ne vois aucune règle, explicite ou implicite, interdisant de contraindre un fork à faire un fork complet, sans utilisation future du code futur du projet d'origine. Je suis entièrement d'accord pour dire que cette clause est hautement inhabituelle, mais ce n'est pas un critère : pour être un logiciel libre, tout ce qui compte, c'est de respecter la définition du logiciel libre, pas de respecter cette définition de façon habituelle.
Exactement. Un exemple, quand je tape cat ~/docs/file.txt, c'est le lanceur de cat, un petit exéctuable de /bin, qui se lance. Il construit alors une arborescence virtuelle contenant simplement le fichier file.txt dans le répertoire ~/docs, puis fait un chroot dans la racine du vrai programme cat (à laquelle il a accès grâce à un lien racine, un lien spécial qui n'est suivable qu'en faisant ce genre de chroot). Ensuite, il fait un execve() sur le vrai binaire de cat.
Ce binaire, à son tour, examine sa ligne de commande, voit qu'il doit accéder à ~/docs/file.txt, l'ouvre (sans repérer qu'il se situe dans une arborescence virtuelle qui ne contient rien d'autre que ce fichier), fait son travail et quitte. Et même s'il y avait eu un exploit jour zéro dans ce fichier, comme cat n'a (normalement) pas l'accès en écriture à sa propre racine, et qu'il n'a accès qu'à un seul autre fichier en-dehors de celle-ci, il se retrouve coincé.
C'est cela que je veux dire par "encaisser" : je ne peux pas empêcher l'existence d'exploits, mais je peux les rendre en pratique inexploitables.
Pour info, je serai ce week-end au premier samedi. S'il y a des franciliens qui n'osent pas l'installer eux-mêmes, ou bien qui ont juste envie de le voir ou d'en discuter, n'hésitez pas!
Alors, si tu fais référence au code de retour : arf, j'avais oublié de le forcer à 0. Corrigé.
En revanche, si tu fais référence à l'implémentation, alors non, la mienne est bien correcte.
Ce qui se passe, c'est qu'il y a une erreur dans la page de manuel française de sched_yield(). Les spécifications ne précisent nullement qu'un nouveau thread sera exécuté (c'est même impossible dans certains cas, par exemple si l'appelant est le seul thread actif ou activable du système), juste qu'il pourra l'être.
De plus, les notions de multitâche et d'exécution parallèle ne sont pas spécifiées, et les choix d'ordonnancement sont laissés à la discrétion de l'implémentation. C'en est même à tel point que les auteurs des spécifications ont dû rajouter une note pour interdire l'implémentation-gag du fork() monothreadé (1).
Par conséquent, lorsqu'un thread appelle sched_yield(), l'implémentation doit le placer parmi les threads ayant fini leur temps d'exécution, puis exécuter un thread activable de son choix. En particulier, elle peut fort bien décider de relancer immédiatement cet appelant. Tout ce que fait mon implémentation, c'est qu'elle choisit de le ré-exécuter à chaque fois. Là aussi, c'est clairement une implémentation-gag, mais c'est un comportement possible, et un choix qui ne viole aucune spécification.
(1) Le fork() monothreadé consiste à choisir, comme politique d'ordonnancement, que lors d'un fork(), le fils s'exécute immédiatement et que le père ne sera exécuté qu'une fois que le fils se sera terminé. Cela aboutit à un UNIX ne comportant qu'une seule thread avec empilement et dépilement des divers processus, et aucun multitâche… Mais cela ne viole pas formellement les spécifications.
Les auteurs de ces spécifications ont ajouté une note pour préciser que ce genre d'implémentation-gag serait regardée comme un jouet et non un véritable système d'exploitation. Mais cela illustre bien le niveau de liberté laissé aux implémentations quant à l'ordonnancement.
Il se trouve que j'ai étudié l'appel-système jail_set(2) de FreeBSD. En ce qui me concerne, j'ai renoncé à l'implémenter ou à m'en inspirer, pour diverses raisons, mais j'ai bien dû reconnaître qu'il était supérieur au chroot(2) de Linux.
Ensuite, Linux dispose d'autres mécanismes de sécurité, comme SELinux, qui rendent une comparaison délicate. A vrai dire, entre Linux et FreeBSD, la différence principale en termes de sécurité ne se situera clairement pas au niveau du choix du système, mais des compétences de l'administrateur de la machine.
Je vois un intérêt à ton système, mais pour certaines application, il lui faudrait un mode débridé, sinon le développement sera vite un enfer ;).
Hélas… Le système lui-même n'est pas à proprement parler débridable (ou plus exactement, la version débridée s'appelle Linux).
Par contre, l'utilisateur peut facilement et automatiquement ajouter tout ce qu'il veut à un programme. Si tu crées un script ~/bin/mon_emacs qui injecte dans le PATH d'emacs toutes les commandes dont tu te sers habituellement, ça fonctionnera sans problème. C'est d'ailleurs ce que fait le binaire ./make des sources du noyau, pour donner à make accès au compilateur, à l'assembleur, à l'éditeur de liens, etc…
Autre question, comment se comporte le système sur plusieurs partition imaginons que je doives éditer 680Go de film sur partition A et 254Go de filme sur partition B?
Pas de vraie différence par rapport à Linux; une même application peut accéder simultanément à des fichiers situés dans des partitions physiques séparées, c'est transparent. Sauf justement dans les cas où ce n'est pas transparent non plus sous Linux, comme pour les déplacer ou créer un lien matériel entre les deux.
Non. Des solutions pourront être mises en place dans l'avenir pour fournir cette fonctionnalité (comme je l'ai évoqué dans un autre commentaire); mais pour l'instant, ça ne marche pas. C'est incontestablement une limitation de mon système. J'estime simplement que les bénéfices tirés de l'accroissement de la sécurité en valent la peine.
Ce genre de fonctionnalité de vim serait tué?
En fait, non. Dans ce cas précis, tu as passé http://XXX sur la ligne de commande de ton lanceur, ce qui permet de comprendre ton intention d'accéder au réseau, par conséquent, le lanceur fournirait à cette instance de vim l'accès requis.
Enfin supposons que quelqu'un ouvre un fichier en étant root
Je commencerais par faire remarquer que mon système n'a pas de root, et que les privilèges peuvent être donnés à n'importe quel utilisateur :-) . C'est documenté dans la FAQ, chapitre "comment peut-on passer root". Et il est impossible d'échapper d'un chroot, quel que soient les privilèges; une application "non chrootée", ça n'a pas vraiment de sens.
En revanche, avec son split dans vim et son ouverture d'un second fichier, l'utilisateur commettrait effectivement une erreur qui permet la propagation de l'attaque. Et c'est faisable, mais pas de la façon dont tu l'envisages : il faudrait passer à vim deux fichiers sur sa ligne de commande, et ensuite ouvrir le second dans le split.
Donc, oui, c'est vrai, c'est une autre faiblesse. Je pense que les utilisateurs apprendront (ou que les logiciels seront patchés pour parer à cela, par exemple en lançant une seconde instance d'eux-même dans ce genre de cas).
Mais effectivement, tu as raison : mon système peut encaisser bien des choses, mais pas ça.
Ça, d'accord, pas de problème. Mais je trouve que s'interroger pour savoir si un système d'exploitation est utilisable pour quoi que ce soit alors qu'il est déjà auto-hébergé, c'est à peu près aussi trollesque que de s'interroger pour savoir si une voiture est capable de circuler après qu'elle ait fini les 24h du Mans.
Une application ne peut donc créer de nouveaux fichiers.
Si, mais seulement ceux dont le nom lui a été passé sur sa ligne de commande.
En revanche, pour des fonctionnalités du genre "nouveau document" ou "enregistrer sous", il faudra effectivement passer par un programme externe. Mais ça ne pose aucun problème : en effet, les programmes graphiques qui proposent ces fonctionnalités le font déjà en employant des bibliothèques (c'est pour ça que les apparences de ces boîtes de dialogue sont si semblables). Tout ce qu'il y aura à faire, c'est de fournir une bibliothèque appelant ce programme.
que l'exemple du ':!ls' ne te fasse pas percuter que c'est ce que les applications passent leur temps à faire
Hmmm… Quelles applications font ce genre de choses? Je veux dire, le lancement de commandes entièrement arbitraires. Je ne vois guère que les shells (gérés), les scripts de l'utilisateur (gérés), et les "make" (gérés).
En ce qui concerne les applications qui ont besoin de faire appel à une autre de façon prévisible, pas de problème : cela signifie que le second programme fait partie de leurs dépendances, et donc qu'ils ont dans leur racine un lien matériel vers le lanceur de ce programme.
Par exemple, si tu as un programme qui a une dépendance sur ls, alors il aura, dans sa racine, un fichier /bin/ls correspondant au lanceur de ls, qui lui permettra de le lancer à volonté, sans restrictions. Mais comme l'accès au lanceur d'un programme n'implique pas l'accès à son xchroot, cela laisse intacte la sécurité de l'application, comme celle de ls.
[^] # Re: licence ?
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 1.
Prenons un cas simple : l'auteur et l'utilisateur sont de nationalité française, vivent en France, et le logiciel couvert a été diffusé et utilisé en France. Dans ces conditions, est-ce que tu vois une seule façon d'éviter l'application de la loi française à un éventuel litige? Et, dans le cas contraire, est-ce que tu vois une façon d'éviter la nullité?
Et le problème se produira à nouveau dans toutes les circonstances où, une fois le droit applicable déterminé, le juge constatera que celui-ci impose explicitement la nullité.
Certes, mais il y a une grande différence entre un risque d'ordre interprétatif et une nullité noir-sur-blanc, comme ici.
[^] # Re: licence ?
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 3.
Désolé de te décevoir, mais le droit d'utiliser un logiciel fait partie du droit d'auteur. Code de la propriété intellectuelle, article L122-1 :
L'utilisation d'un logiciel, chose étrange, est considérée en France comme relevant du droit de reproduction, à cause de l'obligation de placer une copie du logiciel en mémoire pour l'exécuter. Je sais, moi non plus, ça ne me plaît pas énormément, mais c'est comme ça que les tribunaux ont construit la chose.
Holà! Seul la personne investie de l' ensemble des droits d'auteur sur une œuvre a le droit de changer sa licence. Le problème de VLC, c'est qu'il tombait dans la catégorie des œuvres de collaboration, qui sont couvertes par l'article L113-2 du code de la propriété intellectuelle :
La phrase "Les coauteurs doivent exercer leurs droits d'un commun accord" signifie que tous les coauteurs doivent se mettre d'accord sur une licence pour pouvoir diffuser leur œuvre sous celle-ci. Cela ne pose généralement pas de problème dans le monde du logiciel libre, puisque si une personne n'est pas d'accord avec la licence d'un projet, elle n'a qu'à ne pas y participer; et qu'aucun coauteur ne peut tenter de forcer un changement de licence en exerçant son droit de retrait, puisque celui-ci lui est explicitement retiré par l'article L121-7, point 2, de ce même code :
En revanche, pour changer de licence, là, il faut l'accord de tous les coauteurs.
De façon plus générale, il ne faut pas confondre "transmission de droits d'auteur" et "transmission de l'ensemble des droits d'auteur". Un auteur peut très bien ne transmettre qu'une partie de ses droits, par exemple en autorisant la diffusion d'une œuvre, mais non sa modification, ou bien justement dans le cas d'une licence de logiciel libre, où il conserve généralement la propriété de son travail (ainsi donc que le droit de le diffuser sous une autre licence, plus tard, si ça lui chante), mais transmet les droits d'utilisation, de modification et de distribution, dont il serait sans cela le seul détenteur.
Accessoirement, de toutes façons, la transmission de l'ensemble des droits d'auteur est impossible en France, sauf en cas de décès, parce que le droit d'auteur inclut aussi le droit moral, qui est inaliénable et imprescriptible, article L121-1, paragraphe 3, de ce même code.
[^] # Re: licence ?
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 3.
Oui, enfin… Il y a beaucoup de ces batailles qui sont perdues d'avance, et dans lesquelles ils ne se lancent que pour faire gagner du temps à leurs clients. Un grand classique. (J'ai plusieurs avocats dans ma famille).
Enfin, cela dit, tu as raison, ce n'est pas toujours simple, et il faut effectivement y prendre garde. Je ferai spécialement attention à cette clause.
[^] # Re: licence ?
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 2.
L'idée n'est pas mauvaise, mais juridiquement, je n'en ai pas le droit : le texte en question est lui aussi couvert par le droit d'auteur, je n'ai donc pas le droit d'en recopier une portion quelconque dans ma licence. (Et parmi les juristes, ceux spécialisés dans le droit d'auteur qui ont rédigé ce texte ne sont pas exactement du genre à ignorer leurs propres droits en la matière ;-) ).
Cela dit, le mécanisme employé par le texte que tu cites est intéressant. Je vais m'en inspirer.
(Pour ce qui est de préférer des textes rédigés par des juristes, en fait, ça n'a pas grande importance. Tout ce que les juristes apportent, normalement, c'est deux choses : la clarté (pour permettre l'application des articles 1156 à 1164 du code civil), et l'absence d'erreur de droit. Mais, pour le premier point, ce n'est pas bien difficile de demeurer clair, et pour le second, outre le fait que je ne sois pas trop mauvais en droit, comme tu l'auras sans doute remarqué :-) , lorsqu'on suit les mêmes disposition qu'un de leurs textes, on ne fera pas plus d'erreur de droit qu'eux. Et, oui, ça, c'est parfaitement légal, puisque les idées seules ne sont pas soumises au droit d'auteur.
Bon, après, je suppose qu'au-delà d'une certaine échelle, des accusations de plagiarisme pourraient faire surface, mais pour une seule clause comme ici, c'est sans risque.)
[^] # Re: licence ?
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 3.
Disons que je souhaite que les utilisateurs puissent disposer du code source de mon logiciel, et je ne suis pas favorable à sa propriétarisation (à mon avis un non-sens dans ce qui touche la sécurité), donc de ce côté-là, je suis plus favorable aux licences de type GPL que BSD.
De plus, de mon point de vue, les licences BSD ont le même défaut que la GPL : pas de délimitation temporelle et spatiale des droits concédés, donc nullité au regard du droit français.
[^] # Re: licence ?
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 0.
Justement, d'après moi, ma licence est parfaitement libre; et en plus, ce sont les licences habituelles qui sont en réalité non-libres (d'où ma décision de ne pas opter pour l'une d'elles). Si vous trouvez des objections à mon raisonnement sur le sujet, allez-y, cela m'intéresse; malheureusement, je crains qu'il ne soit inattaquable.
Cependant, si vous n'êtes pas convaincus, mais que vous n'avez pas d'arguments juridiques à m'opposer, je peux vous proposer une forme de compromis.
En effet, dans la mesure où j'estime que la GPL est invalide, je n'ai pas d'objection fondamentale à passer mon logiciel sous une double licence "Licence Manux/GPL" : puisque j'estime qu'elle est frappée de nullité, dans une telle approche, de mon point de vue, je ne fournirais en réalité pas réellement de droits supplémentaires.
Je peux donc proposer d'ajouter à ma licence une clause rédigée ainsi :
"La General Public Licence, version 3, dite 'GPLv3', est une licence de logiciel libre rédigée par la Free Software Foundation (FSF), sise [ adresse de la fsf ].
En plus des droits accordés par cette licence, l'utilisateur est autorisé à redistribuer le logiciel sous les termes de la GPLv3, en lieu et place de cette licence-ci, à condition bien sûr que la GPLv3 soit elle-même valide.
Toutefois, l'auteur de cette licence-ci tient à avertir loyalement le licencié que la précédente condition n'est à son avis malheureusement pas remplie, par suite notamment de graves incompatibilités entre la GPLv3 et le droit français. Cependant, il existe dans la communauté du logiciel libre de nombreuses personnes qui ne partagent pas cette opinion, et qui au contraire estiment que, sans la présente clause, c'est la licence Manux elle-même qui serait non-libre. Constatant, d'une part, que le désaccord entre les deux groupes n'a pu être résolu par voie argumentative, et d'autre part, que si l'opinion de l'auteur de la licence était juste, alors l'ajout de la présente clause n'aurait pas d'effet notable, la permission précitée a été ajoutée.
Afin que le licencié ne puisse reprocher à l'auteur de la licence d'avoir agi à son égard de façon traître, en plaçant dans la licence une clause dont il savait par avance qu'elle n'était pas utilisable, ledit auteur a préféré ajouter l'avertissement que vous venez de lire. Le licencié est donc invité à étudier soigneusement le problème avant de faire usage de ce droit."
De la sorte, on préserve les intérêts du loup, de la chèvre et du chou :
Qu'est-ce que vous en pensez?
[^] # Re: 0 day
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 9.
Le pire, c'est que ça vient de me revenir : en fait, j'avais déjà repéré le problème, et décidé d'opter pour un répertoire spécial pour ce cas… Mais ça m'était complètement sorti de l'esprit. Honte sur moi /o\ .
(Bon, pour ma défense, c'était il y a plusieurs années.)
En fait, tous les logiciels qui font ce genre de choses font appel à des bibliothèques externes pour le faire; c'est pour ça que, dans LibreOffice par exemple, lorsqu'on fait "ouvrir", on obtient une fenêtre avec un aspect différent sous Gnome et sous KDE (j'avoue que je ne me suis pas penché plus loin sur la question, et je ne sais pas quelle est précisément cette bibliothèque). Tout ce que je ferai, c'est de fournir une bibliothèque de ce type qui appellera un programme externe, lequel aura accès à tous les fichiers de l'utilisateur ainsi que la possibilité de les ajouter à l'arborescence de son appelant; et c'est ce programme qui affichera la fenêtre à l'utilisateur lui demandant quel fichier il veut ouvrir. De la sorte, pour l'utilisateur, ce sera transparent; quant au logiciel appelant, qu'il s'agisse d'un traitement de texte, d'une messagerie électronique, ou d'autre chose, il n'y verra que du feu.
(J'anticipe la question : que se passera-t-il en cas d'exploit jour zéro dans ce logiciel-là? Ma réponse, c'est que comme il ignorera toutes les options de sa ligne de commande, et qu'il ne s'occupera pas du contenu des fichiers qu'il ouvrira, les exploits seront assez peu probables; en tout cas, nettement plus improbables que dans les logiciels appelants. En plus, pour l'exploiter, il faudrait disposer de deux exploits, l'un dans ce logiciel, l'autre dans un de ses appelants, donc ce sera vraiment très compliqué. Mais effectivement, si ça se produit, la sécurité sera abattue. C'est malheureux, mais dans un tel cas, l'OS aura vraiment fait tout ce qu'il pouvait.)
[^] # Re: 0 day
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 5.
Ah oui, c'est vrai, il y a ce cas-là. Désolé, vu l'esthétique de mon site, c'est vrai que j'avais oublié ces histoires de CSS.
Hé, une minute! Le point que tu viens de soulever est intéressant, j'en conviens, mais il est limité au cas particulier des documents qui incluent ou référencent légitimement des fichiers externes qui ne font pas partie des dépendances du logiciel chargé de les ouvrir, ce qui est relativement limité. (Même gcc n'est pas concerné, les #include locaux fonctionnant du fait de la transmission du chemin courant et des -I répertoire . D'ailleurs, comme mon système est déjà auto-hébergé, si ce problème empêchait son fonctionnement, je l'aurais déjà repéré.).
J'admets que, dans le cas de ces fichiers, il va falloir appliquer une solution légèrement différente de celle à laquelle j'avais songé. En pratique, je vais certainement opter pour l'approche la plus simple : créer un répertoire spécifique à ce genre d'opérations, auquel firefox aura simplement toujours accès; à charge pour le développeur qui veut accéder à son site en local de l'y placer.
(Il existe d'ores et déjà une autre solution, en ligne de commande, puisque l'utilisateur a la possibilité d'ajouter l'accès aux fichiers de son choix à n'importe quel logiciel lors de son appel, mais il est évident qu'on ne peut pas raisonnablement attendre que l'utilisateur tente une telle approche.)
De façon générale, la sécurité est une affaire de compromis : mon système d'exploitation accroît la sécurité au prix d'une diminution de l'utilisabilité, Linux (et les autres systèmes d'exploitation) ont fait le choix inverse. Je tente de maintenir mon système aussi utilisable que possible avec ses sécurités contre les exploits jour zéro, mais son utilisation sera toujours légèrement plus complexe que celle d'un Linux.
[^] # Re: 0 day
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 3.
Pour enregistrer un fichier pdf ou uploader une image, il faudra que le navigateur fasse appel à un programme externe (ou, éventuellement, que l'utilisateur déplace le fichier dans le répertoire du navigateur, ce qui fonctionnerait mais ne serait pas franchement intuitif).
Pour ouvrir un fichier html local, si, pas de problème : il suffira de taper firefox file:///home/me/mon_fichier.html (ou de double-cliquer sur l'icône correspondante, de telle sorte que le shell graphique fasse cet appel pour l'utilisateur), et le tour sera joué. Par contre, en effet, on ne pourra généralement pas l'ouvrir à partir de la barre d'adresse.
Tout à fait. Mais la présence de /bin/login est habituellement indispensable sur une machine, et pas celle de ssh. En ne plaçant qu'un seul de ces programmes au lieu de deux, on réduit d'autant la probabilité d'une faille. Mais oui, dans le cas particulier du serveur ssh, tu as raison, on ne peut hélas faire que de la limitation.
[^] # Re: 0 day
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 4.
Rien. Mon système ne peut qu' encaisser les attaques, pas les empêcher. En ce qui concerne le navigateur, s'il est troué, l'attaquant pourra en prendre le contrôle, regarder, modifier et supprimer l'historique de navigation, regarder ce que fait l'utilisateur sur le net… Mais il ne pourra pas accéder aux documents pdfs, LibreOffice, et autres, situés sur la machine. Je pense que c'est déjà bien, comme protection; et de toutes façons, l'OS seul ne peut malheureusement pas en faire plus.
Ensuite, si l'utilisateur (ou sa distribution) a installé deux instances séparées du navigateur, un pour sa banque, l'autre pour sa navigation privée, l'attaquant qui contrôle le site sexy-tabou.com ne pourra pas obtenir les informations sur les comptes de la victime. Ça aussi, ce n'est pas négligeable.
Tel que les serveurs ssh sont actuellement conçus, rien, et une faille dans un serveur ssh, honnêtement, c'est un peu l'Armaggedon. Mais il est possible de le sécuriser, en séparant le serveur ssh (chargé de la communication réseau) du logiciel d'authentification et de création de session; de la sorte, le serveur ssh se retrouverait incapable d'ouvrir une session arbitraire sans son mot de passe.
Autant dire tout de suite que ce n'est pour l'instant pas implémenté.
[^] # Re: licence ?
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 4.
Justement, le maintien de forks ne pose pas de problème. D'une part, rien ne s'oppose à la création et au maintien d'un fork complet : dès qu'il est renommé, il n'a plus rien à voir avec le précédent logiciel, et ciao!
Ensuite, en ce qui concerne la création de distributions qui s'entreforkent (joli verbe, ça), ça ne pose pas de problème non plus… puisqu'il suffit de déclarer, exactement comme dans le monde Linux, que les distributions s'appellent MandriHat Manux ou RedCake Manux! Bah oui, ce n'est pas un renommage, ça, c'est une intégration du nom dans un autre nom, ce qu'aucune disposition n'interdit - et tout ce que les règles ont oublié d'interdire est autorisé. Et hop, aucune difficulté, ce n'est même pas regardé comme un fork au regard de ma licence.
(Cela dit, maintenant que j'y pense, c'est peut-être de ma faute, ma licence n'est pas très explicite de ce côté… Dans la prochaine version, je la modifierai pour qu'il soit clair que ce comportement ne constitue pas un renommage.)
[^] # Re: 0 day
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 4.
Pas de problème.
En fait, la mémoire partagée sera implémentée dans l'avenir; cependant, comme chacun sait, celle-ci entraîne la création de canaux de communication cachés très importants dans le système. Pour résoudre ce problème, l'administrateur aura le choix entre :
Cela dépend du mécanisme. Si c'est un simple pipe, pas de problème : il est créé classiquement par le père par pipe(2) avant le fork(2), puis conservé par les fils après l'execve(2). Si c'est un pipe nommé ou une socket du domaine UNIX, il faut recourir à un lien matériel vers le fichier en question pour lui permettre d'apparaître dans les divers chroots. A titre d'exemple, c'est déjà ce qui est fait pour permettre la communication entre init et telinit du paquetage sysvinit.
(Les sockets anonymes du domaine UNIX, qui ne sont au fond qu'une extension Linux, ne seront tout simplement pas implémentées.)
En ce qui concerne les segments de mémoire partagés, et les autres IPCs system-V, je reconnais que je n'ai pas encore décidé de la façon dont j'allais procéder à leur isolement, mais j'emploierai certainement une méthode de type "espace de noms" comme sous Linux (CLONE_NEWIPC); de même pour les signaux.
[^] # Re: licence ?
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 4.
J'avoue que je ne sais pas ce qui se passe si un français intente un procès à un étranger pour obtenir l'annulation de sa licence au titre d'une disposition du droit français sans équivalent à l'étranger, je ne sais pas dans quelles conditions il peut obtenir l'application du droit français au contrat sans désignation de droit qu'est la GPL. Il faudrait effectivement se pencher sur les règles de l'OMC pour le savoir, mais là, je ne suis plus trop dans ma spécialité.
Cela dit, une licence comportant une clause "si vous vivez en France, vous devez cesser définitivement de distribuer et d'utiliser le logiciel dès la réception d'une simple demande de n'importe quel auteur" serait immédiatement jugée non-libre. Or toutes les licences en question comportent exactement cette clause, en version implicite…
Oui et non… Je me souviens d'un procès, dont je ne retrouve plus l'arrêt, dans lequel le violateur de la GPL avait tenté d'invoquer cette nullité pour s'exonérer de ses fautes. Le juge avait répondu qu'il n'était pas l'un des auteurs, et donc que, si la GPL était invalide, alors il n'aurait pas eu de licence légale du tout, ce qui aurait fait de lui un contrefacteur, et a donc refusé d'examiner l'argument plus avant.
Cette solution était juste, mais force est de constater que c'était passé tout près. La nullité était bien là, mais l'avocat du défenseur n'a pas réussi à l'invoquer précisément parce que ce n'est qu'une nullité relative, et qu'il ne faisait pas partie des personnes protégées par la disposition violée. A contrario, s'il était l'un des auteurs, la nullité aurait vraisemblablement triomphé.
Les juges sont tenus d'appliquer la loi, qu'elle leur plaise ou non. Et quant à ces fameux "meilleurs spécialistes", voyons donc ce qu'ils en disent :
http://fr.jurispedia.org/index.php/Licence_libre_%28fr%29#Une_cession_non_express.C3.A9ment_limit.C3.A9e
Ah, tiens, ils ont repéré la même nullité que moi?
Les logiciels sous licence GPL et CDDL sont non-mixables; cela a beau agacer bien des gens, cela reste des licences libres.
La clause 6 prévoit ce cas.
[^] # Re: 0 day
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 9.
Il faut les regénérer. Cela ralentit l'installation des bibliothèques, j'en suis conscient, mais il n'y a pas d'alternative.
Alors, euh… Si j'avais programmé la mémoire partagée, alors oui, la mémoire serait effectivement partagée entre les différents logiciels situés dans des chroots différents, mais, comme je ne l'ai, euh, pas encore programmé…
[^] # Re: Bibliothèques partagées
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 6.
Les bibliothèques partagées sont gérées sans problème : elles sont liées matériellement dans la racine de chaque programme qui en a besoin. Lors de l'installation d'un paquetage, c'est l'une des tâches du logiciel de résolution de dépendances.
[^] # Re: 0 day
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 8.
Pour ce qui est des bibliothèques, aucun souci : au moment de l'installation des dépendances, elles sont simplement installées dans la racine du programme qui en a besoin à l'aide de liens matériels. Résultat, le coût additionnel est nul.
En ce qui concerne les programmes, oui, il y a un ralentissement, mais il est vraiment minime. Les lanceurs sont compilés statiquement sans libc, les appels-systèmes étant simplement réalisés avec asm volatile ("int $0x80" : : ); et les opérations requises sont très rapides. Pour donner une idée, la seule initialisation de la glibc au lancement d'un programme, avant l'appel à main(), prend plus de temps que la totalité des opérations du lanceur.
[^] # Re: licence ?
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 3.
Dans le monde du logiciel libre, la notion de "licence libre" est souvent un point contentieux, des définitions et des analyses différentes pouvant mener à des résultats très distincts. A mon avis, ce sont les licences GPLv2, GPLv3, BSD 2-clauses, BSD 3-clauses, BSD 4-clauses, Apache et MIT qui auraient dû être déclarées non-libres.
Explication (avant que vous ne me preniez pour un troll particulièrement en forme) : aucune de ces licences ne comporte de clause précisant la loi applicable. Cela signifie qu'on peut leur appliquer la loi que l'on souhaite; donc en particulier la loi française.
Prenons donc le code de la propriété intellectuelle, partie législative, chapitre I, article L131-3, premier paragraphe :
Cela signifie que, pour qu'une licence logicielle soit valide, elle doit comporter, à peine de nullité, la mention du lieu et de la durée d'utilisation qu'elle couvre. La CeCILL le fait (article 2 : la licence est mondiale, article 4.2 : la licence produira ses effets durant toute la durée de protection des droits patrimoniaux du logiciel); les licences précitées, non.
Résultat, toutes les licences en question sont entachées de nullité. Nullité relative, certes (et heureusement!), mais nullité quand même. (La nullité est relative parce que les dispositions en question visent à protéger les détenteurs du droit d'auteur, pas à sauvegarder l'ordre public : elle ne peut donc pas être soulevée par n'importe quelle partie, uniquement par un auteur qui s'en prétend "lésé").
De ce fait, si l'auteur d'une portion (significative) d'un logiciel quelconque distribué sous l'une de ces licences s'installe en France, puis intente une action en justice parce que, bah, "je n'avais pas prévu que des gens continueraient à utiliser ce logiciel après que j'aie arrêté de le distribuer et que je sois allé travailler dans le privé", il gagnera son procès, et les utilisateurs et distributeurs recevront une gentille mise en demeure de cesser d'utiliser et de distribuer ce logiciel. Bref, comme ces licences ne précisent pas la durée d'exploitation, alors que cette mention est absolument obligatoire, elles seront invalidées dès qu'un détenteur des droits le demandera.
Ah, et inutile d'essayer de plaider la mauvaise foi de l'auteur, la mauvaise foi n'étant pas une défense recevable face à une nullité. (Enfin, façon de parler. Si vous êtes confronté à cette situation, allez-y, plaidez sa mauvaise foi : ce n'est pas interdit, et cela devrait sérieusement réduire, voire supprimer, les dommages et intérêts auxquels vous pourriez être condamné).
Bref, à mon avis, le fait de permettre ainsi à tout auteur de mettre fin au droit d'utiliser et de distribuer le logiciel fait que toutes les licences en question auraient dû être regardées comme non-libres. Cela étant, je conçois que cela pose d'énormes problèmes : il y a énormément de logiciels sous ces licences, il est extrêmement difficile de s'en passer, d'ailleurs, j'en utilise et distribue moi-même. Mais il va de soi que je ne souhaite pas créer un problème de ce type pour mes utilisateurs, donc j'ai choisi de placer mon logiciel sous ma propre licence.
(J'aurais aussi pu choisir la CECiLL, mais elle ne comportait pas de clause d'auto-incompatibilité en cas de renommage, et puis, de façon secondaire, sa clause 13.2 n'est pas en majuscules, ce qui crée des doutes sur sa validité).
Hmmm… Non, ce n'est pas vraiment le problème. Mon seul objectif était de casser la viabilité des forks créés exclusivement pour des motifs bassement mercantiles et anti-communautaires, en les contraignant à faire des forks complets (dont le coût détruirait la viabilité du projet), pas d'embêter les développeurs qui voudraient le modifier de façon "conventionnelle".
D'ailleurs, je me permets de remarquer qu'il y a dans ma licence une sécurité implicite, mais très puissante, contre un tel comportement : aucune règle ne précise dans quelles circonstances le responsable légal désigné est tenu de contraindre un projet concurrent à changer de nom; en particulier, "jamais et en aucune circonstance" est un choix autorisé.
Cela signifie que, si un responsable légal, fût-ce moi-même, décidait de "mettre des bâtons dans les roues" d'un autre projet parce que tout ne lui "revient pas", ledit projet se retrouverait effectivement contraint de faire un fork… Et ensuite, lequel des deux projets se retrouvera avec l'ensemble de la communauté moins un développeur? Hé oui, comme le logiciel est libre, rien n'empêchera le nouveau projet de promettre d'autoriser les usages de leur nom sans restrictions; d'ailleurs, il pourra même s'y contraindre légalement, en publiant un contrat d'usage de sa propre marque dans laquelle il autorise effectivement n'importe quel usage. Résultat, les développeurs le rejoindront, et le responsable qui avait abusé de son droit se retrouvera seul dans son bac à sable.
En pratique, cela signifie qu'il n'est pas possible d'utiliser cette clause pour quoi que ce soit d'autre que son objectif annoncé, parce que tout autre usage sera vécu comme un "coup dans le dos" par la communauté, résultant en un fork, un basculement de la communauté sur le nouveau projet, et voilà tout. Cf. l'aventure de Xfree86, qui avait abusé des droits qu'il détenait sur le logiciel, ce qui a simplement amené la naissance de X.org.
Je ne vois pas en quoi cela rendrait la licence non-libre. C'est une clause d'auto-incompatibilité inattendue, certes, mais à ma connaissance, aucune règle du logiciel libre ne précise quel degré de compatibilité avec les autres logiciels les licences libres doivent fournir. D'ailleurs, ces incompatibilités peuvent survenir avec d'autres licences, par exemple, si on passe sous GPL un logiciel sous BSD, il sera impossible d'inclure du code originaire du nouveau venu dans son prédécesseur.
De façon plus générale, dans toutes les définitions du logiciel libre, je ne vois aucune règle, explicite ou implicite, interdisant de contraindre un fork à faire un fork complet, sans utilisation future du code futur du projet d'origine. Je suis entièrement d'accord pour dire que cette clause est hautement inhabituelle, mais ce n'est pas un critère : pour être un logiciel libre, tout ce qui compte, c'est de respecter la définition du logiciel libre, pas de respecter cette définition de façon habituelle.
[^] # Re: 0 day
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 6.
Exactement. Un exemple, quand je tape cat ~/docs/file.txt, c'est le lanceur de cat, un petit exéctuable de /bin, qui se lance. Il construit alors une arborescence virtuelle contenant simplement le fichier file.txt dans le répertoire ~/docs, puis fait un chroot dans la racine du vrai programme cat (à laquelle il a accès grâce à un lien racine, un lien spécial qui n'est suivable qu'en faisant ce genre de chroot). Ensuite, il fait un execve() sur le vrai binaire de cat.
Ce binaire, à son tour, examine sa ligne de commande, voit qu'il doit accéder à ~/docs/file.txt, l'ouvre (sans repérer qu'il se situe dans une arborescence virtuelle qui ne contient rien d'autre que ce fichier), fait son travail et quitte. Et même s'il y avait eu un exploit jour zéro dans ce fichier, comme cat n'a (normalement) pas l'accès en écriture à sa propre racine, et qu'il n'a accès qu'à un seul autre fichier en-dehors de celle-ci, il se retrouve coincé.
C'est cela que je veux dire par "encaisser" : je ne peux pas empêcher l'existence d'exploits, mais je peux les rendre en pratique inexploitables.
# Premier samedi
Posté par Emmanuel Colbus . En réponse au journal Premiers pas avec Manux. Évalué à 4.
Pour info, je serai ce week-end au premier samedi. S'il y a des franciliens qui n'osent pas l'installer eux-mêmes, ou bien qui ont juste envie de le voir ou d'en discuter, n'hésitez pas!
[^] # Re: Vu dans les Manux Facts
Posté par Emmanuel Colbus . En réponse au journal Premiers pas avec Manux. Évalué à 10.
Alors, si tu fais référence au code de retour : arf, j'avais oublié de le forcer à 0. Corrigé.
En revanche, si tu fais référence à l'implémentation, alors non, la mienne est bien correcte.
Ce qui se passe, c'est qu'il y a une erreur dans la page de manuel française de sched_yield(). Les spécifications ne précisent nullement qu'un nouveau thread sera exécuté (c'est même impossible dans certains cas, par exemple si l'appelant est le seul thread actif ou activable du système), juste qu'il pourra l'être.
De plus, les notions de multitâche et d'exécution parallèle ne sont pas spécifiées, et les choix d'ordonnancement sont laissés à la discrétion de l'implémentation. C'en est même à tel point que les auteurs des spécifications ont dû rajouter une note pour interdire l'implémentation-gag du fork() monothreadé (1).
Par conséquent, lorsqu'un thread appelle sched_yield(), l'implémentation doit le placer parmi les threads ayant fini leur temps d'exécution, puis exécuter un thread activable de son choix. En particulier, elle peut fort bien décider de relancer immédiatement cet appelant. Tout ce que fait mon implémentation, c'est qu'elle choisit de le ré-exécuter à chaque fois. Là aussi, c'est clairement une implémentation-gag, mais c'est un comportement possible, et un choix qui ne viole aucune spécification.
(1) Le fork() monothreadé consiste à choisir, comme politique d'ordonnancement, que lors d'un fork(), le fils s'exécute immédiatement et que le père ne sera exécuté qu'une fois que le fils se sera terminé. Cela aboutit à un UNIX ne comportant qu'une seule thread avec empilement et dépilement des divers processus, et aucun multitâche… Mais cela ne viole pas formellement les spécifications.
Les auteurs de ces spécifications ont ajouté une note pour préciser que ce genre d'implémentation-gag serait regardée comme un jouet et non un véritable système d'exploitation. Mais cela illustre bien le niveau de liberté laissé aux implémentations quant à l'ordonnancement.
# Si je puis ajouter mon grain de sel...
Posté par Emmanuel Colbus . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 4.
Il se trouve que j'ai étudié l'appel-système jail_set(2) de FreeBSD. En ce qui me concerne, j'ai renoncé à l'implémenter ou à m'en inspirer, pour diverses raisons, mais j'ai bien dû reconnaître qu'il était supérieur au chroot(2) de Linux.
Ensuite, Linux dispose d'autres mécanismes de sécurité, comme SELinux, qui rendent une comparaison délicate. A vrai dire, entre Linux et FreeBSD, la différence principale en termes de sécurité ne se situera clairement pas au niveau du choix du système, mais des compétences de l'administrateur de la machine.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 2.
Hélas… Le système lui-même n'est pas à proprement parler débridable (ou plus exactement, la version débridée s'appelle Linux).
Par contre, l'utilisateur peut facilement et automatiquement ajouter tout ce qu'il veut à un programme. Si tu crées un script ~/bin/mon_emacs qui injecte dans le PATH d'emacs toutes les commandes dont tu te sers habituellement, ça fonctionnera sans problème. C'est d'ailleurs ce que fait le binaire ./make des sources du noyau, pour donner à make accès au compilateur, à l'assembleur, à l'éditeur de liens, etc…
Pas de vraie différence par rapport à Linux; une même application peut accéder simultanément à des fichiers situés dans des partitions physiques séparées, c'est transparent. Sauf justement dans les cas où ce n'est pas transparent non plus sous Linux, comme pour les déplacer ou créer un lien matériel entre les deux.
[^] # Re: Si je comprends bien on ne peut pas modifier un fichier sur le disque
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 4.
Non. Des solutions pourront être mises en place dans l'avenir pour fournir cette fonctionnalité (comme je l'ai évoqué dans un autre commentaire); mais pour l'instant, ça ne marche pas. C'est incontestablement une limitation de mon système. J'estime simplement que les bénéfices tirés de l'accroissement de la sécurité en valent la peine.
En fait, non. Dans ce cas précis, tu as passé http://XXX sur la ligne de commande de ton lanceur, ce qui permet de comprendre ton intention d'accéder au réseau, par conséquent, le lanceur fournirait à cette instance de vim l'accès requis.
Je commencerais par faire remarquer que mon système n'a pas de root, et que les privilèges peuvent être donnés à n'importe quel utilisateur :-) . C'est documenté dans la FAQ, chapitre "comment peut-on passer root". Et il est impossible d'échapper d'un chroot, quel que soient les privilèges; une application "non chrootée", ça n'a pas vraiment de sens.
En revanche, avec son split dans vim et son ouverture d'un second fichier, l'utilisateur commettrait effectivement une erreur qui permet la propagation de l'attaque. Et c'est faisable, mais pas de la façon dont tu l'envisages : il faudrait passer à vim deux fichiers sur sa ligne de commande, et ensuite ouvrir le second dans le split.
Donc, oui, c'est vrai, c'est une autre faiblesse. Je pense que les utilisateurs apprendront (ou que les logiciels seront patchés pour parer à cela, par exemple en lançant une seconde instance d'eux-même dans ce genre de cas).
Mais effectivement, tu as raison : mon système peut encaisser bien des choses, mais pas ça.
[^] # Re: Licence, contrat, schmilblick
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 1.
Ça, d'accord, pas de problème. Mais je trouve que s'interroger pour savoir si un système d'exploitation est utilisable pour quoi que ce soit alors qu'il est déjà auto-hébergé, c'est à peu près aussi trollesque que de s'interroger pour savoir si une voiture est capable de circuler après qu'elle ait fini les 24h du Mans.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 5.
Si, mais seulement ceux dont le nom lui a été passé sur sa ligne de commande.
En revanche, pour des fonctionnalités du genre "nouveau document" ou "enregistrer sous", il faudra effectivement passer par un programme externe. Mais ça ne pose aucun problème : en effet, les programmes graphiques qui proposent ces fonctionnalités le font déjà en employant des bibliothèques (c'est pour ça que les apparences de ces boîtes de dialogue sont si semblables). Tout ce qu'il y aura à faire, c'est de fournir une bibliothèque appelant ce programme.
Hmmm… Quelles applications font ce genre de choses? Je veux dire, le lancement de commandes entièrement arbitraires. Je ne vois guère que les shells (gérés), les scripts de l'utilisateur (gérés), et les "make" (gérés).
En ce qui concerne les applications qui ont besoin de faire appel à une autre de façon prévisible, pas de problème : cela signifie que le second programme fait partie de leurs dépendances, et donc qu'ils ont dans leur racine un lien matériel vers le lanceur de ce programme.
Par exemple, si tu as un programme qui a une dépendance sur ls, alors il aura, dans sa racine, un fichier /bin/ls correspondant au lanceur de ls, qui lui permettra de le lancer à volonté, sans restrictions. Mais comme l'accès au lanceur d'un programme n'implique pas l'accès à son xchroot, cela laisse intacte la sécurité de l'application, comme celle de ls.