-----BEGIN PGP SIGNED MESSAGE-----
On 09/03/2010 08:16 PM, Stephen Gallagher wrote:
Patch 0001: Ack.
Patch 0002: Ack.
Patch 0003: Nack
>>> [PATCH 3/7] Password obfuscation utility functions
>> Your b64_encode function declaration is confusing. Please change the
>> variable name "obufsize" to make it clear that it is the size of the
>> input buffer to the function, not the output size.
You changed the wrong variable name. The ofbufsize argument is
describing the size of the input buffer, not the size of the output
buffer (which is allocated internally by BTOA_DataToAscii)
Ah, OK, I though you were referring to the buffer name as to indicate
whether the conversion is done in-place or not, I though that the size
variable was clear since its pass-by-value. Anyway, changed, hopefully
the declaration looks clear now.
>> We probably want to include a NULL byte (or some other,
>> terminator like "\0\1\2\3") at the end of the buffer that we can check
>> before blindly reading memory in. This way we can tell if we have a
>> corrupted or simply wrong obfuscated password.
A good start, but I think you missed the point a little bit.
I did :-)
I want us
to read up to ctsize, then test that the four bytes p+ctsize are the
This way if the buffer is corrupt or malicious (e.g. the ctsize ==
MAX_UINT16) we aren't suddenly allocating and copying 64MB of data.
Agreed, this is better, fixed now.
Patch 0004: Ack.
Patch 0005: Ack.
Patch 0006: Ack.
Patch 0007: Ack.
Almost there :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----