[Mixmaster-devel] mixmaster patches

[Trek <tre...@tr...>]

Hi,

i've made some little patch to mixmaster 2.9.1 to fix some bug, but i'm
not really familiar with the code, so i don't know if all it is ok.

I have to ask to the developers some question abuot my patches
(referenced with sourceforge number):

- 873497 prngpad
  In an old mail Disastry said that the usage of the random entropy pool
  to fill messages with garbage can be a problem, because if the entropy
  pool begin empty, the cryptographic functions may be slow down or more
  predictable.
  That patch use the RAND_pseudo_bytes() function to generate garbage in
  the body of type I messages, as well in the buf_pad() function for body
  and headers of type II messages.
  I'm not a cryptography expert, so i don't know if may be a problem to
  use pseudo random bytes in the mixmaster headers. I think that Ulf
  Möller can tell the correct thing. Probably the correct way is to
  use RAND_pseudo_bytes() only to fill message bodies.

- 873498 confirm
  This patch request a random confirm string to the email that should be
  blocked and will block the address only when it received the confirm.
  I don't know if the split of blockrequest() that i've made is correct.
  Also there is some code doubled in confirmrequest(): should i try to
  find a better way to parse a common type of request "COMMAND ARGUMENT"?
  Should i readd the domain blocking too?

- [not yet finished] bounce
  This patch should bounce a message when mixmaster can't add a new
  temporary file to the pool (ex. disk full, bug 628703). My problem is
  that i know if the message can be added in mix_pool(), before isnewid()
  was called, so if the message bounce it will be rejected when it will be
  resent. Should i split isnewid()? what is the preferred way to maintain
  the lock?
  This is only the start to fix the 703770 bug, because there are others
  possible point of failure when writing pool files. Someone have some
  idea about the way to correct this? I must find a way to be sure that a
  file can be copied/decripted to a new one before to unlink it.

I've made another patch (877312) for doallow() to check all the addresses
on the line that should be good and the mpgp man page (bug 585054) that
can contains many english typos.

If the coding style and comments are ok, i will do some minor fix and make
tests on these patchs to be sure that they not contains bugs. Also if some
patch should go in the 3.0 branch only i will adapt to it.

Thank for your time :-)

3		http://www.trek.eu.org/
k		PGPKey: 7016731A57D4A69B 1A8EE5E90EF2608E (since 1995)