Le souci, c'est que les gens sont contre la diversité, sauf si ça implique de changer ce qu'ils utilisent, auquel cas, c'est liberticide.
Exemple, systemd, gnome3, etc.
Donc tenter de résoudre ça de façon générique est impossible, il y aune balance, et la balance est "celui fait le travail décide". Bien sur, ça va faire des frustrations, mais bon, les gens sont libres.
Il y a des dizaines et dizaines d'exemple d'exactement ca, a la
virgule pres. Aucun ne s'est jamais fait poursuivre.
Ceci dit, les gens sont pas à l'abri d'un changement d'avis de la part de l'éditeur, suite à un changement de direction. Le souci n'est pas de faire confiance ou pas aux gens maintenant, mais de faire confiance à des gens totalement différent dans le futur.
Par contre pour la sécurité, seulement une petite partie des
failles est trouvée par une analyse du code source, et d'autre
techniques comme le fuzzing donnent des résultats autrement
plus intéressants.
J'aurais tendance à dire au contraire que de nos jours, la majeur partie des failles se trouvent par analyse automatisé du code. Et que le code est corrigé avant la release.
Il y a fort à parier que les gouvernements ont accès aux mêmes outils que Microsoft, voir potentiellement moins ( vu que microsoft a quand même une equipe qui bosse sur son propre compilateur ). Les boites comme coverty vendent leur logiciel à tout le monde, donc la seule distinction serait de rajouter des tests, et/ou de faire son propre logiciel. Faire son propre logiciel serait une gageure pour un gouvernement. Et rajouter des tests, ça serait se retrouver en concurrence avec le domaine privé, une des choses ou les organismes gouvernementaux ont du mal ( la preuve, même la NSA réutilise l'infra de tracking des publicitaires ).
Donc à mon sens, le code est pas la pour trouver les failles avant ( car Microsoft a tout intérêt à corriger ça avant publication, donc va utiliser les tests automatisés et du fuzzing, et dispose de plus de moyens ), mais plus pour analyser l'impact des failles après divulgation. Regarder tout le code est une tache colossale. Regarder juste la partie que tu sais avoir un souci est bien moins couteux.
Et bon, si il y avait tellement de gens capable de lire le code source pour trouver des failles au point d'aller bosser pour le service publique, on aurait pas tant de mal à trouver ce genre de profil. Voir même, si la demande était si forte, quelqu'un aurait fini par faire un cursus universitaire sur le sujet qui tienne la route.
Tout le monde pensera que c'est une faille tout simplement, car
je suis pas idiot, je vais pas mettre un commentaire au dessus
disant que c'est une backdoor, et je vais pas faire un
system("ssh monserver a moi") non plus, et tout le monde
continuera a l'utiliser.
Ton opinion des autres développeurs est bien haute, cf CVE-2001-0008 :)
On noteras que le dit Kadalka n'a plus donné signe de vie nulle part depuis 1 an ( ni sur son wordpress, ni sur son pinterest ). Donc de la à dire que le cycle de moinssage soit quelque chose qui a tué totalement son envie de contribuer, il y a un pas que je ne franchirais pas ( car 1 personne n'est pas un échantillon, et parce que je continue de douter du fait que Kadalka ne soit pas un sock puppet, pour reprendre les termes de Wikipedia ).
C'est dommage car j'avais un beau fichier de fortune :
$ fortune kadalka
Alien existait déjà pour fédérer des paquets donc Steve
Jobs n'a rien inventé.
https://linuxfr.org/nodes/98264/comments/1450572
$ fortune kadalka
La plupart des applications modernes utilisent des pages
web pour être configurées…
Webmin est un exemple typique.
https://linuxfr.org/nodes/97929/comments/1448515
Bonne question, tu accepterais combien pour faire ça ?
Car si tout le monde a un prix, on devrait obtenir facilement une estimation pour savoir à partir de combien ça deviens plus facile et rapide d'utiliser une voie alternative.
Disons qu'on a eu suffisament d'exemple ces quelques dernieres
années qui prouvent que personne ne relit le code, ou tout du
moins pas de facon suffisament serieuse
Ton affirmation est des plus douteuses. Tu prends comme référentiel les fois ou du code foireux est passé, mais combien de fois est ce que du code foireux n'est pas passé ? À partir de la, comment tu peux dire que personne ne relit le code, alors que le code est visiblement relu au vu des failles trouvés après publication ou au vue du code refusé dans le kernel à longueur de journée, etc, etc.
Le souci, c'est que faire du code, c'est compliqué. On peut tourner autour du pot sans arrêt, il faut bien voir que si on passe des années à apprendre à le faire, c'est que c'est pas trivial. Et tu as beau dire "le C, c'est tout pourri", le fait est qu'openstack, écrit en python, a aussi régulièrement des soucis de sécurité ( cf oss-security@ ).
Ensuite, je pense que l'idée même d'agent dormant est toxique.
Toxique parce que ça ne peux qu'aboutir à moins de collaboration à terme, et c'est exactement ce que Assange a tenté de faire avec Wikileaks ( ie, réduire la collaboration entre divers groupes cachés en augmentant leur paranoia http://blogs.cornell.edu/info2040/2012/11/01/julian-assange-on-governments-as-networks/ ). Et moins de collaboration pour le libre, c'est contre la nature même du libre. Et je pense que j'ai pas besoin de citer la mort de Staline comme exemple extrême de dégâts de la paranoia.
Toxique parce que ça part hors du domaine du rationnel et dans le domaine au mieux de l'intuition, et qu'on s'éloigne du raisonnement scientifique qu'on aimerais tous avoir pour juger le code. Ça s'éloigne tellement du rationnel que le simple fait de combattre l'idée renforce son existence en l'alimentant, car bien sur, malgré le fait que rien ne le prouve, si quelqu'un dit qu'il y a rien, alors il est peut être lui même dans le secret.
Le problème (entre autres) de la certification c'est que le
processus n'est pas public.
tu parles de quel certification ?
Des trucs comme FIPS sont publics, c'est globalement juste une liste de chose à mettre ou ne pas mettre. Une certification E4L+ est aussi public, tu connais les critères et tu peux techniquement faire la vérification toi même.
Le souci, c'est que les gens savent pas exactement ce que la certif veut dire. Un appareil certifié NF ne va pas forcément être de qualité et durer 10 ans. mais on sait qu'il va marcher sur les prises francaises. Un logiciel certifié FIPS-140-2 va pas forcément avoir du code sans bug ( loin de la ), mais tu sais qu'il implémente une liste précise d'algo et qu'il retire d'autres, etc. Bien sur comme les certifications sont des documents longs et chiants, personne ou presque ne les lit, et les gens comprennent pas ( ce qui implique aussi le responsable marketing moyen et le décideur moyen, voir le codeur moyen qui est à 100 lieux d'avoir le recul pour voir ce que ça recouvre et le but ).
Je te cite :
"c'est de recommander des produits que l'on sait être pourvus de porte(s) dérobée(s) (obligation légale pour les société américaines). "
FISA et Patriot Act, c'est kif kif, le second "patchant" la première. Et ça concerne les communications et les données, ce qui est différent des logiciels vendus ( je dit vendu, pas loué, au contraire du modèle SaaS dans le cloud computing ).
L'obligation de donner accès aux données ( chose qu'on retrouve dans beaucoup de législation je pense ) ne veut pas dire "obligation de mettre une porte dérobé". Et Calea concerne les entreprises du domaine des télécoms, ce qui est différent des "entreprises américaines", qui sous entends quand même "toute les entreprises américaines". Et je pense que Calea implique pas forcement une backdoor logiciel, mais plus que la FBI soit capable de demander à faire une écoute sur ton installation, ou le fait d'avoir la possibilité de le faire. Dans le cas d'un routeur cisco, ça serait sans doute équivalent à la fonction de port mirroring, qui sert aussi pour le debug. Si faire une écoute, ça se fait en mettant un compte pour eux, pareil, ça satisfait la loi. On est bien loin de "mettre des backdoors".
Visiblement, au vue des liens qui pointent sur des articles pas forcément utiles ( car bon, le wikipedia fr donne juste "Calea est un genre végétal de la famille des Asteracées" ), je voit que c'est pas la précision et le souci du détail qui t'étouffe.
Quand à déduire à partir du nom d'une variable la présence d'une backdoor, ça me semble des plus faible. Surtout si c'est pour dire "elle existe encore, mais on ne voit plus rien", ie que rien ne prouve quoi que ce soit, mais qu'il faut faire acte de foi dans ce qu'un inconnu dit sans avoir le moindre fait.
Tu crois que distribuer le code source va empecher l'insertion
d'une backdoor ?
Si tu veux faire une backdoor, tu as 2 choix. Soit tu fait un truc générique pour tout le monde, et je pense que oui, certains clients vont voir que le code fait pas la même chose que le binaire. Soit tu fait un rpm pour un client spécifique et tu lui donnes, mais du coup, ça implique de mettre vachement plus de gens au courant ( genre l'équipe QA qui va devoir tester la backdoor, l'équipe support qui va devoir savoir quoi répondre, les gens qui gèrent les miroirs, etc ). Et ils sont pas tous aux USA, loin de la pour des questions évidentes de support 24/7.
Donc le risque est de mettre au courant plein de gens qui sont pas forcément sous ta juridiction ( voir potentiellement des agents ennemis ). Autant dire qu'aucune agence de renseignement ne va prendre ce risque, et on le voit via l'unité qui rajoute les firmwares customs dans les routeurs.
Et il reste donc le fait de demander de rajouter une backdoor générique pour tous. Et la, c'est pareil. Si la NSA demande un patch difficile à justifier à ajouter par une ou deux personnes, ça change rien au fait que tout le monde peut voir, à commencer par les concurrents qui se feront un plaisir de leaker la chose pour pourrir la boite. Ce qui implique donc de griller un agent et/ou une personne, ce qu'ils veulent visiblement éviter.
On noteras aussi que pour le moment, la majorité des méthodes sont soit via les moyens légaux ( ie, des écoutes légales ), soit via du parasitisme ( ie, l'ajout de sonde au niveau réseau ). Il n'y a que des suppositions non fondés sur la présence d'agent dormant, pas le moindre document publié que je sache.
Justement si. Tous les fournisseurs de services sont dans le
même panier, tous les fournisseurs d'OS sont dans le même
panier aussi
Je ne doute pas que ça arrangerais bien Microsoft, surtout vu la nouvelle direction visant à se positionner autrement, et je veux bien laisser le bénéfice du doute à Microsoft. Mais tu peux dire ce que tu veux, le fait de publier le code pour tous change radicalement les choses et complexifie grandement la tache de rajouter une backdoor.
Tout comme le fait d'avoir des signatures sur les rpms pour vérifier la provenance ( car par exemple, je ne pense pas qu'une installation Windows soit vérifiable vis à vis d'une base signé des hashs des fichiers pour voir que personne n'a modifié l'OS avant de le donner ).
je demande à voir, parce que je pense que ta compréhension des textes est fausse, et semble oublier pas mal de choses, genre les conditions d'applications. Donc plutôt qu'une affirmation non fondé, donne un lien vers un texte juridique.
Red hat ne fait quasiment pas d’hébergement et pas envers des particuliers ( ie, openshift online se destine plus pour les entreprises et les startups, et comme c'est sur amazon, je pense qu'ils peuvent directement se passer de demander à RH et directement aller chez Amazon ).
Quand à rajouter une backdoor, ça serait relativement pas discret, vu que Red Hat distribue le code source ( sauf à violer la GPL ) des logiciels. Il serait aussi plus efficace d'aller directement upstream.
Et bon, on noteras aussi que Red hat ( ni même les autres fournisseurs de systéme d'exploitation libre, à l'exception de Google ) n'apparaissent dans une liste publié par Edward Snowden.
Donc mon hypothése est que la NSA s'est surtout focalisé sur les actions directs et ciblés sur les données via les fournisseurs SaaS que sur les logiciels, ne serais que parce que c'est moins couteux, bien plus facile à justifier et moins risqué.
Donc c'est bien tenté de mettre tout le monde dans le même panier, mais c'est pas le cas.
C'est globalement ce qui se passe quand tu payes une boite pour bosser sur un logiciel libre qu'elle produit au lieu de passer par les versions communautaires du truc. Genre, quand tu payes puppetlabs au lieu de prendre le puppet depuis les sources et de refaire le taf toi même.
Sauf que l'état, comme la majorité des clients, préfèrent payer des millions d'euros à des boites qui vendent cher leur truc et de mégoter sur les boites plus petites.
Moi, j'ai entendu dire que l'équipe cloud de Bull s'est fait débauché par Mirantis ( qui a d'ailleurs aussi forké les meetups en créant un contre groupe sur paris pour faire d'autres rencontres, mais juste pour eux ).
Sinon, tu peux aussi regarder du coté d'openshift ( https://www.openshift.com/products/pricing ). Je sais pas vraiment si c'est moins cher pour ton use case, mais je pense que pour ton site perso, un prix de 0$ me parait pas mal ( sans le ssl, ça fait du 30$ avec ).
En rajoutant du code ( grosso modo ~ 10 lignes de selinux, plus sans doute une 10 à 20aine de lignes pour ta configuration, ou plus ), tu peux faire une transition d'un type selinux qui a l'accès au réseau à un type qui le supporte pas.
Alors même si ça ne fait pas exactement la même chose, et que je pense que mettre seccomp dans un programme permet de rajouter un filtre après traitement divers et variés, il est possible d'utiliser systemd pour avoir une partie des avantages de seccomp sans rajouter de code.
Grosso modo, pour les projets modernes, tu as 3 cas d'usages. Un usage. Le mode "block" ( ie, tu exportes un bloc ), le mode filesystem ( ie, tu export directement un file system ) et le mode objet ( ie, tu exportes des objets, un peu comme swift et s3 ).
Gluster est surtout fort dans filesystem, ce qu'il fait nativement, et on a rajouté les 2 autres modes par dessus.
Ceph au contraire est à la base un système d'objet distribué sur lequel on rajoute le mode filesystem et block.
Donc chacun a ses faiblesses et ses forces. Ceph a une architecture plus complexe que Gluster, ce qui lui permet d'être entièrement distribué. Par contre, gluster a un système de layer, ce qui permet d'être plus souple ( à mon sens ) d'un point de vue de ce que tu peux rajouter.
Mais je connait surtout gluster et pas trop Ceph, donc je dit peut être de la merde.
Doc l'idée, c'est d'avoir 2 systèmes, pour adresser 2 cas d'usages différents, avec des fondements différents d'un point de vue technique.
Et pour être franc, j'aurais été déçu que personne ne pointe la chose. Il y a plein de trucs à redire sur les suppositions de ce poste de blog, et c'est pour ça que je pensais qu'il était parfait pour une discussion durant un vendredi, comme par exemple, la perception "business" et le fait que les communautés sont oubliés.
Mais bon, ça ne prends pas, personne ne discute, tant pis :)
Je n’aime pas trop miser sur des outils spécifiques : je peux
être amené à changer de distribution
alors utilise l'outil spécifique pour lancer un truc comme ansible
et par ailleurs, on n’est jamais sûr qu’ils ne disparaissent pas
brusquement
au contraire d'un outil non spécifique ? les choses partent pas "brutalement", c'est plus les gens qui découvrent brutalement qu'il fallait suivre les changements. Je dit pas que c'est simple ceci dit, vu comme le monde du libre bouge. Mais par exemple, puppet, non spécifique, a des soucis de versions en fonction du client puppet, qui lui même depend de la version de ruby et des gems. De même, ils ont retiré les manifests en ruby dans la version 3.0, et y a des gens qui s'en servaient.
Cela a été remplacé par gnome-initial-setup ( https://fedoraproject.org/wiki/Features/NewFirstboot ), qui en effet ne propose pas un réglage aussi fin que tu voudrais de ldap, ceci étant reservé à la commande authconfig
Mais RH dit que c'est pas supporté pour RHEL. Et pour Fedora, la communauté se bat depuis des années pour savoir si ça marche ou pas, et comment ( ie, preupgrade/fedup vs yum ). Y a pas moyen de tester de façon exhaustive, mais les gens le font et corrige à la main et disent de le faire. Et parfois, garder une vielle configuration montre des comportements inattendus dans les softs.
Ça marche avec Debian, mais c'est pas non plus "j'ai rien à faire" comme on m'a vendu ça y a plusieurs années ( et dieu merci, sinon j'aurais pas eu de boulot à corriger ça ).
# En résumé
Posté par Misc (site web personnel) . En réponse au journal La diversité ou la complexité inutile ?. Évalué à 10.
Le souci, c'est que les gens sont contre la diversité, sauf si ça implique de changer ce qu'ils utilisent, auquel cas, c'est liberticide.
Exemple, systemd, gnome3, etc.
Donc tenter de résoudre ça de façon générique est impossible, il y aune balance, et la balance est "celui fait le travail décide". Bien sur, ça va faire des frustrations, mais bon, les gens sont libres.
[^] # Re: 1994
Posté par Misc (site web personnel) . En réponse au journal TrueCrypt, la fin ?. Évalué à 2.
Ceci dit, les gens sont pas à l'abri d'un changement d'avis de la part de l'éditeur, suite à un changement de direction. Le souci n'est pas de faire confiance ou pas aux gens maintenant, mais de faire confiance à des gens totalement différent dans le futur.
[^] # Re: 1994
Posté par Misc (site web personnel) . En réponse au journal TrueCrypt, la fin ?. Évalué à 2.
J'aurais tendance à dire au contraire que de nos jours, la majeur partie des failles se trouvent par analyse automatisé du code. Et que le code est corrigé avant la release.
Il y a fort à parier que les gouvernements ont accès aux mêmes outils que Microsoft, voir potentiellement moins ( vu que microsoft a quand même une equipe qui bosse sur son propre compilateur ). Les boites comme coverty vendent leur logiciel à tout le monde, donc la seule distinction serait de rajouter des tests, et/ou de faire son propre logiciel. Faire son propre logiciel serait une gageure pour un gouvernement. Et rajouter des tests, ça serait se retrouver en concurrence avec le domaine privé, une des choses ou les organismes gouvernementaux ont du mal ( la preuve, même la NSA réutilise l'infra de tracking des publicitaires ).
Donc à mon sens, le code est pas la pour trouver les failles avant ( car Microsoft a tout intérêt à corriger ça avant publication, donc va utiliser les tests automatisés et du fuzzing, et dispose de plus de moyens ), mais plus pour analyser l'impact des failles après divulgation. Regarder tout le code est une tache colossale. Regarder juste la partie que tu sais avoir un souci est bien moins couteux.
Et bon, si il y avait tellement de gens capable de lire le code source pour trouver des failles au point d'aller bosser pour le service publique, on aurait pas tant de mal à trouver ce genre de profil. Voir même, si la demande était si forte, quelqu'un aurait fini par faire un cursus universitaire sur le sujet qui tienne la route.
[^] # Re: 1994
Posté par Misc (site web personnel) . En réponse au journal TrueCrypt, la fin ?. Évalué à 4.
Nan, on peut faire comme d'habitude et croire sur parole sans voir le code du tout.
[^] # Re: 1994
Posté par Misc (site web personnel) . En réponse au journal TrueCrypt, la fin ?. Évalué à 3.
Ton opinion des autres développeurs est bien haute, cf CVE-2001-0008 :)
# Kadalka, est ce que c'est toi ?
Posté par Misc (site web personnel) . En réponse au journal [+]. Évalué à 4.
C'était l’hypothèse défendu par kadalka ( https://linuxfr.org/nodes/98837/comments/1466947 ) entre ses divers délires sur la stratégie.
On noteras que le dit Kadalka n'a plus donné signe de vie nulle part depuis 1 an ( ni sur son wordpress, ni sur son pinterest ). Donc de la à dire que le cycle de moinssage soit quelque chose qui a tué totalement son envie de contribuer, il y a un pas que je ne franchirais pas ( car 1 personne n'est pas un échantillon, et parce que je continue de douter du fait que Kadalka ne soit pas un sock puppet, pour reprendre les termes de Wikipedia ).
C'est dommage car j'avais un beau fichier de fortune :
[^] # Re: 1994
Posté par Misc (site web personnel) . En réponse au journal TrueCrypt, la fin ?. Évalué à 2.
Bonne question, tu accepterais combien pour faire ça ?
Car si tout le monde a un prix, on devrait obtenir facilement une estimation pour savoir à partir de combien ça deviens plus facile et rapide d'utiliser une voie alternative.
[^] # Re: 1994
Posté par Misc (site web personnel) . En réponse au journal TrueCrypt, la fin ?. Évalué à 3.
Ton affirmation est des plus douteuses. Tu prends comme référentiel les fois ou du code foireux est passé, mais combien de fois est ce que du code foireux n'est pas passé ? À partir de la, comment tu peux dire que personne ne relit le code, alors que le code est visiblement relu au vu des failles trouvés après publication ou au vue du code refusé dans le kernel à longueur de journée, etc, etc.
Le souci, c'est que faire du code, c'est compliqué. On peut tourner autour du pot sans arrêt, il faut bien voir que si on passe des années à apprendre à le faire, c'est que c'est pas trivial. Et tu as beau dire "le C, c'est tout pourri", le fait est qu'openstack, écrit en python, a aussi régulièrement des soucis de sécurité ( cf oss-security@ ).
Ensuite, je pense que l'idée même d'agent dormant est toxique.
Toxique parce que ça ne peux qu'aboutir à moins de collaboration à terme, et c'est exactement ce que Assange a tenté de faire avec Wikileaks ( ie, réduire la collaboration entre divers groupes cachés en augmentant leur paranoia http://blogs.cornell.edu/info2040/2012/11/01/julian-assange-on-governments-as-networks/ ). Et moins de collaboration pour le libre, c'est contre la nature même du libre. Et je pense que j'ai pas besoin de citer la mort de Staline comme exemple extrême de dégâts de la paranoia.
Toxique parce que ça part hors du domaine du rationnel et dans le domaine au mieux de l'intuition, et qu'on s'éloigne du raisonnement scientifique qu'on aimerais tous avoir pour juger le code. Ça s'éloigne tellement du rationnel que le simple fait de combattre l'idée renforce son existence en l'alimentant, car bien sur, malgré le fait que rien ne le prouve, si quelqu'un dit qu'il y a rien, alors il est peut être lui même dans le secret.
[^] # Re: Chiffrement matériel
Posté par Misc (site web personnel) . En réponse au journal TrueCrypt, la fin ?. Évalué à 3.
tu parles de quel certification ?
Des trucs comme FIPS sont publics, c'est globalement juste une liste de chose à mettre ou ne pas mettre. Une certification E4L+ est aussi public, tu connais les critères et tu peux techniquement faire la vérification toi même.
Le souci, c'est que les gens savent pas exactement ce que la certif veut dire. Un appareil certifié NF ne va pas forcément être de qualité et durer 10 ans. mais on sait qu'il va marcher sur les prises francaises. Un logiciel certifié FIPS-140-2 va pas forcément avoir du code sans bug ( loin de la ), mais tu sais qu'il implémente une liste précise d'algo et qu'il retire d'autres, etc. Bien sur comme les certifications sont des documents longs et chiants, personne ou presque ne les lit, et les gens comprennent pas ( ce qui implique aussi le responsable marketing moyen et le décideur moyen, voir le codeur moyen qui est à 100 lieux d'avoir le recul pour voir ce que ça recouvre et le but ).
[^] # Re: le code avait été audité
Posté par Misc (site web personnel) . En réponse au journal TrueCrypt, la fin ?. Évalué à 1.
Je te cite :
"c'est de recommander des produits que l'on sait être pourvus de porte(s) dérobée(s) (obligation légale pour les société américaines). "
FISA et Patriot Act, c'est kif kif, le second "patchant" la première. Et ça concerne les communications et les données, ce qui est différent des logiciels vendus ( je dit vendu, pas loué, au contraire du modèle SaaS dans le cloud computing ).
L'obligation de donner accès aux données ( chose qu'on retrouve dans beaucoup de législation je pense ) ne veut pas dire "obligation de mettre une porte dérobé". Et Calea concerne les entreprises du domaine des télécoms, ce qui est différent des "entreprises américaines", qui sous entends quand même "toute les entreprises américaines". Et je pense que Calea implique pas forcement une backdoor logiciel, mais plus que la FBI soit capable de demander à faire une écoute sur ton installation, ou le fait d'avoir la possibilité de le faire. Dans le cas d'un routeur cisco, ça serait sans doute équivalent à la fonction de port mirroring, qui sert aussi pour le debug. Si faire une écoute, ça se fait en mettant un compte pour eux, pareil, ça satisfait la loi. On est bien loin de "mettre des backdoors".
Visiblement, au vue des liens qui pointent sur des articles pas forcément utiles ( car bon, le wikipedia fr donne juste "Calea est un genre végétal de la famille des Asteracées" ), je voit que c'est pas la précision et le souci du détail qui t'étouffe.
Quand à déduire à partir du nom d'une variable la présence d'une backdoor, ça me semble des plus faible. Surtout si c'est pour dire "elle existe encore, mais on ne voit plus rien", ie que rien ne prouve quoi que ce soit, mais qu'il faut faire acte de foi dans ce qu'un inconnu dit sans avoir le moindre fait.
[^] # Re: 1994
Posté par Misc (site web personnel) . En réponse au journal TrueCrypt, la fin ?. Évalué à 3.
Si tu veux faire une backdoor, tu as 2 choix. Soit tu fait un truc générique pour tout le monde, et je pense que oui, certains clients vont voir que le code fait pas la même chose que le binaire. Soit tu fait un rpm pour un client spécifique et tu lui donnes, mais du coup, ça implique de mettre vachement plus de gens au courant ( genre l'équipe QA qui va devoir tester la backdoor, l'équipe support qui va devoir savoir quoi répondre, les gens qui gèrent les miroirs, etc ). Et ils sont pas tous aux USA, loin de la pour des questions évidentes de support 24/7.
Donc le risque est de mettre au courant plein de gens qui sont pas forcément sous ta juridiction ( voir potentiellement des agents ennemis ). Autant dire qu'aucune agence de renseignement ne va prendre ce risque, et on le voit via l'unité qui rajoute les firmwares customs dans les routeurs.
Et il reste donc le fait de demander de rajouter une backdoor générique pour tous. Et la, c'est pareil. Si la NSA demande un patch difficile à justifier à ajouter par une ou deux personnes, ça change rien au fait que tout le monde peut voir, à commencer par les concurrents qui se feront un plaisir de leaker la chose pour pourrir la boite. Ce qui implique donc de griller un agent et/ou une personne, ce qu'ils veulent visiblement éviter.
On noteras aussi que pour le moment, la majorité des méthodes sont soit via les moyens légaux ( ie, des écoutes légales ), soit via du parasitisme ( ie, l'ajout de sonde au niveau réseau ). Il n'y a que des suppositions non fondés sur la présence d'agent dormant, pas le moindre document publié que je sache.
Je ne doute pas que ça arrangerais bien Microsoft, surtout vu la nouvelle direction visant à se positionner autrement, et je veux bien laisser le bénéfice du doute à Microsoft. Mais tu peux dire ce que tu veux, le fait de publier le code pour tous change radicalement les choses et complexifie grandement la tache de rajouter une backdoor.
Tout comme le fait d'avoir des signatures sur les rpms pour vérifier la provenance ( car par exemple, je ne pense pas qu'une installation Windows soit vérifiable vis à vis d'une base signé des hashs des fichiers pour voir que personne n'a modifié l'OS avant de le donner ).
[^] # Re: le code avait été audité
Posté par Misc (site web personnel) . En réponse au journal TrueCrypt, la fin ?. Évalué à 2.
je demande à voir, parce que je pense que ta compréhension des textes est fausse, et semble oublier pas mal de choses, genre les conditions d'applications. Donc plutôt qu'une affirmation non fondé, donne un lien vers un texte juridique.
[^] # Re: 1994
Posté par Misc (site web personnel) . En réponse au journal TrueCrypt, la fin ?. Évalué à 5.
Red hat ne fait quasiment pas d’hébergement et pas envers des particuliers ( ie, openshift online se destine plus pour les entreprises et les startups, et comme c'est sur amazon, je pense qu'ils peuvent directement se passer de demander à RH et directement aller chez Amazon ).
Quand à rajouter une backdoor, ça serait relativement pas discret, vu que Red Hat distribue le code source ( sauf à violer la GPL ) des logiciels. Il serait aussi plus efficace d'aller directement upstream.
Et bon, on noteras aussi que Red hat ( ni même les autres fournisseurs de systéme d'exploitation libre, à l'exception de Google ) n'apparaissent dans une liste publié par Edward Snowden.
Donc mon hypothése est que la NSA s'est surtout focalisé sur les actions directs et ciblés sur les données via les fournisseurs SaaS que sur les logiciels, ne serais que parce que c'est moins couteux, bien plus facile à justifier et moins risqué.
Donc c'est bien tenté de mettre tout le monde dans le même panier, mais c'est pas le cas.
[^] # Re: Et le nom du projet ?
Posté par Misc (site web personnel) . En réponse au journal La novlangue fait son entrée dans Django. Évalué à 1.
Ça vient de Django Reinhart, le musicien.
[^] # Re: Oui, mais
Posté par Misc (site web personnel) . En réponse au journal Système d'exploitation "made in france" -- Cocorico. Évalué à 5.
C'est globalement ce qui se passe quand tu payes une boite pour bosser sur un logiciel libre qu'elle produit au lieu de passer par les versions communautaires du truc. Genre, quand tu payes puppetlabs au lieu de prendre le puppet depuis les sources et de refaire le taf toi même.
Sauf que l'état, comme la majorité des clients, préfèrent payer des millions d'euros à des boites qui vendent cher leur truc et de mégoter sur les boites plus petites.
[^] # Re: Le cloud de bull ?
Posté par Misc (site web personnel) . En réponse au journal Système d'exploitation "made in france" -- Cocorico. Évalué à 3.
"Vite, ATOS veut nous racheter, on fait tomber le cloud pour réduire notre prix en bourse"
# Le cloud de bull ?
Posté par Misc (site web personnel) . En réponse au journal Système d'exploitation "made in france" -- Cocorico. Évalué à 6.
Moi, j'ai entendu dire que l'équipe cloud de Bull s'est fait débauché par Mirantis ( qui a d'ailleurs aussi forké les meetups en créant un contre groupe sur paris pour faire d'autres rencontres, mais juste pour eux ).
peut être ceci explique pourquoi il réponds pas ?
[^] # Re: Hébergement
Posté par Misc (site web personnel) . En réponse au journal Help Me Quit ou comment j'ai arrêté de fumer en aidant des gorilles. Évalué à 4.
Sinon, tu peux aussi regarder du coté d'openshift ( https://www.openshift.com/products/pricing ). Je sais pas vraiment si c'est moins cher pour ton use case, mais je pense que pour ton site perso, un prix de 0$ me parait pas mal ( sans le ssl, ça fait du 30$ avec ).
[^] # Re: Autres projets utilisant seccomp-bpf
Posté par Misc (site web personnel) . En réponse au journal Seccomp, une sandbox intégrée au noyau Linux…. Évalué à 4.
Sans rajouter de code, non.
En rajoutant du code ( grosso modo ~ 10 lignes de selinux, plus sans doute une 10 à 20aine de lignes pour ta configuration, ou plus ), tu peux faire une transition d'un type selinux qui a l'accès au réseau à un type qui le supporte pas.
C'est pas trop dur à faire, faut juste s'en tirer avec le peu de code d'exemple qui existe. Par exemple la fonction condSELinuxContext du patch https://lists.fedoraproject.org/pipermail/devel/2013-September/188732.html
Ou ce genre de chose, ou tu forkes après :
http://cgit.freedesktop.org/systemd/systemd/commit/?id=7b52a628f8b43ba521c302a7f32bccf9d0dc8bfd
( ce que iodine fait aussi, par exemple )
https://github.com/yarrick/iodine/blob/eca80f769bfeaa3a33392c569506f1186e3a4654/src/common.c#L241
Et faire une policy qui permette la transition :
http://danwalsh.livejournal.com/23944.html
https://wiki.gentoo.org/wiki/SELinux/Tutorials/How_does_a_process_get_into_a_certain_context
# Et sinon, y a systemd
Posté par Misc (site web personnel) . En réponse au journal Seccomp, une sandbox intégrée au noyau Linux…. Évalué à 4.
Alors même si ça ne fait pas exactement la même chose, et que je pense que mettre seccomp dans un programme permet de rajouter un filtre après traitement divers et variés, il est possible d'utiliser systemd pour avoir une partie des avantages de seccomp sans rajouter de code.
Cf https://lwn.net/Articles/507067/
perso, je trouve ça un peu contraignant, mais ceci dit, c'est pas pire que selinux à ce niveau la, donc why not ?
[^] # Re: Lapin
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat rachète la société Inktank à l'origine de Ceph. Évalué à 5.
Grosso modo, pour les projets modernes, tu as 3 cas d'usages. Un usage. Le mode "block" ( ie, tu exportes un bloc ), le mode filesystem ( ie, tu export directement un file system ) et le mode objet ( ie, tu exportes des objets, un peu comme swift et s3 ).
Gluster est surtout fort dans filesystem, ce qu'il fait nativement, et on a rajouté les 2 autres modes par dessus.
Ceph au contraire est à la base un système d'objet distribué sur lequel on rajoute le mode filesystem et block.
Donc chacun a ses faiblesses et ses forces. Ceph a une architecture plus complexe que Gluster, ce qui lui permet d'être entièrement distribué. Par contre, gluster a un système de layer, ce qui permet d'être plus souple ( à mon sens ) d'un point de vue de ce que tu peux rajouter.
Mais je connait surtout gluster et pas trop Ceph, donc je dit peut être de la merde.
Doc l'idée, c'est d'avoir 2 systèmes, pour adresser 2 cas d'usages différents, avec des fondements différents d'un point de vue technique.
[^] # Re: Léger détail
Posté par Misc (site web personnel) . En réponse au journal C'est vendredi, c'est permis, aka, MS devrait faire une offre à MS pour sa boite. Évalué à 6.
C'est vrai, et puis un vendredi de pont, c'est un peu comme un samedi. Bon, le jour aprés, c'est aussi un peu comme un samedi ceci dit.
[^] # Re: Léger détail
Posté par Misc (site web personnel) . En réponse au journal C'est vendredi, c'est permis, aka, MS devrait faire une offre à MS pour sa boite. Évalué à 4.
Oui, c'est pas à moi qu'il faut le dire.
Et pour être franc, j'aurais été déçu que personne ne pointe la chose. Il y a plein de trucs à redire sur les suppositions de ce poste de blog, et c'est pour ça que je pensais qu'il était parfait pour une discussion durant un vendredi, comme par exemple, la perception "business" et le fait que les communautés sont oubliés.
Mais bon, ça ne prends pas, personne ne discute, tant pis :)
[^] # Re: Fedora
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 2.
alors utilise l'outil spécifique pour lancer un truc comme ansible
au contraire d'un outil non spécifique ? les choses partent pas "brutalement", c'est plus les gens qui découvrent brutalement qu'il fallait suivre les changements. Je dit pas que c'est simple ceci dit, vu comme le monde du libre bouge. Mais par exemple, puppet, non spécifique, a des soucis de versions en fonction du client puppet, qui lui même depend de la version de ruby et des gems. De même, ils ont retiré les manifests en ruby dans la version 3.0, et y a des gens qui s'en servaient.
En effet, j'ai pas installé de Fedora 20, j'ai juste fait un yum search firstboot et j'ai pas vu qu'il était installé, pas dispo. Et donc en effet : https://admin.fedoraproject.org/pkgdb/acls/name/firstboot
Cela a été remplacé par gnome-initial-setup ( https://fedoraproject.org/wiki/Features/NewFirstboot ), qui en effet ne propose pas un réglage aussi fin que tu voudrais de ldap, ceci étant reservé à la commande authconfig
Il est présent dans EL7 ceci dit.
[^] # Re: OSEF
Posté par Misc (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à 3.
Mais RH dit que c'est pas supporté pour RHEL. Et pour Fedora, la communauté se bat depuis des années pour savoir si ça marche ou pas, et comment ( ie, preupgrade/fedup vs yum ). Y a pas moyen de tester de façon exhaustive, mais les gens le font et corrige à la main et disent de le faire. Et parfois, garder une vielle configuration montre des comportements inattendus dans les softs.
Ça marche avec Debian, mais c'est pas non plus "j'ai rien à faire" comme on m'a vendu ça y a plusieurs années ( et dieu merci, sinon j'aurais pas eu de boulot à corriger ça ).