🚲 Tanguy Ortolo a écrit 12091 commentaires

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 ?

À noter que, si on parle surtout de fraude avec le prélèvement, le virement peut également être un moyen de fraude, combiné à l'ingénierie sociale. Deux exemples, ciblant plutôt les entreprises, mais avec lesquels des particulier peuvent tout à fait se faire avoir aussi :

• quelqu'un on envoie au comptable, le vendredi soir, une facture avec un IBAN, à payer pour hier, avec un nom et un logo de fournisseur probable, et parallèlement l'appelle en se faisant passer pour le président, expliquant qu'il a passé un achat vachement important, malheureusement hors des règles normalement appliquées dans l'entreprise, pour cause d'urgence : si le comptable paie, ce n'est évidemment pas un fournisseur légitime mais un voleur, qui reçoit le virement ;
• quelqu'un envoie au comptable une lettre aux couleurs d'un vrai fournisseur habituel de l'entreprise, expliquant qu'il a changé de banque et qu'il faut prendre en compte tel nouvel IBAN : si le comptable enregistre ce changement, la prochaine facture ne sera pas versée au fournisseur mais à un voleur…

Éludé seulement. Je ne suis volontairement pas rentré dans la gestion a posteriori des fraudes et des cas litigieux, mon avis étant qu'il est préférable de rendre la fraude impossible, plutôt que de réagir après qu'elle ait eu lieu.

(Comme avec les cartes de paiement sans contact en fait : ça permet un certain type de fraude, et même si les banques assurent qu'elles fournissent tout ce qu'il faut pour se faire rembourser en cas de problème, pas de fraude est à un avis préférable à une fraude qu'il faut détecter et demander à se faire rembourser.)

Ensuite, on aurait pu construire un système d'achat sur internet où le vendeur diffuserait ses coordonnées et les acheteurs feraient des virement sur ce compte.

Régler ses fournisseurs par virement ? Tous les fournisseurs sérieux proposent cela, l'ennui c'est qu'il y a plein de fournisseurs qui sont des guignols évidemment…

Après, pour les achats de détail, ce n'est pas pratique, mais pour des trucs comme les abonnements, je t'assure que si tu dois payer une facture à, disons, ton fournisseur d'électricité, et que tu lui propose de la régler par virement, il est très peu probable qu'il refuse, puisqu'il s'agit d'être payé. C'est comme quand on change de compte en banque, les fournisseurs ne font aucune difficulté à noter le changement puisque s'ils ne le font pas, ils ne seront plus payés !

Il y a aussi un autre truc rigolo, qui est la grande mode actuelle des associations qui demandent, non plus des dons ponctuels, mais des dons mensuels, par prélèvement. Là où c'est intéressant, c'est que ça donne un magnifique argument pour envoyer paître le démarcheur :

• D'accord, je veux bien donner 10 euros par mois, quel est votre identité bancaire ?
• Ah non, ça ne marche pas comme ça, il faut que vous signiez ce mandat de prélèvement.
• Désolé, je ne donne jamais de mandat de prélèvement pour un don mensuel fixe, mais je peux mettre en place un virement permanent.
• Ah non, on ne marche pas comme ça, c'est par prélèvement !
• Dommage, moi je veux bien donner mais de la façon qui me convient, ensuite si vous ne voulez pas de mon don, c'est votre problème. Au revoir Monsieur.

BNP Paribas :

• mode liste blanche.

Je commence un fil sur les moyens de contrôle des acceptation et des refus des prélèvements proposés par chaque banque.

CIC :

• mode liste noire ;
• mode liste blanche ;
• limitation du montant prélevable par créancier.

Sauf justement si votre banque propose un système de contrôle par liste blanche, auquel cas elle refusera tous les ordres de prélèvement émis par des créanciers non autorisés au préalable. Et si malgré ça elle en laisse passer sans autorisation, c'est assez pour aller faire un scandale, en agence et sur Internet, tant qu'à faire.

On est sur une question de terminologie là, sans intérêt pour le débat.

Je vais donc reformuler, en disant que pour moi, la laïcité à la française consiste en ce que les autorités religieuses n'ont pas de pouvoir politique, et que l'autorité civile de l'État n'a pas de pouvoir religieux.

Pourtant, les trois principales religions monothéistes s'accordent sur un grand principe qui devrait nous protéger de toutes ces conneries : c'est à Dieu qu'il appartient de juger les hommes.

Pas uniquement non, parce que cette seule affirmation impliquerait que les trois monothéismes en question soient opposées au principe de justice humaine, ce qui n'est à ma connaissance pas le cas.

C'est du lobbyisme si tu veux, mais je ne vois pas en quoi c'est un problème. Je ne connais aucun lobbyisme qui n'ait pas des opposants, et ce n'est pas une raison pour interdire les entreprises, les gays, les juifs, les libristes, les altermondialistes, les communistes, les syndicalistes et tous les groupes qu'on voudra d'agir en politique.

Non, la tu extrapoles mes propos. Tout ce que j'ai dit, c'est que les réactions apparemment favorables à cet attentat peuvent permettre à la police d'établir une liste de gens à surveiller. Après, je n'ai pas été plus précis, mais pour aller plus loin, j'ajouterai que je ne pense pas que les policiers soient idiots, et qu'en fonction du reste des écrits de chaque auteur, ils doivent pouvoir déterminer ceux qui sont des petits cons qu'ils serait contre-productif de surveiller, et qui sont de potentiels sympathisants avec les terroristes, qu'il faut vraiment surveiller. Et je parle de surveiller, pas d'arrêter, hein.

Ca m'étonne que tu dises ça, vu ce que la religion chrétienne essaye toujours de s'ingérer en politique en pesant de tout son poid sur des lois qui autorisent des choses qu'elle n'aime pas et que ça ne te dérange pas (voir tu soutiens / participe).

Ce n'est pas de l'ingérence ça, c'est de l'exercice de la liberté d'expression et de la démocratie… Enfin, tant qu'il n'y a pas quelque chose comme, par exemple, des évêques nommés d'office députés.