On Jun 3, 2013 9:45 PM, "Raymond Hettinger"
wrote:
>
> Does anyone know what we would need to do to get Python in the Apple
application store as a free App?
>
> The default security settings on OS X 10.8 block the installation of the
DMG (or any software downloaded outside the app store). A numb
On Tue, Jun 4, 2013 at 12:44 PM, Raymond Hettinger
wrote:
> Does anyone know what we would need to do to get Python in the Apple
> application store as a free App?
>
> The default security settings on OS X 10.8 block the installation of the DMG
> (or any software downloaded outside the app store
Does anyone know what we would need to do to get Python in the Apple
application store as a free App?
The default security settings on OS X 10.8 block the installation of the DMG
(or any software downloaded outside the app store). A number of my students
are having difficulty getting around i
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Sat, May 18, 2013 at 10:33 PM, Antoine Pitrou wrote:
> On Sat, 18 May 2013 16:22:55 +0200
> Armin Rigo wrote:
>> Hi Antoine,
>>
>> On Sat, May 18, 2013 at 3:45 PM, Antoine Pitrou wrote:
>> >> How is this done? I don't see a clear way to determine it by looking
>> >> only at the objects in th
On Jun 3, 2013, at 6:01 PM, Paul Moore wrote:
>
> On 3 June 2013 22:46, Donald Stufft wrote:
>> Also, we should consider the issue for application users. Suppose I'm using
>> a Python application that downloads something from the web. I upgrade to
>> 3.4, and the app stops working because of
On 3 June 2013 22:46, Donald Stufft wrote:
> Also, we should consider the issue for application users. Suppose I'm
> using a Python application that downloads something from the web. I upgrade
> to 3.4, and the app stops working because of a "will cease to work" case.
> As an end user, how can I
On Jun 3, 2013, at 5:51 PM, Antoine Pitrou wrote:
> On Mon, 3 Jun 2013 17:47:31 -0400
> Donald Stufft wrote:
>>
>> On Jun 3, 2013, at 5:41 PM, Antoine Pitrou wrote:
>>
>>> On Mon, 3 Jun 2013 22:31:40 +0100
>>> Paul Moore wrote:
> Some legit sites with proper
> certificates sti
On Mon, 3 Jun 2013 17:47:31 -0400
Donald Stufft wrote:
>
> On Jun 3, 2013, at 5:41 PM, Antoine Pitrou wrote:
>
> > On Mon, 3 Jun 2013 22:31:40 +0100
> > Paul Moore wrote:
> >>
> >>> Some legit sites with proper
> >>> certificates still manage to muck something up administratively
> >>> (devel
On Jun 3, 2013, at 5:31 PM, Paul Moore wrote:
>
> On 3 June 2013 21:05, Chris Angelico wrote:
> +1 for having the default be safe, but this will have to be very
> loudly announced ("when migrating from 3.3 to 3.4, TLS connections
> will cease to work if blah blah").
>
> +1 on the default bein
On Jun 3, 2013, at 5:41 PM, Antoine Pitrou wrote:
> On Mon, 3 Jun 2013 22:31:40 +0100
> Paul Moore wrote:
>>
>>> Some legit sites with proper
>>> certificates still manage to muck something up administratively
>>> (developer.quicksales.com.au has a cert from RapidSSL but doesn't
>>> bundle the
On Tue, Jun 4, 2013 at 7:31 AM, Paul Moore wrote:
>
> On 3 June 2013 21:05, Chris Angelico wrote:
>> Some legit sites with proper
>> certificates still manage to muck something up administratively
>> (developer.quicksales.com.au has a cert from RapidSSL but doesn't
>> bundle the intermediates, an
On Mon, 3 Jun 2013 22:31:40 +0100
Paul Moore wrote:
>
> > Some legit sites with proper
> > certificates still manage to muck something up administratively
> > (developer.quicksales.com.au has a cert from RapidSSL but doesn't
> > bundle the intermediates, and I've told their devs about it, but all
On 3 June 2013 21:05, Chris Angelico wrote:
> +1 for having the default be safe, but this will have to be very
> loudly announced ("when migrating from 3.3 to 3.4, TLS connections
> will cease to work if blah blah").
>
+1 on the default being safe, certainly. But with the proviso that the same
c
In article <699d9ab5-26e0-4cce-89c5-8e92c3305...@stufft.io>,
Donald Stufft wrote:
> On Jun 3, 2013, at 4:19 PM, Christian Heimes wrote:
> > Most Linux and BSD-ish operating systems have SSL certs at some standard
> > location.
> > https://bitbucket.org/pypa/setuptools/src/6de3186fdfd9f5b543380e
On Jun 3, 2013, at 4:19 PM, Christian Heimes wrote:
> Am 03.06.2013 21:52, schrieb Antoine Pitrou:
>> cadefault=True will probably be fail if the system certs are not
>> properly configured in OpenSSL, e.g. under Windows or with a hand-made
>> OpenSSL build.
>> And, because of the way the OpenSS
Am 03.06.2013 21:52, schrieb Antoine Pitrou:
> cadefault=True will probably be fail if the system certs are not
> properly configured in OpenSSL, e.g. under Windows or with a hand-made
> OpenSSL build.
> And, because of the way the OpenSSL API works, there's no way of
> knowing if it is the case or
On Mon, 2013-06-03 at 12:48 -0400, Barry Warsaw wrote:
> On Jun 03, 2013, at 09:05 AM, Ben Darnell wrote:
>
> >The data is analogous to the time zone database (PEP 431) in that it may
> >need to be updated independently of Python's own release schedule, so we
> >may want to use similar techniques
On Tue, Jun 4, 2013 at 4:56 AM, Ethan Furman wrote:
> On 06/03/2013 11:34 AM, Antoine Pitrou wrote:
>>
>> On Mon, 3 Jun 2013 14:12:34 -0400
>> Donald Stufft wrote:
>>>
>>>
>>> I worry with the current situation people will just use TLS connections
>>> without realizing it's not being verified and
On Mon, 03 Jun 2013 11:56:45 -0700
Ethan Furman wrote:
> On 06/03/2013 11:34 AM, Antoine Pitrou wrote:
> > On Mon, 3 Jun 2013 14:12:34 -0400
> > Donald Stufft wrote:
> >>
> >> I worry with the current situation people will just use TLS connections
> >> without realizing it's not being verified an
On 06/03/2013 11:34 AM, Antoine Pitrou wrote:
On Mon, 3 Jun 2013 14:12:34 -0400
Donald Stufft wrote:
I worry with the current situation people will just use TLS connections without realizing
it's not being verified and thinking they are "safe".
Yet there's quite a visible warning in the docs
On Mon, Jun 3, 2013 at 1:04 PM, Barry Warsaw wrote:
> On Jun 03, 2013, at 02:21 PM, Donald Stufft wrote:
>
> >The other additional comment I'd like to throw in here is that if we don't
> >bundle SSL certs I think we should still verify by default (which means
> HTTPS
> >urls will throw an error b
On Jun 3, 2013, at 1:07 PM, Barry Warsaw wrote:
> On Jun 03, 2013, at 02:17 PM, Donald Stufft wrote:
>
>> I'd actually prefer for Linux to not use the bundled certs when installed
>> from a package manager because it should use the system certs, but people
>> can't depend on certs being there i
On Mon, 3 Jun 2013 14:12:34 -0400
Donald Stufft wrote:
>
> I worry with the current situation people will just use TLS connections
> without realizing it's not being verified and thinking they are "safe".
Yet there's quite a visible warning in the docs:
http://docs.python.org/dev/library/urllib
On 06/03/2013 10:55 AM, Donald Stufft wrote:
On Jun 3, 2013, at 12:52 PM, Ethan Furman wrote:
On 06/03/2013 09:43 AM, Donald Stufft wrote:
On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:
The problem with a "slightly outdated" CA store is that it can be a
security risk.
Tracking the Mozill
On Jun 03, 2013, at 02:17 PM, Donald Stufft wrote:
>I'd actually prefer for Linux to not use the bundled certs when installed
>from a package manager because it should use the system certs, but people
>can't depend on certs being there if they are only there on linux.
I think we agree on that.
>
On Jun 3, 2013, at 12:48 PM, Barry Warsaw wrote:
> On Jun 03, 2013, at 09:05 AM, Ben Darnell wrote:
>
>> The data is analogous to the time zone database (PEP 431) in that it may
>> need to be updated independently of Python's own release schedule, so we
>> may want to use similar techniques to
On Jun 03, 2013, at 02:21 PM, Donald Stufft wrote:
>The other additional comment I'd like to throw in here is that if we don't
>bundle SSL certs I think we should still verify by default (which means HTTPS
>urls will throw an error by default if we can't locate a certificate store)
>because I thin
On Jun 3, 2013, at 12:52 PM, Barry Warsaw wrote:
> On Jun 03, 2013, at 03:12 AM, Donald Stufft wrote:
>
>> That's fine with me too. My only reason for wanting to use the system certs
>> first is so if someone has modified their system certs (say to include a
>> corporate cert) that it would ide
On Jun 03, 2013, at 03:12 AM, Donald Stufft wrote:
>That's fine with me too. My only reason for wanting to use the system certs
>first is so if someone has modified their system certs (say to include a
>corporate cert) that it would ideally take affect for Python as well.
This reminds me of one o
On Jun 3, 2013, at 12:36 PM, Barry Warsaw wrote:
> On Jun 03, 2013, at 01:20 AM, Donald Stufft wrote:
>
>> So I would like to propose that CPython adopt the Mozilla SSL certificate
>> list and include it in core, and switch over the API's so that they verify
>> HTTPS by default. This is what mo
On Jun 03, 2013, at 09:05 AM, Ben Darnell wrote:
>The data is analogous to the time zone database (PEP 431) in that it may
>need to be updated independently of Python's own release schedule, so we
>may want to use similar techniques to manage both. Also see certifi (
>https://pypi.python.org/pypi
On Jun 03, 2013, at 01:20 AM, Donald Stufft wrote:
>So I would like to propose that CPython adopt the Mozilla SSL certificate
>list and include it in core, and switch over the API's so that they verify
>HTTPS by default. This is what most people are going to expect when using a
>https url (Especia
On Jun 3, 2013, at 12:52 PM, Ethan Furman wrote:
> On 06/03/2013 09:43 AM, Donald Stufft wrote:
>> On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:
>>>
>>> The problem with a "slightly outdated" CA store is that it can be a
>>> security risk.
>>
>> Tracking the Mozilla store isn't difficult.
On 06/03/2013 09:43 AM, Donald Stufft wrote:
On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:
The problem with a "slightly outdated" CA store is that it can be a
security risk.
Tracking the Mozilla store isn't difficult. New additions can be ignored for
currently released Pythons so we'd ju
On Mon, 3 Jun 2013 12:43:32 -0400
Donald Stufft wrote:
>
> On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:
>
> > On Mon, 3 Jun 2013 21:37:10 +1200
> > Ben Hoyt wrote:
> >>
> >> I'm not familiar with Unix/Linux, but on Windows, if it's anything
> >> like mimetypes it'll be really hard to get
On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:
> On Mon, 3 Jun 2013 21:37:10 +1200
> Ben Hoyt wrote:
>>
>> I'm not familiar with Unix/Linux, but on Windows, if it's anything
>> like mimetypes it'll be really hard to get consistent behaviour across
>> different boxes/versions from the regist
On 06/02/2013 10:20 PM, Donald Stufft wrote:
So I would like to propose that CPython adopt the Mozilla SSL certificate list
and include it in core, and switch over
the API's so that they verify HTTPS by default.
+1
Also, +1 on using system certs when available.
--
~Ethan~
__
On Mon, Jun 3, 2013 at 1:20 AM, Donald Stufft wrote:
> As of right now, as far as I can tell, Python does not validate HTTPS
> certificates by default. As far as I can tell this is because there is no
> guaranteed certificates available.
>
> So I would like to propose that CPython adopt the Mozil
>> I'm not familiar with Unix/Linux, but on Windows, if it's anything
>> like mimetypes it'll be really hard to get consistent behaviour across
>> different boxes/versions from the registry, or wherever certs might be
>> stored on Windows. I'd much rather have a slightly outdated but
>> consistent
On Sun, 2 Jun 2013 19:16:17 -0700
Benjamin Peterson wrote:
> 2013/5/18 Antoine Pitrou :
> > Calling finalizers only once is fine with me, but it would be a change
> > in behaviour; I don't know if it may break existing code.
>
> I agree with Armin that this is better behavior. (Mostly significant
On Sun, 2 Jun 2013 19:27:49 -0700
Benjamin Peterson wrote:
> 2013/5/18 Antoine Pitrou :
> >
> > Hello,
> >
> > I would like to submit the following PEP for discussion and evaluation.
>
> Will the API of the gc module be at all affected? I assume nothing
> will just be printed for DEBUG_UNCOLLECTA
On Mon, 3 Jun 2013 21:37:10 +1200
Ben Hoyt wrote:
>
> I'm not familiar with Unix/Linux, but on Windows, if it's anything
> like mimetypes it'll be really hard to get consistent behaviour across
> different boxes/versions from the registry, or wherever certs might be
> stored on Windows. I'd much
Am 03.06.2013 07:20, schrieb Donald Stufft:
> Ideally this would take the shape of attempting to locate the system
> certificate store if possible, and if that doesn't work falling back to
> the bundled certificates. That way the various Linux distros can easily
> have their copies of Python depend
> The situation for certs is probably fairly parallel: on unix, it would
> probably be an advantage as Python would automatically follow distro
> decisions about cert chains, while on windows trying to use a system
> cert store would probably be a disaster.
Yeah, fair enough. If it's stable and j
On Mon, 03 Jun 2013 19:38:45 +1200, Ben Hoyt wrote:
> Love this idea. Some third-party HTTP libraries turn this on by
> default in any case (eg: requests, and I think others), so this would
> mean Python would get their "safe-by-default" behaviour in its stdlib.
>
> > > Ideally this would take th
On Sun, 2 Jun 2013 22:57:15 -0700
Chris Rebert wrote:
> On Jun 2, 2013 10:22 PM, "Donald Stufft" wrote:
> >
> > As of right now, as far as I can tell, Python does not validate HTTPS
> > certificates by default. As far as I can tell this is because there is no
> > guaranteed certificates availab
On Mon, 3 Jun 2013 01:20:42 -0400
Donald Stufft wrote:
> As of right now, as far as I can tell, Python does not validate HTTPS
> certificates by default. As far as I can tell this is because there is
> no guaranteed certificates available.
Also for backwards compatibility.
Regards
Antoine.
__
Love this idea. Some third-party HTTP libraries turn this on by
default in any case (eg: requests, and I think others), so this would
mean Python would get their "safe-by-default" behaviour in its stdlib.
> > Ideally this would take the shape of attempting to locate the system
> > certificate stor
2013/6/3 Donald Stufft :
>
> On Jun 3, 2013, at 1:58 AM, Benjamin Peterson wrote:
>
> 2013/6/2 Donald Stufft :
>
> As of right now, as far as I can tell, Python does not validate HTTPS
> certificates by default. As far as I can tell this is because there is no
> guaranteed certificates available.
On Jun 3, 2013, at 1:58 AM, Benjamin Peterson wrote:
> 2013/6/2 Donald Stufft :
>> As of right now, as far as I can tell, Python does not validate HTTPS
>> certificates by default. As far as I can tell this is because there is no
>> guaranteed certificates available.
>>
>> So I would like to pr
51 matches
Mail list logo
