🚲 Tanguy Ortolo a écrit 12252 commentaires

Si tu en es à envisager de changer de matériel, profites-en pour vérifier avant la compatibilité. En matière de carte graphique, si tu veux éviter de te prendre la tête, le plus simple est de choisir de l'intégré Intel. En revanche, si ce que tu veux, ce sont des performances en matière de 3D par exemple, ce n'est pas un bon choix…

En fait, c'est proche des DRM, techniquement c'est à peu près la même chose mais pour du code exécutable au lieu de contenus culturels. Mais le terme exact, c'est informatique déloyale, également connu sous le terme de propagande « informatique de confiance », qui rappelle qu'il s'agit de contrôler quel logiciels peuvent ou ne peuvent pas être exécutés sur un ordinateur, le fournisseur du système en question ayant décidé à l'avance de ne pas faire confiance à l'utilisateur pour cela.

Ça, c'est le genre de domaine où il vaut mieux ne pas être meneur. Ni suiveur d'ailleurs, plutôt hors course.

À mon avis, ta prédiction est trop optimiste, j'ai peur qu'il se passe bien pire, à savoir : que Mozilla mette ça en place, et que ce soit finalement accepté sans faire trop de vagues. Ce serait bien pire, parce que ce serait un pas de plus, avec un effet cliquet si vous voulez, vers l'acceptation définitive de DRM applicatifs, considérés comme quelque chose de normal.

Je trouve déjà totalement flippant le seul fait qu'un acteur comme Mozilla envisage d'utiliser à son tour des DRM applicatifs, qui, à l'époque où on commençait à en parler, avec une technologie de Microsoft et d'Intel il me semble, nommée Palladium, avaient rencontrés une telle opposition que même une société comme Microsoft avait dû faire marche arrière dessus. Que de chemin parcouru depuis, pour qu'un acteur du libre puisse à son tour se lancer là-dedans, et que cette décision soit saluée comme un progrès ! On est à fond dans l'effet cliquet, ou la stratégie du pied dans la porte, peu importe comment on l'appelle, mais ça n'augure rien de bon.

Si Mozilla constate qu’ils se tirent une balle dans le pied, ils changeront d’avis.

Sauf que la simple concurrence ne suffit pas à pousser les acteurs à agir pour le bien de l'humanité, en tout cas pas dans un domaine aussi technique. Il faut une volonté particulière pour cela, et voir une organisation qui luttait dans ce sens se mettre à faire du DRM, c'est, comment dire, gerbant, en fait.

S'il s'agit de rendre impossible l'utilisation d'extensions non validées par Mozilla, sans possibilité pour l'utilisateur de désactiver cette restriction, il n'y a pas le moindre doute, c'est du DRM applicatif, ce que Microsoft avait tenté de faire avec Palladium avant de faire marche arrière, que TiVo avait mis en place pour la première fois, puis qu'Apple avait repris de façon massive dans leurs téléphones, avant que cette idée ne se répande un peu partout.

Maintenant, ce qui m'amuse, c'est que la possibilité de signer des extensions existe depuis des années avec les logiciels Mozilla, et que je n'ai jamais vu une extension signée jusqu'à présent, seulement des avertissements : cette extension n'est pas signée, voulez-vous l'installer ?

Comme l'immense majorité des plugins PGP pour navigateur Web, il ne prend en charge que le format obsolète de PGP en ligne, et pas le format actuel PGP/MIME.

Ça me rappelle qu'il y a quelques années, j'avais reçu un appel de Médiamétrie, qui proposaient de me rappeler pour une étude sur l'usage de la télévision. J'avais répondu que je n'avais pas de téléviseur, et que je ne regardais pas la télévision sur mon ordinateur : malgré ça, je les intéressais quand même, et on avait convenu d'une heure de rendez-vous pour répondre à cette étude. Sauf qu'à la date et à l'heure dite, j'avais bien fait en sorte de me libérer, mais ils ne m'ont jamais rappelé…

C'est donc presque trop beau pour être vrai et comme disait Virgile (qui n'était pas ivre) : "Timeo Danaos et dona ferentes".

Et tu écoutes des Romains sobres, sachant que par ailleurs in vino veritas ?

Il s'agit donc d'un logiciel qui fournit les fonctions suivantes, si j'ai bien compris :

• serveur de courrier (SMTP) ;
• serveur de boîte aux lettres (IMAP) ;
• serveur Web et Webmail ;
• serveur WebDAV ;
• serveur CardDAV.

C'est bien ça ?

Et ton numéro de carte bancaire.

Alors franchement va falloir que vous m'expliquez pourquoi vous, administrateurs réseau, utilisez encore cette vieillerie d'FTPS ?!

À mon avis, la raison principale en est que, comme comme SFTP a moins de trente ans, Microchiottes Windaube ne le prend pas en charge nativement, contrairement à FTPS.

Et c'est du JPEG… Pour quelqu'un qui fait des logos, évoquer un contexte différent de ce dont on parle (un prompt DOS pour une faille GNU) et en plus utiliser un format d'image inadapté, ça cumule…

/me court se cacher. Il faut dire que quand on a lu jusqu'au bout, on ne se souvient pas forcément du début. :-)

Ça c'est de la belle cryptanalyse, merci de l'avoir partagée, même si ça m'a fait perdre pas mal de temps ! Son auteur a-t-il contacté MISC ou un autre journal pour y rédiger un article ?

Sachant que la clef privée contient la clef publique, enfin, ce qu'on appelle clef privée avec GnuPG contient ce qu'on appelle clef publique, tu aurais pu exporter simplement ta clef privée, et repartir de là avec un .gnupg tout neuf.

Si tu repars sur une nouvelle clef, avant de la publier, assure-toi qu'elle est bien conforme aux recommandations actuelles (RSA 4096 bits). Et révoque l'ancienne.

Tu peux exporter ton ancienne clef (publique et privée) avec :

% gpg --export KEYID > KEYID.pub
% gpg --export-secret-keys KEYID > KEYID.sec

Ensuite, tu peux bazarder ton .gnupg (à ta place, je le déplacerais seulement), puis repartir proprement en important ces deux clefs.

% apt-cache show nodejs-legacy 
Package: nodejs-legacy
Source: nodejs
Version: 0.10.29~dfsg-1.1
Installed-Size: 101
Maintainer: Debian Javascript Maintainers <pkg-javascript-devel@lists.alioth.debian.org>
Architecture: all
Depends: nodejs (>= 0.6.19~dfsg1-3~)
Conflicts: node
Description-en: evented I/O for V8 javascript (legacy symlink)
 Node.js is a platform built on Chrome's JavaScript runtime for easily
 building fast, scalable network applications. Node.js uses an
 event-driven, non-blocking I/O model that makes it lightweight and
 efficient, perfect for data-intensive real-time applications that run
 across distributed devices.
 .
 This package contains a symlink for legacy Node.js code requiring
 binary to be /usr/bin/node (not /usr/bin/nodejs as provided in Debian).
 .
 No other Debian packages should depend on this package.  For more
 information, see
 <http://lists.debian.org/debian-devel-announce/2012/07/msg00002.html>
Description-md5: c72fe66177b6537572dbe9b186ed3611
Homepage: http://nodejs.org/
Section: web
Priority: extra
Filename: pool/main/n/nodejs/nodejs-legacy_0.10.29~dfsg-1.1_all.deb
Size: 80220
MD5sum: e24bd87bf4fdb50351fc3d45ee6513d2
SHA1: 13a4f1176c5dd68fcba446636179acf0fe52c2f5
SHA256: becae245cc8b8c7fc611d7af3a099ba6983eadc5f0c8f6473df613f669788e9a

En France, tu reçois un chèque, il te faut 15 jours pour être sûr d'avoir l'argent. S'il est refusé, c'est pour ta pomme. Alors les banques ont créés des chèques 'certifiés', pour combler et rassurer les banques.

Ce que tu appelles chèque certifié, c'est en fait un chèque de banque. C'est un chèque qui n'est pas émis par un client, mais pas sa banque. Par exemple, client à la BNP, si je demande un chèque de banque, la BNP va prélever le montant sur mon compte et faire elle-même un chèque (émetteur : la BNP elle-même). Ainsi, ce chèque est endossable par la banque du destinataire, indépendamment de l'état de mon compte, puisqu'il est tiré sur un compte de la BNP elle-même. Il n'y a ainsi plus de risque lié à l'individu qui a fourni ce chèque, mais seulement un risque lié à sa banque.

Or, on peut indiquer dans un entête HTTP (HTTP Public Key Pinning, épinglage de clé public HTTP) l’autorité de certification qui produit les certificats valides du site. Firefox prend désormais en compte cet entête pour empêcher la connexion s’il détecte un certificat non-conforme à ce qui est indiqué par l’entête. Voir le brouillon de la RFC de l'IETF pour les plus courageux.

Donc ils ont mis en œuvre un système d'épinglage de clefs qui est à l'état de brouillon. En revanche, le système plus général et plus sûr DANE, qui lui n'est pas à l'état de brouillon mais bien publié, toujours pas ?

Ça reste un effet de mode, vu que ça ne se faisait pas ou très peu il y a, disons, dix ans, et qu'il y avait déjà des associations.

Car, dans ce que j'imaginais, si un tel système (qui a l'avantage de réduire à presque zéro les fraudes) avait été poussé par les banques, un champs "référence" aurait été joint au virement contenant la référence qu'attendait le commerçant/créancier.

Bon, alors bienvenue dans le monde réel, parce qu'avec SEPA, les virement contiennent un champ référence. L'ennui c'est que toutes les banques ne permettent pas de le remplir, super non ?

Le problème d'un virement c'est que comptablement ça peut prendre une éternité à identifier et c'est pour ça que les fournisseurs n'aiment pas toujours. Savoir qui on prélève est facile, identifier quelle dette est sensée recouvrir un chèque ça peut être rapide (si le payeur joint le papillon de règlement pré découpé) mais identifier un virement apparaissant sur un compte bancaire peut tourner au cauchemar, voir être impossible.

Meuh non.

Savoir qui on prélève est facile

Oui, parce que le client a fourni ses coordonnées bancaires au fournisseur. Or, s'il veut payer par virement, ces mêmes coordonnées bancaires apparaîtront dans le virement, l'identification est donc triviale.

EDF ne permet pas de payer par virement justement, seulement prélèvement ou TIP à renvoyer par la poste à chaque fois (pour les particuliers et entreprises en tout cas)

En temps normal, non, mais si tu as une facture en retard, entre ne pas être payés et recevoir un virement, je pense qu'ils accepteront le second.

Après, comme je le disais, ce sont les fournisseurs sérieux qui acceptent les virements, et la plupart sont simplement des gignols, EDF compris visiblement, rien de nouveau donc.

D'ailleurs, comment fait-on, sans chèque, pour régler, disons, un médecin ? On lui remet une promesse formelle de virement ?

L'avantage avec un chèque, c'est que le créancier détient l'ordre, le chèque donc, et peut s'estimer raisonnablement satisfait dès qu'il l'a en main, alors qu'avec un virement, il ne peut que compter sur la parole de son client non ?