Benoît Sibaud a écrit 9306 commentaires

Petite correction d'ortho : property pas propertie. Il faudra aussi définir la fonction die.

Aurais-tu une URL pour le suivi de ce bug stp ?

Corrigé, merci.

Corrigé, merci.

Pour t'aider à comprendre :

$ apt-get moo
                 (__) 
                 (oo) 
           /------\/ 
          / |    ||   
         *  /\---/\ 
            ~~   ~~   
..."Have you mooed today?"...

$ for i in $(seq 1 6); do opt="${opt}v";aptitude -$opt moo ; done
Il n'y a vraiment pas d'œufs de Pâques dans ce programme.
Ne vous ai-je pas déjà dit qu'il n'y avait pas d'œufs de Pâques dans ce programme ?
Arrêtez donc !
D'accord, d'accord, si je vous donne un œuf de Pâques, vous en irez-vous ?
D'accord, vous avez gagné.

                               /----\
                       -------/      \
                      /               \
                     /                |
   -----------------/                  --------\
   ----------------------------------------------
Qu'est-ce que c'est ? C'est un éléphant qui se fait manger par un
serpent, bien sûr.

Et le tout récent :

$ apt moo
                 (__) 
                 (oo) 
           /------\/ 
          / |    ||   
         *  /\---/\ 
            ~~   ~~   
..."Have you mooed today?"...

Beaucoup plus clair maintenant non ?

Avant : Facebook t'envoie une info en clair. Elle est visible de Facebook, du destinataire, de ceux qui sont sur son chemin (exemple la NSA) et de ceux qui peuvent la récupérer chez Facebook (exemple la NSA).
Après : Facebook t'envoie l'info chiffrée. Elle est visible de Facebook, du destinataire et de ceux qui peuvent la récupérer chez Facebook (exemple la NSA).

Encore un peu de folklore :

bsdmainutils: /usr/bin/printerbanner
et probablement un peu aussi la libcaca

Ce n'est pas le cas du flux Atom de Wikipédia par exemple et pourtant Firefox fait pareil. Idem sur le flux RSS https://blog.mozilla.org/ sans image. Pour le moment je n'ai rien trouvé à ce propos dans le bugzilla Mozilla.

Corrigé, merci.

C'est envisageable, mais pas prioritaire (il y a pas mal d'autres entrées de suivi à gérer avant par exemple).

J'avais bien noté ce point en essayant d'ouvrir le fichier sans succès, mais j'étais confiant sur le fait que tu n'avais pas essayé de nous refiler un gros cheval de Troie en douce et qu'un jour j'aurais un Gimp capable de l'ouvrir :). D'ailleurs le message d'erreur est explicite.

Il y a 3 points différents (plus ou moins entrelacés cependant) dans lesdites convictions, présentés ici sans classement particulier :

1. la sécurité et le modèle foireux des CA
2. le logiciel libre
3. la décentralisation, disons l'indépendance et le fait de ne pas devoir passer par un oligopole pour avoir le droit d'exister en ligne

Sur le point 1, oui, complètement d'accord sur les alternatives que tu évoques. Pour le moment les points bloquants restent le temps disponible (plus de gens pour vouloir faire des choses ou pour dire comment les faire que pour les faire) et les logiciels disponibles sur nos serveurs. Et je bats ma coulpe et j'aurais préféré bosser sur les alternatives que de me taper le changement de CA par exemple.
Sur le point 2, signalons quand même que CAcert publie son code sous licence libre, permettant potentiellement à d'autres CA de se créer. L'association LinuxFr a pour « objectif de promouvoir les Logiciels Libres » donc ça reste un point important. On peut considérer que l'on régresse sur ce point en passant par une CA qui à ma connaissance ne publie pas son code.
Sur le point 3, CAcert offre des fonctions de toile en confiance en plus des classiques certificats. Le site tournant avec une équipe de bénévoles, le fait de devoir demander la permission (payante) à quelqu'un d'autre d'exister en ligne me choque (mais les certificats autosignés ont été voués aux gémonies par les navigateurs).

J'avais pourtant l'impression de revoir une activité de ce côté: présence d'un stand CAcert au Fosdem par exemple, il me semble avoir lu que Debian allait (ou a ?) ré-intégrer les certificats racine (pas trop le temps de vérifier ça maintenant, ni de risquer une mise à jour sur ma SID aujourd'hui).

J'ai aussi lu que le nombre d'accréditeurs CAcert avait augmenté. Et pour Debian, il s'agit du paquet ca-cacert, annoncé par CAcert.

Bref, on se pose sérieusement la question de garder CAcert ou pas, j'ai l'impression de trahir un (petit) peu nos convictions si on le fait, mais maintenant que même DLFP lâche le morceau, on se sent plus seuls.

Tu peux utiliser le CCC comme référence si tu veux. On a toujours/encore des accréditeurs CAcert dans l'équipe et on a aussi un certificat CAcert wildcard valide au besoin ou pour des tests.

Et à titre personnel qui n'engage que moi, et indépendamment du fait que ça soit peut-être un bon choix pragmatiquement parlant, « j'ai l'impression de trahir un (petit) peu [mes] convictions ». J'avais le même sentiment quand l'April a abandonné CAcert (en ayant de vraies bonnes raisons car l'asso gère des paiements en ligne par exemple) ou quand l'April continue à utiliser du vote électronique ou quand je devais installer un JDK propriétaire pour déclarer mes revenus ou quand j'utilise un microcode ou un BIOS propriétaire ou quand je dois passer par du Flash propriétaire ou…

Dans le même genre que celle de Gruik, on peut s'y connecter, redémarrer électriquement, voir que le serveur est allumé, et pleurer.

$ curl -v -o /dev/null https://linuxfr.org/news.atom
(...)
* Connected to linuxfr.org (88.191.250.176) port 443 (#0)
(...)
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
(...)
< HTTP/1.1 200 OK

De fait ça marche moins bien sans vérification possible de certificat :

$ curl -v -o /dev/null --cacert /dev/null https://linuxfr.org/news.atom
(...)
* Connected to linuxfr.org (88.191.250.176) port 443 (#0)
* found 0 certificates in /dev/null
(...)
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification failed. CAfile: /dev/null CRLfile: none

Et pour comparaison, le flux Atom Wikipédia. En fait c'est Firefox qui choisit de ne pas afficher la page de rendu Atom comme du HTTPS classique (chromium le fait par exemple).

2, 3 ou 4 pales c'est visiblement très courant. 5 ça arrive.
Sikorsky CH-54 ou Sud-Aviation SA321 Super Frelon avec 6 pales
Sikorsky CH-53K King Stallion avec 7 pales
Mil Mi-26 avec 8 pales
(liste non exhaustive)

C'est très péremptoire comme réponse, sans savoir ce qu'il y a sur ce serveur. Et à un moment, il faut bien mettre à jour les serveurs physiques aussi.

Oui

Il est allumé mais inaccessible à distance, donc y a un souci oui.

Le changement est effectif.
Cf https://linuxfr.org/news/quoi-de-neuf-cote-linuxfr-org#changement-de-certificat-x509-et-dautorit%C3%A9-de-certification

Il n'y a eu aucune intervention de Florent en tant que président de dlfp

Surtout que :

« L'association LinuxFr
(…)
Président : Nicolas Vérité
Secrétaire/trésorier : Florent Zara
»

On peut faire un tableau en markdown au besoin (mais pas avec couleurs à ma connaissance, pas sans passer par le pour des , ce qui ne serait pas très accessible de toute façon).

Précision ajoutée dans la dépêche, merci.

Corrigé, merci.

• Paquet Debian pour réinstaller les certificats CAcert https://packages.debian.org/search?keywords=ca-cacert&searchon=names&suite=all&section=all