---------- Forwarded message ----------
From: Zooko Wilcox-OHearn
Date: Tue, Jul 22, 2014 at 12:23 PM
Subject: a catalog of bugs, or "Why to disable assembly optimization"
Folks:
We had already agreed to disable assembly optimizations in pycryptopp,
because there seem to have been a lot of bugs in the optimized
assembly code in the past, and because the added speed really makes no
difference to our uses, as far as I know.
However, in order to explain and justify to other people (e.g. Debian
packagers) why we are doing this, and why they should consider doing
the same thing themselves, I just read through the entire history of
issues in pycryptopp and classified whether they were runtime errors
(and therefore potential security bugs) or build-time errors
(therefore probably not), and whether they would have been avoided if
we had been disabling assembly optimizations all along. Here are the
results. They clearly show that we should disable the optimized
assembly! About half of all the security-threatening bugs we've had
would never have been an issue if we'd avoided assembly from the
beginning.
By the way, in my opinion the author of Crypto++, Wei Dai, is an
*exceptionally* skilled, careful, and experienced coder, and I would
assume that if Crypto++ has had this many security-threatening bugs in
its optimized assembly code, then other crypto libraries that also use
optimized assembly code also have at least as many.
Here's the ticket to track this issue:
https://tahoe-lafs.org/trac/pycryptopp/ticket/85
bugs that cause run-time failures
=================================
(These bugs are potential security issues.)
* would have been avoided by DISABLE_ASM:
- https://tahoe-lafs.org/trac/pycryptopp/ticket/24
- https://tahoe-lafs.org/trac/pycryptopp/ticket/31
- https://tahoe-lafs.org/trac/pycryptopp/ticket/45 (three
*different* bugs in the assembly implementation)
- https://tahoe-lafs.org/trac/pycryptopp/ticket/67
- https://tahoe-lafs.org/trac/pycryptopp/ticket/84
- https://tahoe-lafs.org/trac/pycryptopp/ticket/86
* unclear if it would have been avoided if we'd used DISABLE_ASM:
- https://tahoe-lafs.org/trac/pycryptopp/ticket/65
* would not have been avoided by DISABLE_ASM:
- https://tahoe-lafs.org/trac/pycryptopp/ticket/17
- https://tahoe-lafs.org/trac/pycryptopp/ticket/44
- https://tahoe-lafs.org/trac/pycryptopp/ticket/83
* would not have been avoided by DISABLE_ASM (but would have been
avoided by using cffi instead of CPython API)
- https://tahoe-lafs.org/trac/pycryptopp/ticket/19
- https://tahoe-lafs.org/trac/pycryptopp/ticket/70
- https://tahoe-lafs.org/trac/pycryptopp/ticket/80
* would have been avoided if we *didn't* use DISABLE_ASM! (A bug only
in the non-ASM version!)
- https://tahoe-lafs.org/trac/pycryptopp/ticket/66
bugs that cause deterministic build or compilation failures
===========================================================
(These bugs are *typically* not potential security issues but they can
be, and in any case they are engineering/deployment issues.)
* would have been avoided by DISABLE_ASM:
- https://tahoe-lafs.org/trac/pycryptopp/ticket/37
- https://tahoe-lafs.org/trac/pycryptopp/ticket/96
* would not have been avoided by DISABLE_ASM:
- https://tahoe-lafs.org/trac/pycryptopp/ticket/22
- https://tahoe-lafs.org/trac/pycryptopp/ticket/23
- https://tahoe-lafs.org/trac/pycryptopp/ticket/32
- https://tahoe-lafs.org/trac/pycryptopp/ticket/39
- https://tahoe-lafs.org/trac/pycryptopp/ticket/62
- https://tahoe-lafs.org/trac/pycryptopp/ticket/77
- https://tahoe-lafs.org/trac/pycryptopp/ticket/78
--
Regards,
Zooko Wilcox-O'Hearn
Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
