gouttegd a écrit 1805 commentaires

Un Kobo Touch, version « by Fnac ».

Une liseuse électronique, c'est plusieurs mois d'autonomie en lisant pas mal.

Ça doit varier beaucoup d’un modèle à l’autre, alors, parce que la mienne, c’est trois à quatre semaines maximum.

Et ce qui est vraiment pénible, c’est que rien ne permet de prévoir que la batterie est presque complètement déchargée (le témoin de charge de la batterie n’est pas affiché en permanence, seulement à l’allumage). Résultat : tu es en train de lire, tu « tournes une page », et paf, « veuillez recharger votre appareil de lecture numérique ». Et pour couronner le tout, il n’est pas possible de continuer à lire pendant la charge, donc à ce moment-là tu n’as plus qu’à poser ta liseuse et ressortir un livre papier…

J'ai passé pas mal de temps à dessiner les premières de couverture et la carte avec Gimp, toutefois je ne suis pas du tout une professionnelle. J'espère qu'elles vous plaisent quand même !

La carte me plaît beaucoup. D’ailleurs, si elle a été faite avec Gimp, serait-il possible d’inclure le fichier .xcf dans l’archive des sources ?

(Edit pour qu’il n’y ait pas de malentendu : il ne faut surtout pas comprendre que seule la carte me plaît, c’est juste que je n’ai pas encore lu le texte.)

Mais si la connaissance de l'algo est indispensable pour le déchiffrement, ne serait-ce pas un bon moyen de protection finalement ?

Non. C’est de la sécurité par l’obscurité.

Un principe élémentaire de la cryptographie (le principe de Kerckoffs) est que la sécurité d’un procédé de chiffrement ne doit dépendre que de la clé. Le procédé en lui-même doit pouvoir tomber entre les mains de l’attaquant sans remettre en cause la confidentialité des communications tant que la clé, et seulement la clé, reste secrète.

C'est pas R le langage ou le runtime qui est rapide, ce sont les libs d'algèbre linéaire qu'il y a dessous (et je prends le pari que c'est du C).

Pas que, une partie au moins est en Fortran.

En bio-informatique par exemple, il est très courant d'employer des langages interprétés (principalement R et python) même pour les algorithmes critiques.

Je ne sais pas à quels « algorithmes critiques » tu penses, mais toutes les implémentations d’algorithmes d’alignement (BLAST, Clustal, Muscle, Needleman & Wunsch, etc.) que je connais sont en C ou en C++. La seule implémentation en Python de BLAST que j’ai vu était à but pédagogique uniquement.

Au passage, la version C++ du NCBI BLAST est beaucoup plus lente que la version C…

En déménageant on peut imaginer que tu acquières un droit sur une autre de ces identité « géolocalisée », tout en gardant pour une période limitée une redirection depuis l'ancienne

Je ne vois pas la différence par rapport à ce qu’on fait déjà aujourd’hui avec les adresses e-mail : tu changes d’employeur, tu changes d’adresse, avec une période de transition (quelques mois à un an) pendant laquelle les mails adressés à ton ancienne adresse sont redirigés vers la nouvelle. Ce n’est qu’une solution bancale pour pallier le fait que ces adresses dépendantes de l’employeur ne sont pas pérennes.

Le fait que je sois, à l’instant t, domicilié dans telle région, abonné à tel FAI, ou employé dans telle société ne fait pas, à mon sens, partie de mon « identité ».

Je me laisse même aller à imaginer qu'il serait possible pour une administration locale d'assigner un nom, local, à chaque personne, formant ainsi une «identité numérique» propre

Une « identité numérique » qui serait liée à la localisation géographique ? Genre je déménage de Rhône-Alpes en Aquitaine, mon identité numériqie change ? Ça ne m’intéresse pas, désolé. Je loue un nom de domaine sur lequel j’ai ma propre adresse e-mail précisément pour que mon « identité numérique » reste pérenne, peu importe que je change de région (voire de pays), d’employeur, ou de fournisseur d’accès.

En même temps j'ai jamais dit que je voulais être constructif. Je souhaitais juste vérifier si j'étais seul ou non …

Pour ça une simple recherche aurait suffi : premier résultat sur Google pour « gmic internal compiler error »…

C’est donc déjà corrigé dans gcc-4.8.3. En attendant, avec gcc-4.8.2, désactiver OpenMP (OPENMP_CFLAGS=) fonctionne chez moi.

Parce qu'il sont en train de casser GTK+, en le rendant GNOME ONLY…

Et c'est si grave que ça pour le reste du monde libre ?

Pour le reste du monde libre, je ne sais pas, mais pour les développeurs C souhaitant utiliser GTK+ sans pour autant vouloir lier leur application à GNOME, c’est rédhibitoire.

Pour rappel, GTK+ se présente toujours, officiellement, comme un « multi-platform toolkit for creating graphical user interfaces », sans aucune référence à GNOME.

Si GTK+ est en réalité une bibliothèque de GNOME, soit, mais alors qu’on le présente comme tel (« GTK+ is a GNOME-specific toolkit for creating graphical user interfaces tailored for the GNOME desktop ») et qu’on arrête de prétendre que c’est un toolkit générique.

Par contre, je ne connais pas le chiffrement par défaut (mais manifestement il peut être changé).

Par défaut c’est le même algorithme (peu sûr) que celui utilisé par PkZip. Il peut être changé pour Blowfish via l’option cryptmethod.

Sous Emacs, quand tu sauves un fichier avec l'extension .gpg il est chiffré.

Pour Vim, le plugin gnupg.vim offre une fonctionnalité similaire.

Maintenant les contributeurs sont censés dire merci pour avoir l'immense honneur de passer des heures à écrire des choses qui ne seront pas nonchalamment effacées par des mégalos en puissance qui se cachent derrière une montagne de procédures et règlements pour jouir du plaisir de faire chier les autres avec un pouvoir arbitraire.

For the record et pour ce que ça vaut, je tiens à signaler que ce ressenti, qui semble partagé par pas mal de témoins ici, ne correspond pas du tout à ma propre expérience de contributeur.

En fait, je n’ai jamais vraiment vu ni la communauté de contributeurs enthousiastes toujours prêts à s’entraider, ni la caste élitiste des « mégalos en puissance » et autres suppressionnistes que beaucoup décrient. Dans mon expérience la contribution à Wikipédia a presque toujours été un exercice solitaire, avec très peu d’interaction avec les autres contributeurs. C’est à la fois rassurant (personne ne rejette mes contributions) et un peu décevant (personne ne les améliore non plus).

Nan mais si je connais un mot en espéranto, que je connais sa prononciation, je sais l’écrire […]

Peux-tu donner un exemple de langue vivante, c'est à dire utilisée pour plus que du hobby?

Le turc ? La prononciation du turc ne cache aucun piège, chaque lettre a une prononciation et une seule, qui ne change jamais en fonction des lettres voisines (une seule exception, car même la règle disant qu’il n’y a pas d’exception doit bien admettre une exception : le « ğ », qui change très légèrement selon les lettres entre lesquelles il se trouve). Le turc se prononce comme il s’écrit, et s’écrit comme il se prononce.

Juste au cas où il s’agirait de vraies questions :

mais attends est-ce que la syntaxe crochet elle fonctionne avec /bin/sh?

À moins que sur ton système /bin/sh ne soit réellement le « vrai » shell Bourne d’origine (et non un lien vers Ash, Bash, Dash, etc.), oui. La « syntaxe crochet » est définie par POSIX, tous les shells un tant soit peu modernes la supportent.

Il n’y a guère que les plus barbus des développeurs GNU qui agissent encore comme s’ils s’attendaient à tout moment à tomber sur un système où le seul shell disponible est un Bourne shell antérieur à POSIX (et où le seul compilateur C disponible ne comprend que le C « K&R »). Un tel souci de la compatibilité est admirable, mais franchement en 2014 tu peux écrire un script shell sans te préocupper de le faire tourner sur une machine des années 1980…

il faut utiliser les accents grave, mais sauf que maintenant il faut utiliser $(), à moins que ça non plus ça ne marche pas sur tous les shells?

Encore une fois cette syntaxe est définie par POSIX, elle fonctionne sur tous les shells conformes à POSIX (attention, le « C shell » et ses dérivés ne sont pas des shells POSIX).

Et plus sur le sujet du journal :

enfin comme je le disais son problème de touches de luminosité me parait plus que douteux, systemd ne s’occupe pas de ça.

Ah bon ? Sur beaucoup de machines (toutes ?), les touches de luminosité sont gérées par ACPI (par production d’évènements video/brightness{up|down}). Comme systemd prend en charge lui-même certains évènements ACPI (au point de pouvoir, éventuellement, remplacer complètement acpid), une éventuelle interaction malencontreuse (aka « bug ») de systemd avec ces touches n’est pas complètement invraisemblable (pas suffisamment en tout cas pour balayer cette hypothèse comme émanant forcément d’un Lennart-hater…).

Et 0 personnes a témoigné d'une expérience positive.

Je n‘avais pas l’intention de témoigner, un peu par flemme et un peu parce que, précisément, je ne voulais donner l’impression de faire passer mon exemple pour une généralité. Mais puisqu’on me demande…

Contributeur épisodique, j’ai fait un peu de tout : j’ai « wikifié » quelques articles, j’ai ajouté des sources par-ci par là, j’ai ajouté des compléments à des articles pré-existants (toujours sourcés), j’ai aussi à quelques reprises presque complètement ré-écrit d’un bloc des articles que je jugeais trop mal partis pour pouvoir être amélioré de façon incrémentale. Jamais les hypothétiques « propriétaires de l’article » évoqués par ici ne me sont tombés dessus. J’ai aussi écrit un article de toute pièce, qui n’a jamais suscité la moindre réaction « suppressionniste ».

j’ai aussi ajouté quelques images et schémas sur Commons, qui y sont toujours et n’ont apparemment jamais dérangé personne.

Après, à quelques exceptions près je ne touche qu’aux sujets relevant de mon domaine de compétence (biologie) ; lorsque je touche au fond plutôt qu’à la forme j’ai toujours des sources ; et j’évite soigneusement tout sujet polémique. Ceci explique peut-être cela.

la conclusion de cette équipe est que le logarithme discret n'est plus une méthode considérée comme fiable pour de la cryptographie.

Ça c’est la conclusion du service des relations publiques du CNRS qui a pondu le communiqué de presse repris par Futura Sciences. La conclusion des auteurs du papier auquel il est fait référence pourrait bien être très différente et notamment bien plus modeste (je ne peux pas vérifier vu que le texte intégral est derrière un fucking paywall — mort à l’éditeur —, mais rien que l’abstract est déjà beaucoup plus mesuré que le communiqué de presse).

Ce ne serait pas la première fois qu’un marketeux s’emporte et fait dire à une étude beaucoup plus que ce que les auteurs ont réellement écrit.

je fais confiance au CNRS qui n'est pas réputé pour sa légèreté dans les publications.

Les chercheurs du CNRS, oui.¹ Mais le département PR ne vaut pas mieux que celui de n’importe quel organisme de recherche, et est aussi enclin que les autres à transformer une découverte banale en percée extraordinaire.

---

¹ Et je ne dis pas ça parce que j’en fais partie. ;)

Après lecture de la FAQ, deux choses me dérangent :

① Pas de PGP/MIME, on en est réduit aux messages « PGP inline » — pour un projet qui démarre en 2014, je trouve ça un peu fort, le RFC 3156 date de 2001 tout de même. Bon, ils disent « End-To-End does not currently support RFC 3156 », ça laisse un peu d’espoir qu’ils se mettent à la page plus tard…

② Génération de clefs à base de courbes elliptiques uniquement (et ça ils n’ont pas l’air de vouloir revenir dessus). Même si End-To-End permettra d’importer d’autres types de clefs, je crains que le fait qu’il ne génère que des clefs EC ne conduise à une utilisation massive de celles-ci (si End-To-End lui-même devient massivement utilisé, ce à quoi on peut s’attendre si Google le pousse sérieusement), ce qui est exactement ce que souhaite la NSA — dans l’intérêt de tout le monde… ou dans l’intérêt de la NSA ?

Traitez-moi de parano, mais je suis très suspicieux vis-à-vis des courbes elliptiques. Les inquiétudes de Bruce Schneier à leur sujet (voir ses commentaires par exemple ici ou là) n’améliorent rien, et voir un projet de Google promouvoir leur usage non plus.

Signer ses emails, ça suppose qu'on demande un effort supplémentaire à l'interlocuteur

Signer, non : ce n’est pas parce que tu signes tes mails que tes interlocuteurs sont tenus d’avoir ta clef publique et de vérifier systématiquement que la signature est bonne. Ils peuvent le faire (tout comme ils peuvent vérifier en recevant un courrier papier de ta part que la signature manuscrite ressemble bien à celle qu’ils connaissent), mais le simple fait que tu signes ne les contraint à rien.

Chiffrer, là d’accord. Mais si tu chiffres, c’est que de toute façon ton interlocuteur avait déjà fait l’effort nécessaire (sinon tu ne pourrais pas avoir sa clef publique), donc tu ne lui demandes rien non plus.

Selon le serveur mail que tu utilises, tu peux valider les certificats auto-signés si l’administrateur du serveur distant a publié ledit certificat dans le DNS via un enregistrement TLSA — et j’invite tous les utilisateurs de certificats auto-signés à le faire.

Postfix, au moins (et peut-être d’autres) permet une telle validation, qui peut être exigée (« dane-only », pas de connexion possible en l’absence d’enregistrements TLSA, ce qui est probablement exagéré pour l’instant) ou optionnelle (validation du certificat si des enregistrements TLSA existent, sinon comme avant on prend le risque d’accepter un certificat non-vérifié).

Je chiffre rarement mes messages, simplement parce que peu de mes contacts ont une paire de clefs.

En revanche, je signe systématiquement. Au fil du temps, c’est devenu aussi naturel pour moi que d’apposer une signature manuscrite au bas d’un courrier traditionnel, et je le fais d’ailleurs pour la même raison : pour affirmer que c’est bien moi qui a écrit le courrier et que j’en assume pleinement le contenu.

C’est un réflexe très pratique avant d’envoyer un message sur une liste de diffusion : il m’est déjà arrivé plusieurs fois de préparer un message inutile (réponse à un troll, message qui se résume à « moi aussi je pense pareil », etc.) et d’annuler son envoi au moment de le signer, parce que je réalise à cet instant que je ne veux pas assumer publiquement un message qui n’apporte rien à la discussion.

(Comment ça, je devrais faire pareil sur linuxfr.org ?)

Si la communication est protégé entre les deux serveurs auto-hébergés par TLS, l'adresse mail source et l'adresse mail destination ne sont pas récupérables.

Bof. Quiconque intercepte le traffic pourra tout de même savoir que tel serveur parle à tel serveur, et dans le cas de serveurs auto-hébergés (qui n’ont en général pas beaucoup d’utilisateurs à part l’auto-hébergeur lui-même), ça revient presque à savoir qui parle à qui.

Contre l’analyse de traffic, un serveur de GMail qui parle à un serveur de Yahoo est plus discret (sauf vis-à-vis de GMail et Yahoo, évidemment) que mon serveur qui parle à ton serveur.

Ou dit autrement, si mon correspondant est auto-hébergé et que je suis auto-hébergé avec nos deux serveurs d'emails bien configurés, on est bien dans une situation où l'auto-hébergement protège la vie privée non ?

Là d’accord. Mais tu choisis des prémisses plutôt favorables, quand même. ;)

Mon courrier est auto-hébergé, et d’autres auto-hébergés, je n’en connais pas des masses parmi mes correspondants. J’en connais un seul, en fait, et détail amusant, c’est aussi le seul que je connaisse qui utilise OpenPGP (ce qui n’est sûrement pas une coïncidence d’ailleurs…) — du coup, le fait que nous soyons tous deux auto-hébergés ne sert en fait à rien question protection de la vie privée, puisque nos messages sont chiffrés de bout en bout de toute façon.

le commentaire de gnumdk est-il pertinent ?

À mon sens, oui, même si je ne serais pas aussi catégorique. Les mails peuvent circuler en clair sur une partie du transit, et ce quoi que tu fasses, parce que tu n’es responsable que d’une partie de leur transit. Que le message ne circule jamais en clair sur tout son trajet dépend du bon vouloir de tous les acteurs impliqués dans son transport, pas seulement le tien.

(Tu peux configurer ton serveur pour rendre TLS obligatoire dans les connections de serveur à serveur, mais ça n’affectera que la portion du transit allant de ton serveur au serveur suivant — et tu risques de te couper de pas mal de monde, même si ironiquement, tu ne te couperas pas de tes correspondants utilisant GMail, parce que les serveurs de GMail supportent le TLS de serveur à serveur.)

Si les deux serveurs d'emails communiquent via TLS et que tu te connectes à ton webmail via https (ou un IMAP SSL/TLS), ce n'est pas chiffré de bout en bout ?

Pas de bout en bout, non. Dans le meilleurs des cas, si tu te connectes en à ton serveur d’envoi via TLS, que ledit serveur et le serveur de ton correspondant supportent tous deux TLS, et que ton correspondant se connecte à son serveur de réception via TLS, alors le message est chiffré sur chaque portion du trajet, mais il est toujours en clair sur les serveurs d’envoi et de réception. Ça protège le message contre la plupart des yeux indiscrets, sauf ceux des deux fournisseurs de service de messagerie impliqués (le tien et celui de ton correspondant) — ce qui est déjà mieux que rien, évidemment.

Pour du vrai chiffrement « de bout en bout », où même les intermédiaires chargés de transporter le message sont tenus à l’écart, il faut chiffrer le message lui-même (via S/MIME ou OpenPGP), et non le canal de communication.

le client se connecte à l'attaquant en pensant qu'il s'agit du serveur, et celui-ci lui fournit son propre certificat à la place de celui du serveur. Il s'agit là du scénario le plus classique de MiTM, qui est irréalisable avec une utilisation normale de TLS

Pas si irréalisable que ça, vu que le navigateur vérifie uniquement que le certificat présenté par le serveur est bien signé par une autorité de certification « de confiance ». Il suffit donc à l’attaquant d’obtenir un certificat signé par une des (centaines de) CA présentes dans le magasin des navigateurs.

qui nécessite soit la corruption d'une autorité de certification

Ou de s’adresser à une CA peu regardante…

Je croyais être tranquille pour Heartbleed avec une mise à jour de sécurité automatique quotidienne

Des mises à jour de sécurité, même automatiques et même quotidiennes, ne suffisent pas à « être tranquille ».

Heartbleed en est justement un bon exemple : la mise à jour du paquet libssl1.0.0 chez Debian se charge bien de redémarrer automatiquement les principaux services potentiellement concernés, mais ça s’arrête là. Il reste encore à l’administrateur à révoquer et remplacer les certificats dont les clefs privées ont potentiellement fuité — le genre de tâches qu’un gestionnaire de paquets ne peut pas faire à sa place.

Est-ce que cela est selon vous un problème de sécurité et que je devrais pousser pour qu'ils corrigent ?

Je ne vois aucun intérêt à empêcher l’exécution des scripts de /etc/cron.daily, et c’est certainement quelque chose qui devrait être corrigé d’après moi.

Mais ça ne pose pas pour autant de problème de sécurité. Ça empêche le déclenchement des mises à jour automatiques, d’accord, mais celles-ci ne sont de toute façon pas activées par défaut sous Debian et l’administrateur devra donc toujours faire quelque chose pour les activer (et j’ajouterai que les mises à jour automatiques ne sont pas une feature de sécurité).

Le plus gros problème que je vois, c’est que la rotation quotidienne des journaux ne se fera pas (c’est normalement piloté par le script /etc/cron.daily/logrotate). Si l’administrateur ne s’en aperçoit pas, tout semblera fonctionner correctement, jusqu’au jour où les journaux seront trop volumineux…