[cryptopp-users] When is the next version of cryptopp after 7.0 going to be released?

[Andrew Marlow]

Hello everyone and especially Jeff :-)

I wonder when the next version of cryptopp is going to be released.

The project I am on is using 563 and we need to change to avoid some CVEs
on that release. But I am reluctant to move to either 6.0 or 7.0 because of
a couple of things: first, Jeff reported that some solaris issues have been
sorted since then and the project I am on does run on solaris as well,
where we have seen some of these issues. Second, I would like to see
something done about zlib.h so that it does not clash with a header of the
same name from the zlib library. At the moment when any project using
crypto says #include <zlib.h> the reader cannot tell from this statement
which header the coder intended. I think that either the header should be
renamed or qualified by a subdirectory such as cryptopp so the code would
read #include <cryptopp/zlib.h>.

Regards,

Andrew Marlow
http://www.andrewpetermarlow.co.uk

[Jeffrey Walton]

Post by Andrew Marlow
Hello everyone and especially Jeff :-)
I wonder when the next version of cryptopp is going to be released.
The project I am on is using 563 and we need to change to avoid some CVEs
on that release. But I am reluctant to move to either 6.0 or 7.0 because of
a couple of things: first, Jeff reported that some solaris issues have been
sorted since then and the project I am on does run on solaris as well,
where we have seen some of these issues.

Yeah, in your case you want the non-buggy Solaris gear in Master.

Post by Andrew Marlow
Second, I would like to see something done about zlib.h so that it does
not clash with a header of the same name from the zlib library. At the
moment when any project using crypto says #include <zlib.h> the reader
cannot tell from this statement which header the coder intended. I think
that either the header should be renamed or qualified by a subdirectory
such as cryptopp so the code would read #include <cryptopp/zlib.h>.

We likely won't be changing header names. You will need to find a local
workaround.

We can probably release in a couple of days. We've added another 6 or 8
algorithms and fixed those Solaris bugs. Now would be a good time for a
point release to 7.1. The wrinkle is, the ABI broke when adding
AlgorithmProvider() so we need to bump to 8.0. For an 8.0 release I wanted
more in it. But like I said, we can release with less considering we've got
some [overdue] bug fixes you need.

Jeff

[Andrew Marlow]

Post by Jeffrey Walton

Post by Andrew Marlow
Hello everyone and especially Jeff :-)
I wonder when the next version of cryptopp is going to be released.
The project I am on is using 563 and we need to change to avoid some CVEs
on that release. But I am reluctant to move to either 6.0 or 7.0 because of
a couple of things: first, Jeff reported that some solaris issues have been
sorted since then and the project I am on does run on solaris as well,
where we have seen some of these issues.

Yeah, in your case you want the non-buggy Solaris gear in Master.

I'm looking forward to it.

Post by Jeffrey Walton

Post by Andrew Marlow
Second, I would like to see something done about zlib.h so that it does
not clash with a header of the same name from the zlib library. At the
moment when any project using crypto says #include <zlib.h> the reader
cannot tell from this statement which header the coder intended. I think
that either the header should be renamed or qualified by a subdirectory
such as cryptopp so the code would read #include <cryptopp/zlib.h>.

We likely won't be changing header names. You will need to find a local
workaround.

I do wish you would reconsider please. I am working on a project that uses
both zlib and cryptopp. There are two cpp source files that both contain
the line: #include <zlib.h>. The meaning of this line is different
depending on which file you are looking at. In one of them the meaning is
to include the zlib header. In the other the meaning is to include the
cryptopp header. I would the second one to say #include <cryptopp_zlib.h>,
which I think makes it very clear. Without this change I will have to patch
the source of cryptopp once I've downloaded it. It's not hard to do, I
admit. But my request is not do with me being saved from the effort. It is
to do with all projects that use this cryptopp header. The #include
statement required is misleading. It looks to the reader like the inclusion
is for the standard zlib.h header. It is especially confusing for those
projects that also need to include the real zlib header. And what if one
day a project comes along where a cpp file is required to include them both?

[Uri Blumenthal]

Andrew,

Could you explain why the standard approach like

#include <cryptopp/zlib.h>
#include <zlib.h>

did not work for you?

P.S. You are NOT supposed to add -I$prefix/include/cryptopp flag. If you do - please reconsider.

Sent from my test iPhone

Post by Andrew Marlow

Post by Jeffrey Walton

Post by Andrew Marlow
Hello everyone and especially Jeff :-)
I wonder when the next version of cryptopp is going to be released.
The project I am on is using 563 and we need to change to avoid some CVEs on that release. But I am reluctant to move to either 6.0 or 7.0 because of a couple of things: first, Jeff reported that some solaris issues have been sorted since then and the project I am on does run on solaris as well, where we have seen some of these issues.

Yeah, in your case you want the non-buggy Solaris gear in Master.

I'm looking forward to it.

Post by Jeffrey Walton

Post by Andrew Marlow
Second, I would like to see something done about zlib.h so that it does not clash with a header of the same name from the zlib library. At the moment when any project using crypto says #include <zlib.h> the reader cannot tell from this statement which header the coder intended. I think that either the header should be renamed or qualified by a subdirectory such as cryptopp so the code would read #include <cryptopp/zlib.h>.

We likely won't be changing header names. You will need to find a local workaround.

I do wish you would reconsider please. I am working on a project that uses both zlib and cryptopp. There are two cpp source files that both contain the line: #include <zlib.h>. The meaning of this line is different depending on which file you are looking at. In one of them the meaning is to include the zlib header. In the other the meaning is to include the cryptopp header. I would the second one to say #include <cryptopp_zlib.h>, which I think makes it very clear. Without this change I will have to patch the source of cryptopp once I've downloaded it. It's not hard to do, I admit. But my request is not do with me being saved from the effort. It is to do with all projects that use this cryptopp header. The #include statement required is misleading. It looks to the reader like the inclusion is for the standard zlib.h header. It is especially confusing for those projects that also need to include the real zlib header. And what if one day a project comes along where a cpp file is required to include them both?
--
You received this message because you are subscribed to "Crypto++ Users". More information about Crypto++ and this group is available at http://www.cryptopp.com and http://groups.google.com/forum/#!forum/cryptopp-users.
---
You received this message because you are subscribed to the Google Groups "Crypto++ Users" group.
For more options, visit https://groups.google.com/d/optout.