0
aMule est un client des réseaux pair à pair Kad/Overnet/eDonkey qui a la particularité d'être basé sur wxWidgets, donc multi plateformes (Unix, Mac et Windows), et d'avoir une architecture client/serveur lui permettant de tourner en temps que service d'arrière plan tout en ayant une interface utilisateur native du système ou bien une interface web, localement ou à distance.
Après un essoufflement dans le développement et deux ans de labeur depuis la version 2.1.3, la version 2.2.1 est finalement et officiellement sortie. Pour ceux qui se demandent ou est la 2.2.0, et bien vous n'êtes pas seul, tout le monde se le demande, et si jamais vous l'avez vue passer, faites signe à l'équipe de maintenance du projet.
Nous n'avons pas à faire à des travaux de fond qui ont été effectué lors de la migration complète vers wxWidgets il y a déjà quelques années, mais plutôt a une grosse version de maintenance, avec de nombreuses corrections de bugs, ajustement de fonctionnalités et compatibilité avec les protocoles.
Pour le plus important, on notera la gestion de Kad2, l'obscurcissement de protocole et l'UPnP.
![[en]](../images/en.png)
Annonce (Excusez moi, avez vous vu ma mise à jour 2.2.0 quelque part?) (893 hits)-
Liste complète des changements (673 hits)
-
Téléchargement (sources) (619 hits)
> Lire les commentaires (37 commentaires, moyenne: 5,4).
Vous avez demandé le commentaire #944485.
Run by 
Cette page a été générée par Templeet en 0.0679s (dont 0.0137 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Pas d'entropie en trop
Dans le ChangeLog, on appréciera le :
Patch for debian bug #350396: "amule depletes entropy pool".
À noter qu'aMule dépend maintenant de la bibliothèque crypto++.
[^]Re: Pas d'entropie en trop
Bas Zoetekouw a écrit un patch qui remplace CryptoPP::AutoSeededRandomPool par CryptoPP::AutoSeededX917RNG<CryptoPP::DES_EDE3>. Je n'ai pas bien compris quel était le problème : le bug parle de urandom, or urandom est non bloquant sous Linux !? Je ne comprend pas non plus les conséquences de ce changement (baisse de la sécurité ou non ?).
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350396
[^]Re: Pas d'entropie en trop
urandom est non bloquant mais il est lent et utilise (et réutilise) l'entropie du système. Ça peut être ennuyeux de se retrouver à court d'entropie pour d'autres applications.
L'auteur du patch écrit :
It seems the random number generator of libcrypto++ reads lots of bytes from /dev/urandom. I can't say that I understand how the donkey protocol works, but I doubt that's there any need for real strong encryption, and so rand() should do fine for random numbers.
En fait, urandom n'est même pas fait pour le chiffrement fort (voir la page de man). L'efficacité de /dev/random (en quantité) et /dev/urandom (en qualité) est toute relative. Le projet HLFS (Hardened Linux From Scratch) utilise d'ailleurs frandom et erandom :
http://billauer.co.il/frandom.html
Est-ce que le changement baisse la sécurité ?
X917RNG est de bonne qualité couplé avec du Triple DES. Malheureusement, le problème provient toujours de l'initialisation de l'algorithme. Si on n'utilise pas de source entropique, il peut être possible de prévoir la valeur du seed et donc de casser tout le système.
C'est ce qui s'est passé avec Netscape que David Wagner a cassé en 1995 :
http://www.cs.berkeley.edu/~daw/my-posts/netscape-cracked-0
Ici, il semble que AutoSeededX917RNG construit un seed à partir de rand(), qui n'est pas vraiment imprévisible...
Bref, l'entropie, c'est bon, mais je crois que décidément, ça ne plait pas aux debianistes.