🚲 Tanguy Ortolo a écrit 12690 commentaires

DANE me semble bien pour ça, pourquoi ? Pitié, pas de « on ne peut pas résoudre un problème politique avec une solution technologique », la dernière fois que j'ai entendu quelque chose de semblable — « ton truc c'est un problème social, on ne peut pas résoudre un problème social par une solution technologique » — ben j'ai ignoré cet avis et simplement résolu le problème en question. Avec un solution technologique.

Mais toutes les implémentations ne le supportent pas, en particulier les anciennes.

Pour être plus précis, toutes les implémentations de SSL relativement récentes le prennent en charge, seules les implémentations antiques, de plus de dix ans, ne le prennent pas en charge, notamment celle de Windows XP.

Et un problème supplémentaire :

• peut-on accepter un passage obligatoire par la guilde des autorités de certification, un péage en quelque sorte, pour pouvoir publier sur le web ?

Moi ce que je trouve marrant, c'est l'aspect mendiant de cette histoire...

Sivoplé, un dual boot... J'ai pu travail, j'ai pu client, sivoplé...

Pour rien au monde je voudrais passer sur un truc 'traditionnel'

Même sur Usenet ? Les fils de discussion, ça vient de là non ? Un accès Usenet aux forums de DLFP, ça ce serait chouette non ?

Euh, je me suis très mal exprimé. Aujourd'hui, on peut sans problème mettre son nom en CN, et les noms de domaine en subjectAltName. Ce sera pris en charge sur tous les logiciels, sauf les antiquités telles que Windows XP.

En revanche, ce n'est pas ce qui se fait habituellement, qui consiste à mettre un nom de domaine dans le CN. C'est une pratique issue d'une contrainte historique — un seul nom par certificat —, pratique tout à fait aberrante.

C'est fait pour les certificats EV (extended validation)

Pas besoin d'EV. On peut mettre son nom comme CN du sujet du certificat, et les noms de domaines comme subjectAltName. La convention, universelle et seule prise en charge partout, de mettre le nom de domaine en CN est une aberration.

Dans les critiques contre ce système :

1. si le but est de faire payer la pollution par les poids-lourds, celle-ci étant proportionnelle à leur consommation de carburant, il est plus simple de taxer le carburant, ce qui peut se faire uniquement pour les PL sans problème ;
2. si le but est de faire payer la distance parcourue, ce qui est peu justifié, cela peut se faire en lisant les enregistrements de trajet des PL, inutile d'introduire un traçage complet des trajets, l'enregistrement actuellement obligatoire étant déjà bien assez intrusif.

Mmmh, achète-toi un pavé numérique ?

Pareil, avec un esprit que je veux synthétique, chaque fois que je conçois quelque chose, avant tout j'essaie de simplifier au maximum sa mise en œuvre, et je ne comprends pas qu'on puisse mettre en place de telles usines à gaz alors qu'une simple taxe sur le carburant aurait suffi, surtout vu les inconvénients de la méthode choisie à la place.

Et si les logiciels le mettent en œuvre. Comme on parle surtout du web, je vous rappelle que cette application d'Internet est restée fossilisée à une époque antérieure à la simple introduction des enregistrements DNS dédiés aux protocoles, le premier étant le MX pour le courrier électronique, et n'a pas évolué depuis. HTML a évolué, HTTP est resté figé. Donc l'adoption d'un truc pareil, ce n'est pas pour demain, enfin dans Firefox il y a peut-être une chance, encore que, mais alors dans les autres...

Par contre j'ai vraiment du mal a comprendre pourquoi il faut absolument vérifier la véracité de l'identité de la personne. Pourquoi ne pas simplement se borner a vérifier que l'on est bien le locataire/gérant du nom de domaine ?

C'est la seule chose qui est vérifiée pour les certificats de six mois. Et je suis d'accord, il n'y a pas de raison de vérifier l'identité, à moins de la mettre dans le certificat, ce qui n'est pas fait aujourd'hui. C'est d'ailleurs une absurdité du modèle actuel : quand tu vas sur le site de ta banque, ou que tu consultes ton courrier, tu te moques du nom de domaine, ce qui t'intéresse, c'est en réalité l'identité de la personne qui possède les serveurs auxquels tu te connectes.

Édit : non rien (j'avais mis un commentaire qui n'était pas pertinent parce que répondant à aurte chose en fait).

Je l'avais écarté à dessein ;)

Je ne comprends pas la raison. Autant écarter l'auto-signé dans ce cas.

D'un point de vue purement pragmatique, un certificat CAcert est aussi utile pour les usages d'auto-hébergement vu qu'il faut faire une manipulation technique pour le faire reconnaître à une machine.

Pas compris.

Ça a l'air facile sous Debian, qu'en est-il sur un poste Windows, un Mac, un smartphone, une tablette ?

Aller sur le site de CAcert, installer le certificat racine, sans garantie sur son intégrité.

Ca ressemble fortement au cas 1 cette histoire...

En un peu plus sérieux.

Tu as oublié de mentionner CAcert. Je complète donc.

utiliser un certificat de chez CAcert

• Avantages : demander un certificat ou son renouvellement est facile et gratuit.
• Contraintes : les utilisateurs doivent récupérer le certificat racine de CAcert par un canal sécurisé, par exemple en installant le paquet Debian ca-certificates puis en important le certificat en question dans leur navigateur depuis leur système de fichier. À noter que même si ce n'est pas automatique, c'est déjà plus sérieux que d'accepter aveuglément un certificat auto-signé.
• Usage propices : hébergements de services avec volonté libriste ou sécuritaire ou rejet des autorités de certification commerciales.

On peut également mentionner le fait que la vérification d'identité par les membres de la communauté CAcert est nettement plus sérieuse que celle qu'effectuent les autorités de certification commerciales, dont l'intérêt est en fait de ne rien vérifier du tout pour éviter de devoir refuser des ventes. Mais cet avantage concerne le (mauvais) système X.509 en général et non les utilisateurs.

Eh bien c'est tordu. LNMP serait plus compréhensible non ?

LEMP ? LAMP, je connais, ça veut dire GNU/Linux, Apache, MySQL et PHP, mais LEMP ? Que signifie le E ?

Et ils sont adhérents à l'April. J'ai eu quelques pannes avec eux, suite à des tempêtes en Bretagne, où ils sont installés, mais ils rétablissent le service rapidement une fois l'événement passé.

• gestion de commentaire (par exemple avec disqus)

Non, pitié, pas Disqus... On n'installe pas son propre service d'albums photos pour aller mettre les commentaires sur un service privateur centralisé !

Une galerie ? De quel logiciel parles-tu ?

Accessoirement, c'est également une fonctionnalité qui différencie assez bien les services libres, dont il est facile d'extraire les données, des services privateurs dont il est difficile de sortir et qui encouragent l'utilisation exclusive de leur propre écosystème. Google Picasa par exemple...

(après dans mes contraintes il y a des points bonus, comme l'utilisation de mots-clefs ou la localisation par exemple)

Note que je ne prétends pas que c'est une fonctionnalité qui sera demandée ou utilisée par beaucoup de gens, simplement que c'est une fonctionnalité très importante. C'est comme pouvoir changer soi-même l'huile d'un moteur ou l'eau d'un circuit de refroidissement, je doute que les gens le fassent souvent, il est très important de pouvoir le faire.

Là, le cas d'usage c'est un événement avec plusieurs personnes. A priori, tout le monde est intéressé par les photo. Les regarder en ligne, c'est une chose, mais il est important de pouvoir les récupérer définitivement, pour pouvoir les consulter lorsque le site sera retiré. Après, que les gens le fassent ou non, c'est leur problème, ce qui est important c'est de leur permettre de le faire.

En ce qui me concerne, ça fait partie des fonctionnalités indispensables. Actuellement, pour choisir un logiciel d'album photo en ligne, je regarde ceux qui :

• permettent l'organisation en albums hiérarchiques (exit MediaGoblin) ;
• permettent le téléchargement (exit EnVadrouille pour le moment) ;
• ne nécessitent pas de serveur de base de données (exit Gallery).

Bon, actuellement j'utilise Gallery, mais c'était clairement un choix par défaut à l'époque où j'avais dû choisir. Aujourd'hui, je me tournerais plutôt vers PhotoShow je pense. Si EnVadrouille évolue et se trouve répondre à mon besoin, j'en profiterais bien pour l'empaqueter pour Debian.

Parce que c'est un langage qu'on choisit souvent par défaut. Comme langage, c'est de la merde, c'est incohérent au possible, avec de grosses fautes de conception. Mais c'est disponible presque partout. Les hébergements mutualisés proposant le plus souvent PHP.

Bref, on choisit PHP pour être accessible, mais on n'aime pas ça, donc on n'est certainement pas enthousiaste à son sujet.