flan a écrit 1830 commentaires

Tu peux prouver une backdoor en expliquant comment s'en servir.

C'est faux de dire que tu peux vérifier une distro Linux. Tu peux en analyser quelques petits bouts de code, mais c'est tout. Faire croire le contraire est tout simplement faux (d'autant qu'entre le début et la fin de ta vérification, une bonne partie aura évolué et tu seras bon pour tout refaire).

Et pour la sécurité, non, ce n'est pas HS. Ce n'est pas en ayant le code source que tu vas pouvoir dire qu'une faille a été ajoutée intentionnellement (sauf si bien sûr dans le message de commit il y a « backdoor secrète ©2014, NSA »).

C'était du second degré, bien évidemment…

C'est pourtant simple : pour Windows, c'est à toi de montrer qu'il n'y a pas de backdoor. Pour Linux, c'est à toi de montrer qu'il y en a une. Et si on trouve une faille dans linux (ou une de ses composantes, genre openssl ou openssh), introduite plus ou moins récemment, jamais elle ne sera intentionnelle. Je ne vois pas ce qui te choque là-dedans.

Je suis tout à fait d'accord, c'est un peu le même problème que les GOTO : si c'est dans le langage, c'est qu'on peut les utiliser sans remord (mais ce n'est pas pour ça qu'il faut en mettre à toutes les sauces !).

J'ai une petite expérience en Python, et ça m'arrive régulièrement de reprendre (ou relire) du code externe.
Ça arrive d'avoir des syntaxes que je ne connaissais pas (par exemple [int(x) for x in [0, 2] if x != 1] ), mais je n'ai à peu près jamais eu de problème de compréhension.

Là, avec une expérience équivalente en C++, je pense que je serais totalement largué dans du code externe qui jongle avec un peu tous les nouveaux aspects du C++. C'est quand même un inconvénient.

Aucun pays n'autorise à tout dire, et surtout pas les secrets d'état. Et heureusement, d'ailleurs…
La liberté d'expression n'autorise pas tout et n'importe quoi.

Je suis assez d'accord. Au final, on obtient un langage qui sera maîtrisé par de moins en moins de monde.
Sur le fond, c'est cool d'avoir toutes ces fonctions, mais si c'est pour qu'il n'y ait que deux tondus et trois pelés qui sachent s'en servir, c'est bien dommage. J'attends beaucoup des nouvelles générations de langages (genre Rust), pour avoir quelque chose de relativement simple à apprendre tout en ayant les avantages du C++.

Tu déformes quand même beaucoup le contenu de l'article.

On passe de « certains matériels vendus à des personnes (morales ou non) bien particulières sont piégés » à « (tous) les routeurs Cisco embarquent un mouchard ».
Le premier ne me choque pas du tout sur le concept (ça n'a a priori rien d'une surveillance massive), alors que le deuxième est bien plus dérangeant.

Oui et non.
Oui, parce qu'en effet, tu peux demander à l'utilisateur d'entrer son mot de passe et le valider via un script (ou via PAM).

Non, parce que le but de Kerberos est (entre autres) de ne pas avoir à fournir de mot de passe en permanence (l'autre but étant que ton mot de passe ne circule pas — tu peux donc t'authentifier même sur un réseau en clair). L'idéal étant de ne pas en avoir du tout, par exemple avec un certificat + clef privée stockés sur une carte à puce qui te permettent d'obtenir un ticket Kerberos (sachant que la clef privée ne quitte à aucun moment la carte à puce), et à partir de là, tu t'authentifies sur tous les services de façon transparente.

J'avais regardé il y a quelques temps différents serveurs XMPP, et Prosody est apparu comme nettement au-dessus du lot. La doc est claire, il est facile à installer, il fait « propre », les erreurs sont claires et explicites, il y a beaucoup d'options et de possibilités. Rien à voir avec ejabberd.
Le seul reproche que je lui fais est l'absence de gestion de Kerberos pour l'authentification.

Évidemment, dans la mesure où SQLite est un fichier, on peut tout faire à base de fichiers. Mais s'il s'agit de rester simple, je pense qu'une base devient rapidement une meilleure solution. Après, effectivement, une solution à base de fichiers plats peut tout à fait être la meilleure solution. Simplement, j'aime bien titiller pour avoir tous les arguments et mieux connaître les avantages et inconvénients de chaque solution. En l'occurrence, je n'ai pas bien saisi les inconvénients de la version SQLite…

Je me suis d'ailleurs fait un wiki basé sur des fichiers plats, vu que ça me permettait de garder facilement le contenu wiki dans du SVN (et donc de faire facilement de l'édition sur mon ordi pour que ça soit répercuté sur le wiki). Bon, ok, maintenant je m'installerais tout bêtement un Gitlab et je passerais à git ^{^}

Ça doit venir de ma mauvaise expérience : à chaque fois, je me dis que je vais faire un petit truc tout simple avec peu de fonctions, et au final je rajoute les fonctions peu à peu. Par exemple, une base SQL permettrait de faire facilement une suppression de commentaires (spam…), compter le nombre de commentaires et d'articles, faire un flux RSS avec les commentaires et les articles, etc…
Faire du fichier te bloque pas mal à ce niveau-là, alors que faire du SQL ne te ferme pas de porte (même si c'est très légèrement plus lourd).

On parle de Python, donc on a sqlite embarqué par défaut (sauf si on a compilé Python bizarrement).

Autant je peux comprendre qu'on ne veuille pas de dépendances à compiler (comme le connecteur MySQL le plus classique), autant j'ai un peu plus de mal à comprendre l'intérêt de faire une croix sur les dépendances en Python pur par principe. Y a-t-il un vrai gain de perf au moins ?

Bin justement, j'ai lu beaucoup de choses sur les données stockées chez les entreprises, mais pas grand-chose sur les logiciels eux-mêmes.

À ce que j'ai compris, le bug en question ne concerne pas le S/MIME, mais plutôt le stockage en local qui est censé chiffrer toutes les données personnelles du téléphone (que le mail ait été envoyé en clair ou non). Les pièces jointes envoyées en S/MIME sont chiffrées (sinon, elles ne pourraient pas être décodées à l'arrivée, je crois). D'ailleurs, il y a de fortes chances que les mails envoyés en S/MIME soient stockés chiffrés (sinon, ça perd beaucoup de son intérêt).

Qu'on veuille un logiciel libre par principe comme PolePosition, ça, je peux le comprendre tout à fait.

En revanche, je n'ai vu aucune preuve comme quoi les mails chiffrés sur iOS était accessibles à « certaines agences gouvernementales ». Aurais-tu un lien précis, ou ne te bases-tu sur rien ?

Pourquoi faut-il un client libre pour chiffrer ? iOS supporte par défaut le chiffrement S/MIME sans aucun problème, il suffit d'avoir un certificat + clef (.p12) correct installé sur le téléphone.

Tu peux maintenant faire du noSQL, au moins avec LDAP, Neo4j et MongoDB.

L'ORM de Django s'est quand même beaucoup amélioré avec les dernières versions. Cela dit, je ne connais pas spécialement SQLAlchemy. Mais pour ma culture personnelle, qu'est-ce qui est possible sur SQLAlchemy et qui ne l'est pas avec Django ?

Est-ce vraiment si bien que ça de devoir choisir un ORM, un moteur de template, un système d'authentification, … ?

Je dois avoir une vision déformée par l'abus de Django, mais j'ai du mal à croire que ça soit si pratique que ça au quotidien.
Après, ok, on peut faire un site en un seul fichier, mais à nouveau, je ne suis pas convaincu de l'utilité. De toute façon, il faudra bien ajouter un ORM, des templates, une couche d'authentification, …

Quand je démarre un site Django, j'ai un générateur pour me faire la structure du code (avec la conf pour la base de données, le système d'authentification, …), et j'ai un truc immédiatement fonctionnel avec un découpage logique et surtout toujours standard, ce qui rend les choses bien plus faciles pour se plonger dans un code externe.

Windows Mobile n'a rien à voir avec Windows Phone (à part le nom).

Et même si une partie ne veut pas de Windows, elle est suffisamment faible pour que ça ne pose pas de problème. Seuls 5% ont OS X, et ça n'a pas empêché Apple de proposer une logithèque conséquente sur iOS.

Bah Canonical a quand même un OS qui n'est pas encore accessible au grand public à offrir, c'est tellement mieux qu'un OS qui a déjà un certain succès !

(certes bien moindre qu'iOS ou Android, mais il se défend pas trop mal quand même)

Oui, il y a de ça aussi, en effet.

Ça ne concerne pas rpm ou deb, ça.
La façon de noter les dépendances est identique dans les deux types de paquet (paquet, et critères sur la version).

C'est lié à yum, aptitude, apt, … D'ailleurs, apt et aptitude n'ont pas exactement la même méthode de gestion des dépendances, ce qui fait que certaines opérations sont faisables avec l'un mais pas avec l'autre quand il y a des soucis de dépendance.

Un .deb, c'est une archive .ar qui contient un .tar.gz pour les métadonnées (infos sur le paquet à installer sous forme texte, plus les scripts d'installation et suppression) et un .tar.gz qui contient l'arborescence complète des fichiers à écrire.

Un .rpm, c'est une archive .cpio qui contient (de mémoire) une archive pour les métadonnées (infos sur le paquet à installer sous forme XML, plus les scripts d'installation et de suppression), et un .tar.gz qui contient l'arborescence complète des fichiers à écrire.

Qu'est-ce qui fait la différence pour la difficulté à mettre à jour avec du .rpm ?