Please Test Crypto++ 5.6.4 Release Candidate

[Jeffrey Walton]

Hi Everyone,

We are at the last step of 5.6.4 release. I've uploaded a Crypto++ 5.6.4 release page and linked to the release candidate. Please visit https://www.cryptopp.com/release564.html.

I verified the download, the hash and the build under Linux and Windows. We won't be repeating the 5.6.3 release issue.

If there are no issues, we will tag the release, update the home page, and make the announcement.

Jeff

[Jeffrey Walton]

We are at the last step of 5.6.4 release. I've uploaded a Crypto++ 5.6.4 release page and linked to the release candidate. Please visit https://www.cryptopp.com/release564.html.

Last call. If you have any concerns or objections, then please raise the.

Jeff

[Andrew Marlow]

Many thanks for releasing version 564. I see there are lots of improvements :-)

I had a go testing it on Solaris 11 with Sun Studio 12.4 in 64 bit and have to report a few problems:

1) There could be more info in the Readme.txt to explain how to build it on solaris.
2) I had to hack the makefile to remove use of the -pipe option, near where it says: Add -pipe for everything except ARM (allow ARM-64 because they seems to have > 1 GB of memory)
3) The test program core dumps when run with the v option.
Testing MessageDigest algorithm SHA-384.
..signal BUS (invalid address alignment) in CryptoPP::SHA512::Transform at line 27 in file "sha.cpp"
   27   #define blk0(i) (W[i] = data[i])
(dbx) print data
data = 0xffffffff7fffc1ec
(dbx) print i
dbx: "i" is not defined in the scope `cryptest.exe`sha.cpp`CryptoPP::SHA512::Transform(unsigned long long*,const unsigned long long*)`
dbx: see `help scope' for details
(dbx) where
=>[1] CryptoPP::SHA512::Transform(state = 0x1010f1980, data = 0xffffffff7fffc1ec) (optimized), at 0x1006041a8 (line ~27) in "sha.cpp"
  [2] CryptoPP::IteratedHashWithStaticTransform<unsigned long long,CryptoPP::EnumToType<CryptoPP::ByteOrder,1>,128U,64U,CryptoPP::SHA384,48U,false>::HashEndianCorrectedBlock(this = 0x1010f18d0, data = 0xffffffff7fffc1ec) (optimized), at 0x1004b30b8 (line ~89) in "iterhash.h"
  [3] CryptoPP::IteratedHashBase<unsigned long long,CryptoPP::HashTransformation>::HashMultipleBlocks(this = 0x1010f18d0, input = 0xffffffff7fffc1ec, length = <value unavailable>) (optimized), at 0x1005cff6c (line ~91) in "iterhash.cpp"

The compiler options that got used were:
 -DNDEBUG -g3 -xO2 -fPIC -m64 -native -KPIC -template=no%extdef -w -erroff=wvarhidemem -erroff=voidretw

-Andrew M.

[Andrew Marlow]

For the benefit of anyone picking up this thread I would like to point out that the problem was due to a compiler bug in the sun 12.4 compiler. On moving to version 565 of cryptopp and using the 12.5 compiler this problem went away.

[Jeffrey Walton]

On Wednesday, January 18, 2017 at 5:52:21 AM UTC-5, Andrew Marlow wrote:

For the benefit of anyone picking up this thread I would like to point out that the problem was due to a compiler bug in the sun 12.4 compiler. On moving to version 565 of cryptopp and using the 12.5 compiler this problem went away.

Here's a quote by Dr. Gutmann that always makes me laugh. He's talking about Cryptlib, which is his crypto library. It was one of the earliest free and open libraries (http://cryptlib.mbsks.franken.narkive.com/PCehp90Q/use-cc-instead-of-gcc#post2):

    There's a historic reason for cryptlib's attempt to use gcc if at all
    possible, which was that commercial vendors have traditionally shipped truly
    ghastly C compilers (or, in Sun's case, a non-C compiler that pretended to be
    a compiler so you had to use all sorts of trickery to determine whether there
    was a real compiler present or not).

 Jeff