Botched 5.6.3 Check-in

[Jeffrey Walton]

Hi Everyone,

I tested a check-out of 5.6.3 from version control. Its botched.

It looks like a drag/drop from a VMware guest to my OS X host got mangled. There are about six or eight problems like these:

    --- a/ecp.h
    +++ b/ecp.h
    @@ -143,6 +143,3 @@ private:
     NAMESPACE_END
 
     #endif
    -E_END
    -
    -#endif

And:

    --- a/seal.h
    +++ b/seal.h
    @@ -48,6 +48,3 @@ struct SEAL : public SEAL_Info<B>, public SymmetricCipherDocumentation
     NAMESPACE_END
 
    #endif
    -SPACE_END
    -
    -#endif

Notice the tail of the file has extra garbage.

This needs to be corrected before Monday morning. I think we have three options:

    (1) check-in the fix and call it 5.6.4
    (2) ckeck-in the fix and call it 5.6.3
         - re-tag check-in to CRYPTOPP_5_6_3
         - rebuild ZIP to ensure consistent sources
    (3) check-in the fix and do nothing

(3) is not a good option because it means folks who use CRYPTOPP_5_6_3 for their release engineering have a broken set of sources.

Are there any other options? How should we proceed with it?

Jeff

[David Irvine]

Ah typical, what a shame with all the effort and long days and nights you have spent here. 

Is it worth 

1. Check in a hard build error to 5,6,3 branch (pragma error) and re-tag that (with a commit to state it's a deprecated release)

2. Remove the build error and apply these fixes you have found

3. Build and tag 5.6.4 

4. remove 5.6.3 zip as deprecated

5. Release 5.6.4 zip with new hashes etc. 

A PITA but maybe this is a sledgehammer approach but beyond re-writing git history (very bad) then perhaps this strong-arm tactic will be best. Of course somebody may have a neater solution. 

a soon as I get a minute or if anyone has time and experience, setting up travis, appveyor and using the travis auto check for coverity then will be a great help at catching the small stuff like this. (travis will switch on clang/gcc and clang on osx if we ask nicely)

Thanks again Jeff,  really appreciate what you have achieved in the last few months, well worth it.

--

David Irvine

twitter: @metaquestions

blog:  http://metaquestions.me

[Jeffrey Walton]

Hi Everyone,

I talked with Wei about this. We basically took option (2) below. First we started with a fresh ZIP file. Next we reverted the bad check-ins from both Sourceforge and GitHub. We followed with a commit of the un-corrupted files. Finally, we tagged the commits as CRYPTOPP_5_6_3.

The commits are available at:

  * http://sourceforge.net/p/cryptopp/code/604
  * http://github.com/weidai11/cryptopp/commit/298988a5b9687f64de733ce01319e90e94b0b688

The new ZIP is available at http://cryptopp.com/cryptopp563.zip. Here are the new checksums:

 * SHA-1: f2fcd1fbf884bed70a69b565970ecd8b33a68cc4
 * SHA-256: 9390670a14170dd0f48a6b6b06f74269ef4b056d4718a1a329f6f6069dc957c9

My sincerest apologies for the confusion.

Jeff

[Mobile Mouse]

I think this is the right way to deal with the situation at hand.

Sent from my iPad

--
--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-user...@googlegroups.com.
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 cryptopp-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeffrey Walton]

On Sun, Nov 22, 2015 at 10:20 PM, Mobile Mouse <mous...@gmail.com> wrote:
> I think this is the right way to deal with the situation at hand.

Yeah, this was an uncomfortable spot.

The revert, clean commit and re-tagging was required to ensure users
experienced as little pain as possible. It also satisfies change
control systems, where folks may have to go back in time
deterministically. In one week or one year, it will still be correct.

I hope Wei dies not start questioning our abilities to self govern....
Sadly, it will be my fault if he takes it away from us. I hope it does
not come to that.

Jeff

[Jeffrey Walton]

Hi Everyone,

It looks like a drag/drop from a VMware guest to my OS X host got mangled. There are about six or eight problems like these:

    --- a/ecp.h
    +++ b/ecp.h
    @@ -143,6 +143,3 @@ private:
     NAMESPACE_END
 
     #endif
    -E_END
    -
    -#endif

...

I updated the testing and release process with a step to catch this sort of thing in the future: https://cryptopp.com/wiki/Release_Testing#The_Process .

Its probably going to be less of a problem in the future since there will be one version control system to manage, and not two of them. Two of them was the reason we effectively worked offline, and hand copied changes into both source control system.

Jeff