Issue 97: Continuous integration and testing

[Jeffrey Walton]

I know this comes up frequently, and its been a long time coming... I'd like to get a process in places that takes advantage of CI.

The GitHub/Travis-CI combination appears to have some gaps (https://github.com/travis-ci/travis-ci/issues/1724), so we have to be careful about what we do. I'm not trying to throw the baby out with the bath water, but we do need to ensure a Travis compromise does not lead to a Crypto++ compromise.

We are tracking things with "Issue 92: Continuous integration and testing", http://github.com/weidai11/cryptopp/issues/97.

[Jean-Pierre Münch]

Just a random idea of mine:

Can we mirror the repository (and maybe create a Crypto++ service GitHub user for that?) and allow Travis the access to said mirror?
Of course changes in the mirror should have no effect to the source...

BR

JPM

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

[Jean-Pierre Münch]

Am 30.12.2015 um 21:06 schrieb Jean-Pierre Münch:

Just a random idea of mine:

Can we mirror the repository (and maybe create a Crypto++ service GitHub user for that?) and allow Travis the access to said mirror?

From Github's ToS:

One person or legal entity may not maintain more than one free account.

So service accounts are not allowed :(

We could still mirror Crypto++ on our accounts though and allow Travis-CI access via this way.

[David Irvine]

I think that could work, perhaps also have the travis/appveyor badges point to the instance used by the mirror and then it is less obvious. 

Still it seems like a degree of obfuscation/indirection that is always a bit nervy. We can add the ability for the travis script to automatically run coverity scan as well. So may be worth the extra hassle. I am not sure how quick the mirror will update, but the nice thing of not doing that and being direct is that the PR's will tell us if the code at least passes the tests etc, before pushing. So again it is a bit more work to check the mirror instead of the PR itself. 

I suspect there are manual work-arounds to admin priv for travis but not push access. Both of which I suppose are dangerous, unless we create another server to check the build or even move to reproducible  builds (a lot of work). Debian / mozilla etc (Tor/bitcoin) have done work, but I am still not convinced this is foolproof either (https://wiki.debian.org/ReproducibleBuilds )

I suppose the scary part is travis and other CI privileges, at least though as it is git in the background there can be more checks made that could catch any injection etc. These could be prior to packaging but perhaps not as part of CI. 

Anyway sorry for the ramble, just some thoughts. 

--

David Irvine

twitter: @metaquestions

blog:  http://metaquestions.me

[jh...@emocha.com]

"one *FREE* account"

We could get a paid account. Also, I think bitbucket git accounts are cheaper than github. But at this point we would need donations... Perhaps we could have the service provider donate to the project for the exposure.