From paul.l.kehrer at gmail.com Tue Oct 1 23:10:18 2013 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Tue, 1 Oct 2013 16:10:18 -0500 Subject: [Cryptography-dev] Message Digest Naming / PEP247 Message-ID: Hey guys, I'm implementing some basic hashes in cryptography (specifically the ones NIST has test vectors for: SHA-1 and SHA-2 family) and wanted to get some opinions on a few questions. 1) What would people like the module to be named? OpenSSL generally refers to them as "message digests" but pedantically they're cryptographic hash functions that output message digests. I currently have the module as cryptography.primitives.digests, but we could do cryptography.primitives.hashes, or some third option. 2) My current implementation complies with PEP247 with the exception of the new function. In its place you do something like this: from cryptography.primitives import digests digest = digests.SHA512() digest.update("text goes here") digest.update("more things to hash into the object state") digest.hexdigest() I'm leaning against implementing new since I don't really see much advantage, but this is your chance to tell me how wrong I am! -Paul From donald at stufft.io Tue Oct 1 23:16:03 2013 From: donald at stufft.io (Donald Stufft) Date: Tue, 1 Oct 2013 17:16:03 -0400 Subject: [Cryptography-dev] Message Digest Naming / PEP247 In-Reply-To: References: Message-ID: <15EEA4EE-E04D-45D6-9DC3-8843E813991B@stufft.io> On Oct 1, 2013, at 5:10 PM, Paul Kehrer wrote: > Hey guys, > > I'm implementing some basic hashes in cryptography (specifically the > ones NIST has test vectors for: SHA-1 and SHA-2 family) and wanted to > get some opinions on a few questions. > > 1) What would people like the module to be named? OpenSSL generally > refers to them as "message digests" but pedantically they're > cryptographic hash functions that output message digests. I currently > have the module as cryptography.primitives.digests, but we could do > cryptography.primitives.hashes, or some third option. I'd call the module hashes, it's the proper name for it and we should base our API on what's correct and not inherent OpenSSL's brokenness. > > 2) My current implementation complies with PEP247 with the exception > of the new function. In its place you do something like this: > > from cryptography.primitives import digests > digest = digests.SHA512() > digest.update("text goes here") > digest.update("more things to hash into the object state") > digest.hexdigest() > > I'm leaning against implementing new since I don't really see much > advantage, but this is your chance to tell me how wrong I am! Theoretical advantage is that you can swap it out with any other PEP247 compliant hash. However I think PEP247's new() function is particularly bad. It forces a module per hash layout which is pretty terrible. Additionally hashlib itself doesn't even support this, it has a new() function but it takes a string to do the lookup which I find A) pointless compared to getattr() and B) it's slower than just using the named constructors. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Wed Oct 2 20:35:32 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 2 Oct 2013 11:35:32 -0700 Subject: [Cryptography-dev] Disabling force push Message-ID: Hey all, I've been told that if you request it, you can get GitHub to disable force pushes on a repository. Is that a thing we want to do, it seems like it might be? Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarret.raim at RACKSPACE.COM Wed Oct 2 21:23:55 2013 From: jarret.raim at RACKSPACE.COM (Jarret Raim) Date: Wed, 2 Oct 2013 19:23:55 +0000 Subject: [Cryptography-dev] Disabling force push In-Reply-To: Message-ID: So things can only be merged through PRs? I'd be +1 on that. How do you do it? I'd like to turn it on for my other products :) Jarret Raim | Security Intrapreneur ------------------------------------------------------------- 5000 Walzem Road Office: 210.312.3121 San Antonio, TX 78218 Cellular: 210.437.1217 ------------------------------------------------------------- rackspace hosting | experience fanatical support From: Alex Gaynor > Reply-To: "cryptography-dev at python.org" > Date: Wednesday, October 2, 2013 1:35 PM To: "cryptography-dev at python.org" > Subject: [Cryptography-dev] Disabling force push Hey all, I've been told that if you request it, you can get GitHub to disable force pushes on a repository. Is that a thing we want to do, it seems like it might be? Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Wed Oct 2 21:57:05 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 2 Oct 2013 12:57:05 -0700 Subject: [Cryptography-dev] Disabling force push In-Reply-To: References: Message-ID: "Email support" is what I was told :) This doesn't prevent pushing directly to master from your machine. Alex On Wed, Oct 2, 2013 at 12:23 PM, Jarret Raim wrote: > So things can only be merged through PRs? I'd be +1 on that. > > How do you do it? I'd like to turn it on for my other products :) > > > > *Jarret Raim **| Security Intrapreneur* > > -------------------------------------------------------------**** > > 5000 Walzem Road Office: 210.312.3121**** > > San Antonio, TX 78218 Cellular: 210.437.1217**** > > -------------------------------------------------------------**** > > *rackspace hosting** **|** *experience fanatical support > > From: Alex Gaynor > Reply-To: "cryptography-dev at python.org" > Date: Wednesday, October 2, 2013 1:35 PM > To: "cryptography-dev at python.org" > Subject: [Cryptography-dev] Disabling force push > > Hey all, > > I've been told that if you request it, you can get GitHub to disable > force pushes on a repository. Is that a thing we want to do, it seems like > it might be? > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-paul at hybridcluster.com Thu Oct 3 13:25:04 2013 From: jean-paul at hybridcluster.com (Jean-Paul Calderone) Date: Thu, 03 Oct 2013 07:25:04 -0400 Subject: [Cryptography-dev] Disabling force push In-Reply-To: References: Message-ID: <524D5410.7030301@hybridcluster.com> On 10/02/2013 02:35 PM, Alex Gaynor wrote: > Hey all, > > I've been told that if you request it, you can get GitHub to disable > force pushes on a repository. Is that a thing we want to do, it seems > like it might be? > Is there some concern that one of the people with permission will do a bad force push over objections of other developers? Jean-Paul > Alex > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From alex.gaynor at gmail.com Thu Oct 3 16:20:38 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Thu, 3 Oct 2013 07:20:38 -0700 Subject: [Cryptography-dev] Disabling force push In-Reply-To: <524D5410.7030301@hybridcluster.com> References: <524D5410.7030301@hybridcluster.com> Message-ID: Amongst things I'm concerned about, that's *incredibly* low, accidental force pushes rank far above it in terms of things I'm worried about. Which basically gives us a question of: do they have utility, and if so is that utility greater than the chance they'll be used accidentally and the negative effects thereof. Alex On Thu, Oct 3, 2013 at 4:25 AM, Jean-Paul Calderone < jean-paul at hybridcluster.com> wrote: > On 10/02/2013 02:35 PM, Alex Gaynor wrote: > > Hey all, > > I've been told that if you request it, you can get GitHub to disable > force pushes on a repository. Is that a thing we want to do, it seems like > it might be? > > Is there some concern that one of the people with permission will do a > bad force push over objections of other developers? > > Jean-Paul > > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > > > _______________________________________________ > Cryptography-dev mailing listCryptography-dev at python.orghttps://mail.python.org/mailman/listinfo/cryptography-dev > > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Sat Oct 5 06:02:28 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Fri, 4 Oct 2013 21:02:28 -0700 Subject: [Cryptography-dev] Moving to an org Message-ID: Hi all, A while ago we discussed moving the repo off my account name, and into a seperate org. We've gone ahead and done that, Donald set up a new pyca (Python Cryptographic Authority) org, the name suggested by Hynek, and endorsed by a few people, in the same vein as PyPA (The Python Packaging Authority). Besides needing to repoint your repos, nothing should change. The pyca org also owns a few other repos: a bcrypt impl, pynacl, and ed25519 (an optimized version of DJB's reference implementation, properly packaged). Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Sat Oct 5 06:04:28 2013 From: donald at stufft.io (Donald Stufft) Date: Sat, 5 Oct 2013 00:04:28 -0400 Subject: [Cryptography-dev] Moving to an org In-Reply-To: References: Message-ID: If you want your membership to be public you need to publicize it on https://github.com/pyca?tab=members On Oct 5, 2013, at 12:02 AM, Alex Gaynor wrote: > Hi all, > > A while ago we discussed moving the repo off my account name, and into a seperate org. We've gone ahead and done that, Donald set up a new pyca (Python Cryptographic Authority) org, the name suggested by Hynek, and endorsed by a few people, in the same vein as PyPA (The Python Packaging Authority). > > Besides needing to repoint your repos, nothing should change. > > The pyca org also owns a few other repos: a bcrypt impl, pynacl, and ed25519 (an optimized version of DJB's reference implementation, properly packaged). > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From donald at stufft.io Mon Oct 7 22:41:53 2013 From: donald at stufft.io (Donald Stufft) Date: Mon, 7 Oct 2013 16:41:53 -0400 Subject: [Cryptography-dev] Bundling OpenSSL Message-ID: <2DA9C58A-3214-47F2-8902-1B3225C0B6C9@stufft.io> Something that's come up in the terms of Camella, but is going to keep coming up, is that sometimes the OpenSSL on a system is really old (OSX), or neutered (RHEL), or non existent (Windows). In these cases it would be useful to bundle a copy of OpenSSL with cryptography in order to be assured we have a minimal and consistent base to work off of. Bundling does not mean we must always use it, in PyNaCl I've worked my setup.py so that it will detect if it's backing library is available on the system and if the system version is new enough for what I require. There is also the ability to force it to either use or not use the bundled library. Questions: 1 Do we want to bundle a backing library to ensure that there is always a minimal level of support? 2 Do we want to bundle OpenSSL or is there another backing library that we'd want to bundle? (Easier to build, more portable etc?) ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From zooko at leastauthority.com Mon Oct 7 23:56:08 2013 From: zooko at leastauthority.com (Zooko Wilcox-OHearn) Date: Mon, 7 Oct 2013 21:56:08 +0000 Subject: [Cryptography-dev] Bundling OpenSSL Message-ID: [in response to https://mail.python.org/pipermail/cryptography-dev/2013-October/000091.html ] > 1 Do we want to bundle a backing library to ensure that there is always a minimal level of support? We've found it necessary to do this in pycryptopp, even though it means we support both the bundled and non-bundled builds. > 2 Do we want to bundle OpenSSL or is there another backing library that we'd want to bundle? (Easier to build, more portable etc?) I personally wouldn't recommend OpenSSL, because its source code is a mess and it has a bad reputation among cryptographers who've looked at it (by which I mean Matt Green). When we faced this decision in 1999, and then when we faced it again in 2006, we chose, both times, Crypto++. This has worked out acceptably well for us, and I'm not eager to move pycryptopp from Crypto++ to anything else, since the current thing is working, and changing it would be a pain, and would introduce risk of bugs/vulns/regressions. I would love to share code, and hard-earned experience, and mutual support between the pyca and pycryptopp projects! So please feel free to copy what we do. If I were starting over again today I would probably choose Botan over Crypto++, because Botan is more actively developed nowadays, and because its primary author and maintainer has provided some Python wrappers. If you are going to go with OpenSSL, you should of course try to benefit from the work that has gone into pyOpenSSL. That includes some work for bundling a copy of the OpenSSL libs into the resulting pyOpenSSL distributions. Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters. From donald at stufft.io Tue Oct 8 00:21:52 2013 From: donald at stufft.io (Donald Stufft) Date: Mon, 7 Oct 2013 18:21:52 -0400 Subject: [Cryptography-dev] Bundling OpenSSL In-Reply-To: References: Message-ID: On Oct 7, 2013, at 5:56 PM, Zooko Wilcox-OHearn wrote: > [in response to > https://mail.python.org/pipermail/cryptography-dev/2013-October/000091.html > ] > >> 1 Do we want to bundle a backing library to ensure that there is always a minimal level of support? > > We've found it necessary to do this in pycryptopp, even though it > means we support both the bundled and non-bundled builds. > >> 2 Do we want to bundle OpenSSL or is there another backing library that we'd want to bundle? (Easier to build, more portable etc?) > > I personally wouldn't recommend OpenSSL, because its source code is a > mess and it has a bad reputation among cryptographers who've looked at > it (by which I mean Matt Green). We'll support being backed by OpenSSL either way, exarkun wants to use our bindings to power that. This library is going to support multiple backing libs so someone could choose to use Crypto++ over OpenSSL if they desired. The question I guess becomes what features do we consider a minimum as that will drive a lot of the decision making as to what library (if any) we bundle as the "well we'll know for sure we have this available". > > When we faced this decision in 1999, and then when we faced it again > in 2006, we chose, both times, Crypto++. This has worked out > acceptably well for us, and I'm not eager to move pycryptopp from > Crypto++ to anything else, since the current thing is working, and > changing it would be a pain, and would introduce risk of > bugs/vulns/regressions. > > I would love to share code, and hard-earned experience, and mutual > support between the pyca and pycryptopp projects! So please feel free > to copy what we do. > > If I were starting over again today I would probably choose Botan over > Crypto++, because Botan is more actively developed nowadays, and > because its primary author and maintainer has provided some Python > wrappers. > > If you are going to go with OpenSSL, you should of course try to > benefit from the work that has gone into pyOpenSSL. That includes some > work for bundling a copy of the OpenSSL libs into the resulting > pyOpenSSL distributions. > > Regards, > > Zooko Wilcox-O'Hearn > > Founder, CEO, and Customer Support Rep > https://LeastAuthority.com > Freedom matters. > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From christian at python.org Tue Oct 8 00:28:46 2013 From: christian at python.org (Christian Heimes) Date: Tue, 08 Oct 2013 00:28:46 +0200 Subject: [Cryptography-dev] Bundling OpenSSL In-Reply-To: References: Message-ID: <5253359E.6040807@python.org> Am 07.10.2013 23:56, schrieb Zooko Wilcox-OHearn: > I personally wouldn't recommend OpenSSL, because its source code is > a mess and it has a bad reputation among cryptographers who've > looked at it (by which I mean Matt Green). Everybody who had laid eyes on the source code of OpenSSL shares Matt's opinion. I also share the same opinion. It's aweful, bad and hard to use. But Matt Green also says that OpenSSL is probably the best library for SSL because it is widely used and supported by lots and lots of people. GnuTLS and NSS are not used as much as OpenSSL. Watch this: http://www.youtube.com/watch?v=uP6np_oKVCk :) Christian From paul.l.kehrer at gmail.com Tue Oct 8 15:17:41 2013 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Tue, 8 Oct 2013 08:17:41 -0500 Subject: [Cryptography-dev] Bundling OpenSSL In-Reply-To: References: Message-ID: On Mon, Oct 7, 2013 at 5:21 PM, Donald Stufft wrote: > > We'll support being backed by OpenSSL either way, exarkun wants to use > our bindings to power that. This library is going to support multiple > backing libs so someone could choose to use Crypto++ over OpenSSL > if they desired. > > The question I guess becomes what features do we consider a minimum > as that will drive a lot of the decision making as to what library (if any) we > bundle as the "well we'll know for sure we have this available". > Agreed. I'm not sure how we arrive at this list though. My one hard requirement would be that an AEAD mode should be available to every user of cryptography. We can't get that without bundling something. From donald at stufft.io Sun Oct 20 02:26:52 2013 From: donald at stufft.io (Donald Stufft) Date: Sat, 19 Oct 2013 20:26:52 -0400 Subject: [Cryptography-dev] Bundling OpenSSL Message-ID: <4BF2F1FC-5C9D-49EA-9EFA-2D25C8333EEF@stufft.io> I've started working on bundling OpenSSL within cryptography and fixing the packaging up. There are a number of things I'd like to do that will make things smoother in the long run but require some changes right now. These things are: Disable implicit compile - This masks problems with the packaging. I tried leaving it on when doing the same thing for PyNaCl and it caused immense frustration with strange edge cases breaking. Further more the cffi devs say they are planning on removing it anyways. Move the cryptography directory into a src directory - Since cryptography will require an implicit compile step with the above, it's easy to accidentally import the cryptography that is sitting on the file system that hasn't been compiled yet, moving it means you have to install cryptography somehow to import it (or cd into the src directory). This should lower confusing errors when ``python -c 'import cryptography'`` does work. Further since we'll need a folder for the OpenSSL code it makes sense I think to have a single folder for all the things we have in repo, see: https://github.com/pyca/pynacl/tree/master/src Lazily load the compiled library - Right now the compiled library is loaded when the cryptography.bindings.openssl.api library is imported, this is the way CFFI currently works. As i've done in PyNaCl i'd like to make the Api object lazy so that it loads the compiled library on first access and proxies the calls to the exposed functions/variables to the lazily loaded underlying library object. You can see this at: https://github.com/pyca/pynacl/blob/master/src/nacl/_lib/__init__.py#L59-L84 The final solution to this would be that we have a library that is always built at build time with a consistent version of OpenSSL. Thoughts on these steps? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From donald at stufft.io Sun Oct 20 02:29:50 2013 From: donald at stufft.io (Donald Stufft) Date: Sat, 19 Oct 2013 20:29:50 -0400 Subject: [Cryptography-dev] Bundling OpenSSL In-Reply-To: <4BF2F1FC-5C9D-49EA-9EFA-2D25C8333EEF@stufft.io> References: <4BF2F1FC-5C9D-49EA-9EFA-2D25C8333EEF@stufft.io> Message-ID: <21EA18CF-ED85-42B8-AB0B-DA98F46FE876@stufft.io> Just to be clear, the way bundling will work is utilizing distutils ability to call build_clib (builds c library) before it calls build_ext (builds the actual cffi extension). build_clib will end up with a static library that build_ext will compile against statically. The .a will be discarded when the build directory is cleaned up. On Oct 19, 2013, at 8:26 PM, Donald Stufft wrote: > I've started working on bundling OpenSSL within cryptography and fixing the packaging up. > > There are a number of things I'd like to do that will make things smoother in the long run but require some changes right now. These things are: > > Disable implicit compile > - This masks problems with the packaging. I tried leaving it on when doing the same thing for PyNaCl and it caused immense frustration with strange edge cases breaking. Further more the cffi devs say they are planning on removing it anyways. > > Move the cryptography directory into a src directory > - Since cryptography will require an implicit compile step with the above, it's easy to accidentally import the cryptography that is sitting on the file system that hasn't been compiled yet, moving it means you have to install cryptography somehow to import it (or cd into the src directory). This should lower confusing errors when ``python -c 'import cryptography'`` does work. Further since we'll need a folder for the OpenSSL code it makes sense I think to have a single folder for all the things we have in repo, see: https://github.com/pyca/pynacl/tree/master/src > > > Lazily load the compiled library > - Right now the compiled library is loaded when the cryptography.bindings.openssl.api library is imported, this is the way CFFI currently works. As i've done in PyNaCl i'd like to make the Api object lazy so that it loads the compiled library on first access and proxies the calls to the exposed functions/variables to the lazily loaded underlying library object. You can see this at: https://github.com/pyca/pynacl/blob/master/src/nacl/_lib/__init__.py#L59-L84 > > The final solution to this would be that we have a library that is always built at build time with a consistent version of OpenSSL. > > Thoughts on these steps? > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jean-paul at hybridcluster.com Sun Oct 20 15:44:09 2013 From: jean-paul at hybridcluster.com (Jean-Paul Calderone) Date: Sun, 20 Oct 2013 09:44:09 -0400 Subject: [Cryptography-dev] Bundling OpenSSL In-Reply-To: <4BF2F1FC-5C9D-49EA-9EFA-2D25C8333EEF@stufft.io> References: <4BF2F1FC-5C9D-49EA-9EFA-2D25C8333EEF@stufft.io> Message-ID: <5263DE29.4050104@hybridcluster.com> On 10/19/2013 08:26 PM, Donald Stufft wrote: > I've started working on bundling OpenSSL within cryptography and fixing the packaging up. > > There are a number of things I'd like to do that will make things smoother in the long run but require some changes right now. These things are: > > Disable implicit compile > - This masks problems with the packaging. I tried leaving it on when doing the same thing for PyNaCl and it caused immense frustration with strange edge cases breaking. Further more the cffi devs say they are planning on removing it anyways. I agree that implicit compile is a little bit crazy. It ends up invoking a ton of code when the user probably doesn't expect it. The only concern I have with disabling this is that it sounds like the outcome of doing it naively means that source and compiled modules can easily get out of sync resulting in confusing errors. It would be nice if there could at *least* be a warning emitted if the source and compiled modules are mismatched. > Move the cryptography directory into a src directory > - Since cryptography will require an implicit compile step with the above, it's easy to accidentally import the cryptography that is sitting on the file system that hasn't been compiled yet, moving it means you have to install cryptography somehow to import it (or cd into the src directory). This should lower confusing errors when ``python -c 'import cryptography'`` does work. Further since we'll need a folder for the OpenSSL code it makes sense I think to have a single folder for all the things we have in repo, see: https://github.com/pyca/pynacl/tree/master/src I don't like this idea. It sounds like the reasoning behind it is "explicitly compilation makes things more inconvenient so we should re-arrange the repository to make things even *more* inconvenient than that" and then somehow conflating "inconvenient" with "not confusing". Moreover, I don't find the explanation that people will be confused if they try to use cryptography without compiling it compelling. If you want to remove confusing errors from that usage, detect missing compiled artifacts and raise an explicit exception about the problem. "src" directories are a holdover from ancient history when tools worked differently. It's almost always pointless now (even if the entire project is written in C). > > Lazily load the compiled library > - Right now the compiled library is loaded when the cryptography.bindings.openssl.api library is imported, this is the way CFFI currently works. As i've done in PyNaCl i'd like to make the Api object lazy so that it loads the compiled library on first access and proxies the calls to the exposed functions/variables to the lazily loaded underlying library object. You can see this at: https://github.com/pyca/pynacl/blob/master/src/nacl/_lib/__init__.py#L59-L84 Why? If someone imports cryptography.bindings.openssl.api then isn't it pretty likely they're going to use something from the compiled library? What is the scenario in which this results in less work being done? Jean-Paul > The final solution to this would be that we have a library that is always built at build time with a consistent version of OpenSSL. > > Thoughts on these steps? > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From donald at stufft.io Sun Oct 20 19:42:03 2013 From: donald at stufft.io (Donald Stufft) Date: Sun, 20 Oct 2013 13:42:03 -0400 Subject: [Cryptography-dev] Bundling OpenSSL In-Reply-To: <5263DE29.4050104@hybridcluster.com> References: <4BF2F1FC-5C9D-49EA-9EFA-2D25C8333EEF@stufft.io> <5263DE29.4050104@hybridcluster.com> Message-ID: On Oct 20, 2013, at 9:44 AM, Jean-Paul Calderone wrote: > On 10/19/2013 08:26 PM, Donald Stufft wrote: >> >> I've started working on bundling OpenSSL within cryptography and fixing the packaging up. >> >> There are a number of things I'd like to do that will make things smoother in the long run but require some changes right now. These things are: >> >> Disable implicit compile >> - This masks problems with the packaging. I tried leaving it on when doing the same thing for PyNaCl and it caused immense frustration with strange edge cases breaking. Further more the cffi devs say they are planning on removing it anyways. > I agree that implicit compile is a little bit crazy. It ends up invoking a ton of code when the user probably doesn't expect it. > > The only concern I have with disabling this is that it sounds like the outcome of doing it naively means that source and compiled modules can easily get out of sync resulting in confusing errors. > > It would be nice if there could at *least* be a warning emitted if the source and compiled modules are mismatched. I'm not sure how to do this warning. Do you know of a way? But yes it does mean that things can get out of sync. > >> Move the cryptography directory into a src directory >> - Since cryptography will require an implicit compile step with the above, it's easy to accidentally import the cryptography that is sitting on the file system that hasn't been compiled yet, moving it means you have to install cryptography somehow to import it (or cd into the src directory). This should lower confusing errors when ``python -c 'import cryptography'`` does work. Further since we'll need a folder for the OpenSSL code it makes sense I think to have a single folder for all the things we have in repo, see: https://github.com/pyca/pynacl/tree/master/src > > I don't like this idea. It sounds like the reasoning behind it is "explicitly compilation makes things more inconvenient so we should re-arrange the repository to make things even *more* inconvenient than that" and then somehow conflating "inconvenient" with "not confusing". Moreover, I don't find the explanation that people will be confused if they try to use cryptography without compiling it compelling. If you want to remove confusing errors from that usage, detect missing compiled artifacts and raise an explicit exception about the problem. > > "src" directories are a holdover from ancient history when tools worked differently. It's almost always pointless now (even if the entire project is written in C). I'm neutral on src directories. The primary reason I want to do it here is from my experience in fixing PyNaCl is it got confusing for me personally. If I ran ``pip install .`` and then tried to import nacl I would get an error because Python automatically added the current directory to the path which meant nacl tried to import the copy sitting on my disk which didn't have a compiled library. This isn't a requirement for sane packaging or bundling OpenSSL though, I just think it's cleaner to get rid of that potential pain point as well as provide a single directory for all of the source things we bundle. > >> >> Lazily load the compiled library >> - Right now the compiled library is loaded when the cryptography.bindings.openssl.api library is imported, this is the way CFFI currently works. As i've done in PyNaCl i'd like to make the Api object lazy so that it loads the compiled library on first access and proxies the calls to the exposed functions/variables to the lazily loaded underlying library object. You can see this at: https://github.com/pyca/pynacl/blob/master/src/nacl/_lib/__init__.py#L59-L84 > > Why? If someone imports cryptography.bindings.openssl.api then isn't it pretty likely they're going to use something from the compiled library? What is the scenario in which this results in less work being done? Essentially the way cffi works at the moment is you have to import the cryptography.bindings.openssl.api to get the distutils Extension class. If implicit compile is disabled then if importing that module attempts to load the compiled library (which it will how the code is currently) which will fail because it doesn't exist. Essentially we need to either lazily load, duplicate code into the setup.py, leave implicit compile on, or move the creation of the library instance to another module. (FFI verify implicit creates the library, but that can be moved). > > Jean-Paul > >> The final solution to this would be that we have a library that is always built at build time with a consistent version of OpenSSL. >> >> Thoughts on these steps? >> >> ----------------- >> Donald Stufft >> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA >> An additional question is wether we want to bundle the OpenSSL source unpacked in the source tree (like I did with libsodium in PyNacl) or if we want to just include a tarball and unpack it at build time to a temporary directory? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Thu Oct 24 17:27:02 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Thu, 24 Oct 2013 08:27:02 -0700 Subject: [Cryptography-dev] Criteria for first release? Message-ID: Hi all! We're at an exciting point where it's actually possible to do stuff with cryptography. You know what that means... time to start thinking about a release! I'd like us to make a list of the stuff we think should be in our first release. Here's my list: * Figure out our packaging / bundling story with OpenSSL * Finish binding OpenSSL to the point where JP can use it for PyOpenSSL * The last two block ciphers that conch would need (CAST and Blowfish) * Finalizing the iterator APIs for BlockCipher * Padding APIs Here's stuff I'm not sure about: * Everything that conch needs (this means figuring out the API for RSA/DSA) * GCM * CommonCrypto backend What do ya'll think, am I missing anything, do I have to much? As a heads up: once we're ready to do the release and we've frozen a release-candidate I plan to investigate getting it audited. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Thu Oct 24 17:32:38 2013 From: donald at stufft.io (Donald Stufft) Date: Thu, 24 Oct 2013 11:32:38 -0400 Subject: [Cryptography-dev] Criteria for first release? In-Reply-To: References: Message-ID: On Oct 24, 2013, at 11:27 AM, Alex Gaynor wrote: > Hi all! > > We're at an exciting point where it's actually possible to do stuff with cryptography. You know what that means... time to start thinking about a release! I'd like us to make a list of the stuff we think should be in our first release. Here's my list: > > * Figure out our packaging / bundling story with OpenSSL > * Finish binding OpenSSL to the point where JP can use it for PyOpenSSL > * The last two block ciphers that conch would need (CAST and Blowfish) > * Finalizing the iterator APIs for BlockCipher > * Padding APIs > > Here's stuff I'm not sure about: > * Everything that conch needs (this means figuring out the API for RSA/DSA) > * GCM > * CommonCrypto backend I?d really like to get GCM and RSA into it, GCM is something I think all of us wanted which we punted on to get the easier modes sorted out first. Without RSA we don?t have *any* asymmetric ciphers which is kinda lame. CommonCrypto I?m meh on. > > What do ya'll think, am I missing anything, do I have to much? > > As a heads up: once we're ready to do the release and we've frozen a release-candidate I plan to investigate getting it audited. Whose going to pay for an audit? > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jean-paul at hybridcluster.com Thu Oct 24 17:33:01 2013 From: jean-paul at hybridcluster.com (Jean-Paul Calderone) Date: Thu, 24 Oct 2013 11:33:01 -0400 Subject: [Cryptography-dev] Criteria for first release? In-Reply-To: References: Message-ID: <52693DAD.2090107@hybridcluster.com> On 10/24/2013 11:27 AM, Alex Gaynor wrote: > Hi all! > > We're at an exciting point where it's actually possible to do stuff > with cryptography. You know what that means... time to start thinking > about a release! I'd like us to make a list of the stuff we think > should be in our first release. Here's my list: > > * Figure out our packaging / bundling story with OpenSSL > * Finish binding OpenSSL to the point where JP can use it for PyOpenSSL > * The last two block ciphers that conch would need (CAST and Blowfish) > * Finalizing the iterator APIs for BlockCipher > * Padding APIs > > Here's stuff I'm not sure about: > * Everything that conch needs (this means figuring out the API for > RSA/DSA) This seems like a good target for a future release. Jean-Paul > * GCM > * CommonCrypto backend > > What do ya'll think, am I missing anything, do I have to much? > > As a heads up: once we're ready to do the release and we've frozen a > release-candidate I plan to investigate getting it audited. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From paul.l.kehrer at gmail.com Thu Oct 24 18:05:16 2013 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Thu, 24 Oct 2013 11:05:16 -0500 Subject: [Cryptography-dev] Criteria for first release? In-Reply-To: References: Message-ID: On Thu, Oct 24, 2013 at 10:27 AM, Alex Gaynor wrote: > Hi all! > > We're at an exciting point where it's actually possible to do stuff with > cryptography. You know what that means... time to start thinking about a > release! I'd like us to make a list of the stuff we think should be in our > first release. Here's my list: > > * Figure out our packaging / bundling story with OpenSSL > * Finish binding OpenSSL to the point where JP can use it for PyOpenSSL > * The last two block ciphers that conch would need (CAST and Blowfish) I assume the ultimate goal is to have conch use cryptography for everything. Would implementing CAST/BF and punting on RSA/DSA still be useful to conch or is it all or nothing? > * Finalizing the iterator APIs for BlockCipher > * Padding APIs > > Here's stuff I'm not sure about: > * Everything that conch needs (this means figuring out the API for RSA/DSA) > * GCM I'd prefer GCM support to be present in the first release. It's (ideally) the best mode to use and I'd love to be able to suggest its use immediately. I'm okay with pushing RSA/DSA to the future as there are many pieces to that (including OAEP, etc). > * CommonCrypto backend The CommonCrypto backend can probably wait for a subsequent release. If we did decide we wanted it to be part of an initial release we would need to prioritize getting a test infrastructure outside of Travis up and running so we can run OS X tests. > > What do ya'll think, am I missing anything, do I have to much? > > As a heads up: once we're ready to do the release and we've frozen a > release-candidate I plan to investigate getting it audited. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > From donald at stufft.io Thu Oct 24 18:05:01 2013 From: donald at stufft.io (Donald Stufft) Date: Thu, 24 Oct 2013 12:05:01 -0400 Subject: [Cryptography-dev] Criteria for first release? In-Reply-To: References: Message-ID: One thing we?ll need is a backwards compat policy/versioning scheme. Personally I think semver with PEP440 syntax? On Oct 24, 2013, at 11:27 AM, Alex Gaynor wrote: > Hi all! > > We're at an exciting point where it's actually possible to do stuff with cryptography. You know what that means... time to start thinking about a release! I'd like us to make a list of the stuff we think should be in our first release. Here's my list: > > * Figure out our packaging / bundling story with OpenSSL > * Finish binding OpenSSL to the point where JP can use it for PyOpenSSL > * The last two block ciphers that conch would need (CAST and Blowfish) > * Finalizing the iterator APIs for BlockCipher > * Padding APIs > > Here's stuff I'm not sure about: > * Everything that conch needs (this means figuring out the API for RSA/DSA) > * GCM > * CommonCrypto backend > > What do ya'll think, am I missing anything, do I have to much? > > As a heads up: once we're ready to do the release and we've frozen a release-candidate I plan to investigate getting it audited. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hs at ox.cx Thu Oct 24 18:10:25 2013 From: hs at ox.cx (Hynek Schlawack) Date: Thu, 24 Oct 2013 18:10:25 +0200 Subject: [Cryptography-dev] Criteria for first release? In-Reply-To: References: Message-ID: <7411E2F7-1027-4A0B-917F-FA657B1E44DA@ox.cx> I?m not a fan of semver. The backward compat policy for a project like cryptography should be simply ?don?t break it?. FWIW, I like Ubuntu?s & Twisted?s time-base versioning with possible point-releases for urgent bug fixes. Am 24.10.2013 um 18:05 schrieb Donald Stufft : > One thing we?ll need is a backwards compat policy/versioning scheme. > > Personally I think semver with PEP440 syntax? > > On Oct 24, 2013, at 11:27 AM, Alex Gaynor wrote: > >> Hi all! >> >> We're at an exciting point where it's actually possible to do stuff with cryptography. You know what that means... time to start thinking about a release! I'd like us to make a list of the stuff we think should be in our first release. Here's my list: >> >> * Figure out our packaging / bundling story with OpenSSL >> * Finish binding OpenSSL to the point where JP can use it for PyOpenSSL >> * The last two block ciphers that conch would need (CAST and Blowfish) >> * Finalizing the iterator APIs for BlockCipher >> * Padding APIs >> >> Here's stuff I'm not sure about: >> * Everything that conch needs (this means figuring out the API for RSA/DSA) >> * GCM >> * CommonCrypto backend >> >> What do ya'll think, am I missing anything, do I have to much? >> >> As a heads up: once we're ready to do the release and we've frozen a release-candidate I plan to investigate getting it audited. >> >> Alex >> >> -- >> "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) >> "The people's good is the highest law." -- Cicero >> GPG Key fingerprint: 125F 5C67 DFE9 4084 >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> https://mail.python.org/mailman/listinfo/cryptography-dev > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Thu Oct 24 18:38:00 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Thu, 24 Oct 2013 09:38:00 -0700 Subject: [Cryptography-dev] Criteria for first release? In-Reply-To: References: Message-ID: On Thu, Oct 24, 2013 at 8:32 AM, Donald Stufft wrote: > > On Oct 24, 2013, at 11:27 AM, Alex Gaynor wrote: > > > Hi all! > > > > We're at an exciting point where it's actually possible to do stuff with > cryptography. You know what that means... time to start thinking about a > release! I'd like us to make a list of the stuff we think should be in our > first release. Here's my list: > > > > * Figure out our packaging / bundling story with OpenSSL > > * Finish binding OpenSSL to the point where JP can use it for PyOpenSSL > > * The last two block ciphers that conch would need (CAST and Blowfish) > > * Finalizing the iterator APIs for BlockCipher > > * Padding APIs > > > > Here's stuff I'm not sure about: > > * Everything that conch needs (this means figuring out the API for > RSA/DSA) > > * GCM > > * CommonCrypto backend > > I?d really like to get GCM and RSA into it, GCM is something I think all > of us wanted > which we punted on to get the easier modes sorted out first. Without RSA > we don?t > have *any* asymmetric ciphers which is kinda lame. > > CommonCrypto I?m meh on. > > > > > What do ya'll think, am I missing anything, do I have to much? > > > > As a heads up: once we're ready to do the release and we've frozen a > release-candidate I plan to investigate getting it audited. > > Whose going to pay for an audit? > > I'm going to try to get some security firms to donate it. Failing that . > > > > Alex > > > > -- > > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > > "The people's good is the highest law." -- Cicero > > GPG Key fingerprint: 125F 5C67 DFE9 4084 > > _______________________________________________ > > Cryptography-dev mailing list > > Cryptography-dev at python.org > > https://mail.python.org/mailman/listinfo/cryptography-dev > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mcmillan.ws Fri Oct 25 01:14:03 2013 From: paul at mcmillan.ws (Paul McMillan) Date: Thu, 24 Oct 2013 23:14:03 +0000 Subject: [Cryptography-dev] Criteria for first release? In-Reply-To: References: Message-ID: On Thu, Oct 24, 2013 at 4:05 PM, Paul Kehrer wrote: > I'd prefer GCM support to be present in the first release. It's > (ideally) the best mode to use and I'd love to be able to suggest its > use immediately. I agree that GCM is an excellent feature, which would be really nice to have in a first release. That said, I have real difficulty recommending it as a primative without a sanity wrapper (and to some extent, even with one) because it comes with some fantastic footguns that are non-obvious in dev/test environments, and difficult to systematically correct at the library level. All that boils down to the feeling that while it would be nice, shipping without it is not the end of the world. -Paul From jarret.raim at RACKSPACE.COM Fri Oct 25 20:51:24 2013 From: jarret.raim at RACKSPACE.COM (Jarret Raim) Date: Fri, 25 Oct 2013 18:51:24 +0000 Subject: [Cryptography-dev] Criteria for first release? In-Reply-To: References: Message-ID: <6824C20A6CE7A44A939B31B7084E55962259832A@ORD1EXD03.RACKSPACE.CORP> > > * CommonCrypto backend > > The CommonCrypto backend can probably wait for a subsequent release. > If we did decide we wanted it to be part of an initial release we would need > to prioritize getting a test infrastructure outside of Travis up and running so > we can run OS X tests. As a side note, I'm working on this. There is a team inside Rackspace that has a small mac mini farm they use for testing builds. I'm trying to get us a VM on it so we can use it to test. Failing that, I'll go get us one of those fancy new trashcans or something to use for automated builds. We started talking a bit on IRC about OS packing for cryptography. I'd like to offer up some space on the Rackspace pub cloud to do this. We should be able to have a Jenkins instance that farms out to various build slaves for building and testing packages. Besides the OSX one above, we should be able to cover most / all major distros. The full list is below if anyone is interested. We can add anything that's missing of course. Do we think this is the right approach? I'm not wild about using both Travis and Jenkins, but I don't think there is a way to have Travis build off of remote build slaves and it only offers Ubuntu and OSX backends right now. Anyway, if we like the Jenkins approach I'll go get us the Cloud account and get it set up. Jarret Arch 2013.9 CentOS 5.9 CentOS 6.4 Debian 6.06 (Squeeze) Debian 7 (Wheezy) Fedora 18 (Spherical Cow) Fedora 19 (Schrodinger's Cat) FreeBSD 9.1 Gentoo 13.3 OpenSUSE 12.3 Red Hat Enterprise Linux 5.9 Red Hat Enterprise Linux 6.4 Scientific Linux 6.4 Ubuntu 10.04 LTS (Lucid Lynx) Ubuntu 12.04 LTS (Precise Pangolin) Ubuntu 12.10 (Quantal Quetzal) Ubuntu 13.04 (Raring Ringtail) Ubuntu 13.10 (Saucy Salamander) Vyatta Network OS 6.5R2 Windows Server 2008 R2 SP1 Windows Server 2008 R2 SP1 (base install without updates) Windows Server 2008 R2 SP1 + SharePoint 2010 Foundation with SQL Server 2008 R2 Express Windows Server 2008 R2 SP1 + SharePoint 2010 Foundation with SQL Server 2008 R2 SP1 Standard Windows Server 2008 R2 SP1 + SQL Server 2008 R2 SP2 Standard Windows Server 2008 R2 SP1 + SQL Server 2008 R2 SP2 Web Windows Server 2008 R2 SP1 + SQL Server 2012 SP1 Standard Windows Server 2008 R2 SP1 + SQL Server 2012 SP1 Web Windows Server 2012 Windows Server 2012 (base install without updates) Windows Server 2012 + SharePoint 2013 with SQL Server 2012 SP1 Standard Windows Server 2012 + SQL Server 2012 SP1 Standard Windows Server 2012 + SQL Server 2012 SP1 Web From donald at stufft.io Fri Oct 25 21:10:24 2013 From: donald at stufft.io (Donald Stufft) Date: Fri, 25 Oct 2013 15:10:24 -0400 Subject: [Cryptography-dev] Criteria for first release? In-Reply-To: <6824C20A6CE7A44A939B31B7084E55962259832A@ORD1EXD03.RACKSPACE.CORP> References: <6824C20A6CE7A44A939B31B7084E55962259832A@ORD1EXD03.RACKSPACE.CORP> Message-ID: On Oct 25, 2013, at 2:51 PM, Jarret Raim wrote: >>> * CommonCrypto backend >> >> The CommonCrypto backend can probably wait for a subsequent release. >> If we did decide we wanted it to be part of an initial release we would need >> to prioritize getting a test infrastructure outside of Travis up and running so >> we can run OS X tests. > > As a side note, I'm working on this. There is a team inside Rackspace that has a small mac mini farm they use for testing builds. I'm trying to get us a VM on it so we can use it to test. Failing that, I'll go get us one of those fancy new trashcans or something to use for automated builds. > > We started talking a bit on IRC about OS packing for cryptography. I'd like to offer up some space on the Rackspace pub cloud to do this. We should be able to have a Jenkins instance that farms out to various build slaves for building and testing packages. Besides the OSX one above, we should be able to cover most / all major distros. The full list is below if anyone is interested. We can add anything that's missing of course. Just to be clear, your idea here is to provide repositories or something that people could install cryptography with using their system package managers? > > Do we think this is the right approach? I'm not wild about using both Travis and Jenkins, but I don't think there is a way to have Travis build off of remote build slaves and it only offers Ubuntu and OSX backends right now. Anyway, if we like the Jenkins approach I'll go get us the Cloud account and get it set up. This is for tests? Or for packaging? For tests we could possibly use pytest-xdist to test on a rackspace slave. For packaging we?d probably want to check in some build scripts and just run those build scripts from jenkins. Honestly some of the biggest problem is the need to have isolated throw away environments. This is especially important for pull requests. > > > > Jarret > > > Arch 2013.9 > CentOS 5.9 > CentOS 6.4 > Debian 6.06 (Squeeze) > Debian 7 (Wheezy) > Fedora 18 (Spherical Cow) > Fedora 19 (Schrodinger's Cat) > FreeBSD 9.1 > Gentoo 13.3 > OpenSUSE 12.3 > Red Hat Enterprise Linux 5.9 > Red Hat Enterprise Linux 6.4 > Scientific Linux 6.4 > Ubuntu 10.04 LTS (Lucid Lynx) > Ubuntu 12.04 LTS (Precise Pangolin) > Ubuntu 12.10 (Quantal Quetzal) > Ubuntu 13.04 (Raring Ringtail) > Ubuntu 13.10 (Saucy Salamander) > Vyatta Network OS 6.5R2 > Windows Server 2008 R2 SP1 > Windows Server 2008 R2 SP1 (base install without updates) > Windows Server 2008 R2 SP1 + SharePoint 2010 Foundation with SQL Server 2008 R2 Express > Windows Server 2008 R2 SP1 + SharePoint 2010 Foundation with SQL Server 2008 R2 SP1 Standard > Windows Server 2008 R2 SP1 + SQL Server 2008 R2 SP2 Standard > Windows Server 2008 R2 SP1 + SQL Server 2008 R2 SP2 Web > Windows Server 2008 R2 SP1 + SQL Server 2012 SP1 Standard > Windows Server 2008 R2 SP1 + SQL Server 2012 SP1 Web > Windows Server 2012 > Windows Server 2012 (base install without updates) > Windows Server 2012 + SharePoint 2013 with SQL Server 2012 SP1 Standard > Windows Server 2012 + SQL Server 2012 SP1 Standard > Windows Server 2012 + SQL Server 2012 SP1 Web > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alex.gaynor at gmail.com Sun Oct 27 21:29:19 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sun, 27 Oct 2013 13:29:19 -0700 Subject: [Cryptography-dev] Criteria for first release? In-Reply-To: References: <6824C20A6CE7A44A939B31B7084E55962259832A@ORD1EXD03.RACKSPACE.CORP> Message-ID: After getting some feedback from some other people, I'd like to suggest the following idea: We not do a full release until we have some high level recipes, otherwise it's just primitives, and we've basically released a foot-gun. Alex On Fri, Oct 25, 2013 at 12:10 PM, Donald Stufft wrote: > > On Oct 25, 2013, at 2:51 PM, Jarret Raim > wrote: > > >>> * CommonCrypto backend > >> > >> The CommonCrypto backend can probably wait for a subsequent release. > >> If we did decide we wanted it to be part of an initial release we would > need > >> to prioritize getting a test infrastructure outside of Travis up and > running so > >> we can run OS X tests. > > > > As a side note, I'm working on this. There is a team inside Rackspace > that has a small mac mini farm they use for testing builds. I'm trying to > get us a VM on it so we can use it to test. Failing that, I'll go get us > one of those fancy new trashcans or something to use for automated builds. > > > > We started talking a bit on IRC about OS packing for cryptography. I'd > like to offer up some space on the Rackspace pub cloud to do this. We > should be able to have a Jenkins instance that farms out to various build > slaves for building and testing packages. Besides the OSX one above, we > should be able to cover most / all major distros. The full list is below if > anyone is interested. We can add anything that's missing of course. > > Just to be clear, your idea here is to provide repositories or something > that people could install cryptography with using their system package > managers? > > > > > Do we think this is the right approach? I'm not wild about using both > Travis and Jenkins, but I don't think there is a way to have Travis build > off of remote build slaves and it only offers Ubuntu and OSX backends right > now. Anyway, if we like the Jenkins approach I'll go get us the Cloud > account and get it set up. > > This is for tests? Or for packaging? For tests we could possibly use > pytest-xdist to test on a rackspace slave. For packaging we?d probably want > to check in some build scripts and just run those build scripts from > jenkins. > > Honestly some of the biggest problem is the need to have isolated throw > away environments. This is especially important for pull requests. > > > > > > > > > Jarret > > > > > > Arch 2013.9 > > CentOS 5.9 > > CentOS 6.4 > > Debian 6.06 (Squeeze) > > Debian 7 (Wheezy) > > Fedora 18 (Spherical Cow) > > Fedora 19 (Schrodinger's Cat) > > FreeBSD 9.1 > > Gentoo 13.3 > > OpenSUSE 12.3 > > Red Hat Enterprise Linux 5.9 > > Red Hat Enterprise Linux 6.4 > > Scientific Linux 6.4 > > Ubuntu 10.04 LTS (Lucid Lynx) > > Ubuntu 12.04 LTS (Precise Pangolin) > > Ubuntu 12.10 (Quantal Quetzal) > > Ubuntu 13.04 (Raring Ringtail) > > Ubuntu 13.10 (Saucy Salamander) > > Vyatta Network OS 6.5R2 > > Windows Server 2008 R2 SP1 > > Windows Server 2008 R2 SP1 (base install without updates) > > Windows Server 2008 R2 SP1 + SharePoint 2010 Foundation with SQL Server > 2008 R2 Express > > Windows Server 2008 R2 SP1 + SharePoint 2010 Foundation with SQL Server > 2008 R2 SP1 Standard > > Windows Server 2008 R2 SP1 + SQL Server 2008 R2 SP2 Standard > > Windows Server 2008 R2 SP1 + SQL Server 2008 R2 SP2 Web > > Windows Server 2008 R2 SP1 + SQL Server 2012 SP1 Standard > > Windows Server 2008 R2 SP1 + SQL Server 2012 SP1 Web > > Windows Server 2012 > > Windows Server 2012 (base install without updates) > > Windows Server 2012 + SharePoint 2013 with SQL Server 2012 SP1 Standard > > Windows Server 2012 + SQL Server 2012 SP1 Standard > > Windows Server 2012 + SQL Server 2012 SP1 Web > > > > > > _______________________________________________ > > Cryptography-dev mailing list > > Cryptography-dev at python.org > > https://mail.python.org/mailman/listinfo/cryptography-dev > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Sun Oct 27 22:38:49 2013 From: donald at stufft.io (Donald Stufft) Date: Sun, 27 Oct 2013 17:38:49 -0400 Subject: [Cryptography-dev] Criteria for first release? In-Reply-To: References: <6824C20A6CE7A44A939B31B7084E55962259832A@ORD1EXD03.RACKSPACE.CORP> Message-ID: On Oct 27, 2013, at 4:29 PM, Alex Gaynor wrote: > After getting some feedback from some other people, I'd like to suggest the following idea: > > We not do a full release until we have some high level recipes, otherwise it's just primitives, and we've basically released a foot-gun. +1 ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: