Changes between Initial Version and Version 1 of Ticket #85, comment 20
- Timestamp:
- 2014-07-22T19:22:46Z (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #85, comment 20
initial v1 3 3 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. 4 4 5 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 have also had at least as many.5 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 have also had at least as many. 6 6 7 7