Benoît Sibaud a écrit 9306 commentaires

Ils ne sont pas forcément potes et n'iront pas boire des coups ensemble, mais ils ont réglé leur différend sans aller devant les tribunaux. Sauf erreur, « résolution à l'amiable » comprend ce cas.

Visiblement il s'agit d'un cas de double modération : j'ai essayé de rejetée une dépêche déjà rejetée par quelqu'un d'autre en parallèle, et ce cas n'est pas couvert.

Modification faite.

Merci de rester courtois dans les échanges, conformément aux règles de modération en vigueur sur le site.

Voilà, désolé d'être critique mais je trouve la news très approximative et mal rédigée…

Mais continuez quand même ! :-)

N'hésite pas à venir participer dans l'espace collaboratif de rédaction.

Alors qu'en Europe, quand t'as l'ABA, money money money.

Pour rester en HTTPS :

• soit HTTPS Everywhere cf https://www.eff.org/https-everywhere/atlas/domains/linuxfr.org.html
• soit se loguer en HTTPS et via un cookie cf https://linuxfr.org/aide#aide-cookies

Stats chez Debian : https://buildd.debian.org/stats/ (les deux images ci-dessous sont disponibles en meilleure résolution en cliquant dessus)

À comparer avec le Debian Popularity Contest :

Il ne reste plus qu'à faire une vraie version originale en quenya, sindarin, khuzdul, noir parler, adûnaic, westron, etc. en doublant les acteurs anglophones donc.

$ 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 :).