segfault in Ed25519 on Fedora+gcc-4.7.0-prerelease

[zooko]

​https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora%20syslib/builds/44

​https://tahoe-lafs.org/buildbot-pycryptopp/builders/Ruben%20Fedora%20syslib/builds/44/steps/test%20valgrind/logs/valgrind

valgrind reports the following before the segfault occurs:

==9709== Invalid read of size 1
==9709==    at 0xB4FEE70: crypto_hash_sha512 (sha512-hash.c:40)
==9709==    by 0xB4F8F23: crypto_sign_publickey (ed25519.c:30)
==9709==    by 0xB4F7EEB: ed25519_publickey (ed25519module.c:48)
==9709==    by 0x4F0A153: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==9709==    by 0x4F0B7C0: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==9709==    by 0x4E9C2BA: ??? (in /usr/lib64/libpython2.7.so.1.0)
==9709==    by 0x4E78A1D: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0)
==9709==    by 0x4E86EEF: ??? (in /usr/lib64/libpython2.7.so.1.0)
==9709==    by 0x4E78A1D: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0)
==9709==    by 0x4ECBC41: ??? (in /usr/lib64/libpython2.7.so.1.0)
==9709==    by 0x4ECB8DB: ??? (in /usr/lib64/libpython2.7.so.1.0)
==9709==    by 0x4E78A1D: PyObject_Call (in /usr/lib64/libpython2.7.so.1.0)
==9709==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9709== 

The first culprit I suspect is Fedora's pre-release of gcc 4.7.0, since this source passes tests (including valgrind clean) on several other platforms and since the underlying C code (i.e. ​sha512-hash.c) is used elsewhere, I think probably including in ​the nacl crypto lib from djb.

[zooko]

The version of g++ is reported by the show-tool-versions build step as 4.7.0 20120126 (Red Hat 4.7.0-0.10).

[zooko]

I opened a ticket on the gcc issue tracker: ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52236 and a ticket on the Fedora issue tracker: ​https://bugzilla.redhat.com/show_bug.cgi?id=790114

[zooko]

I opened a ticket on launchpad.net with which to track the progress of this issue across multiple other issue trackers: pycryptopp, GCC, Fedora, and possibly DJB's "nacl" crypto library if there is any way to track such issues other than emailing the author. ​https://bugs.launchpad.net/pycryptopp/+bug/931542

[zooko]

Thanks to Samuel Neves, we figured out that the bug is in our pycryptopp (and python-ed25519) glue code: ed25519module.c line 45​ uses type int to hold the size of something, but the module has declared PY_SSIZE_T_CLEAN which means it promises to only use size_t's to hold sizes of things.

[warner]

Ok, I've released python-ed25519 1.1 with the fix, and pushed that fix into pycryptopp in [1ae745ac/git]. Now watching the buildbot to confirm that it works (complicated by the ambient failures right now.. Zooko, you spotted this one, could you eyeball it and confirm?).

[zooko]

Yes, the fix is correct and it made the buildbots go from red to green, as far as I remember. I don't remember what the ambient failures were that Brian mentioned in comment:5. Thanks, Brian!