Am 01.09.2015 um 00:03 schrieb Jeffrey Walton:
>
>
> On Monday, August 31, 2015 at 5:35:46 PM UTC-4, jean-pierre.muench wrote:
>
>     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 :)
>
>
> Oh man... I did not realize how much work release engineering was/is;
> and how much effort Wei had to put into it.
>
>>     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?
>
>
> Yeah, from 10,000 feet, that's about 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.
>
>
> I *think* we need a world-writable page somewhere to keep track of
> these things.
>
> How does the wiki sound?
I had a bit of spare time and set up the wiki-page "Roadmap":
https://cryptopp.com/wiki/Roadmap
Anyone should be able to edit this page.
I hope I added all the points into the right categories.

I've taken the freedom to add "EdDSA" to the list and "native EdDSA".
The first one is supposed to make use of Crypto++'s current ECC engine
and the second one would require manually adding the Curve25519 and
Ed25519 related functions.
Details on the how-to for the first one can be found here:
http://crypto.stackexchange.com/a/27847/23623.
>
>>     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?
>
>
> Yeah, so this is a grey/muddy area. We can say, "we will do X, Y and
> Z". That may be fine on Linux, but it might run afoul on Apple.
>
> What we are really trying to do is use a versioning scheme that is
> effectively the most restrictive with respect to operations and their
> intersection on Major-Minor-Revision. That means we will honor most
> platform's requirements.
>
> As an example, here is Apple's official docs on versioning:
> https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html.
>
>>     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?
>
>
> No, nothing tagged in Git. Related:
> https://github.com/weidai11/cryptopp/issues/18.
>
> We do have testing on a Big Endian machine. One of them is an Apple
> G5/OS X 10.5 PowerPC. The machine only exists for PowerPC testing and
> GCC 4.0.1 testing. Folks from OpenSSL and Cryptlib projects have
> access for similar testing.
>
> If you (or anyone else) wants access, then send over your
> SSH-{RSA|ECDSA|ed25519} key.
I may come back to this offer once I start testing my Threefish/Skein
code again for Crypto++ inclusion.
>
>>     The improved Download area of the website should facilitate
>>     retention requirements.
>
> I did not plan on being fancy :)
>
> Our requirements are simple: (1) users need a way to identify and
> download "current" (say 5.6.2 or 5.7), and (2) users need a way to
> identify and download "past" (like 4.0, 5.0, 5.1, or 5.6.1). To avoid
> confusion, "current" goes on the Home page and Download page; while
> "past" goes on the Download page only.
>
> Let me get something whipped up at
> https://www.cryptopp.com/index2.html so you can make concrete suggestions.
Is that the playground? :)

So I propose this:

 1. Get rid of every release note older than 5 years (= everything
    except 5.6.1 and 5.6.2 atm) as I hope our users will visit the page
    at least every 5 years.
 2. Make a page and link to it for older release notes
 3. Move everything but the most important downloads (5.6.3 / 5.7.0 /
    6.0) away from the main page into its own page
 4. Move the checksums away to their own page, except for the SHA-256s
    and SHA-1s of the most important downloads and link each download
    file (on the download page) to their set of checksums (on the
    checksum page, direct jump please)
 5. Change the "To Contribute" section to reflect the current situation
 6. Change the announce list (and maybe provide a link to some archive
    for the SF-announce one?)

That's all I see right now. I hope it's not too much :)

BR

JPM

>
> Jeff
>
> -- 
> -- 
> 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.

Reply via email to