>>> I can't either, and yet I have multiple people reporting problems >>> with the 1.0.1e version saying the 1.0.1c version works without >>> problems. >> This happened recently on Fedora as well. >> >> See: >> https://bugzilla.redhat.com/show_bug.cgi?id=918981 > > I'm convinced that there still is a problem with the 1.0.1e > version and AES-NI, I just can't reproduce it, but there > seem to be plenty of people who can.
There are two AES-NI code paths: "plain" AES-NI and AES-NI+SHA1 stitch, e_aes_cbc_hmac_sha1.c. Vanilla 1.0.1e defaults to latter, so we assume it's the case. The decrypt code, specifically padding and MAC validation is all new in 1.0.1e and is all about record length. I've tried random strings of *all* lengths up to 1K with s_server/s_client with OPENSSL_ia32cap=0 on different sides. That is if there was some record length related bug it should have shown. I've tried to download Debian binary, but can't reproduce the problem. I've tried to download Fedora binary, but can't reproduce the problem. It might be appropriate for you, Kurt and Tomas, to prepare openssl binaries not compiled with shared support, i.e. not linked dynamically with lib[ssl|crypto], and attach them to bug reports for people to verify. I mean idea would be if application fails, user should attempt to reproduce the problem with s_client. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
