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. On Wed, Dec 30, 2015 at 8:06 PM, Jean-Pierre Münch < [email protected]> wrote: > 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 > > > Am 30.12.2015 um 20:45 schrieb 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. > -- > -- > 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>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. > > > -- > -- > 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. > -- David Irvine twitter: @metaquestions blog: http://metaquestions.me -- -- 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.
