Am 31.08.2015 um 23:12 schrieb Jeffrey Walton: > Hi Everyone, > > Here's an update on Crypto++ 5.6.3 and 5.7/6.0. It's (finally) happening :) > > Crypto++ 5.6.3 is a minimal set of changes which attempts to honor > versioning requirements. The versioning requirements are tricky > because some of the Sanitizer and Valgrind findings that have been > remediated break versioning. I'm beginning to think we are going to > have to pick a poison... Our requirements are: Don't break anything, eliminate as much potentially bad code as possible and make sure it runs better everywhere. Am I seeing this right? > > Crypto++ 5.7/6.0 is a more complete set of changes. Its not clear what > the version number will be because we have to take it modulo > versioning requirements. Because 5.7 changes some publicly exported > symbols, I believe that effectively means it needs to be 6.0 (even > though it is, at its essence, a 5.7). > > The major version bump of Crypto++ 5.7/6.0 should probably include the > KeyDerivationParameters to avoid an immediate 7.0 bump. At the moment, > it does not. It definitely should. I'd also like to request a RNG interface reconsideration to enable full compatibility with the NIST DRBGs and Fortuna. Furthermore I think we need to design / derive a TweakableBlockTransformation class for Threefish for 6.0. This would allow us to push Skein, Threefish and Fortuna to 6.1. > > Looking to the future, once we get Crypto++ 6.0 + > KeyDerivationParameters in place, we should be OK with minor bumps > since its consistent with versioning requirements. For example, we can > add the NIST DRBG from SP800-108, and then change the version to 6.1. > Crypto++ 6.1 is fine because its compatible with 6.0 clients, and only > adds new features. Am I reading this right that a third minor version increase (-> 5.6.3) means we only apply security fixes. A minor version increase allows us to add new features but forces us to keep full compatibility? A major version increase allows us to break old things? > > Crypto++ 5.6.3 and 5.7/6.0 are testing OK on the major platforms. They > are undergoing tests on the lesser platforms and compilers, like ARM, > MIPS or OS X 10.5 with GCC 4.0. I know there's an outstanding issue on > ARMEL at the moment. Do we have a 5.6.3 and a 5.7/6.0 branch on GitHub for pre-rc testing? Did we actually test our code on any Big-Endian platform? > > As soon as we get the ARMEL issue resolved, I think we are going to > offer 5.6.3-rc0 and 6.0-rc0 for others to comment and test (or forever > hold their peace). There's been mixed feelings on release candidate > downloads. I think a good compromise is to keep them to a minimum > because they need retained for historical purposes. I think we can identify and fix most issues that are still present very well with a single RC. > The improved Download area of the website should facilitate retention > requirements. We could hide them somehow like "stables" and "stables + RCs" as view options. > > Jeff BR
JPM > -- > -- > You received this message because you are subscribed to the "Crypto++ > Users" Google Group. > To unsubscribe, send an email to > [email protected]. > More information about Crypto++ and this group is available at > http://www.cryptopp.com. > --- > You received this message because you are subscribed to the Google > Groups "Crypto++ Users" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
