From alex.gaynor at gmail.com Sun Mar 1 17:56:52 2015 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sun, 1 Mar 2015 08:56:52 -0800 Subject: [Cryptography-dev] PEM export for RSA private keys just landed Message-ID: Hey all, This has been a long time in the works -- thanks to Paul Kehrer for pushing through on this, and all the folks that contributed over 150 comments to the pull request! If this is a feature that you've been interested in (and we know there's a lot of you!), please check out the docs and kick the tires on the API: https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#key-serialization Thanks, 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 glyph at twistedmatrix.com Mon Mar 2 00:23:17 2015 From: glyph at twistedmatrix.com (Glyph) Date: Sun, 1 Mar 2015 15:23:17 -0800 Subject: [Cryptography-dev] PEM export for RSA private keys just landed In-Reply-To: References: Message-ID: <03B483D8-CFD4-4917-BED8-247E1A380EA4@twistedmatrix.com> http://24.media.tumblr.com/tumblr_m1neqsYSoj1qk4r78o1_500.gif That is all. -g > On Mar 1, 2015, at 8:56 AM, Alex Gaynor wrote: > > Hey all, > > This has been a long time in the works -- thanks to Paul Kehrer for pushing through on this, and all the folks that contributed over 150 comments to the pull request! > > If this is a feature that you've been interested in (and we know there's a lot of you!), please check out the docs and kick the tires on the API: https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#key-serialization > > Thanks, > 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: From warner at lothar.com Wed Mar 4 21:06:11 2015 From: warner at lothar.com (Brian Warner) Date: Wed, 04 Mar 2015 12:06:11 -0800 Subject: [Cryptography-dev] PyNaCl-0.3.0 release Message-ID: <54F765B3.9080500@lothar.com> I'm pleased to announce that we've released PyNaCl-0.3.0 to PyPI. https://pypi.python.org/pypi/PyNaCl/ "pynacl", as the package is known, is a python2/3/pypy binding to libsodium[1], which gives applications access to the "NaCl" cryptography library[2] (Curve25519 "Box" public-key authenticated encryption, Salsa20/Poly1305 secret-key authenticated encryption, and various lower-level primitives). It's been 17 months since the previous (0.2.3) release, so a lot of things have changed. The most important items, however, are: * "pip install pynacl" now works, as does using pynacl as a dependency of another pip-installed program (install_requires=["pynacl"]) * The raw "nacl.c" module has been removed, and replaced with "nacl.bindings" that offers the same functionality. The API is different, however (in particular the arguments now match other nacl/libsodium bindings), so we decided to remove the old module to avoid confusion. * a URLSafeBase64Encoder was added, for encoding messages and keys * upgraded to libsodium-1.0.1 (but note 1.0.2 is now the most recent) Thanks to everyone who's contributed code, testing, and eyeballs to this release! Please report any bugs to the github tracker[3]. cheers, -Brian [1]: https://github.com/jedisct1/libsodium/ [2]: http://nacl.cr.yp.to/ [3]: https://github.com/pyca/pynacl From olivier.sallou at gmail.com Sat Mar 7 12:33:12 2015 From: olivier.sallou at gmail.com (olivier sallou) Date: Sat, 07 Mar 2015 11:33:12 +0000 Subject: [Cryptography-dev] Help required for RSAPrivateKeyWithSerialization Message-ID: Hi, I followed examples to create an rsa (public/private) key and it works fine. I do not see however how to "save" my keys for later reuse/exchange. I see no "export/convertt to bytes" method to save keys in a file. In documentation, there are references to RSAPrivateKeyWithSerialization but I do not see how to get one from rsa.generate_private_key(). Could you help me? Thanks Olivier -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Sat Mar 7 16:34:20 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sat, 7 Mar 2015 09:34:20 -0600 Subject: [Cryptography-dev] Help required for RSAPrivateKeyWithSerialization In-Reply-To: References: Message-ID: Hi Olivier, The currently released version (0.7.2) does not support saving the keys, but 0.8 (which should be out in the next few days) will support it via "private_bytes" (https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#cryptography.hazmat.primitives.asymmetric.rsa.RSAPrivateKeyWithSerialization.private_bytes). At that point when you call rsa.generate_private_key() you can verify you get back an object with the RSAPrivateKeyWithSerialization interface by calling isinstance(key, rsa.RSAPrivateKeyWithSerialization). -Paul Kehrer On March 7, 2015 at 8:59:44 AM, olivier sallou (olivier.sallou at gmail.com) wrote: Hi, I followed examples to create an rsa (public/private) key and it works fine. I do not see however how to "save" my keys for later reuse/exchange. I see no "export/convertt to bytes" method to save keys in a file. In documentation, there are references to?RSAPrivateKeyWithSerialization but I do not see how to get one from?rsa.generate_private_key(). Could you help me? Thanks Olivier _______________________________________________ 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: From olivier.sallou at gmail.com Sat Mar 7 18:09:57 2015 From: olivier.sallou at gmail.com (olivier sallou) Date: Sat, 07 Mar 2015 17:09:57 +0000 Subject: [Cryptography-dev] Help required for RSAPrivateKeyWithSerialization References: Message-ID: Thanks, I had seen on dev release, but i expected there was already something available, maybe more complex. Anyway, i gonna way for next release Olivier Le sam. 7 mars 2015 16:34, Paul Kehrer a ?crit : > Hi Olivier, > > The currently released version (0.7.2) does not support saving the keys, > but 0.8 (which should be out in the next few days) will support it via > "private_bytes" ( > https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#cryptography.hazmat.primitives.asymmetric.rsa.RSAPrivateKeyWithSerialization.private_bytes). > At that point when you call rsa.generate_private_key() you can verify you > get back an object with the RSAPrivateKeyWithSerialization interface by > calling isinstance(key, rsa.RSAPrivateKeyWithSerialization). > > > -Paul Kehrer > > > On March 7, 2015 at 8:59:44 AM, olivier sallou (olivier.sallou at gmail.com) > wrote: > > Hi, > I followed examples to create an rsa (public/private) key and it works > fine. > I do not see however how to "save" my keys for later reuse/exchange. > > I see no "export/convertt to bytes" method to save keys in a file. > > In documentation, there are references to RSAPrivateKeyWithSerialization > but I do not see how to get one from rsa.generate_private_key(). > > Could you help me? > > Thanks > > Olivier > > _______________________________________________ > 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: From paul.l.kehrer at gmail.com Mon Mar 9 05:58:19 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sun, 8 Mar 2015 23:58:19 -0500 Subject: [Cryptography-dev] PyCA cryptography 0.8 release Message-ID: On behalf of all the contributors to PyCA cryptography (https://github.com/pyca/cryptography) I?m extremely happy to announce that 0.8 has been tagged and released to PyPI. This release is one of our largest ever (complete changelog here:?https://cryptography.io/en/latest/changelog/). Some highlights: * X509 name parsing support (subject and issuer on X509 certificates) * X509 signature algorithm support * Serialization support for both public and private asymmetric keys (see docs for details and current limitations) * Compiles against LibreSSL * Windows wheels are now built against OpenSSL 1.0.2 -Paul Kehrer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcea at jcea.es Mon Mar 16 03:27:57 2015 From: jcea at jcea.es (Jesus Cea) Date: Mon, 16 Mar 2015 03:27:57 +0100 Subject: [Cryptography-dev] X.509 certificate creation Message-ID: <55063FAD.70303@jcea.es> A feature request :-). I would love to be able to manage a X.509 PKI infrastructure without touching OpenSSL. OpenSSL stock configuration misses a lot of options and knobs. For instance creating X.509 certificates with "subject alt name" field is really painful. I think this would be a selling point in some environments... :-). -- Jes?s Cea Avi?n _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From alex.gaynor at gmail.com Mon Mar 16 03:40:13 2015 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sun, 15 Mar 2015 22:40:13 -0400 Subject: [Cryptography-dev] X.509 certificate creation In-Reply-To: <55063FAD.70303@jcea.es> References: <55063FAD.70303@jcea.es> Message-ID: This is absolutely a long term plan. As you've probably seen, right now we can parse certificates, and expose some attributes -- once that's basically complete (we still need extensions) we'll move on to creating them. Alex On Sun, Mar 15, 2015 at 10:27 PM, Jesus Cea wrote: > A feature request :-). > > I would love to be able to manage a X.509 PKI infrastructure without > touching OpenSSL. OpenSSL stock configuration misses a lot of options > and knobs. For instance creating X.509 certificates with "subject alt > name" field is really painful. > > I think this would be a selling point in some environments... :-). > > -- > Jes?s Cea Avi?n _/_/ _/_/_/ _/_/_/ > jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ > Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ > jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > > > _______________________________________________ > 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 paul.l.kehrer at gmail.com Fri Mar 20 17:02:17 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Fri, 20 Mar 2015 11:02:17 -0500 Subject: [Cryptography-dev] PyCA cryptography 0.8.1 release Message-ID: PyCA cryptography 0.8.1 has been released to PyPI. This version contains no changes outside of the Windows wheels, which are now built against OpenSSL 1.0.2a. -Paul Kehrer From alex.gaynor at gmail.com Sat Mar 28 20:29:53 2015 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sat, 28 Mar 2015 15:29:53 -0400 Subject: [Cryptography-dev] Unsupported platforms? Message-ID: Hi folks, I'd like to propose we deprecate, with the intention of removing, support for Python 2.6. The reason for this is that Python 2.6 is no longer receiving support for the Python core developers in any form, including security releases. We provide a piece of security sensitive software, and I claim it would be irresponsible to say it's supported on platforms which are themselves not supported. This would affect our current downstreams, such as pyOpenSSL, Twisted, and OpenStack, as well as things we'd like to be our downstreams, such as Paramiko/Fabric. So I'm hoping some of them will chime in. By way of adding data around this: Django's latest release is 2.7/3.x only, however there has been some measure of requests to add additional long term support for a past release which has 2.6 support. I've seen numbers from Donald that (as of the end of last year) 2.6 is ~10-15% of PyPI downloads across the board. Thoughts? 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 jean-paul at clusterhq.com Sat Mar 28 20:48:06 2015 From: jean-paul at clusterhq.com (Jean-Paul Calderone) Date: Sat, 28 Mar 2015 15:48:06 -0400 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: References: Message-ID: Speaking as the pyOpenSSL maintainer, I'd like time to perform one last pyOpenSSL release along with an announcement that it will be the last pyOpenSSL release to support Python 2.6. Strictly speaking, I could probably retain Python 2.6 support in pyOpenSSL even if the cryptography project drops it but that seems unreasonable for several reasons (pyOpenSSL shares many of cryptography's reasons for wanting to drop Python 2.6 support, requiring that pyOpenSSL continue to work with only cryptography <= 0.8.1 will be a bunch of extra work, etc). I can't say exactly when the next pyOpenSSL release will be but if the cryptography project lays out its timeline for this then at least I'll know what bounds I have to work with (and I'm clearly long overdue so as long as you don't decide something like "tomorrow" I won't have much room to complain). Jean-Paul On Sat, Mar 28, 2015 at 3:29 PM, Alex Gaynor wrote: > Hi folks, > > I'd like to propose we deprecate, with the intention of removing, support > for Python 2.6. The reason for this is that Python 2.6 is no longer > receiving support for the Python core developers in any form, including > security releases. > > We provide a piece of security sensitive software, and I claim it would be > irresponsible to say it's supported on platforms which are themselves not > supported. > > This would affect our current downstreams, such as pyOpenSSL, Twisted, and > OpenStack, as well as things we'd like to be our downstreams, such as > Paramiko/Fabric. So I'm hoping some of them will chime in. > > By way of adding data around this: Django's latest release is 2.7/3.x > only, however there has been some measure of requests to add additional > long term support for a past release which has 2.6 support. I've seen > numbers from Donald that (as of the end of last year) 2.6 is ~10-15% of > PyPI downloads across the board. > > Thoughts? > > 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: From alex.gaynor at gmail.com Sat Mar 28 20:52:00 2015 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sat, 28 Mar 2015 15:52:00 -0400 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: References: Message-ID: I think we'd want to do a full deprecation cycle on this: 0.9: PendingDeprecationWarning 1.0: DeprecationWarning 1.1: removed So that's like, 2.5 months notice or so? (Not sure quite how quickly we've been releasing in past). Donald: How hard would it be to get download statistics for cryptography and pyOpenSSL from the last few months by Python versoin? Alex On Sat, Mar 28, 2015 at 3:48 PM, Jean-Paul Calderone < jean-paul at clusterhq.com> wrote: > Speaking as the pyOpenSSL maintainer, I'd like time to perform one last > pyOpenSSL release along with an announcement that it will be the last > pyOpenSSL release to support Python 2.6. Strictly speaking, I could > probably retain Python 2.6 support in pyOpenSSL even if the cryptography > project drops it but that seems unreasonable for several reasons (pyOpenSSL > shares many of cryptography's reasons for wanting to drop Python 2.6 > support, requiring that pyOpenSSL continue to work with only cryptography > <= 0.8.1 will be a bunch of extra work, etc). > > I can't say exactly when the next pyOpenSSL release will be but if the > cryptography project lays out its timeline for this then at least I'll know > what bounds I have to work with (and I'm clearly long overdue so as long as > you don't decide something like "tomorrow" I won't have much room to > complain). > > Jean-Paul > > > On Sat, Mar 28, 2015 at 3:29 PM, Alex Gaynor > wrote: > >> Hi folks, >> >> I'd like to propose we deprecate, with the intention of removing, support >> for Python 2.6. The reason for this is that Python 2.6 is no longer >> receiving support for the Python core developers in any form, including >> security releases. >> >> We provide a piece of security sensitive software, and I claim it would >> be irresponsible to say it's supported on platforms which are themselves >> not supported. >> >> This would affect our current downstreams, such as pyOpenSSL, Twisted, >> and OpenStack, as well as things we'd like to be our downstreams, such as >> Paramiko/Fabric. So I'm hoping some of them will chime in. >> >> By way of adding data around this: Django's latest release is 2.7/3.x >> only, however there has been some measure of requests to add additional >> long term support for a past release which has 2.6 support. I've seen >> numbers from Donald that (as of the end of last year) 2.6 is ~10-15% of >> PyPI downloads across the board. >> >> Thoughts? >> >> 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 >> >> > > _______________________________________________ > 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 Sat Mar 28 23:56:22 2015 From: donald at stufft.io (Donald Stufft) Date: Sat, 28 Mar 2015 18:56:22 -0400 Subject: [Cryptography-dev] Dedicated Travis Builders Message-ID: <919C8B85-469A-4210-9890-5B05842F2C17@stufft.io> I was talking to the Travis CI folks and they mentioned they have the possibility of using openstack builders now (or in the near future). We talked a little bit about the possibility of getting PyCA it's own dedicated set of builders in Travis CI hosted inside of Rackspace on one of our cloud accounts. Currently the entirety of the PyPA organization on Github gets 10 concurrent builders (typically this number is 5) across all repositories. Assuming Travis CI is able to do it (they'd need to check with their ops team, and there would be some cost associated with things on their side as well) we could essentially control how much concurrency we want by just throwing more Rackspace VMs at our builds. Josh said they use a 2 vCPU machine w/ 4GB of ram, so looking at the Rackspace Compute1-4 which is similar we'd be looking at the ability to run ~27 of those VMs full time on the "standard" 2k/month free cloud offering that Rackspace offers OSS projects. However we'd actually be able to get more than that probably because Travis starts up the VMs on demand so anytime there aren't tests to run we won't have any VMs running. Independent of this, they are also working on the ability to run custom docker images (which means custom Linux OS images) that we can preinstall different software into. Is this something we'd want to explore? Assuming that the Travis CI ops team and such are OK with it, it could essentially let us scale up our concurrency on Travis to whatever amount of dollars of Rackspace cloud we want to throw at it. --- Donald Stufft PGP: 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 Sat Mar 28 23:58:50 2015 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sat, 28 Mar 2015 18:58:50 -0400 Subject: [Cryptography-dev] Dedicated Travis Builders In-Reply-To: <919C8B85-469A-4210-9890-5B05842F2C17@stufft.io> References: <919C8B85-469A-4210-9890-5B05842F2C17@stufft.io> Message-ID: Just to be clear, can we do *both* the custom docker and the Rackspace thing? This sounds like it'd be a big win: we could centralize all of our Linux builders onto that, they'd manage it, we'd get all the concurrency we need because the system would have VMs shut down most of the time to save money, and it'd even be easy to have them all feeding into coveralls! Alex On Sat, Mar 28, 2015 at 6:56 PM, Donald Stufft wrote: > I was talking to the Travis CI folks and they mentioned they have the > possibility of using openstack builders now (or in the near future). We > talked > a little bit about the possibility of getting PyCA it's own dedicated set > of > builders in Travis CI hosted inside of Rackspace on one of our cloud > accounts. > > Currently the entirety of the PyPA organization on Github gets 10 > concurrent > builders (typically this number is 5) across all repositories. Assuming > Travis > CI is able to do it (they'd need to check with their ops team, and there > would > be some cost associated with things on their side as well) we could > essentially > control how much concurrency we want by just throwing more Rackspace VMs at > our builds. > > Josh said they use a 2 vCPU machine w/ 4GB of ram, so looking at the > Rackspace > Compute1-4 which is similar we'd be looking at the ability to run ~27 of > those > VMs full time on the "standard" 2k/month free cloud offering that Rackspace > offers OSS projects. However we'd actually be able to get more than that > probably because Travis starts up the VMs on demand so anytime there aren't > tests to run we won't have any VMs running. > > Independent of this, they are also working on the ability to run custom > docker > images (which means custom Linux OS images) that we can preinstall > different > software into. > > Is this something we'd want to explore? Assuming that the Travis CI ops > team > and such are OK with it, it could essentially let us scale up our > concurrency > on Travis to whatever amount of dollars of Rackspace cloud we want to > throw at > it. > > --- > Donald Stufft > PGP: 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 Mar 29 00:06:14 2015 From: donald at stufft.io (Donald Stufft) Date: Sat, 28 Mar 2015 19:06:14 -0400 Subject: [Cryptography-dev] Dedicated Travis Builders In-Reply-To: References: <919C8B85-469A-4210-9890-5B05842F2C17@stufft.io> Message-ID: <5BB9E215-9D51-4EF1-BF7B-8059CFDF4379@stufft.io> Yes, we can run custom docker images *and* have dedicated builders running inside Rackspace. > On Mar 28, 2015, at 6:58 PM, Alex Gaynor wrote: > > Just to be clear, can we do *both* the custom docker and the Rackspace thing? > > This sounds like it'd be a big win: we could centralize all of our Linux builders onto that, they'd manage it, we'd get all the concurrency we need because the system would have VMs shut down most of the time to save money, and it'd even be easy to have them all feeding into coveralls! > > Alex > > On Sat, Mar 28, 2015 at 6:56 PM, Donald Stufft > wrote: > I was talking to the Travis CI folks and they mentioned they have the > possibility of using openstack builders now (or in the near future). We talked > a little bit about the possibility of getting PyCA it's own dedicated set of > builders in Travis CI hosted inside of Rackspace on one of our cloud accounts. > > Currently the entirety of the PyPA organization on Github gets 10 concurrent > builders (typically this number is 5) across all repositories. Assuming Travis > CI is able to do it (they'd need to check with their ops team, and there would > be some cost associated with things on their side as well) we could essentially > control how much concurrency we want by just throwing more Rackspace VMs at > our builds. > > Josh said they use a 2 vCPU machine w/ 4GB of ram, so looking at the Rackspace > Compute1-4 which is similar we'd be looking at the ability to run ~27 of those > VMs full time on the "standard" 2k/month free cloud offering that Rackspace > offers OSS projects. However we'd actually be able to get more than that > probably because Travis starts up the VMs on demand so anytime there aren't > tests to run we won't have any VMs running. > > Independent of this, they are also working on the ability to run custom docker > images (which means custom Linux OS images) that we can preinstall different > software into. > > Is this something we'd want to explore? Assuming that the Travis CI ops team > and such are OK with it, it could essentially let us scale up our concurrency > on Travis to whatever amount of dollars of Rackspace cloud we want to throw at > it. > > --- > Donald Stufft > PGP: 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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev --- Donald Stufft PGP: 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 terrycwk1994 at gmail.com Sun Mar 29 04:24:27 2015 From: terrycwk1994 at gmail.com (Terry Chia) Date: Sun, 29 Mar 2015 02:24:27 +0000 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: References: Message-ID: This essentially involves dropping support for RHEL 5, which IIRC was the primary motivation for 2.6 support in the first place? If we are ok with that this gets a +1 from me as it will make some of my current work like integrating Hypothesis[0] into our test suites easier since Hypothesis does not support 2.6. A full deprecation cycle will realistically take 3.5 - 4 months (I'm not as optimistic as Alex about our release timings. :P) so that should be plenty of time to cut a new pyOpenSSL release. [0]: https://github.com/pyca/cryptography/pull/1773 On Sun, Mar 29, 2015 at 3:52 AM Alex Gaynor wrote: > I think we'd want to do a full deprecation cycle on this: > > 0.9: PendingDeprecationWarning > 1.0: DeprecationWarning > 1.1: removed > > So that's like, 2.5 months notice or so? (Not sure quite how quickly we've > been releasing in past). > > Donald: How hard would it be to get download statistics for cryptography > and pyOpenSSL from the last few months by Python versoin? > > Alex > > On Sat, Mar 28, 2015 at 3:48 PM, Jean-Paul Calderone < > jean-paul at clusterhq.com> wrote: > >> Speaking as the pyOpenSSL maintainer, I'd like time to perform one last >> pyOpenSSL release along with an announcement that it will be the last >> pyOpenSSL release to support Python 2.6. Strictly speaking, I could >> probably retain Python 2.6 support in pyOpenSSL even if the cryptography >> project drops it but that seems unreasonable for several reasons (pyOpenSSL >> shares many of cryptography's reasons for wanting to drop Python 2.6 >> support, requiring that pyOpenSSL continue to work with only cryptography >> <= 0.8.1 will be a bunch of extra work, etc). >> >> I can't say exactly when the next pyOpenSSL release will be but if the >> cryptography project lays out its timeline for this then at least I'll know >> what bounds I have to work with (and I'm clearly long overdue so as long as >> you don't decide something like "tomorrow" I won't have much room to >> complain). >> >> Jean-Paul >> >> >> On Sat, Mar 28, 2015 at 3:29 PM, Alex Gaynor >> wrote: >> >>> Hi folks, >>> >>> I'd like to propose we deprecate, with the intention of removing, >>> support for Python 2.6. The reason for this is that Python 2.6 is no longer >>> receiving support for the Python core developers in any form, including >>> security releases. >>> >>> We provide a piece of security sensitive software, and I claim it would >>> be irresponsible to say it's supported on platforms which are themselves >>> not supported. >>> >>> This would affect our current downstreams, such as pyOpenSSL, Twisted, >>> and OpenStack, as well as things we'd like to be our downstreams, such as >>> Paramiko/Fabric. So I'm hoping some of them will chime in. >>> >>> By way of adding data around this: Django's latest release is 2.7/3.x >>> only, however there has been some measure of requests to add additional >>> long term support for a past release which has 2.6 support. I've seen >>> numbers from Donald that (as of the end of last year) 2.6 is ~10-15% of >>> PyPI downloads across the board. >>> >>> Thoughts? >>> >>> 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 >>> >>> >> >> _______________________________________________ >> 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 > _______________________________________________ > 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: From donald at stufft.io Sun Mar 29 07:46:07 2015 From: donald at stufft.io (Donald Stufft) Date: Sun, 29 Mar 2015 01:46:07 -0400 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: References: Message-ID: <20BCACFC-F7DC-444D-89C2-DB20AC3E1924@stufft.io> RHEL5 ships with Python 2.4, however you can get Python 2.6 from EPEL. RHEL6 ships with Python 2.6, however you can get Python 2.7 from SCL. Dropping support for Python 2.6 will mean dropping support for RHEL5 altogether and dropping support for RHEL6 without using SCL to install Python 2.7. I don?t feel strongly about if we should drop Python 2.6, I do want to point out one thing though. It?s true that Python 2.6 is no longer getting security updates from python-dev, it is also true however, that Python 2.6 *is* getting support from downstream redistributors. We *are* a security sensitive library so it?s not uncommon to tell people that if they are still stuck on Python 2.6 they can get access to the functionality of the new Python SSL module by installing pyOpenSSL (and by extension cryptography). Obviously at some point we have to tell those people enough is enough and we?re dropping support and if you want support go talk to your vendor, is this that point? I don?t know. I haven?t started dropping support for Python 2.6 in my own projects because continuing to support Python 2.6 is a minimal amount of effort over Python 2.7. It might finally be time to consider it for real. I don?t have the numbers immediately available, but I can get them. It takes me awhile to load them up but it?s not too hard to do. For what it?s worth, I do have cryptography specific numbers from September [1], however that?s a long time ago in the lifetime of cryptography so I?m not sure it?s really relevant to what things look like today. [1] https://s3.amazonaws.com/f.cl.ly/items/0E0H2A2Y2m0y1z0b0S26/stacked-py-pct.png > On Mar 28, 2015, at 10:24 PM, Terry Chia wrote: > > This essentially involves dropping support for RHEL 5, which IIRC was the primary motivation for 2.6 support in the first place? If we are ok with that this gets a +1 from me as it will make some of my current work like integrating Hypothesis[0] into our test suites easier since Hypothesis does not support 2.6. > > A full deprecation cycle will realistically take 3.5 - 4 months (I'm not as optimistic as Alex about our release timings. :P) so that should be plenty of time to cut a new pyOpenSSL release. > > [0]: https://github.com/pyca/cryptography/pull/1773 > On Sun, Mar 29, 2015 at 3:52 AM Alex Gaynor > wrote: > I think we'd want to do a full deprecation cycle on this: > > 0.9: PendingDeprecationWarning > 1.0: DeprecationWarning > 1.1: removed > > So that's like, 2.5 months notice or so? (Not sure quite how quickly we've been releasing in past). > > Donald: How hard would it be to get download statistics for cryptography and pyOpenSSL from the last few months by Python versoin? > > Alex > > On Sat, Mar 28, 2015 at 3:48 PM, Jean-Paul Calderone > wrote: > Speaking as the pyOpenSSL maintainer, I'd like time to perform one last pyOpenSSL release along with an announcement that it will be the last pyOpenSSL release to support Python 2.6. Strictly speaking, I could probably retain Python 2.6 support in pyOpenSSL even if the cryptography project drops it but that seems unreasonable for several reasons (pyOpenSSL shares many of cryptography's reasons for wanting to drop Python 2.6 support, requiring that pyOpenSSL continue to work with only cryptography <= 0.8.1 will be a bunch of extra work, etc). > > I can't say exactly when the next pyOpenSSL release will be but if the cryptography project lays out its timeline for this then at least I'll know what bounds I have to work with (and I'm clearly long overdue so as long as you don't decide something like "tomorrow" I won't have much room to complain). > > Jean-Paul > > > On Sat, Mar 28, 2015 at 3:29 PM, Alex Gaynor > wrote: > Hi folks, > > I'd like to propose we deprecate, with the intention of removing, support for Python 2.6. The reason for this is that Python 2.6 is no longer receiving support for the Python core developers in any form, including security releases. > > We provide a piece of security sensitive software, and I claim it would be irresponsible to say it's supported on platforms which are themselves not supported. > > This would affect our current downstreams, such as pyOpenSSL, Twisted, and OpenStack, as well as things we'd like to be our downstreams, such as Paramiko/Fabric. So I'm hoping some of them will chime in. > > By way of adding data around this: Django's latest release is 2.7/3.x only, however there has been some measure of requests to add additional long term support for a past release which has 2.6 support. I've seen numbers from Donald that (as of the end of last year) 2.6 is ~10-15% of PyPI downloads across the board. > > Thoughts? > > 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 > > > > _______________________________________________ > 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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev --- Donald Stufft PGP: 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 alexs at prol.etari.at Sun Mar 29 12:16:23 2015 From: alexs at prol.etari.at (Alex Stapleton) Date: Sun, 29 Mar 2015 11:16:23 +0100 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: References: Message-ID: <14c65082d68.27e9.91731227630488f1d17e3e780e9eb50a@prol.etari.at> Aren't RedHat supporting 2.6 within RHEL 6 until 2020? In principle I could be convinced this would be OK though. Particularly if we commit to continuing to do any security patches they need and the packaging situation isn't going to cause them too much disruption. On 28 March 2015 19:30:09 Alex Gaynor wrote: > Hi folks, > > I'd like to propose we deprecate, with the intention of removing, support > for Python 2.6. The reason for this is that Python 2.6 is no longer > receiving support for the Python core developers in any form, including > security releases. > > We provide a piece of security sensitive software, and I claim it would be > irresponsible to say it's supported on platforms which are themselves not > supported. > > This would affect our current downstreams, such as pyOpenSSL, Twisted, and > OpenStack, as well as things we'd like to be our downstreams, such as > Paramiko/Fabric. So I'm hoping some of them will chime in. > > By way of adding data around this: Django's latest release is 2.7/3.x only, > however there has been some measure of requests to add additional long term > support for a past release which has 2.6 support. I've seen numbers from > Donald that (as of the end of last year) 2.6 is ~10-15% of PyPI downloads > across the board. > > Thoughts? > > 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: From paul.l.kehrer at gmail.com Sun Mar 29 18:17:00 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sun, 29 Mar 2015 11:17:00 -0500 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: <20BCACFC-F7DC-444D-89C2-DB20AC3E1924@stufft.io> References: <20BCACFC-F7DC-444D-89C2-DB20AC3E1924@stufft.io> Message-ID: As Donald already mentioned, we're used to provide improved security for people who (for whatever reason) don't have the option to upgrade their Python version. I want barriers to utilization to be as low as possible so I'd prefer not to drop 2.6 support until such time as it becomes a noticeable burden to us (whether that means CI burden or code maintenance).? I'd be +1 on adding language to our docs that states we strongly discourage the usage of 2.6 and while we continue to support it users should upgrade as soon as possible. However, as a compromise, we could potentially do a significantly longer deprecation timeline for this specific issue. 2.6 until end of 2015 or something of that nature? BTW, Openstack has removed 2.6 support from kilo so that project will not be negatively affected by this decision. -Paul On March 29, 2015 at 12:46:17 AM, Donald Stufft (donald at stufft.io) wrote: RHEL5 ships with Python 2.4, however you can get Python 2.6 from EPEL. RHEL6 ships with Python 2.6, however you can get Python 2.7 from SCL. Dropping support for Python 2.6 will mean dropping support for RHEL5 altogether and dropping support for RHEL6 without using SCL to install Python 2.7. I don?t feel strongly about if we should drop Python 2.6, I do want to point out one thing though. It?s true that Python 2.6 is no longer getting security updates from python-dev, it is also true however, that Python 2.6 *is* getting support from downstream redistributors. We *are* a security sensitive library so it?s not uncommon to tell people that if they are still stuck on Python 2.6 they can get access to the functionality of the new Python SSL module by installing pyOpenSSL (and by extension cryptography). Obviously at some point we have to tell those people enough is enough and we?re dropping support and if you want support go talk to your vendor, is this that point? I don?t know. I haven?t started dropping support for Python 2.6 in my own projects because continuing to support Python 2.6 is a minimal amount of effort over Python 2.7. It might finally be time to consider it for real. I don?t have the numbers immediately available, but I can get them. It takes me awhile to load them up but it?s not too hard to do. For what it?s worth, I do have cryptography specific numbers from September [1], however that?s a long time ago in the lifetime of cryptography so I?m not sure it?s really relevant to what things look like today. [1]?https://s3.amazonaws.com/f.cl.ly/items/0E0H2A2Y2m0y1z0b0S26/stacked-py-pct.png On Mar 28, 2015, at 10:24 PM, Terry Chia wrote: This essentially involves dropping support for RHEL 5, which IIRC was the primary motivation for 2.6 support in the first place? If we are ok with that this gets a?+1 from me as it will make some of my current work like integrating Hypothesis[0] into our test suites easier since Hypothesis does not support 2.6.? A full deprecation cycle will realistically take 3.5 - 4 months (I'm not as optimistic as Alex about our release timings. :P) so that should be plenty of time to cut a new pyOpenSSL release. [0]:?https://github.com/pyca/cryptography/pull/1773 On Sun, Mar 29, 2015 at 3:52 AM Alex Gaynor wrote: I think we'd want to do a full deprecation cycle on this: 0.9: PendingDeprecationWarning 1.0: DeprecationWarning 1.1: removed So that's like, 2.5 months notice or so? (Not sure quite how quickly we've been releasing in past). Donald: How hard would it be to get download statistics for cryptography and pyOpenSSL from the last few months by Python versoin? Alex On Sat, Mar 28, 2015 at 3:48 PM, Jean-Paul Calderone wrote: Speaking as the pyOpenSSL maintainer, I'd like time to perform one last pyOpenSSL release along with an announcement that it will be the last pyOpenSSL release to support Python 2.6.? Strictly speaking, I could probably retain Python 2.6 support in pyOpenSSL even if the cryptography project drops it but that seems unreasonable for several reasons (pyOpenSSL shares many of cryptography's reasons for wanting to drop Python 2.6 support, requiring that pyOpenSSL continue to work with only cryptography <= 0.8.1 will be a bunch of extra work, etc). I can't say exactly when the next pyOpenSSL release will be but if the cryptography project lays out its timeline for this then at least I'll know what bounds I have to work with (and I'm clearly long overdue so as long as you don't decide something like "tomorrow" I won't have much room to complain). Jean-Paul On Sat, Mar 28, 2015 at 3:29 PM, Alex Gaynor wrote: Hi folks, I'd like to propose we deprecate, with the intention of removing, support for Python 2.6. The reason for this is that Python 2.6 is no longer receiving support for the Python core developers in any form, including security releases. We provide a piece of security sensitive software, and I claim it would be irresponsible to say it's supported on platforms which are themselves not supported. This would affect our current downstreams, such as pyOpenSSL, Twisted, and OpenStack, as well as things we'd like to be our downstreams, such as Paramiko/Fabric. So I'm hoping some of them will chime in. By way of adding data around this: Django's latest release is 2.7/3.x only, however there has been some measure of requests to add additional long term support for a past release which has 2.6 support. I've seen numbers from Donald that (as of the end of last year) 2.6 is ~10-15% of PyPI downloads across the board. Thoughts? 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 _______________________________________________ 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 _______________________________________________ Cryptography-dev mailing list Cryptography-dev at python.org https://mail.python.org/mailman/listinfo/cryptography-dev _______________________________________________ Cryptography-dev mailing list Cryptography-dev at python.org https://mail.python.org/mailman/listinfo/cryptography-dev --- Donald Stufft PGP: 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: From alex.gaynor at gmail.com Sun Mar 29 18:19:30 2015 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sun, 29 Mar 2015 12:19:30 -0400 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: References: <20BCACFC-F7DC-444D-89C2-DB20AC3E1924@stufft.io> Message-ID: Meaning we start emitting a warning now, with no explicit time table for really removing it? Alex On Sun, Mar 29, 2015 at 12:17 PM, Paul Kehrer wrote: > As Donald already mentioned, we're used to provide improved security for > people who (for whatever reason) don't have the option to upgrade their > Python version. I want barriers to utilization to be as low as possible so > I'd prefer not to drop 2.6 support until such time as it becomes a > noticeable burden to us (whether that means CI burden or code maintenance). > > I'd be +1 on adding language to our docs that states we strongly > discourage the usage of 2.6 and while we continue to support it users > should upgrade as soon as possible. However, as a compromise, we could > potentially do a significantly longer deprecation timeline for this > specific issue. 2.6 until end of 2015 or something of that nature? > > BTW, Openstack has removed 2.6 support from kilo so that project will not > be negatively affected by this decision. > > -Paul > > On March 29, 2015 at 12:46:17 AM, Donald Stufft (donald at stufft.io) wrote: > > RHEL5 ships with Python 2.4, however you can get Python 2.6 from EPEL. > RHEL6 ships with Python 2.6, however you can get Python 2.7 from SCL. > > Dropping support for Python 2.6 will mean dropping support for RHEL5 > altogether and dropping support for RHEL6 without using SCL to install > Python 2.7. > > I don?t feel strongly about if we should drop Python 2.6, I do want to > point out one thing though. It?s true that Python 2.6 is no longer getting > security updates from python-dev, it is also true however, that Python 2.6 > *is* getting support from downstream redistributors. We *are* a security > sensitive library so it?s not uncommon to tell people that if they are > still stuck on Python 2.6 they can get access to the functionality of the > new Python SSL module by installing pyOpenSSL (and by extension > cryptography). > > Obviously at some point we have to tell those people enough is enough and > we?re dropping support and if you want support go talk to your vendor, is > this that point? I don?t know. I haven?t started dropping support for > Python 2.6 in my own projects because continuing to support Python 2.6 is a > minimal amount of effort over Python 2.7. It might finally be time to > consider it for real. > > I don?t have the numbers immediately available, but I can get them. It > takes me awhile to load them up but it?s not too hard to do. > > For what it?s worth, I do have cryptography specific numbers from > September [1], however that?s a long time ago in the lifetime of > cryptography so I?m not sure it?s really relevant to what things look like > today. > > [1] > https://s3.amazonaws.com/f.cl.ly/items/0E0H2A2Y2m0y1z0b0S26/stacked-py-pct.png > > > On Mar 28, 2015, at 10:24 PM, Terry Chia wrote: > > This essentially involves dropping support for RHEL 5, which IIRC was > the primary motivation for 2.6 support in the first place? If we are ok > with that this gets a +1 from me as it will make some of my current work > like integrating Hypothesis[0] into our test suites easier since Hypothesis > does not support 2.6. > > A full deprecation cycle will realistically take 3.5 - 4 months (I'm not > as optimistic as Alex about our release timings. :P) so that should be > plenty of time to cut a new pyOpenSSL release. > > [0]: https://github.com/pyca/cryptography/pull/1773 > > On Sun, Mar 29, 2015 at 3:52 AM Alex Gaynor wrote: > >> I think we'd want to do a full deprecation cycle on this: >> >> 0.9: PendingDeprecationWarning >> 1.0: DeprecationWarning >> 1.1: removed >> >> So that's like, 2.5 months notice or so? (Not sure quite how quickly >> we've been releasing in past). >> >> Donald: How hard would it be to get download statistics for cryptography >> and pyOpenSSL from the last few months by Python versoin? >> >> Alex >> >> On Sat, Mar 28, 2015 at 3:48 PM, Jean-Paul Calderone < >> jean-paul at clusterhq.com> wrote: >> >>> Speaking as the pyOpenSSL maintainer, I'd like time to perform one last >>> pyOpenSSL release along with an announcement that it will be the last >>> pyOpenSSL release to support Python 2.6. Strictly speaking, I could >>> probably retain Python 2.6 support in pyOpenSSL even if the cryptography >>> project drops it but that seems unreasonable for several reasons (pyOpenSSL >>> shares many of cryptography's reasons for wanting to drop Python 2.6 >>> support, requiring that pyOpenSSL continue to work with only cryptography >>> <= 0.8.1 will be a bunch of extra work, etc). >>> >>> I can't say exactly when the next pyOpenSSL release will be but if the >>> cryptography project lays out its timeline for this then at least I'll know >>> what bounds I have to work with (and I'm clearly long overdue so as long as >>> you don't decide something like "tomorrow" I won't have much room to >>> complain). >>> >>> Jean-Paul >>> >>> >>> On Sat, Mar 28, 2015 at 3:29 PM, Alex Gaynor >>> wrote: >>> >>>> Hi folks, >>>> >>>> I'd like to propose we deprecate, with the intention of removing, >>>> support for Python 2.6. The reason for this is that Python 2.6 is no longer >>>> receiving support for the Python core developers in any form, including >>>> security releases. >>>> >>>> We provide a piece of security sensitive software, and I claim it would >>>> be irresponsible to say it's supported on platforms which are themselves >>>> not supported. >>>> >>>> This would affect our current downstreams, such as pyOpenSSL, Twisted, >>>> and OpenStack, as well as things we'd like to be our downstreams, such as >>>> Paramiko/Fabric. So I'm hoping some of them will chime in. >>>> >>>> By way of adding data around this: Django's latest release is 2.7/3.x >>>> only, however there has been some measure of requests to add additional >>>> long term support for a past release which has 2.6 support. I've seen >>>> numbers from Donald that (as of the end of last year) 2.6 is ~10-15% of >>>> PyPI downloads across the board. >>>> >>>> Thoughts? >>>> >>>> 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 >>>> >>>> >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> https://mail.python.org/mailman/listinfo/cryptography-dev >> > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > > --- > Donald Stufft > PGP: 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 > > > _______________________________________________ > 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 paul.l.kehrer at gmail.com Sun Mar 29 18:53:23 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sun, 29 Mar 2015 11:53:23 -0500 Subject: [Cryptography-dev] Dedicated Travis Builders In-Reply-To: <919C8B85-469A-4210-9890-5B05842F2C17@stufft.io> References: <919C8B85-469A-4210-9890-5B05842F2C17@stufft.io> Message-ID: (Sorry for the exposition that's about to happen, just wanted to write it all down first) We use two different CI systems right now: - Travis, which provides OS X 10.9 builds as well as linux builds (against Ubuntu 12.04 with two different versions of OpenSSL). - Jenkins, which provides CentOS 5, CentOS 6.4, CentOS 7, Debian Jessie, Debian Wheezy, FreeBSD 10.1, Ubuntu linking cryptography against LibreSSL, Ubuntu linking cryptography against OpenSSL 1.0.2{letter}, OS X 10.7, OS X 10.8, OS X 10.10, Windows Server 2008 (32-bit Pythons), and Windows Server 2012 (64-bit Pythons). Travis provides us some (large) advantages over Jenkins, including not having to manage our own fleet of builders, far better (albeit less flexible) configuration through .travis.yml, and a difficult to quantify "pleasantness" to the entire experience. So, what problems do we run into with Travis? Coverage ------------ At this time we use coveralls (which is now commenting up to 9 times on every PR for reasons that pass human understanding) to gain a view of our combined coverage. Unfortunately this system ties us to reporting coverage exclusively from Travis. This means code paths (like windows only code) cannot have coverage tracked. Speed/Reliability ---------------------- We have limited (albeit very high at the moment) concurrency available from Travis. On a typical workday it can be 1-3 hours before CI completes, which significantly impairs our ability to quickly review/merge code.??We have had occasions in the past where we've had Travis jobs waiting in the queue for over 8 hours due to reliability problems within the Travis infrastructure. Flexibility ------------ Travis provides only OS X 10.9 and Ubuntu 12.04. The openstack builder possibility solves much of the speed issue, and custom docker images would negate the need for our jenkins linux builders (of which there are currently 7). I am, however, concerned about coverage. Without being able to run more than OS X 10.9 and (potentially) various userlands of Linux via docker images we're still significantly handicapped. It is unreasonable to expect to be able to run arbitrary OSes so we'll always run a small jenkins instance for things like alternate OS X versions, FreeBSD, etc, but the lack of Windows support is painful. We have recently discussed moving entirely off Travis (https://github.com/pyca/cryptography/issues/1729), but if the above comes to fruition and there's a good way to combine coverage from multiple sources (and someone wants to own getting it deployed that isn't me) then I'd be happy to stay with Travis and only use jenkins for the edge cases. -Paul On March 28, 2015 at 5:56:31 PM, Donald Stufft (donald at stufft.io) wrote: I was talking to the Travis CI folks and they mentioned they have the possibility of using openstack builders now (or in the near future). We talked a little bit about the possibility of getting PyCA it's own dedicated set of builders in Travis CI hosted inside of Rackspace on one of our cloud accounts. Currently the entirety of the PyPA organization on Github gets 10 concurrent builders (typically this number is 5) across all repositories. Assuming Travis CI is able to do it (they'd need to check with their ops team, and there would be some cost associated with things on their side as well) we could essentially control how much concurrency we want by just throwing more Rackspace VMs at our builds. Josh said they use a 2 vCPU machine w/ 4GB of ram, so looking at the Rackspace Compute1-4 which is similar we'd be looking at the ability to run ~27 of those VMs full time on the "standard" 2k/month free cloud offering that Rackspace offers OSS projects. However we'd actually be able to get more than that probably because Travis starts up the VMs on demand so anytime there aren't tests to run we won't have any VMs running. Independent of this, they are also working on the ability to run custom docker images (which means custom Linux OS images) that we can preinstall different software into. Is this something we'd want to explore? Assuming that the Travis CI ops team and such are OK with it, it could essentially let us scale up our concurrency on Travis to whatever amount of dollars of Rackspace cloud we want to throw at it. --- Donald Stufft PGP: 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: From alex.gaynor at gmail.com Sun Mar 29 18:55:43 2015 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sun, 29 Mar 2015 12:55:43 -0400 Subject: [Cryptography-dev] Dedicated Travis Builders In-Reply-To: References: <919C8B85-469A-4210-9890-5B05842F2C17@stufft.io> Message-ID: Paul, it seems like coveralls is kind of orthagonal to this porposal, besides the fact that in the short term moving more stuff under Travis would mean coveralls included more stuff? Alex On Sun, Mar 29, 2015 at 12:53 PM, Paul Kehrer wrote: > (Sorry for the exposition that's about to happen, just wanted to write it > all down first) > > We use two different CI systems right now: > > - Travis, which provides OS X 10.9 builds as well as linux builds (against > Ubuntu 12.04 with two different versions of OpenSSL). > - Jenkins, which provides CentOS 5, CentOS 6.4, CentOS 7, Debian Jessie, > Debian Wheezy, FreeBSD 10.1, Ubuntu linking cryptography against LibreSSL, > Ubuntu linking cryptography against OpenSSL 1.0.2{letter}, OS X 10.7, OS X > 10.8, OS X 10.10, Windows Server 2008 (32-bit Pythons), and Windows Server > 2012 (64-bit Pythons). > > Travis provides us some (large) advantages over Jenkins, including not > having to manage our own fleet of builders, far better (albeit less > flexible) configuration through .travis.yml, and a difficult to quantify > "pleasantness" to the entire experience. > > So, what problems do we run into with Travis? > > Coverage > ------------ > At this time we use coveralls (which is now commenting up to 9 times on > every PR for reasons that pass human understanding) to gain a view of our > combined coverage. Unfortunately this system ties us to reporting coverage > exclusively from Travis. This means code paths (like windows only code) > cannot have coverage tracked. > > Speed/Reliability > ---------------------- > We have limited (albeit very high at the moment) concurrency available > from Travis. On a typical workday it can be 1-3 hours before CI completes, > which significantly impairs our ability to quickly review/merge code. We > have had occasions in the past where we've had Travis jobs waiting in the > queue for over 8 hours due to reliability problems within the Travis > infrastructure. > > Flexibility > ------------ > Travis provides only OS X 10.9 and Ubuntu 12.04. > > > > The openstack builder possibility solves much of the speed issue, and > custom docker images would negate the need for our jenkins linux builders > (of which there are currently 7). I am, however, concerned about coverage. > Without being able to run more than OS X 10.9 and (potentially) various > userlands of Linux via docker images we're still significantly handicapped. > It is unreasonable to expect to be able to run arbitrary OSes so we'll > always run a small jenkins instance for things like alternate OS X > versions, FreeBSD, etc, but the lack of Windows support is painful. > > We have recently discussed moving entirely off Travis ( > https://github.com/pyca/cryptography/issues/1729), but if the above comes > to fruition and there's a good way to combine coverage from multiple > sources (and someone wants to own getting it deployed that isn't me) then > I'd be happy to stay with Travis and only use jenkins for the edge cases. > > -Paul > > On March 28, 2015 at 5:56:31 PM, Donald Stufft (donald at stufft.io) wrote: > > I was talking to the Travis CI folks and they mentioned they have the > possibility of using openstack builders now (or in the near future). We > talked > a little bit about the possibility of getting PyCA it's own dedicated set > of > builders in Travis CI hosted inside of Rackspace on one of our cloud > accounts. > > Currently the entirety of the PyPA organization on Github gets 10 > concurrent > builders (typically this number is 5) across all repositories. Assuming > Travis > CI is able to do it (they'd need to check with their ops team, and there > would > be some cost associated with things on their side as well) we could > essentially > control how much concurrency we want by just throwing more Rackspace VMs > at > our builds. > > Josh said they use a 2 vCPU machine w/ 4GB of ram, so looking at the > Rackspace > Compute1-4 which is similar we'd be looking at the ability to run ~27 of > those > VMs full time on the "standard" 2k/month free cloud offering that > Rackspace > offers OSS projects. However we'd actually be able to get more than that > probably because Travis starts up the VMs on demand so anytime there > aren't > tests to run we won't have any VMs running. > > Independent of this, they are also working on the ability to run custom > docker > images (which means custom Linux OS images) that we can preinstall > different > software into. > > Is this something we'd want to explore? Assuming that the Travis CI ops > team > and such are OK with it, it could essentially let us scale up our > concurrency > on Travis to whatever amount of dollars of Rackspace cloud we want to > throw at > it. > > --- > Donald Stufft > PGP: 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 > > > _______________________________________________ > 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 paul.l.kehrer at gmail.com Sun Mar 29 18:59:40 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sun, 29 Mar 2015 11:59:40 -0500 Subject: [Cryptography-dev] Dedicated Travis Builders In-Reply-To: References: <919C8B85-469A-4210-9890-5B05842F2C17@stufft.io> Message-ID: Travis is (potentially) offering to undertake significant work on our behalf so I believe we need to have an answer to our long term coverage questions before we commit to using this solution. Being faster and having custom docker images doesn't grant us a workable coverage solution so we're going to be discussing moving entirely to jenkins again at some point in the future if we can't resolve that issue. -Paul On March 29, 2015 at 11:55:55 AM, Alex Gaynor (alex.gaynor at gmail.com) wrote: Paul, it seems like coveralls is kind of orthagonal to this porposal, besides the fact that in the short term moving more stuff under Travis would mean coveralls included more stuff? Alex On Sun, Mar 29, 2015 at 12:53 PM, Paul Kehrer wrote: (Sorry for the exposition that's about to happen, just wanted to write it all down first) We use two different CI systems right now: - Travis, which provides OS X 10.9 builds as well as linux builds (against Ubuntu 12.04 with two different versions of OpenSSL). - Jenkins, which provides CentOS 5, CentOS 6.4, CentOS 7, Debian Jessie, Debian Wheezy, FreeBSD 10.1, Ubuntu linking cryptography against LibreSSL, Ubuntu linking cryptography against OpenSSL 1.0.2{letter}, OS X 10.7, OS X 10.8, OS X 10.10, Windows Server 2008 (32-bit Pythons), and Windows Server 2012 (64-bit Pythons). Travis provides us some (large) advantages over Jenkins, including not having to manage our own fleet of builders, far better (albeit less flexible) configuration through .travis.yml, and a difficult to quantify "pleasantness" to the entire experience. So, what problems do we run into with Travis? Coverage ------------ At this time we use coveralls (which is now commenting up to 9 times on every PR for reasons that pass human understanding) to gain a view of our combined coverage. Unfortunately this system ties us to reporting coverage exclusively from Travis. This means code paths (like windows only code) cannot have coverage tracked. Speed/Reliability ---------------------- We have limited (albeit very high at the moment) concurrency available from Travis. On a typical workday it can be 1-3 hours before CI completes, which significantly impairs our ability to quickly review/merge code.??We have had occasions in the past where we've had Travis jobs waiting in the queue for over 8 hours due to reliability problems within the Travis infrastructure. Flexibility ------------ Travis provides only OS X 10.9 and Ubuntu 12.04. The openstack builder possibility solves much of the speed issue, and custom docker images would negate the need for our jenkins linux builders (of which there are currently 7). I am, however, concerned about coverage. Without being able to run more than OS X 10.9 and (potentially) various userlands of Linux via docker images we're still significantly handicapped. It is unreasonable to expect to be able to run arbitrary OSes so we'll always run a small jenkins instance for things like alternate OS X versions, FreeBSD, etc, but the lack of Windows support is painful. We have recently discussed moving entirely off Travis (https://github.com/pyca/cryptography/issues/1729), but if the above comes to fruition and there's a good way to combine coverage from multiple sources (and someone wants to own getting it deployed that isn't me) then I'd be happy to stay with Travis and only use jenkins for the edge cases. -Paul On March 28, 2015 at 5:56:31 PM, Donald Stufft (donald at stufft.io) wrote: I was talking to the Travis CI folks and they mentioned they have the possibility of using openstack builders now (or in the near future). We talked a little bit about the possibility of getting PyCA it's own dedicated set of builders in Travis CI hosted inside of Rackspace on one of our cloud accounts. Currently the entirety of the PyPA organization on Github gets 10 concurrent builders (typically this number is 5) across all repositories. Assuming Travis CI is able to do it (they'd need to check with their ops team, and there would be some cost associated with things on their side as well) we could essentially control how much concurrency we want by just throwing more Rackspace VMs at our builds. Josh said they use a 2 vCPU machine w/ 4GB of ram, so looking at the Rackspace Compute1-4 which is similar we'd be looking at the ability to run ~27 of those VMs full time on the "standard" 2k/month free cloud offering that Rackspace offers OSS projects. However we'd actually be able to get more than that probably because Travis starts up the VMs on demand so anytime there aren't tests to run we won't have any VMs running. Independent of this, they are also working on the ability to run custom docker images (which means custom Linux OS images) that we can preinstall different software into. Is this something we'd want to explore? Assuming that the Travis CI ops team and such are OK with it, it could essentially let us scale up our concurrency on Travis to whatever amount of dollars of Rackspace cloud we want to throw at it. --- Donald Stufft PGP: 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 _______________________________________________ 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 _______________________________________________ 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: From alex.gaynor at gmail.com Sun Mar 29 19:02:14 2015 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sun, 29 Mar 2015 13:02:14 -0400 Subject: [Cryptography-dev] Dedicated Travis Builders In-Reply-To: References: <919C8B85-469A-4210-9890-5B05842F2C17@stufft.io> Message-ID: Sorry, I'm not following, it seems like you're assuming that "thing that replaces coveralls" wouldn't be able to work with both Travis and Jenkins? Alex On Sun, Mar 29, 2015 at 12:59 PM, Paul Kehrer wrote: > Travis is (potentially) offering to undertake significant work on our > behalf so I believe we need to have an answer to our long term coverage > questions before we commit to using this solution. Being faster and having > custom docker images doesn't grant us a workable coverage solution so we're > going to be discussing moving entirely to jenkins again at some point in > the future if we can't resolve that issue. > > -Paul > > On March 29, 2015 at 11:55:55 AM, Alex Gaynor (alex.gaynor at gmail.com) > wrote: > > Paul, it seems like coveralls is kind of orthagonal to this porposal, > besides the fact that in the short term moving more stuff under Travis > would mean coveralls included more stuff? > > Alex > > On Sun, Mar 29, 2015 at 12:53 PM, Paul Kehrer > wrote: > >> (Sorry for the exposition that's about to happen, just wanted to write >> it all down first) >> >> We use two different CI systems right now: >> >> - Travis, which provides OS X 10.9 builds as well as linux builds >> (against Ubuntu 12.04 with two different versions of OpenSSL). >> - Jenkins, which provides CentOS 5, CentOS 6.4, CentOS 7, Debian Jessie, >> Debian Wheezy, FreeBSD 10.1, Ubuntu linking cryptography against LibreSSL, >> Ubuntu linking cryptography against OpenSSL 1.0.2{letter}, OS X 10.7, OS X >> 10.8, OS X 10.10, Windows Server 2008 (32-bit Pythons), and Windows Server >> 2012 (64-bit Pythons). >> >> Travis provides us some (large) advantages over Jenkins, including not >> having to manage our own fleet of builders, far better (albeit less >> flexible) configuration through .travis.yml, and a difficult to quantify >> "pleasantness" to the entire experience. >> >> So, what problems do we run into with Travis? >> >> Coverage >> ------------ >> At this time we use coveralls (which is now commenting up to 9 times on >> every PR for reasons that pass human understanding) to gain a view of our >> combined coverage. Unfortunately this system ties us to reporting coverage >> exclusively from Travis. This means code paths (like windows only code) >> cannot have coverage tracked. >> >> Speed/Reliability >> ---------------------- >> We have limited (albeit very high at the moment) concurrency available >> from Travis. On a typical workday it can be 1-3 hours before CI completes, >> which significantly impairs our ability to quickly review/merge code. We >> have had occasions in the past where we've had Travis jobs waiting in the >> queue for over 8 hours due to reliability problems within the Travis >> infrastructure. >> >> Flexibility >> ------------ >> Travis provides only OS X 10.9 and Ubuntu 12.04. >> >> >> >> The openstack builder possibility solves much of the speed issue, and >> custom docker images would negate the need for our jenkins linux builders >> (of which there are currently 7). I am, however, concerned about coverage. >> Without being able to run more than OS X 10.9 and (potentially) various >> userlands of Linux via docker images we're still significantly handicapped. >> It is unreasonable to expect to be able to run arbitrary OSes so we'll >> always run a small jenkins instance for things like alternate OS X >> versions, FreeBSD, etc, but the lack of Windows support is painful. >> >> We have recently discussed moving entirely off Travis ( >> https://github.com/pyca/cryptography/issues/1729), but if the above >> comes to fruition and there's a good way to combine coverage from multiple >> sources (and someone wants to own getting it deployed that isn't me) then >> I'd be happy to stay with Travis and only use jenkins for the edge cases. >> >> -Paul >> >> On March 28, 2015 at 5:56:31 PM, Donald Stufft (donald at stufft.io) wrote: >> >> I was talking to the Travis CI folks and they mentioned they have the >> possibility of using openstack builders now (or in the near future). We >> talked >> a little bit about the possibility of getting PyCA it's own dedicated set >> of >> builders in Travis CI hosted inside of Rackspace on one of our cloud >> accounts. >> >> Currently the entirety of the PyPA organization on Github gets 10 >> concurrent >> builders (typically this number is 5) across all repositories. Assuming >> Travis >> CI is able to do it (they'd need to check with their ops team, and there >> would >> be some cost associated with things on their side as well) we could >> essentially >> control how much concurrency we want by just throwing more Rackspace VMs >> at >> our builds. >> >> Josh said they use a 2 vCPU machine w/ 4GB of ram, so looking at the >> Rackspace >> Compute1-4 which is similar we'd be looking at the ability to run ~27 of >> those >> VMs full time on the "standard" 2k/month free cloud offering that >> Rackspace >> offers OSS projects. However we'd actually be able to get more than that >> probably because Travis starts up the VMs on demand so anytime there >> aren't >> tests to run we won't have any VMs running. >> >> Independent of this, they are also working on the ability to run custom >> docker >> images (which means custom Linux OS images) that we can preinstall >> different >> software into. >> >> Is this something we'd want to explore? Assuming that the Travis CI ops >> team >> and such are OK with it, it could essentially let us scale up our >> concurrency >> on Travis to whatever amount of dollars of Rackspace cloud we want to >> throw at >> it. >> >> --- >> Donald Stufft >> PGP: 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 >> >> >> _______________________________________________ >> 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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://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 warner at lothar.com Sun Mar 29 20:39:46 2015 From: warner at lothar.com (Brian Warner) Date: Sun, 29 Mar 2015 11:39:46 -0700 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: References: Message-ID: <551846F2.1070406@lothar.com> On 3/28/15 7:24 PM, Terry Chia wrote: > This essentially involves dropping support for RHEL 5, which IIRC was > the primary motivation for 2.6 support in the first place? Incidentally, Ubuntu 10.04.4 LTS ("Lucid") still ships with py2.6, and doesn't appear to have a py2.7 package available (at least in the normal places). Fortunately Lucid's EOL[1] is coming soon, 30-Apr-2015. Looking through various linux distributions[2], it appears that CentOS-6.6 is also py2.6-only[3]. I don't use CentOS, but I guess it's meant to be RHEL-compatible, so it's probably an equivalent problem to RHEL compatibility. FreeBSD-8.2 is EOL Dec-2015 and is py2.6. These days, for my personal projects, I'm supporting 2.6/2.7/3.3/3.4 . I haven't really found significant differences between 2.6 and 2.7 that make me wish to drop 2.6 support, but OTOH I don't do a lot of new C extension development. cheers, -Brian [1]: https://wiki.ubuntu.com/Releases [2]: http://distrowatch.com/ [3]: http://distrowatch.com/table.php?distribution=centos From mcepl at cepl.eu Sun Mar 29 21:08:50 2015 From: mcepl at cepl.eu (=?UTF-8?B?TWF0xJtqIENlcGw=?=) Date: Sun, 29 Mar 2015 21:08:50 +0200 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: <14c65082d68.27e9.91731227630488f1d17e3e780e9eb50a@prol.etari.at> References: <14c65082d68.27e9.91731227630488f1d17e3e780e9eb50a@prol.etari.at> Message-ID: <55184DC2.1020306@cepl.eu> On 29/03/15 12:16, Alex Stapleton wrote: > Aren't RedHat supporting 2.6 within RHEL 6 until 2020? Yes, we will. Most likely even a little bit longer (https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle). I would strongly plea for not dropping 2.6. One of the reasons I like this whole project (and why as one of co-maintainer of the upstream of M2Crypto I am suggesting it to all my users) is that I hope it could be finally one true Python cryptographic library (after all, "There should be one -- and preferably only one -- obvious way to do it."). If PyCA could finally kill all those other projects like M2Crypto, python-crypto (please!) et all, it would be the great thing. However, I believe, the key to this mission is that PyCA needs to support all reasonably supported versions of Python first (BTW, does PyCA work with Jython?), otherwise all those other crypto libraries still have raison d'?tre. Mat?j -- http://www.ceplovi.cz/matej/, Jabber: mcepl at ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC A day without sunshine is like night. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: OpenPGP digital signature URL: From donald at stufft.io Sun Mar 29 21:50:32 2015 From: donald at stufft.io (Donald Stufft) Date: Sun, 29 Mar 2015 15:50:32 -0400 Subject: [Cryptography-dev] Dedicated Travis Builders In-Reply-To: References: <919C8B85-469A-4210-9890-5B05842F2C17@stufft.io> Message-ID: <7EE38D36-1763-4D0A-B0CB-3E34EA5AAF8C@stufft.io> > On Mar 29, 2015, at 12:53 PM, Paul Kehrer wrote: > > It is unreasonable to expect to be able to run arbitrary OSes so we'll always run a small jenkins instance for things like alternate OS X versions, FreeBSD, etc, but the lack of Windows support is painful. For whatever it?s worth, I introduced Travis CI to a Microsoft employee who wanted to help them get Windows support something like ~2 weeks ago or so. Windows support is on their roadmap. FreeBSD support and the like isn?t? (though if they are just spinning up Openstack Cloud images and ssh?ing into them and running commands, I wonder if it?s possible to use custom openstack images per matrix item. If it is FreeBSD would probably just work depending on what Travis expects to exist on the target host. It would probably involve us needing to manage our own images if it even did work, and I have no idea if that capability is possible or even likely. --- Donald Stufft PGP: 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 donald at stufft.io Sun Mar 29 21:51:36 2015 From: donald at stufft.io (Donald Stufft) Date: Sun, 29 Mar 2015 15:51:36 -0400 Subject: [Cryptography-dev] Dedicated Travis Builders In-Reply-To: References: <919C8B85-469A-4210-9890-5B05842F2C17@stufft.io> Message-ID: <3B39E5CC-D8EB-4502-9FFD-22E3F145BF8B@stufft.io> One option for coveralls replacement is having each Jenkins job export the .coverage file as an artifact, and then have another job which consumes all of the .coverage files from those jobs and combines them. That would be Jenkins specific if we went with that solution. > On Mar 29, 2015, at 1:02 PM, Alex Gaynor wrote: > > Sorry, I'm not following, it seems like you're assuming that "thing that replaces coveralls" wouldn't be able to work with both Travis and Jenkins? > > Alex > > On Sun, Mar 29, 2015 at 12:59 PM, Paul Kehrer > wrote: > Travis is (potentially) offering to undertake significant work on our behalf so I believe we need to have an answer to our long term coverage questions before we commit to using this solution. Being faster and having custom docker images doesn't grant us a workable coverage solution so we're going to be discussing moving entirely to jenkins again at some point in the future if we can't resolve that issue. > > -Paul > > On March 29, 2015 at 11:55:55 AM, Alex Gaynor (alex.gaynor at gmail.com ) wrote: > >> Paul, it seems like coveralls is kind of orthagonal to this porposal, besides the fact that in the short term moving more stuff under Travis would mean coveralls included more stuff? >> >> Alex >> >> On Sun, Mar 29, 2015 at 12:53 PM, Paul Kehrer > wrote: >> (Sorry for the exposition that's about to happen, just wanted to write it all down first) >> >> We use two different CI systems right now: >> >> - Travis, which provides OS X 10.9 builds as well as linux builds (against Ubuntu 12.04 with two different versions of OpenSSL). >> - Jenkins, which provides CentOS 5, CentOS 6.4, CentOS 7, Debian Jessie, Debian Wheezy, FreeBSD 10.1, Ubuntu linking cryptography against LibreSSL, Ubuntu linking cryptography against OpenSSL 1.0.2{letter}, OS X 10.7, OS X 10.8, OS X 10.10, Windows Server 2008 (32-bit Pythons), and Windows Server 2012 (64-bit Pythons). >> >> Travis provides us some (large) advantages over Jenkins, including not having to manage our own fleet of builders, far better (albeit less flexible) configuration through .travis.yml, and a difficult to quantify "pleasantness" to the entire experience. >> >> So, what problems do we run into with Travis? >> >> Coverage >> ------------ >> At this time we use coveralls (which is now commenting up to 9 times on every PR for reasons that pass human understanding) to gain a view of our combined coverage. Unfortunately this system ties us to reporting coverage exclusively from Travis. This means code paths (like windows only code) cannot have coverage tracked. >> >> Speed/Reliability >> ---------------------- >> We have limited (albeit very high at the moment) concurrency available from Travis. On a typical workday it can be 1-3 hours before CI completes, which significantly impairs our ability to quickly review/merge code. We have had occasions in the past where we've had Travis jobs waiting in the queue for over 8 hours due to reliability problems within the Travis infrastructure. >> >> Flexibility >> ------------ >> Travis provides only OS X 10.9 and Ubuntu 12.04. >> >> >> >> The openstack builder possibility solves much of the speed issue, and custom docker images would negate the need for our jenkins linux builders (of which there are currently 7). I am, however, concerned about coverage. Without being able to run more than OS X 10.9 and (potentially) various userlands of Linux via docker images we're still significantly handicapped. It is unreasonable to expect to be able to run arbitrary OSes so we'll always run a small jenkins instance for things like alternate OS X versions, FreeBSD, etc, but the lack of Windows support is painful. >> >> We have recently discussed moving entirely off Travis (https://github.com/pyca/cryptography/issues/1729 ), but if the above comes to fruition and there's a good way to combine coverage from multiple sources (and someone wants to own getting it deployed that isn't me) then I'd be happy to stay with Travis and only use jenkins for the edge cases. >> >> -Paul >> >> On March 28, 2015 at 5:56:31 PM, Donald Stufft (donald at stufft.io ) wrote: >> >>> I was talking to the Travis CI folks and they mentioned they have the >>> possibility of using openstack builders now (or in the near future). We talked >>> a little bit about the possibility of getting PyCA it's own dedicated set of >>> builders in Travis CI hosted inside of Rackspace on one of our cloud accounts. >>> >>> Currently the entirety of the PyPA organization on Github gets 10 concurrent >>> builders (typically this number is 5) across all repositories. Assuming Travis >>> CI is able to do it (they'd need to check with their ops team, and there would >>> be some cost associated with things on their side as well) we could essentially >>> control how much concurrency we want by just throwing more Rackspace VMs at >>> our builds. >>> >>> Josh said they use a 2 vCPU machine w/ 4GB of ram, so looking at the Rackspace >>> Compute1-4 which is similar we'd be looking at the ability to run ~27 of those >>> VMs full time on the "standard" 2k/month free cloud offering that Rackspace >>> offers OSS projects. However we'd actually be able to get more than that >>> probably because Travis starts up the VMs on demand so anytime there aren't >>> tests to run we won't have any VMs running. >>> >>> Independent of this, they are also working on the ability to run custom docker >>> images (which means custom Linux OS images) that we can preinstall different >>> software into. >>> >>> Is this something we'd want to explore? Assuming that the Travis CI ops team >>> and such are OK with it, it could essentially let us scale up our concurrency >>> on Travis to whatever amount of dollars of Rackspace cloud we want to throw at >>> it. >>> >>> --- >>> Donald Stufft >>> PGP: 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 >> >> _______________________________________________ >> 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 >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> https://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 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev --- Donald Stufft PGP: 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 paul.l.kehrer at gmail.com Sun Mar 29 22:30:52 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sun, 29 Mar 2015 15:30:52 -0500 Subject: [Cryptography-dev] Dedicated Travis Builders In-Reply-To: References: <919C8B85-469A-4210-9890-5B05842F2C17@stufft.io> Message-ID: (we had some conversation in IRC regarding this, but here is a summary of my remarks) I would feel terrible if we tell the Travis people we want them to do all this work, then ultimately decide we need to move off Travis because doing combined coverage there is simple. If we do go down this path then in the future we'll need to deploy a coverage service that can aggregate data from both Travis and jenkins. We've talked about that in the past (and Donald wrote https://github.com/dstufft/converge) but nobody has been willing to step up and own that to date. :( Maybe we can get some volunteers for this effort? Anybody out there want to help? -Paul On March 29, 2015 at 12:02:29 PM, Alex Gaynor (alex.gaynor at gmail.com) wrote: Sorry, I'm not following, it seems like you're assuming that "thing that replaces coveralls" wouldn't be able to work with both Travis and Jenkins? Alex On Sun, Mar 29, 2015 at 12:59 PM, Paul Kehrer wrote: Travis is (potentially) offering to undertake significant work on our behalf so I believe we need to have an answer to our long term coverage questions before we commit to using this solution. Being faster and having custom docker images doesn't grant us a workable coverage solution so we're going to be discussing moving entirely to jenkins again at some point in the future if we can't resolve that issue. -Paul On March 29, 2015 at 11:55:55 AM, Alex Gaynor (alex.gaynor at gmail.com) wrote: Paul, it seems like coveralls is kind of orthagonal to this porposal, besides the fact that in the short term moving more stuff under Travis would mean coveralls included more stuff? Alex On Sun, Mar 29, 2015 at 12:53 PM, Paul Kehrer wrote: (Sorry for the exposition that's about to happen, just wanted to write it all down first) We use two different CI systems right now: - Travis, which provides OS X 10.9 builds as well as linux builds (against Ubuntu 12.04 with two different versions of OpenSSL). - Jenkins, which provides CentOS 5, CentOS 6.4, CentOS 7, Debian Jessie, Debian Wheezy, FreeBSD 10.1, Ubuntu linking cryptography against LibreSSL, Ubuntu linking cryptography against OpenSSL 1.0.2{letter}, OS X 10.7, OS X 10.8, OS X 10.10, Windows Server 2008 (32-bit Pythons), and Windows Server 2012 (64-bit Pythons). Travis provides us some (large) advantages over Jenkins, including not having to manage our own fleet of builders, far better (albeit less flexible) configuration through .travis.yml, and a difficult to quantify "pleasantness" to the entire experience. So, what problems do we run into with Travis? Coverage ------------ At this time we use coveralls (which is now commenting up to 9 times on every PR for reasons that pass human understanding) to gain a view of our combined coverage. Unfortunately this system ties us to reporting coverage exclusively from Travis. This means code paths (like windows only code) cannot have coverage tracked. Speed/Reliability ---------------------- We have limited (albeit very high at the moment) concurrency available from Travis. On a typical workday it can be 1-3 hours before CI completes, which significantly impairs our ability to quickly review/merge code.??We have had occasions in the past where we've had Travis jobs waiting in the queue for over 8 hours due to reliability problems within the Travis infrastructure. Flexibility ------------ Travis provides only OS X 10.9 and Ubuntu 12.04. The openstack builder possibility solves much of the speed issue, and custom docker images would negate the need for our jenkins linux builders (of which there are currently 7). I am, however, concerned about coverage. Without being able to run more than OS X 10.9 and (potentially) various userlands of Linux via docker images we're still significantly handicapped. It is unreasonable to expect to be able to run arbitrary OSes so we'll always run a small jenkins instance for things like alternate OS X versions, FreeBSD, etc, but the lack of Windows support is painful. We have recently discussed moving entirely off Travis (https://github.com/pyca/cryptography/issues/1729), but if the above comes to fruition and there's a good way to combine coverage from multiple sources (and someone wants to own getting it deployed that isn't me) then I'd be happy to stay with Travis and only use jenkins for the edge cases. -Paul On March 28, 2015 at 5:56:31 PM, Donald Stufft (donald at stufft.io) wrote: I was talking to the Travis CI folks and they mentioned they have the possibility of using openstack builders now (or in the near future). We talked a little bit about the possibility of getting PyCA it's own dedicated set of builders in Travis CI hosted inside of Rackspace on one of our cloud accounts. Currently the entirety of the PyPA organization on Github gets 10 concurrent builders (typically this number is 5) across all repositories. Assuming Travis CI is able to do it (they'd need to check with their ops team, and there would be some cost associated with things on their side as well) we could essentially control how much concurrency we want by just throwing more Rackspace VMs at our builds. Josh said they use a 2 vCPU machine w/ 4GB of ram, so looking at the Rackspace Compute1-4 which is similar we'd be looking at the ability to run ~27 of those VMs full time on the "standard" 2k/month free cloud offering that Rackspace offers OSS projects. However we'd actually be able to get more than that probably because Travis starts up the VMs on demand so anytime there aren't tests to run we won't have any VMs running. Independent of this, they are also working on the ability to run custom docker images (which means custom Linux OS images) that we can preinstall different software into. Is this something we'd want to explore? Assuming that the Travis CI ops team and such are OK with it, it could essentially let us scale up our concurrency on Travis to whatever amount of dollars of Rackspace cloud we want to throw at it. --- Donald Stufft PGP: 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 _______________________________________________ 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 _______________________________________________ Cryptography-dev mailing list Cryptography-dev at python.org https://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 _______________________________________________ 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: From paul.l.kehrer at gmail.com Sun Mar 29 22:43:51 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sun, 29 Mar 2015 15:43:51 -0500 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: <55184DC2.1020306@cepl.eu> References: <14c65082d68.27e9.91731227630488f1d17e3e780e9eb50a@prol.etari.at> <55184DC2.1020306@cepl.eu> Message-ID: Do you think a warning on import that suggests an upgrade (similar to what requests does for Python < 2.7.9) without removing support is a reasonable path forward? Jython doesn't support C extensions so not right now. There are some efforts (http://jyni.org) to add support for it and in some past conversations with jython devs they've talked a bit about jffi, but for now we don't work there. On March 29, 2015 at 2:28:54 PM, Mat?j Cepl (mcepl at cepl.eu) wrote: On 29/03/15 12:16, Alex Stapleton wrote: > Aren't RedHat supporting 2.6 within RHEL 6 until 2020? Yes, we will. Most likely even a little bit longer (https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle). I would strongly plea for not dropping 2.6. One of the reasons I like this whole project (and why as one of co-maintainer of the upstream of M2Crypto I am suggesting it to all my users) is that I hope it could be finally one true Python cryptographic library (after all, "There should be one -- and preferably only one -- obvious way to do it."). If PyCA could finally kill all those other projects like M2Crypto, python-crypto (please!) et all, it would be the great thing. However, I believe, the key to this mission is that PyCA needs to support all reasonably supported versions of Python first (BTW, does PyCA work with Jython?), otherwise all those other crypto libraries still have raison d'?tre. Mat?j -- http://www.ceplovi.cz/matej/, Jabber: mcepl at ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC A day without sunshine is like night. _______________________________________________ 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: From alex.gaynor at gmail.com Sun Mar 29 22:45:17 2015 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sun, 29 Mar 2015 16:45:17 -0400 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: References: <14c65082d68.27e9.91731227630488f1d17e3e780e9eb50a@prol.etari.at> <55184DC2.1020306@cepl.eu> Message-ID: I think emitting a DeprecationWarning, with no timetable for actually dropping support, would be a great way forward, and long term we can use download statistics to inform a final decision. Alex On Sun, Mar 29, 2015 at 4:43 PM, Paul Kehrer wrote: > Do you think a warning on import that suggests an upgrade (similar to what > requests does for Python < 2.7.9) without removing support is a reasonable > path forward? > > Jython doesn't support C extensions so not right now. There are some > efforts (http://jyni.org) to add support for it and in some past > conversations with jython devs they've talked a bit about jffi, but for now > we don't work there. > > On March 29, 2015 at 2:28:54 PM, Mat?j Cepl (mcepl at cepl.eu) wrote: > > On 29/03/15 12:16, Alex Stapleton wrote: > > Aren't RedHat supporting 2.6 within RHEL 6 until 2020? > > Yes, we will. Most likely even a little bit longer > (https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle). > > > I would strongly plea for not dropping 2.6. One of the reasons I like > this whole project (and why as one of co-maintainer of the upstream of > M2Crypto I am suggesting it to all my users) is that I hope it could > be finally one true Python cryptographic library (after all, "There > should be one -- and preferably only one -- obvious way to do it."). > If PyCA could finally kill all those other projects like M2Crypto, > python-crypto (please!) et all, it would be the great thing. > > However, I believe, the key to this mission is that PyCA needs to > support all reasonably supported versions of Python first (BTW, does > PyCA work with Jython?), otherwise all those other crypto libraries > still have raison d'?tre. > > Mat?j > > -- > http://www.ceplovi.cz/matej/, Jabber: mcepl at ceplovi.cz > GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC > > A day without sunshine is like night. > > ------------------------------ > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://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 terrycwk1994 at gmail.com Mon Mar 30 00:52:04 2015 From: terrycwk1994 at gmail.com (Terry Chia) Date: Sun, 29 Mar 2015 22:52:04 +0000 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: References: <14c65082d68.27e9.91731227630488f1d17e3e780e9eb50a@prol.etari.at> <55184DC2.1020306@cepl.eu> Message-ID: Download statistics on PyPi doesn't show the whole picture if we are talking about distro support though. +1 on a long term DeprecationWarning. On Mon, 30 Mar 2015 at 4:45 am Alex Gaynor wrote: > I think emitting a DeprecationWarning, with no timetable for actually > dropping support, would be a great way forward, and long term we can use > download statistics to inform a final decision. > > Alex > > On Sun, Mar 29, 2015 at 4:43 PM, Paul Kehrer > wrote: > >> Do you think a warning on import that suggests an upgrade (similar to >> what requests does for Python < 2.7.9) without removing support is a >> reasonable path forward? >> >> Jython doesn't support C extensions so not right now. There are some >> efforts (http://jyni.org) to add support for it and in some past >> conversations with jython devs they've talked a bit about jffi, but for now >> we don't work there. >> >> On March 29, 2015 at 2:28:54 PM, Mat?j Cepl (mcepl at cepl.eu) wrote: >> >> On 29/03/15 12:16, Alex Stapleton wrote: >> > Aren't RedHat supporting 2.6 within RHEL 6 until 2020? >> >> Yes, we will. Most likely even a little bit longer >> ( >> https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle). >> >> >> I would strongly plea for not dropping 2.6. One of the reasons I like >> this whole project (and why as one of co-maintainer of the upstream of >> M2Crypto I am suggesting it to all my users) is that I hope it could >> be finally one true Python cryptographic library (after all, "There >> should be one -- and preferably only one -- obvious way to do it."). >> If PyCA could finally kill all those other projects like M2Crypto, >> python-crypto (please!) et all, it would be the great thing. >> >> However, I believe, the key to this mission is that PyCA needs to >> support all reasonably supported versions of Python first (BTW, does >> PyCA work with Jython?), otherwise all those other crypto libraries >> still have raison d'?tre. >> >> Mat?j >> >> -- >> http://www.ceplovi.cz/matej/, Jabber: mcepl at ceplovi.cz >> GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC >> >> A day without sunshine is like night. >> >> ------------------------------ >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> https://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 > _______________________________________________ > 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: From alex.gaynor at gmail.com Mon Mar 30 00:56:03 2015 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sun, 29 Mar 2015 18:56:03 -0400 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: References: <14c65082d68.27e9.91731227630488f1d17e3e780e9eb50a@prol.etari.at> <55184DC2.1020306@cepl.eu> Message-ID: Anyone using Python 2.6 does not have cryptography available in their distros repos. Alex On Sun, Mar 29, 2015 at 6:52 PM, Terry Chia wrote: > Download statistics on PyPi doesn't show the whole picture if we are > talking about distro support though. > > +1 on a long term DeprecationWarning. > On Mon, 30 Mar 2015 at 4:45 am Alex Gaynor wrote: > >> I think emitting a DeprecationWarning, with no timetable for actually >> dropping support, would be a great way forward, and long term we can use >> download statistics to inform a final decision. >> >> Alex >> >> On Sun, Mar 29, 2015 at 4:43 PM, Paul Kehrer >> wrote: >> >>> Do you think a warning on import that suggests an upgrade (similar to >>> what requests does for Python < 2.7.9) without removing support is a >>> reasonable path forward? >>> >>> Jython doesn't support C extensions so not right now. There are some >>> efforts (http://jyni.org) to add support for it and in some past >>> conversations with jython devs they've talked a bit about jffi, but for now >>> we don't work there. >>> >>> On March 29, 2015 at 2:28:54 PM, Mat?j Cepl (mcepl at cepl.eu) wrote: >>> >>> On 29/03/15 12:16, Alex Stapleton wrote: >>> > Aren't RedHat supporting 2.6 within RHEL 6 until 2020? >>> >>> Yes, we will. Most likely even a little bit longer >>> ( >>> https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle). >>> >>> >>> I would strongly plea for not dropping 2.6. One of the reasons I like >>> this whole project (and why as one of co-maintainer of the upstream of >>> M2Crypto I am suggesting it to all my users) is that I hope it could >>> be finally one true Python cryptographic library (after all, "There >>> should be one -- and preferably only one -- obvious way to do it."). >>> If PyCA could finally kill all those other projects like M2Crypto, >>> python-crypto (please!) et all, it would be the great thing. >>> >>> However, I believe, the key to this mission is that PyCA needs to >>> support all reasonably supported versions of Python first (BTW, does >>> PyCA work with Jython?), otherwise all those other crypto libraries >>> still have raison d'?tre. >>> >>> Mat?j >>> >>> -- >>> http://www.ceplovi.cz/matej/, Jabber: mcepl at ceplovi.cz >>> GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC >>> >>> A day without sunshine is like night. >>> >>> ------------------------------ >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> https://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 >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> https://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 mcepl at cepl.eu Mon Mar 30 10:09:56 2015 From: mcepl at cepl.eu (=?UTF-8?B?TWF0xJtqIENlcGw=?=) Date: Mon, 30 Mar 2015 10:09:56 +0200 Subject: [Cryptography-dev] Unsupported platforms? In-Reply-To: References: <14c65082d68.27e9.91731227630488f1d17e3e780e9eb50a@prol.etari.at> <55184DC2.1020306@cepl.eu> Message-ID: <551904D4.8050704@cepl.eu> On 29/03/15 22:43, Paul Kehrer wrote: > Do you think a warning on import that suggests an upgrade (similar to > what requests does for Python < 2.7.9) without removing support is a > reasonable path forward? Yes, that would be perfect (we can patch it out anyway). > Jython doesn't support C extensions so not right now. There are some > efforts (http://jyni.org) to add support for it and in some past > conversations with jython devs they've talked a bit about jffi, but for > now we don't work there. Well my thoughts were more in the line of having Jython-only Java-crypto backend, so that one could use the same PyCA API over all projects, but that's another issue, not related to 2.6 by any means. Although, jython barely gets to 2.7 sometime now, right? Best, Mat?j -- http://www.ceplovi.cz/matej/, Jabber: mcepl at ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. -- R. P. Feynman's concluding sentence in his appendix to the Challenger Report -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: OpenPGP digital signature URL: