Benoît Sibaud a écrit 10022 commentaires

$ openssl ec -in 001 -pubout -text
read EC key
Private-Key: (256 bit)
priv:
    00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
    xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
    xx:xx:xx
pub: 
    yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:
    yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:
    yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:
    yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:yy:
    yy:yy:yy:yy:yy
ASN1 OID: prime256v1
writing EC key
-----BEGIN PUBLIC KEY-----
(snip)
-----END PUBLIC KEY-----

$ grep -v -- "---" 001|base64 -d|hexdump -C
00000000  30 77 02 01 01 04 20 xx  xx xx xx xx xx xx xx xx
00000010  xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx xx
00000020  xx xx xx xx xx xx xx a0  0a 06 08 2a 86 48 ce 3d
00000030  03 01 07 a1 44 03 42 00  yy yy yy yy yy yy yy yy
00000040  yy yy yy yy yy yy yy yy  yy yy yy yy yy yy yy yy
00000050  yy yy yy yy yy yy yy yy  yy yy yy yy yy yy yy yy
00000060  yy yy yy yy yy yy yy yy  yy yy yy yy yy yy yy yy
00000070  yy yy yy yy yy yy yy yy  yy

Bref les parties fixes indiquent des infos comme la taille et le type de la clé.

cf http://blog.oddbit.com/2011/05/08/converting-openssh-public-keys/ et http://www.openssh.com/specs.html

Corrigé, merci.

Il fait référence à cela, observable ici avec 999 clés générées :

$ for i in $(seq -w 1 999) ; do ssh-keygen -t ecdsa -N "" -f $i ; done

Similitudes sur la première ligne :

$ grep -E "^MHcCAQEEI.{43}oAoGCCqGSM49$" ???|wc -l
996
$ grep -E "^MHYCAQEEH.{42}gCgYIKoZIzj0D$" ???|wc -l
3

Soit en hexadécimal :

00000000  30 77 02 01 01 04 20
ou
00000000  30 76 02 01 01 04 1f

Similitudes sur la seconde ligne :

$ grep -E "^AwEHoUQDQgAE" ???|wc -l
996
$ grep -E "^AQehRANCAA" ???|wc -l
3

Soit en hexadécimal :

00000020  xx xx xx xx xx xx xx a0  0a 06 08 2a 86 48 ce 3d
00000030  03 01 07 a1 44 03 42 00  04 xx xx xx xx xx xx xx
ou
00000020  xx xx xx xx xx xx a0 0a  06 08 2a 86 48 ce 3d 03
00000030  01 07 a1 44 03 42 00 04  xx xx xx xx xx xx xx xx

Analyse sur les 100.000 derniers commentaires sur les derniers contenus (tous confondus) :

• les scores réels vont de -75 à +75 (les bornés de -10 à +10 par construction).
• la médiane des scores réels est 1.
• la moyenne des scores réels est 1,77 et celle des scores bornés est 1,37.
• plus on descend en profondeur, plus la note moyenne des scores (réels ou bornés à [-10,10]) des commentaires baisse (lecteurs initiaux qui ne reviennent pas ensuite, lecteurs qui se lassent d'un débat sans fin, etc. -> moins de lecteurs, donc moins de notes, donc des scores plus faibles)
• au premier niveau, un commentaire noté négativement a plus de chances de donner des fils notés négativement (34% des commentaires à score strictement négatif donnent un fils à score strictement négatif ; contre 7% des commentaires à score positif ou nul).

J'imagine que ça dépend de ce que l'on considère comme un « film de samouraï » par exemple : le film américain Ghost Dog entre-t-il dans la catégorie ? (enfin germano-américano-franco-nippon d'après Wikipédia et IMDB).

Situation en France : « si vous continuez à percevoir des revenus de source française imposables en France » et « vous restez redevable des impôts locaux (taxe d'habitation, taxe foncière et, s'il y a lieu, taxe sur les locaux vacants ou taxe d'habitation sur les locaux vacants) relatifs aux biens immobiliers dont vous disposez ou que vous possédez (ces impôts sont gérés par les services des impôts du lieu de situation des immeubles) »

Aucun problème

Merci d'avoir complété.

Si le lecteur prend la peine de lire les commentaires précédents il n'y aura pas de redite quel que soit le tri. Je ne comprend pas la différence accordée au tri chronologique sur ce point.

Je supposais que le lecteur parcourait la page de haut en bas, et que l'ordre chronologique correspond alors à l'ordre d'affichage et à l'ordre de lecture du français. Maintenant, rien n'oblige le visiteur à faire cela (et la barre d'outils lui permet de se déplacer autrement par exemple). Je suis d'accord que la problématique est assez différente pour celui qui lit assidûment et pour le lecteur occasionnel ou arrivant après le débat.

Certes, mais on peut espérer qu'un commentaire pertinent engendre plus de commentaires pertinents qu'un commentaire inutile. Le tri par pertinence amène au moins cet avantage quand le tri chronologique repose sur ce point entièrement sur le hasard.

À mon avis, c'est quasi aussi aléatoire, mais c'est une estimation au doigt mouillé (un commentaire trollifère à -10 sur « c'est nul ……d » peut déboucher sur un long fil passionnant sur ses avantages et inconvénients, et un commentaire excellent à +10 peut tout aussi bien amener une polémique stérile). C'est une idée de stats intéressante en tout cas, mais c'est un autre sujet.

Ca me paraît être justement être le prolongement logique du système de pertinence, voire son essence même. Pourquoi laisser volontairement la pertinence moins accessible ?

Les arguments qui me viennent à l'esprit ne sont pas forcément fonctionnels : manque de codeurs, multiplication des options avec risque d'inutilité ensuite, autres priorités, etc. Bref plutôt de l'inertie que du choix. Perso je ne suis pas opposé à la mise en place d'un tri supplémentaire sur les commentaires (et je voulais laisser d'autres personnes s'exprimer sur le sujet).

Remplacé par un lien vers Github. Merci.

Alice et Bob ont chacun un compte sur LinuxFr.org. Alice veut envoyer "kikou LOL MDR!" à Bob. Alice utilise un zerobin-like (géré par LinuxFr.org ou ailleurs, on verra plus tard ça) et va obtenir une URL identifier#key correspondant à son message. Il suffirait maintenant que Bob ait cette URL, mais Alice ne sait pas comment lui transmettre. Si cette URL est connue des admins de LinuxFr.org, alors ils peuvent lire le message.

Dans un monde sans spam et sans relou', Bob publierait un moyen de contact (visible uniquement des comptes authentifiés au besoin) et Alice l'utiliserait (et le contenu ne passerait pas par LinuxFr.org).

Le certificat de securite ne t'assure en rien que les admins de LinuxFr ne lisent pas tes messages privees.

Il n'y a pas (plus) de messages privés sur le site web LinuxFr.org. Et une des raisons est qu'il est compliqué techniquement et pratiquement d'avoir une solution de messages privés chiffrés non accessibles aux admins (à l'ère post-Snowden, on voulait éviter ce point).

Qui suit un peut de ce côté si ça avance ? Est-ce qu'il y a une volonté de faire passer l'audit Mozilla ? De revenir dans Debian ?

Iang écrivait sur la liste cacert [traduit par mes soins] en mars dernier « L'audit est un boulot énorme. Cela requiert une réflexion stratégique à long terme et des quantités importantes d'effort. Cela nécessite plus ou loin l'attention de peut-être 50 à 100 volontaires sur des années. Là où nous en sommes, nous avons peut-être 20 à 30 volontaires, soit la moitié de ce dont nous aurions besoin. (…) Ceci, c'est pour un audit. Nous aurions besoin de 3 audits. Alors multipliez par trois ce qui précède. Et ça coûte, n'oubliez pas que ça coûte de l'argent. »

Il indique aussi que tout cela est tellement compliqué que les distributions ne comprennent pas forcément tout le processus, et qu'elles préfèrent se rabattre sur le travail des autres (par exemple celui qui est fait par Mozilla).

Il ne considère pas l'audit comme faisant partie d'une feuille de route plausible, parlant d'une somme nécessaire à 6 chiffres, du fait que Chrome est devenu le leader, etc. et recommande une approche plus sociale (installer la racine dans son navigateur). Il considère toujours CAcert comme protégeant mieux les utilisateurs que les autres processus.

Il est l'auteur d'un texte (que je n'ai pas lu) sur l'audit http://iang.org/papers/open_audit_lisa.html

Et d'après lui, oui il y a besoin de coups de main sur CaCert.

Sinon il continue à se passer des choses côté CaCert : il y a eu des modifications sur les politiques internes et aussi suite aux dernières failles de sécurité par exemple.

Avec Derrick.

Vouloir être « programmeur », c'est comme vouloir être « cuisinier », ça va du fast-food au gastronomique, de la cuisine moléculaire au slow-food, du sandwhich à la pièce montée, du traditionnel à l'exotique, etc. Il y a des bases communes (par exemple l'algorithmique pour la programmation) et ensuite des spécificités. Des envies particulières (faire du web ou du mobile, de l'intelligence artificielle ou des jeux, de la comptabilité ou de la gestion de cimetière, etc.), des besoins personnels (programmer sa calculatrice, son petit robot, son miniPC ou sa cafetière) ou des velléités de rejoindre un projet libre existant ?

• http://fr.wikiversity.org/wiki/Cat%C3%A9gorie:Programmation_informatique
• http://openclassrooms.com/courses?categories=informatique&tags=programmation (des cours sous CC By-NC-Sa apparemment)

La dépêche en question a été publiée : http://linuxfr.org/news/documentaire-les-gardiens-du-nouveau-monde-de-flo-laval

Oui, c'est ma solution préférée aussi (mais ça fait plus d'adminsys pour l'équipe de site). Bon ensuite les gens râleront quand même parce que n'importe quelle CA pourra toujours sortir un faux certificat, que DANE n'est pas utilisable réellement avec des navigateurs courants (pas sur Chrome, et sur Firefox uniquement avec plugin sauf erreur, et rien pour les autres) et que pas grand monde n'a encore accès au réseau de confiance OpenPGP comprenant les admins LinuxFr.org :).

Qu'aucune solution satisfaisante ne remplit les critères de tout le monde, alors chacun choisit son moins pire, suivant ses propres critères ? Ça peut être la simplicité (ce qui marche par défaut dans les navigateurs), la gratuité, l'indépendance, la sécurité, l'éthique, faire comme les autres, etc., sur toute la gamme allant du pragmatisme/court-termiste à l'idéalisme/utopisme.

Il parlait du "Fr" dans LinuxFr.org (et donc il voulait dire Fr. et pas .fr je présume).

Le Z80 est un processeur 8 bits conçu dans les années 70.

Et encore utilisé. Cf http://en.wikipedia.org/wiki/Zilog_Z80#Notable_uses ou cette dépêche sur les calculatrices scientifiques.

Corrigé, merci.

Contrairement à ceux qui voudraient une licence libre, ceux qui veulent du non-youtube non-MP4 n'auront aucun souci à publier un contenu CC By-NC-SA dans le format de leur choix et le moyen de leur choix, il ne tient qu'à eux de le faire (ou de voir avec l'auteur pour cela d'ailleurs).

C'est une demande qui a déjà été faite et invalidée.

Les tris, c'est comme les types de scrutin, y en a plein et on choisit son type pour avoir le résultat qu'on voulait.

Mettons de côté la question de la barre d'outils avec la possibilité de filtrer par note, de se déplacer dans tous les commentaires existants ou tous les nouveaux commentaires par ordre dans l'arbre chronologique. Ainsi que d'autres demandes du suivi concernant les commentaires (note de base, séparation des commentaires sur la forme, etc.).

L'arborescence amène :

• le fait que les questions sont avant les réponses et les citations arrivent après la première utilisation.
• les branches sont dépliables/repliables pour s'y déplacer rapidement par sujet
• un ordre constant au sein d'une branche

Quelques solutions de tris possibles (liste des avantages/inconvénients probablement non exhaustives) :

1) Tri actuel par arbre chronologique

|-A (noté 0)
| |-C (noté 1)
|
|-B (noté 5)
| |-D (noté 10)
| |-E (noté -10)
| |-F (noté -6)
|
|-G (noté 2)

Avantages/inconvénients:

• le tri est constant, ce qui était au début reste au début, etc.
• on évite les redites, si celui qui écrit G a pris la peine de lire les commentaires précédents

2) Tri à plat par note descendante

|-D (noté 10)
|-B (noté 5)
|-G (noté 2)
|-C (noté 1)
|-A (noté 0)
|-F (noté -6)
|-E (noté -10)

Avantages/inconvénients:

• on peut lire les plus pertinents, mais sans contexte
• à plat, en vrac, pénible à lire, désordonné
• le tri varie en fonction des pertinents/inutiles
• le risque de redites est important

3) Tri arborescent par note à la base de la branche

|-B (noté 5)
| |-D (noté 10)
| |-E (noté -10)
| |-F (noté -6)
|
|-G (noté 2)
|
|-A (noté 0)
| |-C (noté 1)

Avantages/inconvénients:

• rien ne dit que la note à la base donne le ton de toute la branche
• le tri varie en fonction des pertinents/inutiles
• le risque de redites est important

4) Tri arborescent par note moyenne de la branche

|-G (noté 2)
|
|-A (noté 0)
| |-C (noté 1)
|
|-B (noté 5)
| |-D (noté 10)
| |-E (noté -10)
| |-F (noté -6)
|

Avantages/inconvénients:

• rien ne dit que la note moyenne donne le ton de toute la branche
• le tri varie en fonction des pertinents/inutiles
• le risque de redites est important

5) Tri par nombre de réponses dans un fil

|-B (noté 5)
| |-D (noté 10)
| |-E (noté -10)
| |-F (noté -6)
|
|-A (noté 0)
| |-C (noté 1)
|
|-G (noté 2)

Avantages/inconvénients:

• rien ne dit que le nombre de commentaires donne le ton de toute la branche
• le tri varie en fonction des pertinents/inutiles
• le risque de redites est important

6) … (probablement plein d'autres possibilités)

Merci beaucoup. J'ai rédigé une dépêche pour l'annoncer.

Référence obligatoire : On the Internet, nobody knows you're a dog

Le tag systemd permet de les retrouver assez rapidement, mais j'ai ajouté le lien dans la dépêche néanmoins. Merci.