pour avoir fait les deux, administrer des annuaires OpenLdap est bien plus facile à gérer que Active Directory. j’admets cependant que ça oblige à étudier le fonctionnement d'un annuaire LDAP, ActiveDirectory n'est pas un vrai annuaire ldap mais un annuaire customise pour les besoin de microsoft :)
ActiveDirectory (le backend) est un vrai annuaire LDAP. Ils ont par contre des schémas bien à eux (mais ça c'est normal pour du LDAP), ils ont des contraintes particulières (mais ça c'est normal pour LDAP), mais ça reste un vrai annuaire LDAP que tu peux attaquer en respectant le standard sans jamais manqué la moindre fonctionnalité. Sous le nom ActiveDirectory se cache aussi les outils d'administration, mais le serveur d'annuaire est un vrai LDAP, le seul manquement au standard est le fait que si tu utilises les résultats paginés sur AD, tu peux dépasser la limite imposée par le serveur en nombre d'objets retournés alors que la RFC 2696 dit bien que ça ne doit pas être le cas.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
C'est vrai qu'au niveau des requêtes, LDAP est moins fourni, l'opposition filtre / requêtes dans un SGBDR est incontestablement emportée par les seconds.
Je suis pas encore convaincu de ça. Dès que tu commences à vouloir croiser beaucoup de données différentes dans un SGBDR tu galères. Un LDAP ça reste une seule requête et peu importe le nombre de données différentes que tu croises.
Après, pour les contraintes au niveau du schéma, LDAP propose des syntaxes, qui sont des règles qui semblent passives, tout comme les règles de matching. Du coup, pas vraiment de contrainte, certes, mais ces informations peuvent être vues comme des directives.
Tu peux toujours créé un objet extensible, soit un objet qui peut contenir tous les attributs connus de ton annuaire. Mais c'est moins performant.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Et tu perd la compatibilité (c'est pas forcément vital mais c'est dommage).
Non, le protocole est standard. Par contre dans le monde des SGBDR, SQL c'est standard mais faut pas vouloir changer la base de données derrières si tu n'utilises pas que SELECT, INSERT, DELETE, UPDATE. Bien que les différences s'estompent, ça reste, je trouve, très casse gueule (et dieu sait comme je maîtrise peu SQL l'ayant abandonné depuis ma rencontre avec LDAP).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
LDAP est un protocole. Après les serveurs d'annuaire parlant le LDAP sont pléthores (OpenLDAP, ActiveDirectory, Samba4, 389 Directory Server (Fedora), …). Le protocole LDAP permet de faire des requêtes genre "je veux tous les objets ayant le type X ou le type Y, ayant l'attribut Z présent, ayant l'attribut V = blabla ou V = blibli. Retournes-moi les attributs A, B et C de ces objets. Applique cette recherche sur les enfants directes de l'entrée E". Je crois que ce qui agrégation et OLAP c'est couvert par les méthodes de recherches. Ensuite les objets LDAP doivent avoir un schéma, mais peuvent avoir autant de schéma que l'on souhaite. Il suffit juste d'en ajouter. Et c'est pas un truc définitif. On créer un objet avec un schéma et six mois plus tard on rajoute un schéma et chaque objet, finalement, à son propre jeu de schéma. Bien entendu il y a les références vers des autres objets.
Et tout le côté orienté objet des schémas avec l'héritage (mais pas multiple) rend le tout très intéressant et les options des attributs, la multiplicité des attributs (un objet peut avoir 0 ou N attribut (le schéma peut forcer un attribut à être 0 ou 1)).
Après tu as encore des trucs comme les entrées ayant une durée de vie. La sécurité avec des règles comme "l'attribut X n'est accessible que si le niveau de sécurité est plus grand que Z (ce niveau correspondra à une recherche faites depuis une connexion TLS authentifiée client et serveur), … Après il y a bien entendu toute la partie d'extension du protocole et tellement d'autres choses …
Par contre c'est très, très mal utilisé en général. Tu prends déjà tous les codes php sont dramatiques : tu n'as pas de connexion persistante possible (donc les résultats paginés tu l'as dans l'os), il te manque l'accès à toute une partie du protocole (les extensions et j'ai proposé un patch), tu n'as pas accès à toutes les requêtes asynchrones et bon, ayant essayé de patcher php-ldap, le code du module me fait peur (et le corriger, j'ai passé pas mal de temps dessus et là j'ai plus le temps, mais il faudrait réécrire complètement parce 1) pas possible de garder les codes existants fonctionnelles 2) l'arrivée d'horreur comme ldap_control_paged_result_response qui normalement est juste une extension que l'on passe avec la requête ldap_search).
Ensuite quand tu lis documentation de la plus part des projets utilisant LDAP, il faut configurer mille trucs (DN, TLS ou pas, …) alors que normalement c'est 1) requête DNS pour savoir où se trouve l'annuaire 2) requête sur le Root DSE de l'annuaire pour savoir ce qu'il a comme schéma, supporte comme sécurité, comme version de TLS, sa racine, ses extensions, … bref tout ce que tu souhaites savoir et 3) tu peux intégrer un nouveau schéma directement par une requête au bonne endroit (le bonne endroit étant donné par l'annuaire).
Avec un annuaire LDAP, tu te poses moins de question quant à la création de ta base de données. Alors qu'avec du relationnel tu vas te poser des questions sur "comment stocker", avec LDAP une fois que tu as répondu à "quoi stocker" tu as ta base prête. Il reste juste à écrire le schéma (ce que tu fais aussi sur une base relationnelle) et utiliser.
Et pour finir, LDAP est certe optimisé en lecture, mais concrètement les cas où tu as la lecture/écriture avec un ratio 1/1 sont rares. Généralement c'est plus proche du 90/10. Et quand tu regardes les performances du dernier né dans les backend de OpenLDAP et face à InnoDB (en gros le backend mdb de OpenLDAP atteint des performances proches de celle de Memcached et lecture/écriture et est même plus rapide en multi-thread car c'est un backend lockless.
Bon dans un système de type transaction comme les banques, une base relationnelle est la seule réponse valable (du moins pour stocker les transations).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
LDAP est plus simple qu'un SGBDR (mais a un peu moins de flexibilité).
O.O moins flexible ??? Il faudra que tu m'expliques ? Honnêtement il est difficile de faire plus flexible que les annuaires LDAP, hormis des bases "clé valeur" sans schéma.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Il n'est pas (encore ?) dans les dépôts, mais c'est un petit projet, qui, à mon avis, à certainement beaucoup d'avenir. Tu peux télécharger le logiciel sur le site du projet …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Surtout sur un clavier AZERTY où le tiret est carrément accessible.
En Suisse, nous utilisons un clavier QWERTZ où le tiret est accessible au-dessus de [Ctrl], il faut donc plier le petit doigt vers l'intérieure de la paume et c'est l'ongle qui touche la touche finalement. Donc non, pas de apt-get.
Sinon pour le reste je suis d'accord, sauf que j'ai pas mal pris son commentaire (enfin je sais pas si quelqu'un pense que je l'ai mal pris).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Oui et aptitude fut, dans Lenny si je me souviens bien, la manière recommandée par le projet pour l'installation des paquets. Comme aptitude est plus facile à taper (pas d'utilisation du petit doigt) j'ai gardé l'habitude et ça m'a jamais posé le moindre problème. Maintenant je sais pas où on en est entre apt-get et aptitude au niveau duquel est recommandé par le projet, mais aptitude me va très bien sauf pour choper les sources, là il n'y a que apt-get.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Parce que ça vient d'un autre (cf le lien) et que lui a décidé d'utiliser perl et que je vais pas réécrire une commande qui fonctionne pour utiliser un autre outil.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Mais les meubles c'est un peu différent. Un meuble tu peux acheter celui qui va presque bien et le modifier pour qu'il soit parfaitement adapté. Aucune possibilité de bloquer ça avec des DRM ou en centralisant les meubles sur un serveur de meuble. Bien entendu en modifiant le meuble tu perds la garantie, mais c'est quelque chose de normal.
Un meuble tu peux le fabriquer toi-même, tu peux acheter les pièces et le monter toi-même, tu peux acheter un meuble fini et le modifier et tu peux faire tous les mélangent de variation entre deux. Dans l'informatique, ces choix sont bloqués artificiellement. Et c'est là où le problème de liberté se pose. On ne monte pas un ownCloud pour le plaisir de le faire, mais parce que si on utilise un service en main privée et centralisé, on se retrouve dans une situation où extraire les données est difficile voir impossible, où les données sont utilisées contre notre volonté, où en cas de problèmes aucune garantie n'est fournie et en cas de changement de technologie du côté du fournisseur, le coût de la migration est souvent laissé à l'utilisateur (dans X jours on ferme ce service, vous pouvez migrer vers ce service Y grâce à un processus long, fastidieux et où pas toutes les méta-données seront présentes (ex. MobileMe de Apple)). Et ce même pour les services payants. Un meuble c'est jamais le cas (si on exclu le "room lock in", cas où l'on a monté un meuble non démontable dans une pièce et, au moment de le sortir, on découvre qu'il ne passe par aucune ouverture).
Je suis convaincu que s'il était possible de bloquer artificiellement ce qu'on peut faire ou pas d'un meuble, ça se ferait de manière généralisée.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Ce n'est qu'une question d'équilibre entre la liberté et la sécurité. Bon je cherche toujours à savoir ce qu'ils souhaitent "sécuriser", mais certainement pas nos libertés.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Non, l'alerte vient du fait qu'aucune autorité de confiance sélectionnée par les fournisseurs de navigateurs et/ou système d'exploitation n'a signé le certificat. L'authentification, dans TLS, vient du fait qu'un tiers de confiance signe ton certificat. Sans ça, pas d'authentification.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Le but de TLS est d'offrir une forme d'authentification, une vérification de l'intégrité et la confidentialité. Dans le cas d'un certificat auto-signé, nous avons que 2 sur 3. Le serveur n'est pas authentifié , mais les messages transmis sont intègres et confidentiels. Donc oui, on ne sait pas si on parle vraiment avec le bon serveur, mais on est certain que ce qu'on transmet est ce qui est reçu et que uniquement l'inconnu et nous sommes en mesure de connaître le contenu.
Donc entre prendre un protocole où il n'y a ni authentification, intégrité et confidentialité (HTTP) ou en prendre un avec uniquement intégrité et confidentialité (HTTPS avec certificat auto-signé), c'est déjà une amélioration.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
CACert est-il si important pour les libristes, ou est-ce juste pour le fun de faire chier avec un avertissement, afin de bien pourrir l'expérience utilisateur en SSL (car à force de cliquer n'importe comment, l'utilisateur se dit que c'est pas bien grave ce warning)?
Non pas pour le libriste, mais pour tout le monde. Les gens ont pris l'habitude de cliquer sur "Je comprends le risques"->"Accepter de prendre tous les risques"->"Je risque de tuer de mignons petits chatons par milliers mais je vais continuer quand même"->"Oui, oui je risque d'atomiser l'espèce humaine mais je veux voir de putain de site parce que c'est peut-être ce que je cherche".
Les gens s'en tapent de la sécurité, et c'est un euphémisme (j'ai des histoires à ne plus en dormir, mais je peux pas les raconter), alors si en plus on bloque la possibilité aux professionnels ou passionnés de pouvoir sécuriser correctement de leur côté par des pratiques douteuses : une trentaine d'euro par an pour que ces messieurs vérifient qu'ils y aient bien XYZ dans un champs TXT de mon DNS (non sécurisé avec DNSSEC évidemment), c'est douteux.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Ce n'est pas pour rien que j'ai parlé de navigateur qui aiment le libre… Mais bon, passons.
Pas vu, désolé.
A ma connaissance, c'est CACert qui ne veut pas.
Ouais en fait c'est un peu plus tordu, j'avais suivi l'histoire, me faut juste reprendre un bain de mailing list pour que la mémoire. Ils ont fait la requête puis lancé un audit, l'audit à détecté des problèmes, du coups la requête a été suspendue chez Mozilla et depuis j'ai plus suivi (aussi parce qu'après avoir contacter plein de monde j'ai jamais réussi à obtenir mes 5 ou 10 points manquant pour devenir assureur (une personne dans les 100km autour de chez moi et plus loin les gens ne répondaient pas ou alors qu'il ne faisait plus ou pas le temps ou …).
Ils l'ont fait, mais, par exemple, pour être dans OS X, il faut payer 75'000$ puis 10'000$ par an. Pour Firefox, le processus est bloqué car ils attendent sur Mozilla http://wiki.cacert.org/InclusionStatus …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Il faut surtout faire un certificat d'autorité racine de longue durée, genre 10-50 ans, généré des autres certificats d'autorité avec une durée du genre 5 ans signé par le premier créer. Le premier sera placé dans un coffre dans une banque et on y accède uniquement lorsqu'il faut révoquer ou générer de nouveaux certificats d'autorités. À partir de là, même si le certificat d'autorité ayant signé le certificat serveur est compromis, le problème est moindre. C'est juste un peu chiant en terme de temps de réaction, mais il est toujours possible de créer une autorité sur trois étages avec au premier étage le CA racine dans le coffre à la banque, le deuxième étage des CA sur CD distribué à chaque admin ou gestionnaire des certificats et le troisième étage sur les serveurs avec la clé privée chiffrée par un mot de passe fort. Ainsi l'autorité de certification sera assez solide et réactive.
Dans le cas d'une association, on peut même envisager que le mot de passe des CA 1 et 2 soient découpés en petit morceau avec http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing et ainsi distribué la possibilité de généré des CA 3 en partageant le secret entre les diverses membres de l'association en définissant un quorum à atteindre pour que le secret existe.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Dur :/
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Gestion de LDAP sous Debian : OpenLDAP. Évalué à 4. Dernière modification le 20 juin 2013 à 14:45.
ActiveDirectory (le backend) est un vrai annuaire LDAP. Ils ont par contre des schémas bien à eux (mais ça c'est normal pour du LDAP), ils ont des contraintes particulières (mais ça c'est normal pour LDAP), mais ça reste un vrai annuaire LDAP que tu peux attaquer en respectant le standard sans jamais manqué la moindre fonctionnalité. Sous le nom ActiveDirectory se cache aussi les outils d'administration, mais le serveur d'annuaire est un vrai LDAP, le seul manquement au standard est le fait que si tu utilises les résultats paginés sur AD, tu peux dépasser la limite imposée par le serveur en nombre d'objets retournés alors que la RFC 2696 dit bien que ça ne doit pas être le cas.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mongueur
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Gestion de LDAP sous Debian : OpenLDAP. Évalué à 3.
Je suis pas encore convaincu de ça. Dès que tu commences à vouloir croiser beaucoup de données différentes dans un SGBDR tu galères. Un LDAP ça reste une seule requête et peu importe le nombre de données différentes que tu croises.
Tu peux toujours créé un objet extensible, soit un objet qui peut contenir tous les attributs connus de ton annuaire. Mais c'est moins performant.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mongueur
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Gestion de LDAP sous Debian : OpenLDAP. Évalué à 4.
Non, le protocole est standard. Par contre dans le monde des SGBDR, SQL c'est standard mais faut pas vouloir changer la base de données derrières si tu n'utilises pas que SELECT, INSERT, DELETE, UPDATE. Bien que les différences s'estompent, ça reste, je trouve, très casse gueule (et dieu sait comme je maîtrise peu SQL l'ayant abandonné depuis ma rencontre avec LDAP).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mongueur
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Gestion de LDAP sous Debian : OpenLDAP. Évalué à 10.
LDAP est un protocole. Après les serveurs d'annuaire parlant le LDAP sont pléthores (OpenLDAP, ActiveDirectory, Samba4, 389 Directory Server (Fedora), …). Le protocole LDAP permet de faire des requêtes genre "je veux tous les objets ayant le type X ou le type Y, ayant l'attribut Z présent, ayant l'attribut V = blabla ou V = blibli. Retournes-moi les attributs A, B et C de ces objets. Applique cette recherche sur les enfants directes de l'entrée E". Je crois que ce qui agrégation et OLAP c'est couvert par les méthodes de recherches. Ensuite les objets LDAP doivent avoir un schéma, mais peuvent avoir autant de schéma que l'on souhaite. Il suffit juste d'en ajouter. Et c'est pas un truc définitif. On créer un objet avec un schéma et six mois plus tard on rajoute un schéma et chaque objet, finalement, à son propre jeu de schéma. Bien entendu il y a les références vers des autres objets.
Et tout le côté orienté objet des schémas avec l'héritage (mais pas multiple) rend le tout très intéressant et les options des attributs, la multiplicité des attributs (un objet peut avoir 0 ou N attribut (le schéma peut forcer un attribut à être 0 ou 1)).
Après tu as encore des trucs comme les entrées ayant une durée de vie. La sécurité avec des règles comme "l'attribut X n'est accessible que si le niveau de sécurité est plus grand que Z (ce niveau correspondra à une recherche faites depuis une connexion TLS authentifiée client et serveur), … Après il y a bien entendu toute la partie d'extension du protocole et tellement d'autres choses …
Par contre c'est très, très mal utilisé en général. Tu prends déjà tous les codes php sont dramatiques : tu n'as pas de connexion persistante possible (donc les résultats paginés tu l'as dans l'os), il te manque l'accès à toute une partie du protocole (les extensions et j'ai proposé un patch), tu n'as pas accès à toutes les requêtes asynchrones et bon, ayant essayé de patcher php-ldap, le code du module me fait peur (et le corriger, j'ai passé pas mal de temps dessus et là j'ai plus le temps, mais il faudrait réécrire complètement parce 1) pas possible de garder les codes existants fonctionnelles 2) l'arrivée d'horreur comme ldap_control_paged_result_response qui normalement est juste une extension que l'on passe avec la requête ldap_search).
Ensuite quand tu lis documentation de la plus part des projets utilisant LDAP, il faut configurer mille trucs (DN, TLS ou pas, …) alors que normalement c'est 1) requête DNS pour savoir où se trouve l'annuaire 2) requête sur le Root DSE de l'annuaire pour savoir ce qu'il a comme schéma, supporte comme sécurité, comme version de TLS, sa racine, ses extensions, … bref tout ce que tu souhaites savoir et 3) tu peux intégrer un nouveau schéma directement par une requête au bonne endroit (le bonne endroit étant donné par l'annuaire).
Avec un annuaire LDAP, tu te poses moins de question quant à la création de ta base de données. Alors qu'avec du relationnel tu vas te poser des questions sur "comment stocker", avec LDAP une fois que tu as répondu à "quoi stocker" tu as ta base prête. Il reste juste à écrire le schéma (ce que tu fais aussi sur une base relationnelle) et utiliser.
Et pour finir, LDAP est certe optimisé en lecture, mais concrètement les cas où tu as la lecture/écriture avec un ratio 1/1 sont rares. Généralement c'est plus proche du 90/10. Et quand tu regardes les performances du dernier né dans les backend de OpenLDAP et face à InnoDB (en gros le backend mdb de OpenLDAP atteint des performances proches de celle de Memcached et lecture/écriture et est même plus rapide en multi-thread car c'est un backend lockless.
Bon dans un système de type transaction comme les banques, une base relationnelle est la seule réponse valable (du moins pour stocker les transations).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mongueur
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Gestion de LDAP sous Debian : OpenLDAP. Évalué à 3.
O.O moins flexible ??? Il faudra que tu m'expliques ? Honnêtement il est difficile de faire plus flexible que les annuaires LDAP, hormis des bases "clé valeur" sans schéma.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: C'est gros, mais je ne peux m'en empêcher.
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Modification d'un paquet Debian. Évalué à 5.
Il n'est pas (encore ?) dans les dépôts, mais c'est un petit projet, qui, à mon avis, à certainement beaucoup d'avenir. Tu peux télécharger le logiciel sur le site du projet …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: apt-get puis aptitude ?!
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Modification d'un paquet Debian. Évalué à 2.
Oui pour faire les passages d'une version majeure à une autre, apt-get a toujours été recommandé et je l'utilise dans ce cas là.
Non : https://linuxfr.org/nodes/98754/comments/1462980
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: apt-get puis aptitude ?!
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Modification d'un paquet Debian. Évalué à 3. Dernière modification le 19 juin 2013 à 19:21.
En Suisse, nous utilisons un clavier QWERTZ où le tiret est accessible au-dessus de [Ctrl], il faut donc plier le petit doigt vers l'intérieure de la paume et c'est l'ongle qui touche la touche finalement. Donc non, pas de apt-get.
Sinon pour le reste je suis d'accord, sauf que j'ai pas mal pris son commentaire (enfin je sais pas si quelqu'un pense que je l'ai mal pris).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: apt-get puis aptitude ?!
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Modification d'un paquet Debian. Évalué à 3.
Oui et aptitude fut, dans Lenny si je me souviens bien, la manière recommandée par le projet pour l'installation des paquets. Comme aptitude est plus facile à taper (pas d'utilisation du petit doigt) j'ai gardé l'habitude et ça m'a jamais posé le moindre problème. Maintenant je sais pas où on en est entre apt-get et aptitude au niveau duquel est recommandé par le projet, mais aptitude me va très bien sauf pour choper les sources, là il n'y a que apt-get.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: debian c'est quand même autre chose
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Modification d'un paquet Debian. Évalué à 2.
Parce que ça vient d'un autre (cf le lien) et que lui a décidé d'utiliser perl et que je vais pas réécrire une commande qui fonctionne pour utiliser un autre outil.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: apt-get puis aptitude ?!
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Modification d'un paquet Debian. Évalué à 9.
J'évite ce genre de personnalisation parce que quand j'arrive sur un système non personnalisé, je suis agacé.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: apt-get puis aptitude ?!
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Modification d'un paquet Debian. Évalué à 3.
Parce que je trouve 'aptitude' plus facile à taper que 'apt-get' donc j'utilise 'apt-get' le moins possible.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Wiki
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Modification d'un paquet Debian. Évalué à 7.
Et bien voilà https://wiki.debian.org/fr/DebSrc3/QuickHowto
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Wiki
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Modification d'un paquet Debian. Évalué à 3.
Oui c'est pertinent, j'attends le mail pour confirmer la création de mon compte et je vais le publier là aussi.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: La bonne blague
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Espionnage: la FSF deconseille le cloud public, recommande les clouds privés basés sur le libre. Évalué à 6.
Mais les meubles c'est un peu différent. Un meuble tu peux acheter celui qui va presque bien et le modifier pour qu'il soit parfaitement adapté. Aucune possibilité de bloquer ça avec des DRM ou en centralisant les meubles sur un serveur de meuble. Bien entendu en modifiant le meuble tu perds la garantie, mais c'est quelque chose de normal.
Un meuble tu peux le fabriquer toi-même, tu peux acheter les pièces et le monter toi-même, tu peux acheter un meuble fini et le modifier et tu peux faire tous les mélangent de variation entre deux. Dans l'informatique, ces choix sont bloqués artificiellement. Et c'est là où le problème de liberté se pose. On ne monte pas un ownCloud pour le plaisir de le faire, mais parce que si on utilise un service en main privée et centralisé, on se retrouve dans une situation où extraire les données est difficile voir impossible, où les données sont utilisées contre notre volonté, où en cas de problèmes aucune garantie n'est fournie et en cas de changement de technologie du côté du fournisseur, le coût de la migration est souvent laissé à l'utilisateur (dans X jours on ferme ce service, vous pouvez migrer vers ce service Y grâce à un processus long, fastidieux et où pas toutes les méta-données seront présentes (ex. MobileMe de Apple)). Et ce même pour les services payants. Un meuble c'est jamais le cas (si on exclu le "room lock in", cas où l'on a monté un meuble non démontable dans une pièce et, au moment de le sortir, on découvre qu'il ne passe par aucune ouverture).
Je suis convaincu que s'il était possible de bloquer artificiellement ce qu'on peut faire ou pas d'un meuble, ça se ferait de manière généralisée.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pas de soucis à se faire ...
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal "Glenn Greenwald, le blogueur qui défie Big Brother". Évalué à 10.
Entre temps il a eu le prix Nobel de la paix, ça peut vous changer un homme ce genre de truc !
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# Pas de soucis à se faire ...
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal "Glenn Greenwald, le blogueur qui défie Big Brother". Évalué à 5.
… car "seulement les terroristes, les criminels et les espions doivent avoir peur des activités secrètes des agences de renseignements américaines et britanniques", enfin c'est ce que promet le secrétaire des affaires étrangères britanniques. http://www.independent.co.uk/news/uk/politics/william-hague-lawabiding-britons-have-nothing-to-fear-from-gchq-8651013.html
Ce n'est qu'une question d'équilibre entre la liberté et la sécurité. Bon je cherche toujours à savoir ce qu'ils souhaitent "sécuriser", mais certainement pas nos libertés.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Blabla
Posté par Etienne Bagnoud (site web personnel) . En réponse à la dépêche Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés. Évalué à 3.
En fait la solution pourrait être beaucoup plus simple. Il semblerait que l'IETF penche sur la possibilité de diffusé son certificat auto-signé via le serveur DNS (sécurisé avec DNSSEC) http://tools.ietf.org/html/draft-ietf-dane-protocol-08, il semblerait que Mozilla est en train de mettre en place ce fonctionnement dans son navigateur https://wiki.mozilla.org/Security/DNSSEC-TLS-details … Google avait mis un système similaire dans Chrome en 2011, j'ai testé avec la dernière version de Chrome ça ne fonctionne plus http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: La question qui manque
Posté par Etienne Bagnoud (site web personnel) . En réponse à la dépêche Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés. Évalué à 3.
Non, l'alerte vient du fait qu'aucune autorité de confiance sélectionnée par les fournisseurs de navigateurs et/ou système d'exploitation n'a signé le certificat. L'authentification, dans TLS, vient du fait qu'un tiers de confiance signe ton certificat. Sans ça, pas d'authentification.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: La question qui manque
Posté par Etienne Bagnoud (site web personnel) . En réponse à la dépêche Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés. Évalué à 2.
Le but de TLS est d'offrir une forme d'authentification, une vérification de l'intégrité et la confidentialité. Dans le cas d'un certificat auto-signé, nous avons que 2 sur 3. Le serveur n'est pas authentifié , mais les messages transmis sont intègres et confidentiels. Donc oui, on ne sait pas si on parle vraiment avec le bon serveur, mais on est certain que ce qu'on transmet est ce qui est reçu et que uniquement l'inconnu et nous sommes en mesure de connaître le contenu.
Donc entre prendre un protocole où il n'y a ni authentification, intégrité et confidentialité (HTTP) ou en prendre un avec uniquement intégrité et confidentialité (HTTPS avec certificat auto-signé), c'est déjà une amélioration.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: La question qui manque
Posté par Etienne Bagnoud (site web personnel) . En réponse à la dépêche Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés. Évalué à 3.
Si mes souvenirs sont exacts, il ne s'agit pas de problèmes de sécurité mais de capacité à grandir qui ont été problématique.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: La question qui manque
Posté par Etienne Bagnoud (site web personnel) . En réponse à la dépêche Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés. Évalué à 5.
Non pas pour le libriste, mais pour tout le monde. Les gens ont pris l'habitude de cliquer sur "Je comprends le risques"->"Accepter de prendre tous les risques"->"Je risque de tuer de mignons petits chatons par milliers mais je vais continuer quand même"->"Oui, oui je risque d'atomiser l'espèce humaine mais je veux voir de putain de site parce que c'est peut-être ce que je cherche".
Les gens s'en tapent de la sécurité, et c'est un euphémisme (j'ai des histoires à ne plus en dormir, mais je peux pas les raconter), alors si en plus on bloque la possibilité aux professionnels ou passionnés de pouvoir sécuriser correctement de leur côté par des pratiques douteuses : une trentaine d'euro par an pour que ces messieurs vérifient qu'ils y aient bien XYZ dans un champs TXT de mon DNS (non sécurisé avec DNSSEC évidemment), c'est douteux.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: La question qui manque
Posté par Etienne Bagnoud (site web personnel) . En réponse à la dépêche Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés. Évalué à 3.
Pas vu, désolé.
Ouais en fait c'est un peu plus tordu, j'avais suivi l'histoire, me faut juste reprendre un bain de mailing list pour que la mémoire. Ils ont fait la requête puis lancé un audit, l'audit à détecté des problèmes, du coups la requête a été suspendue chez Mozilla et depuis j'ai plus suivi (aussi parce qu'après avoir contacter plein de monde j'ai jamais réussi à obtenir mes 5 ou 10 points manquant pour devenir assureur (une personne dans les 100km autour de chez moi et plus loin les gens ne répondaient pas ou alors qu'il ne faisait plus ou pas le temps ou …).
Mais un résumé de la situation de la requête, à l'époque, est là https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158 …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: La question qui manque
Posté par Etienne Bagnoud (site web personnel) . En réponse à la dépêche Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés. Évalué à 4.
Ils l'ont fait, mais, par exemple, pour être dans OS X, il faut payer 75'000$ puis 10'000$ par an. Pour Firefox, le processus est bloqué car ils attendent sur Mozilla http://wiki.cacert.org/InclusionStatus …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Le meilleur des deux mondes?
Posté par Etienne Bagnoud (site web personnel) . En réponse à la dépêche Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés. Évalué à 6.
Il faut surtout faire un certificat d'autorité racine de longue durée, genre 10-50 ans, généré des autres certificats d'autorité avec une durée du genre 5 ans signé par le premier créer. Le premier sera placé dans un coffre dans une banque et on y accède uniquement lorsqu'il faut révoquer ou générer de nouveaux certificats d'autorités. À partir de là, même si le certificat d'autorité ayant signé le certificat serveur est compromis, le problème est moindre. C'est juste un peu chiant en terme de temps de réaction, mais il est toujours possible de créer une autorité sur trois étages avec au premier étage le CA racine dans le coffre à la banque, le deuxième étage des CA sur CD distribué à chaque admin ou gestionnaire des certificats et le troisième étage sur les serveurs avec la clé privée chiffrée par un mot de passe fort. Ainsi l'autorité de certification sera assez solide et réactive.
Dans le cas d'une association, on peut même envisager que le mot de passe des CA 1 et 2 soient découpés en petit morceau avec http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing et ainsi distribué la possibilité de généré des CA 3 en partageant le secret entre les diverses membres de l'association en définissant un quorum à atteindre pour que le secret existe.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell