From paul.l.kehrer at gmail.com Wed Nov 18 23:10:40 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 18 Nov 2015 22:10:40 -0600 Subject: [Cryptography-dev] PyCA cryptography 1.1.1 released Message-ID: PyCA/cryptography (https://github.com/pyca/cryptography) 1.1.1 has been released. cryptography is a package which provides cryptographic recipes and primitives to Python developers. Our goal is for it to be your "cryptographic standard library". We support Python 2.6-2.7, Python 3.3+, and PyPy. Changelog: * Fixed several small bugs related to compiling the OpenSSL bindings with unusual OpenSSL configurations. * Resolved an issue where, depending on the method of installation and which Python interpreter they were using, users on El Capitan (OS X 10.11) may have seen an InternalError on import. Thanks to the users who donated their time in tracking down and resolving these issues. -Paul Kehrer (reaperhulk) -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.trauschke at gmail.com Wed Nov 25 10:57:28 2015 From: erik.trauschke at gmail.com (Erik Trauschke) Date: Wed, 25 Nov 2015 07:57:28 -0800 Subject: [Cryptography-dev] Should datetime objects returned by not_valid_before, etc contain timezone info? Message-ID: I noticed that when ever we return datetime objects which come out of backend.py`_parse_asn1_time(), they don't have a tzinfo attached. Afaik, these values should always be UTC but for someone consuming just the result of not_valid_before, etc. that might not be clear. I think it should be possible to add this to _parse_asn1_time() so that we indicate that these are UTC times. I know it's a bit painful in Python <3.2 because we have to implement the tzinfo class ourself but it's also not that much code. Erik From paul.l.kehrer at gmail.com Wed Nov 25 11:39:39 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 25 Nov 2015 10:39:39 -0600 Subject: [Cryptography-dev] Should datetime objects returned by not_valid_before, etc contain timezone info? In-Reply-To: References: Message-ID: The documentation states that these are na?ve datetimes representing UTC, but it is true that you can't tell by introspecting the object itself. Do you see a significant advantage to attaching an explicit timezone to them outside of being able to introspect the return value in a REPL and see that it's UTC? -Paul On November 25, 2015 at 9:57:40 AM, Erik Trauschke (erik.trauschke at gmail.com) wrote: I noticed that when ever we return datetime objects which come out of backend.py`_parse_asn1_time(), they don't have a tzinfo attached. Afaik, these values should always be UTC but for someone consuming just the result of not_valid_before, etc. that might not be clear. I think it should be possible to add this to _parse_asn1_time() so that we indicate that these are UTC times. I know it's a bit painful in Python <3.2 because we have to implement the tzinfo class ourself but it's also not that much code. Erik _______________________________________________ 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 erik.trauschke at gmail.com Wed Nov 25 12:27:21 2015 From: erik.trauschke at gmail.com (Erik Trauschke) Date: Wed, 25 Nov 2015 09:27:21 -0800 Subject: [Cryptography-dev] Should datetime objects returned by not_valid_before, etc contain timezone info? In-Reply-To: References: Message-ID: As I see it this would be good practice since the timezone is properly defined. I stumbled over it because the code I'm porting asserts that the times we get are UTC so they can be compared correctly to the current time. I guess you could just refer to the documentation but at the moment I don't think it is explicitly mentioned anyway. It just takes the guesswork out. Erik On Wed, Nov 25, 2015 at 8:39 AM, Paul Kehrer wrote: > The documentation states that these are na?ve datetimes representing UTC, > but it is true that you can't tell by introspecting the object itself. Do > you see a significant advantage to attaching an explicit timezone to them > outside of being able to introspect the return value in a REPL and see that > it's UTC? > > -Paul > > On November 25, 2015 at 9:57:40 AM, Erik Trauschke > (erik.trauschke at gmail.com) wrote: > > I noticed that when ever we return datetime objects which come out of > backend.py`_parse_asn1_time(), they don't have a tzinfo attached. > > Afaik, these values should always be UTC but for someone consuming > just the result of not_valid_before, etc. that might not be clear. I > think it should be possible to add this to _parse_asn1_time() so that > we indicate that these are UTC times. > > I know it's a bit painful in Python <3.2 because we have to implement > the tzinfo class ourself but it's also not that much code. > > Erik > _______________________________________________ > 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 > From paul.l.kehrer at gmail.com Wed Nov 25 13:56:16 2015 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 25 Nov 2015 12:56:16 -0600 Subject: [Cryptography-dev] Should datetime objects returned by not_valid_before, etc contain timezone info? In-Reply-To: References: Message-ID: I definitely can't claim to be an expert on tzinfo in Python, but if we can define our own UTC timezone and have it be compatible with py3 UTC objects that seems reasonable. Are there any surprises we should be aware of? -Paul On November 25, 2015 at 11:27:27 AM, Erik Trauschke (erik.trauschke at gmail.com) wrote: As I see it this would be good practice since the timezone is properly defined. I stumbled over it because the code I'm porting asserts that the times we get are UTC so they can be compared correctly to the current time. I guess you could just refer to the documentation but at the moment I don't think it is explicitly mentioned anyway. It just takes the guesswork out. Erik On Wed, Nov 25, 2015 at 8:39 AM, Paul Kehrer wrote: > The documentation states that these are na?ve datetimes representing UTC, > but it is true that you can't tell by introspecting the object itself. Do > you see a significant advantage to attaching an explicit timezone to them > outside of being able to introspect the return value in a REPL and see that > it's UTC? > > -Paul > > On November 25, 2015 at 9:57:40 AM, Erik Trauschke > (erik.trauschke at gmail.com) wrote: > > I noticed that when ever we return datetime objects which come out of > backend.py`_parse_asn1_time(), they don't have a tzinfo attached. > > Afaik, these values should always be UTC but for someone consuming > just the result of not_valid_before, etc. that might not be clear. I > think it should be possible to add this to _parse_asn1_time() so that > we indicate that these are UTC times. > > I know it's a bit painful in Python <3.2 because we have to implement > the tzinfo class ourself but it's also not that much code. > > Erik > _______________________________________________ > 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 > _______________________________________________ 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 Wed Nov 25 14:04:45 2015 From: donald at stufft.io (Donald Stufft) Date: Wed, 25 Nov 2015 14:04:45 -0500 Subject: [Cryptography-dev] Should datetime objects returned by not_valid_before, etc contain timezone info? In-Reply-To: References: Message-ID: <6E742993-2565-4D73-B01C-095BDBEBC07A@stufft.io> This would be a backwards incompatible change FWIW because you can?t compare a naive datetime against an aware datetime. > On Nov 25, 2015, at 1:56 PM, Paul Kehrer wrote: > > I definitely can't claim to be an expert on tzinfo in Python, but if we can define our own UTC timezone and have it be compatible with py3 UTC objects that seems reasonable. Are there any surprises we should be aware of? > > -Paul > > On November 25, 2015 at 11:27:27 AM, Erik Trauschke (erik.trauschke at gmail.com ) wrote: > >> As I see it this would be good practice since the timezone is properly >> defined. I stumbled over it because the code I'm porting asserts that >> the times we get are UTC so they can be compared correctly to the >> current time. >> >> I guess you could just refer to the documentation but at the moment I >> don't think it is explicitly mentioned anyway. It just takes the >> guesswork out. >> >> Erik >> >> On Wed, Nov 25, 2015 at 8:39 AM, Paul Kehrer wrote: >> > The documentation states that these are na?ve datetimes representing UTC, >> > but it is true that you can't tell by introspecting the object itself. Do >> > you see a significant advantage to attaching an explicit timezone to them >> > outside of being able to introspect the return value in a REPL and see that >> > it's UTC? >> > >> > -Paul >> > >> > On November 25, 2015 at 9:57:40 AM, Erik Trauschke >> > (erik.trauschke at gmail.com) wrote: >> > >> > I noticed that when ever we return datetime objects which come out of >> > backend.py`_parse_asn1_time(), they don't have a tzinfo attached. >> > >> > Afaik, these values should always be UTC but for someone consuming >> > just the result of not_valid_before, etc. that might not be clear. I >> > think it should be possible to add this to _parse_asn1_time() so that >> > we indicate that these are UTC times. >> > >> > I know it's a bit painful in Python <3.2 because we have to implement >> > the tzinfo class ourself but it's also not that much code. >> > >> > Erik >> > _______________________________________________ >> > 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 >> > >> _______________________________________________ >> 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: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jean-paul at clusterhq.com Wed Nov 25 14:24:14 2015 From: jean-paul at clusterhq.com (Jean-Paul Calderone) Date: Wed, 25 Nov 2015 14:24:14 -0500 Subject: [Cryptography-dev] Should datetime objects returned by not_valid_before, etc contain timezone info? In-Reply-To: <6E742993-2565-4D73-B01C-095BDBEBC07A@stufft.io> References: <6E742993-2565-4D73-B01C-095BDBEBC07A@stufft.io> Message-ID: The inability to compare naive and aware datetimes is an incompatibility. It is also exactly the reason you want these to be aware, of course. :) I suggest this is worth doing but worth doing in a way that's backwards compatible. Introduce a new API for getting the aware datetime and deprecate the old one? On Wed, Nov 25, 2015 at 2:04 PM, Donald Stufft wrote: > This would be a backwards incompatible change FWIW because you can?t > compare a naive datetime against an aware datetime. > > On Nov 25, 2015, at 1:56 PM, Paul Kehrer wrote: > > I definitely can't claim to be an expert on tzinfo in Python, but if we > can define our own UTC timezone and have it be compatible with py3 UTC > objects that seems reasonable. Are there any surprises we should be aware > of? > > -Paul > > On November 25, 2015 at 11:27:27 AM, Erik Trauschke ( > erik.trauschke at gmail.com) wrote: > > As I see it this would be good practice since the timezone is properly > defined. I stumbled over it because the code I'm porting asserts that > the times we get are UTC so they can be compared correctly to the > current time. > > I guess you could just refer to the documentation but at the moment I > don't think it is explicitly mentioned anyway. It just takes the > guesswork out. > > Erik > > On Wed, Nov 25, 2015 at 8:39 AM, Paul Kehrer > wrote: > > The documentation states that these are na?ve datetimes representing UTC, > > but it is true that you can't tell by introspecting the object itself. Do > > you see a significant advantage to attaching an explicit timezone to them > > outside of being able to introspect the return value in a REPL and see > that > > it's UTC? > > > > -Paul > > > > On November 25, 2015 at 9:57:40 AM, Erik Trauschke > > (erik.trauschke at gmail.com) wrote: > > > > I noticed that when ever we return datetime objects which come out of > > backend.py`_parse_asn1_time(), they don't have a tzinfo attached. > > > > Afaik, these values should always be UTC but for someone consuming > > just the result of not_valid_before, etc. that might not be clear. I > > think it should be possible to add this to _parse_asn1_time() so that > > we indicate that these are UTC times. > > > > I know it's a bit painful in Python <3.2 because we have to implement > > the tzinfo class ourself but it's also not that much code. > > > > Erik > > _______________________________________________ > > 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 > > > _______________________________________________ > 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: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.trauschke at gmail.com Wed Nov 25 14:28:09 2015 From: erik.trauschke at gmail.com (Erik Trauschke) Date: Wed, 25 Nov 2015 11:28:09 -0800 Subject: [Cryptography-dev] Should datetime objects returned by not_valid_before, etc contain timezone info? In-Reply-To: References: <6E742993-2565-4D73-B01C-095BDBEBC07A@stufft.io> Message-ID: Well, the interface for these values are currently class properties, otherwise we could just pass a flag along for tz awareness. I wasn't aware of the incompatibility between both so this does start to look messy. On Wed, Nov 25, 2015 at 11:24 AM, Jean-Paul Calderone wrote: > The inability to compare naive and aware datetimes is an incompatibility. > It is also exactly the reason you want these to be aware, of course. :) > > I suggest this is worth doing but worth doing in a way that's backwards > compatible. Introduce a new API for getting the aware datetime and > deprecate the old one? > > On Wed, Nov 25, 2015 at 2:04 PM, Donald Stufft wrote: >> >> This would be a backwards incompatible change FWIW because you can?t >> compare a naive datetime against an aware datetime. >> >> On Nov 25, 2015, at 1:56 PM, Paul Kehrer wrote: >> >> I definitely can't claim to be an expert on tzinfo in Python, but if we >> can define our own UTC timezone and have it be compatible with py3 UTC >> objects that seems reasonable. Are there any surprises we should be aware >> of? >> >> -Paul >> >> On November 25, 2015 at 11:27:27 AM, Erik Trauschke >> (erik.trauschke at gmail.com) wrote: >> >> As I see it this would be good practice since the timezone is properly >> defined. I stumbled over it because the code I'm porting asserts that >> the times we get are UTC so they can be compared correctly to the >> current time. >> >> I guess you could just refer to the documentation but at the moment I >> don't think it is explicitly mentioned anyway. It just takes the >> guesswork out. >> >> Erik >> >> On Wed, Nov 25, 2015 at 8:39 AM, Paul Kehrer >> wrote: >> > The documentation states that these are na?ve datetimes representing >> > UTC, >> > but it is true that you can't tell by introspecting the object itself. >> > Do >> > you see a significant advantage to attaching an explicit timezone to >> > them >> > outside of being able to introspect the return value in a REPL and see >> > that >> > it's UTC? >> > >> > -Paul >> > >> > On November 25, 2015 at 9:57:40 AM, Erik Trauschke >> > (erik.trauschke at gmail.com) wrote: >> > >> > I noticed that when ever we return datetime objects which come out of >> > backend.py`_parse_asn1_time(), they don't have a tzinfo attached. >> > >> > Afaik, these values should always be UTC but for someone consuming >> > just the result of not_valid_before, etc. that might not be clear. I >> > think it should be possible to add this to _parse_asn1_time() so that >> > we indicate that these are UTC times. >> > >> > I know it's a bit painful in Python <3.2 because we have to implement >> > the tzinfo class ourself but it's also not that much code. >> > >> > Erik >> > _______________________________________________ >> > 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 >> > >> _______________________________________________ >> 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: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >> DCFA >> >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> https://mail.python.org/mailman/listinfo/cryptography-dev >> > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev >