Re: [Python-Dev] Sad status of Python 3.x buildbots

[Nick Coghlan]

On 4 September 2014 15:45, Shorya Raj  wrote:
> Also, have you considered using Travis? It would allow us to add to the
> configurations, at least generally...

Many SaaS solution assume the use of specific centralised identity
providers, which isn't a function we're prepared to outsource (we know
we need to fix our current proliferation of identity silos, but that's
a big project and there are other tasks ahead of it on the todo list
for the existing infrastructure team).

The limiting factor is generally time - various aspects of the current
system are clumsy, but they work, so unless someone is particularly
keen and willing to work through all the factors that led to the
current setup and propose changes (including at least a rough concept
of how ongoing maintenance will work), the status quo wins by default.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7

[Nick Coghlan]

On 4 September 2014 12:21, Benjamin Peterson  wrote:
> On Wed, Sep 3, 2014, at 17:03, Nick Coghlan wrote:
>> On 1 September 2014 08:00, Nick Coghlan  wrote:
>> > Earlier versions of PEP 453 proposed bootstrapping pip into a Python 2.7
>> > maintenance release in addition to including it with Python 3.4.
>> >
>> > That part of the proposal proved to be controversial, so we dropped it from
>> > the original PEP in order to focus on meeting the Python 3.4 specific
>> > release deadlines. This also had the benefit of working out the kinks in 
>> > the
>> > bootstrapping processing as part of the Python 3.4 release cycle.
>> >
>> > However, we still think we should start providing pip by default to Python
>> > 2.7 users as well, at least as part of the Windows and Mac OS X installers.
>>
>> I suggested off-list that, as Python 2.7 release manager, Benjamin
>> would be a good candidate for BDFL-Delegate for this proposal, and
>> both Guido and Benjamin agreed. The PEP has been updated accordingly:
>> http://hg.python.org/peps/rev/909954e4ba43 (I also fixed a
>> copy-and-paste error in the PEP status!)
>
> ... and accepted. Let's make our users' lives' better!.

Huzzah!

Over to you, Ned & Donald. We can give Steve the good news for the
Windows side of things as well :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sad status of Python 3.x buildbots

[Nick Coghlan]

On 4 September 2014 11:07, Antonio Cavallo  wrote:
> I wonder if there is any interest in starting to use the opensuse build
> servers for continuous build and testing on redhat, fedora suse and (I
> think) debian: that will solve once for all the maintenance issues on those
> platforms (and provide a reliable build).

It sounds like a good idea in principle, but I suspect there would be
a lot of devils in those details. That doesn't make it a bad idea,
just something that would need a volunteer to investigate further
before we could form a real opinion.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Nick Coghlan]

On 4 September 2014 10:00, Ethan Furman  wrote:
> On 09/03/2014 04:36 PM, Antoine Pitrou wrote:
>>
>> On Thu, 4 Sep 2014 09:19:56 +1000
>> Nick Coghlan  wrote:


 Python is routinely updated to bugfix releases by Linux distributions
 and other distribution channels, you usually have no say over what's
 shipped in those updates. This is not like changing the major version
 used for executing the script, which is normally a manual change.
>>>
>>>
>>> We can potentially deal with the more conservative part of the user base
>>> on
>>> the redistributor side - so long as the PEP says it's OK for us to not
>>> apply this particular change if we deem it appropriate to do so.
>>
>>
>> So people would believe python.org that they would get HTTPS cert
>> validation by default, but their upstream distributor would have
>> disabled it for them? That's even worse...
>
>
> I agree.  If the vendors don't want to have validation by default, they
> should stick with 2.7.8.

Yes, that's the way it would work in practice - we'd call it 2.7.8,
and backport fixes from upstream 2.7.x as needed (as someone put it to
me recently, a useful way to think of component version numbers in
RHEL is as referring to the *oldest* pieces of code in that
component).

I've spent quite a bit more time considering the proposal, and I'm now
satisfied that making this change upstream isn't likely to cause any
major problems, due to the fact that folks who are likely to suffer
from this change aren't likely to even be on 2.7 yet.

While we managed not to be last this time, the RHEL/CentOS ecosystem
is still a useful benchmark for the roll out of Python versions into
conservative enterprise organisations, and the more conservative users
within *that* ecosystem are likely to wait for the x.1 release (at the
earliest) rather than upgrading as soon as x.0 is out. RHEL 7.0 only
came out in June, so most of those conservative environments are still
going to be on Python 2.6 in RHEL 6. While we shipped 2.7 support well
before the release of RHEL 7 as part of Software Collections and
OpenShift, the kinds of environments where properly validating SSL by
default may cause problems aren't likely to be on the leading edge of
adopting new approaches to software deployment like SCL and PaaS.

Fixing the HTTPS validation defaults would have several significant
positive consequences:

- lowers a major barrier to Python adoption (and continued usage) for
public internet focused services
- fixes a latent security defect for Python applications operating
over the public internet
- fixes a latent security defect for Python applications operating in
a properly configured intranet environment
- reveals a latent security defect for Python applications
communicating with improperly configured public internet services
- reveals a latent security defect for Python applications operating
in improperly configured intranet environments

The debate is thus solely over how to manage the consequences of the
last two, since going from "silent failure" to "noisy failure" looks
like going from "working" to "broken" to someone that isn't already
intimately familiar with the underlying issues.

That question needs to be considered separately for 3 different versions:

- 3.5
- 3.4
- 2.7

3.5 is not controversial, the answer is that the standard library's
handling of HTTPS URLs should change to verify certificates properly.
No ifs, buts, or maybes - Python 3.5 should automatically verify all
HTTPS connections, with explicit developer action required to skip (or
otherwise relax) the validation check.

So far, we have assumed that 3.4 will get at most a warning. However,
I have changed my mind on that, because Python 3 is still largely an
early adopter driven technology (it's making inroads into more
conservative environments, but it's still at least a few years away
from catching up to Python 2 on that front). As a result, the kinds of
environments RDM and I are worried about will generally *not* be using
Python 3, or if they are, it will be for custom scripts that they can
fix. I wouldn't suggest actually making that change without getting an
explicit +1 from the Canonical folks (since 3.4 is in Ubuntu LTS
14.04), but I would now personally be +1 on just *fixing it* in 3.4.2,
rather than doing a bunch of additional development work purely so we
can make folks wait another year for the Python 3 standard library to
correctly handle HTTPS.

That leaves Python 2.7, and I have to say I'm now persuaded that a
backport (including any required httplib and urllib features) is the
right way to go. One of the tasks I'd been dreading as a follow-on
from PEP 466 was organising the code audit to make sure our existing
Python 2 applications are properly configuring SSL. If we instead
change Python 2.7.9 to validate certificates by default, then the need
to do that audit *goes away*, replaced by the far more mundane tasking
of doing integration testing on 2.7.9, which we'd have 

Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7

[Benjamin Peterson]

On Wed, Sep 3, 2014, at 17:03, Nick Coghlan wrote:
> On 1 September 2014 08:00, Nick Coghlan  wrote:
> > Earlier versions of PEP 453 proposed bootstrapping pip into a Python 2.7
> > maintenance release in addition to including it with Python 3.4.
> >
> > That part of the proposal proved to be controversial, so we dropped it from
> > the original PEP in order to focus on meeting the Python 3.4 specific
> > release deadlines. This also had the benefit of working out the kinks in the
> > bootstrapping processing as part of the Python 3.4 release cycle.
> >
> > However, we still think we should start providing pip by default to Python
> > 2.7 users as well, at least as part of the Windows and Mac OS X installers.
> 
> I suggested off-list that, as Python 2.7 release manager, Benjamin
> would be a good candidate for BDFL-Delegate for this proposal, and
> both Guido and Benjamin agreed. The PEP has been updated accordingly:
> http://hg.python.org/peps/rev/909954e4ba43 (I also fixed a
> copy-and-paste error in the PEP status!)

... and accepted. Let's make our users' lives' better!.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sad status of Python 3.x buildbots

[Antonio Cavallo]

I wonder if there is any interest in starting to use the opensuse build 
servers for continuous build and testing on redhat, fedora suse and (I 
think) debian: that will solve once for all the maintenance issues on 
those platforms (and provide a reliable build).



Regards,
Antonio
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sad status of Python 3.x buildbots

[Chris Angelico]

On Thu, Sep 4, 2014 at 3:32 AM, francis  wrote:
>> does mean a measure of trust in some external entity, or else some
>> very careful rules (mainly firewall), which not every coder will know
>> about.
>
>
> Just curious, is there a way to mount the infrastructure the oder way
> around? One sets a system polling for sources changes, if so it starts
> a build an sends per e-mail the results to some address.

I'm more talking about how there's a (virtual) machine that I run,
executing code sent to me by someone else (the Python devs). That
machine needs a certain measure of access to the internet (to fetch
code, and to run certain tests), and the easy and naive way to set it
up is to give it full access to everything, which is the trust that I
spoke of. Firewalling that box so it can't see anything it's not
allowed to see is certainly possible, but that requires sysadmin
skills, not coder skills, hence my comment. And it's very easy to make
a mistake that you won't notice - everything works just fine, because
normally that buildbot won't do anything it shouldn't.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Ethan Furman]

On 09/03/2014 05:00 PM, Ethan Furman wrote:

On 09/03/2014 04:36 PM, Antoine Pitrou wrote:

On Thu, 4 Sep 2014 09:19:56 +1000
Nick Coghlan  wrote:


Python is routinely updated to bugfix releases by Linux distributions
and other distribution channels, you usually have no say over what's
shipped in those updates. This is not like changing the major version
used for executing the script, which is normally a manual change.


We can potentially deal with the more conservative part of the user base on
the redistributor side - so long as the PEP says it's OK for us to not
apply this particular change if we deem it appropriate to do so.


So people would believe python.org that they would get HTTPS cert
validation by default, but their upstream distributor would have
disabled it for them? That's even worse...


I agree.  If the vendors don't want to have validation by default, they should 
stick with 2.7.8.


If good argument can be made for why we should make validation by default optional, then that point should be well made 
in Python's release notes, and some easy programmatic way to tell if validation is on or off  (which may just be more 
docs saying call SSLContext and examine the results:  xxx means you're validating, yyy means you are not).


--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7

[Nick Coghlan]

On 1 September 2014 08:00, Nick Coghlan  wrote:
> Earlier versions of PEP 453 proposed bootstrapping pip into a Python 2.7
> maintenance release in addition to including it with Python 3.4.
>
> That part of the proposal proved to be controversial, so we dropped it from
> the original PEP in order to focus on meeting the Python 3.4 specific
> release deadlines. This also had the benefit of working out the kinks in the
> bootstrapping processing as part of the Python 3.4 release cycle.
>
> However, we still think we should start providing pip by default to Python
> 2.7 users as well, at least as part of the Windows and Mac OS X installers.

I suggested off-list that, as Python 2.7 release manager, Benjamin
would be a good candidate for BDFL-Delegate for this proposal, and
both Guido and Benjamin agreed. The PEP has been updated accordingly:
http://hg.python.org/peps/rev/909954e4ba43 (I also fixed a
copy-and-paste error in the PEP status!)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Ethan Furman]

On 09/03/2014 04:36 PM, Antoine Pitrou wrote:

On Thu, 4 Sep 2014 09:19:56 +1000
Nick Coghlan  wrote:


Python is routinely updated to bugfix releases by Linux distributions
and other distribution channels, you usually have no say over what's
shipped in those updates. This is not like changing the major version
used for executing the script, which is normally a manual change.


We can potentially deal with the more conservative part of the user base on
the redistributor side - so long as the PEP says it's OK for us to not
apply this particular change if we deem it appropriate to do so.


So people would believe python.org that they would get HTTPS cert
validation by default, but their upstream distributor would have
disabled it for them? That's even worse...


I agree.  If the vendors don't want to have validation by default, they should 
stick with 2.7.8.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Antoine Pitrou]

On Thu, 4 Sep 2014 09:19:56 +1000
Nick Coghlan  wrote:
> >
> > Python is routinely updated to bugfix releases by Linux distributions
> > and other distribution channels, you usually have no say over what's
> > shipped in those updates. This is not like changing the major version
> > used for executing the script, which is normally a manual change.
> 
> We can potentially deal with the more conservative part of the user base on
> the redistributor side - so long as the PEP says it's OK for us to not
> apply this particular change if we deem it appropriate to do so.

So people would believe python.org that they would get HTTPS cert
validation by default, but their upstream distributor would have
disabled it for them? That's even worse...

Of course, people could read distribution-specific package changelogs,
but nobody does that.

> 2.7.9 is going to be a somewhat "interesting" release that requires careful
> attention anyway (due to the completion of the PEP 466 backports), so if
> Guido's OK with it, sure, let's kill the "HTTPS isn't" problem for Python 2
> as well.

Possible unvoluntary breakage due to a large backport is one thing.
Deliberate breakage is another.

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Nick Coghlan]

On 4 Sep 2014 06:39, "Alex Gaynor"  wrote:
>
> Guido van Rossum  python.org> writes:
>
> > OK, that changes my position for 2.7 (but not for 3.5). I had assumed
there
> > was a way to disable the cert check by changing one parameter to the
> > urlopen() call. (And I had wanted to add that there should be a clear
FAQ
> > about the subject.) If this isn't possible that changes the situation.
(But I
> > still think that once we do have that simple change option we should do
it,
> > in a later 2.7 upgrade.) I apologize for speaking before I had read all
> > facts, and I'll await what you and Nick come up with.
> > --Guido
>
> This probably doesn't surprise anyone, but I'm more than happy to do the
back-
> porting work for httplib, and any other modules which need SSLContext
support;
> does this require an additional PEP, or does it fit under PEP466 or
PEP476?

I suggest writing up a separate PEP for 2.7 that covers exactly what would
need to be backported in order to make the same HTTPS handling change in
Python 2.

For 476, I suggest taking my list of modules that call
"_create_stdlib_cert" and being completely explicit as to which ones are
*not* changing (as that will help clarify the scope of the backport
proposal).

I learned that lesson with PEP 453 - it's well worth making the Python 3
PEP easier to accept by making it independent of the inevitably more
controversial Python 2 backport PEP :)

Cheers,
Nick.

>
> Alex
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Nick Coghlan]

On 4 Sep 2014 04:39, "Antoine Pitrou"  wrote:
>
> On Wed, 3 Sep 2014 10:54:55 -0700
> Guido van Rossum  wrote:
> >
> > Let's take the plunge on this issue for the next 2.7 release (3.5 being
a
> > done deal).
>
> I'm entirely against this.
>
> > Yes, some people will find that they have an old script
> > accessing an old service which breaks. Surely some of the other changes
in
> > the same 2.7 bugfix release will also break some other scripts. People
deal
> > with it. Probably 90% of the time it's an annoyance (but no worse than
any
> > other minor-release upgrade -- you should test upgrades before
committing
> > to them, and if all else fails, roll it back).
>
> Python is routinely updated to bugfix releases by Linux distributions
> and other distribution channels, you usually have no say over what's
> shipped in those updates. This is not like changing the major version
> used for executing the script, which is normally a manual change.

We can potentially deal with the more conservative part of the user base on
the redistributor side - so long as the PEP says it's OK for us to not
apply this particular change if we deem it appropriate to do so.

That would make this a case of upstream asking us to do the kind of risk
assessment that people pay us for, which is a kind of request I'm generally
happy to get :)

That way, if downstream users get upset, we can point them at their vendor
support department, rather than having them take out their ire on upstream
volunteers.

Also, after thinking through the implications a bit more, my guess is that
Fedora & Software Collections will accept the change without any fuss, but
the CentOS/RHEL side could be a more involved discussion. On the other
hand, orgs with these kinds of problems aren't likely to have rolled out
RHEL 7 or CentOS 7 yet either, so they're probably still back on Python 2.6
(RHEL 6) or even 2.4 (RHEL 5).

2.7.9 is going to be a somewhat "interesting" release that requires careful
attention anyway (due to the completion of the PEP 466 backports), so if
Guido's OK with it, sure, let's kill the "HTTPS isn't" problem for Python 2
as well.

One additional wrinkle in that case: we will likely need to backport the
SSLContext related changes to httplib as well.

Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Benjamin Peterson]

On Wed, Sep 3, 2014, at 13:37, Alex Gaynor wrote:
> Guido van Rossum  python.org> writes:
> 
> > OK, that changes my position for 2.7 (but not for 3.5). I had assumed there
> > was a way to disable the cert check by changing one parameter to the
> > urlopen() call. (And I had wanted to add that there should be a clear FAQ
> > about the subject.) If this isn't possible that changes the situation. (But 
> > I
> > still think that once we do have that simple change option we should do it,
> > in a later 2.7 upgrade.) I apologize for speaking before I had read all
> > facts, and I'll await what you and Nick come up with.
> > --Guido
> 
> This probably doesn't surprise anyone, but I'm more than happy to do the
> back-
> porting work for httplib, and any other modules which need SSLContext
> support;
> does this require an additional PEP, or does it fit under PEP466 or
> PEP476?

I imagine you could put it into 476.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Stephen J. Turnbull]

Guido van Rossum writes:

 > lot: five years ago (when I worked at Google!) it was common to find
 > internal services that required SSL but had a misconfigured certificate,
 > and the only way to access those services was to override the browser
 > complaints. Today (working at Dropbox, a much smaller company!) I don't
 > even remember the last time I had to deal with such a browser complaint --

I would tend to discount your recent experience, then.  Smaller (and
possibly even more important in this fast-developing area, younger)
organizations are a lot more nimble about things like this.

That is not intended to express an opinion about a backport, though.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sad status of Python 3.x buildbots

[Victor Stinner]

2014-09-03 0:13 GMT+02:00 Victor Stinner :
> AMD64 OpenIndiana 3.x: a lot of tests fail with OSError(12, "Not
> enough space") or MemoryError. It's probably on issue on the host.
>
> x86 OpenIndiana 3.x: MemoryError. TestReadline.test_init() also fails.

I sent an email to Jesus Cea (owner of these buildbots).

> x86 RHEL 6 3.x: TestReadline.test_init() fails, issue #19884. I don't
> have to this platform, I don't know how to fix it.

I sent my SSH key to Nick (owner).

> x86 Windows Server 2003 [SB] 3.x: test_build_ext() of test_distutils
> hangs during 1 hang before being killed, it hangs something in the C
> compiler.

I sent an email to the mailing list of the snakebite network.

> x86 XP-4 3.x: test_distutils fails because Visual Studio linker
> (link.exe) fails with the error 1181 (cannot open input file).
> test_capi.test_forced_io_encoding() fails with an assertion error
> because sys.__stdin__ is None.

I sent an email to David Bolen (owner).

> ARMv7 3.x: "Read-only file system", Mercurial fails...

I sent an email to Gregory P. Smith (owner).

> x86 FreeBSD 7.2 3.x: test_io.test_interrupted_write_text() hangs.

I skipped the test on FreeBSD 7.2 (even if the test pass on FreeBSD 6.4):
http://bugs.python.org/issue22331

> x86 FreeBSD 6.4 3.x: (...) test_multiprocessing_spawn fails whereas the
> test should be skipped.

I skipped the test on FreeBSD 6.4:
http://bugs.python.org/issue22332

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Alex Gaynor]

Guido van Rossum  python.org> writes:

> OK, that changes my position for 2.7 (but not for 3.5). I had assumed there
> was a way to disable the cert check by changing one parameter to the
> urlopen() call. (And I had wanted to add that there should be a clear FAQ
> about the subject.) If this isn't possible that changes the situation. (But I
> still think that once we do have that simple change option we should do it,
> in a later 2.7 upgrade.) I apologize for speaking before I had read all
> facts, and I'll await what you and Nick come up with.
> --Guido

This probably doesn't surprise anyone, but I'm more than happy to do the back-
porting work for httplib, and any other modules which need SSLContext support;
does this require an additional PEP, or does it fit under PEP466 or PEP476?

Alex

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

[Matthew Woodcraft]

In article ,
Victor Stinner   wrote:
>2014-09-02 23:03 GMT+02:00 Matthew Woodcraft :
>> In any case I think PEP 475 should be explaining what is going to happen
>> to signal.siginterrupt(). Will setting flag=True be supported?

> I first proposed to deprecate the function, but Charles-François
> thinks that it's unrelated to the PEP (it can be addressed later).

> The function will still be available and work.

>> If so, will doing so change the behaviour of those parts of the stdlib which
>> have already been modified to retry after EINTR?

> I think that the stdlib should not handle InterruptedError exception
> anymore in the Python code, to simplify the code.

That seems good to me. I think it's worth writing in the PEP.

But if Python is going to provide its own higher-level model of signal
handling, then I think signal.siginterrupt() will need to be documented
in terms of that model; it should be saying something along the lines of
"if a signal arrives while Python is blocking in a system call then
InterruptedError will be raised", and I suppose it will need to say what
happens if the signal handler also raised an exception.


>> (I think it would be helpful if we could tell people "if you want the
>> old EINTR behaviour, just do this simple thing". And I suppose
>> siginterrupt flag=True is a candidate for that.)

> Why do you want the old behaviour?

Purely to avoid breaking existing programs, particularly in ways which
will require effort to fix.

I think Python's backward-compatibility rules are basically "the
behavior of an API must not change without going through the deprecation
process".

If we're going to be making an exception to that here, then it would be
much better to say "here's a simple change to make to keep your old
program working", rather than "please rewrite your fiddly
signal-handling code to use more modern techniques", however much nicer
those modern techniques are.

Or perhaps it would be better to not make an exception at all, and
instead add an 'interrupt_syscalls' boolean keyword argument to
signal.signal(), while strongly recommending that people set it False.

-M-

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Christian Heimes]

On 03.09.2014 21:37, Guido van Rossum wrote:
> OK, that changes my position for 2.7 (but not for 3.5). I had
> assumed there was a way to disable the cert check by changing one
> parameter to the urlopen() call. (And I had wanted to add that
> there should be a clear FAQ about the subject.) If this isn't
> possible that changes the situation. (But I still think that once
> we do have that simple change option we should do it, in a later
> 2.7 upgrade.)
> 
> I apologize for speaking before I had read all facts, and I'll
> await what you and Nick come up with.

You are welcome! :)

I like to see cert checks in Python 2.7, too. Eventually Python 2.7
should have them enabled by default or at least have one very simple
way to enable them globally. Right now we aren't there yet. Perhaps
Python 2.7.10 or 2.7.11 will have the necessary bits and backports.

Christian


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Christian Heimes]

On 03.09.2014 21:37, Victor Stinner wrote:
> Thanks, you replied before I asked the question :-) (If
> certificates are validated by default, how do you disable the
> checks?)
> 
> Sorry, I didn't follow the whole discussion and Python 2.7 changes 
> related to security. Does Python 2.7 support loading
> (automatically) system certificate authorities? Like the Windows
> certificate store: 
> https://docs.python.org/dev/whatsnew/3.4.html#whatsnew34-win-cert-store

Yes!

Alex and others have ported all SSL features back to Python 2.7.
The SSL module in Python 2.7.9 will have the same feature set as
Python 3.4.

Christian


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Ethan Furman]

On 09/03/2014 12:10 PM, R. David Murray wrote:

On Wed, 03 Sep 2014 10:09:36 -0700, Ethan Furman  wrote:

On 09/03/2014 08:58 AM, R. David Murray wrote:


I'm OK with letting go of this invalid-cert issue myself, given the lack
of negative feedback Twisted got.  I'll just keep my fingers crossed.


I apologize if I missed this point, but if we have the source code then it is 
possible to go in and directly modify the
application/utility to be able to talk over https to a router with an invalid 
certificate?  This is an option when
creating the ssl_context?


The immediately preceding paragraph that you didn't quote said that the
context was 3rd party applications, not source code under your control.
Yes, you can (usually) still hack the source, but there are good reasons to
prefer to not do that, unfamiliarity with the codebase being just one of
them.


I appreciate that there is a distinction, yet in most cases we have the source code available (it is the nature of 
Python) and if push comes to shove (and a bunch of other colloquialisms) then modifying that source code can get you up 
and running again.


--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Guido van Rossum]

OK, that changes my position for 2.7 (but not for 3.5). I had assumed there
was a way to disable the cert check by changing one parameter to the
urlopen() call. (And I had wanted to add that there should be a clear FAQ
about the subject.) If this isn't possible that changes the situation. (But
I still think that once we do have that simple change option we should do
it, in a later 2.7 upgrade.)

I apologize for speaking before I had read all facts, and I'll await what
you and Nick come up with.

--Guido


On Wed, Sep 3, 2014 at 12:26 PM, Christian Heimes 
wrote:

> On 03.09.2014 19:54, Guido van Rossum wrote:
> > Let's take the plunge on this issue for the next 2.7 release (3.5 being
> > a done deal). Yes, some people will find that they have an old script
> > accessing an old service which breaks. Surely some of the other changes
> > in the same 2.7 bugfix release will also break some other scripts.
> > People deal with it. Probably 90% of the time it's an annoyance (but no
> > worse than any other minor-release upgrade -- you should test upgrades
> > before committing to them, and if all else fails, roll it back). But at
> > least some of the time it will be a wake-up call and an expired
> > certificate will be replaced, resulting in more security for all.
>
> I'm +1 for Python 3.5 but -1 for Python 2.7.
>
> The SSLContext backport will landed in Python 2.7.9 (to be released). No
> Python 2 user is familiar with the feature yet. But more importantly:
> None of the stdlib modules support the new feature, too. httplib,
> imaplib ... they all don't take a SSLContext object as an argument.
> PEP-466 does not include the backport for the network modules. Without
> the context argument there is simply no clean way to configure the SSL
> handshake properly.
>
> The default settings must stay until we decide to backport the context
> argument and have a way to configure the default behavior. Nick and me
> are planing a PEP.
>
> Christian
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Victor Stinner]

2014-09-03 21:26 GMT+02:00 Christian Heimes :
> On 03.09.2014 19:54, Guido van Rossum wrote:
> I'm +1 for Python 3.5 but -1 for Python 2.7.
>
> The SSLContext backport will landed in Python 2.7.9 (to be released). No
> Python 2 user is familiar with the feature yet. But more importantly:
> None of the stdlib modules support the new feature, too. httplib,
> imaplib ... they all don't take a SSLContext object as an argument.
> PEP-466 does not include the backport for the network modules. Without
> the context argument there is simply no clean way to configure the SSL
> handshake properly.

Thanks, you replied before I asked the question :-) (If certificates
are validated by default, how do you disable the checks?)

Sorry, I didn't follow the whole discussion and Python 2.7 changes
related to security. Does Python 2.7 support loading (automatically)
system certificate authorities? Like the Windows certificate store:
https://docs.python.org/dev/whatsnew/3.4.html#whatsnew34-win-cert-store

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Christian Heimes]

On 03.09.2014 19:54, Guido van Rossum wrote:
> Let's take the plunge on this issue for the next 2.7 release (3.5 being
> a done deal). Yes, some people will find that they have an old script
> accessing an old service which breaks. Surely some of the other changes
> in the same 2.7 bugfix release will also break some other scripts.
> People deal with it. Probably 90% of the time it's an annoyance (but no
> worse than any other minor-release upgrade -- you should test upgrades
> before committing to them, and if all else fails, roll it back). But at
> least some of the time it will be a wake-up call and an expired
> certificate will be replaced, resulting in more security for all.

I'm +1 for Python 3.5 but -1 for Python 2.7.

The SSLContext backport will landed in Python 2.7.9 (to be released). No
Python 2 user is familiar with the feature yet. But more importantly:
None of the stdlib modules support the new feature, too. httplib,
imaplib ... they all don't take a SSLContext object as an argument.
PEP-466 does not include the backport for the network modules. Without
the context argument there is simply no clean way to configure the SSL
handshake properly.

The default settings must stay until we decide to backport the context
argument and have a way to configure the default behavior. Nick and me
are planing a PEP.

Christian
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Guido van Rossum]

Antoine, I think we are well past the point where arguments can sway
positions. There clearly is no agreement on this issue. So please treat my
post as a BDFL tie-breaker. I will just give you one thing to ponder --
those small/non-profit websites that can't afford proper certs are exactly
the ones that will be hosting malware soon. Sorry for them, and the
certificate vendors certainly aren't in it for charity, but they must fix
their certificate issues (and probably improve many other sysadmin
practices).

--Guido


On Wed, Sep 3, 2014 at 11:37 AM, Antoine Pitrou  wrote:

> On Wed, 3 Sep 2014 10:54:55 -0700
> Guido van Rossum  wrote:
> >
> > Let's take the plunge on this issue for the next 2.7 release (3.5 being a
> > done deal).
>
> I'm entirely against this.
>
> > Yes, some people will find that they have an old script
> > accessing an old service which breaks. Surely some of the other changes
> in
> > the same 2.7 bugfix release will also break some other scripts. People
> deal
> > with it. Probably 90% of the time it's an annoyance (but no worse than
> any
> > other minor-release upgrade -- you should test upgrades before committing
> > to them, and if all else fails, roll it back).
>
> Python is routinely updated to bugfix releases by Linux distributions
> and other distribution channels, you usually have no say over what's
> shipped in those updates. This is not like changing the major version
> used for executing the script, which is normally a manual change.
>
> > Today (working at Dropbox, a much smaller company!) I don't
> > even remember the last time I had to deal with such a browser
> > complaint -- internal services here all redirect to SSL, and not a
> > browser that can find fault with their certs.
>
> Good for you. I still sometimes get warnings about expired certificates
> - and sometimes ones that don't exactly match the domain being
> fetched (for example, the certificate wouldn't be valid for that
> specific subdomain - note that CAs often charge a premium for multiple
> subdomains, which why small or non-profit Web sites sometimes skimp on
> them).
>
> You shouldn't assume that the experience of well-connected people in
> the Silicon Valley is representative of what people over the world
> encounter. Yes, where there's a lot of money and a lot of accumulated
> domain competence, security procedures are updated and followed more
> scrupulously...
>
> > But at least some of the
> > time it will be a wake-up call and an expired certificate will be
> replaced,
> > resulting in more security for all.
>
> Only if you are actually the one managing that certificate and the
> machine it's installed one...
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[R. David Murray]

On Wed, 03 Sep 2014 10:09:36 -0700, Ethan Furman  wrote:
> On 09/03/2014 08:58 AM, R. David Murray wrote:
> >
> > I'm OK with letting go of this invalid-cert issue myself, given the lack
> > of negative feedback Twisted got.  I'll just keep my fingers crossed.
> 
> I apologize if I missed this point, but if we have the source code then it is 
> possible to go in and directly modify the 
> application/utility to be able to talk over https to a router with an invalid 
> certificate?  This is an option when 
> creating the ssl_context?

The immediately preceding paragraph that you didn't quote said that the
context was 3rd party applications, not source code under your control.
Yes, you can (usually) still hack the source, but there are good reasons to
prefer to not do that, unfamiliarity with the codebase being just one of
them.

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Christian Heimes]

On 03.09.2014 19:29, Ethan Furman wrote:
> Excellent.  Last question (I hope): it is possible to (easily) create an
> SSLContext that will verify against a self-signed certificate?

Yes:

   context = ssl.create_default_context(cafile="/path/to/selfsigned.pem")

That works iff the certificate is valid, not expired and its CN or SAN
matches the hostname of the service. When the hostname doesn't match
then you have to set

   context.check_hostname = False

Christian

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[R. David Murray]

On Wed, 03 Sep 2014 20:37:38 +0200, Antoine Pitrou  wrote:
> On Wed, 3 Sep 2014 10:54:55 -0700
> Guido van Rossum  wrote:
> > Today (working at Dropbox, a much smaller company!) I don't
> > even remember the last time I had to deal with such a browser
> > complaint -- internal services here all redirect to SSL, and not a
> > browser that can find fault with their certs.
> 
> Good for you. I still sometimes get warnings about expired certificates
> - and sometimes ones that don't exactly match the domain being
> fetched (for example, the certificate wouldn't be valid for that
> specific subdomain - note that CAs often charge a premium for multiple
> subdomains, which why small or non-profit Web sites sometimes skimp on
> them).
> 
> You shouldn't assume that the experience of well-connected people in
> the Silicon Valley is representative of what people over the world
> encounter. Yes, where there's a lot of money and a lot of accumulated
> domain competence, security procedures are updated and followed more
> scrupulously...

Heck, yesterday I got invalid certs from...I think it was roku.com, but
in any case not some obscure little company...the actual cert was an
akamai cert, which means something is configured wrong somewhere.

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Donald Stufft]

> On Sep 3, 2014, at 1:54 PM, Guido van Rossum  wrote:
> 
> On Wed, Sep 3, 2014 at 8:58 AM, R. David Murray  > wrote:
> I'm OK with letting go of this invalid-cert issue myself, given the lack
> of negative feedback Twisted got.  I'll just keep my fingers crossed.
> 
> I'm with this sentiment (cautiously +1) -- and not just because of Twisted's 
> experience or Glyph's passion.
> 
> Network security is much more important now than it was five years ago -- and 
> yet Python 2.7 is at least that old. My own experience has changed a lot: 
> five years ago (when I worked at Google!) it was common to find internal 
> services that required SSL but had a misconfigured certificate, and the only 
> way to access those services was to override the browser complaints. Today 
> (working at Dropbox, a much smaller company!) I don't even remember the last 
> time I had to deal with such a browser complaint -- internal services here 
> all redirect to SSL, and not a browser that can find fault with their certs. 
> If I did get a complaint about a certificate I would fire off an email to a 
> sysadmin alerting them to the issue.
> 
> Let's take the plunge on this issue for the next 2.7 release (3.5 being a 
> done deal). Yes, some people will find that they have an old script accessing 
> an old service which breaks. Surely some of the other changes in the same 2.7 
> bugfix release will also break some other scripts. People deal with it. 
> Probably 90% of the time it's an annoyance (but no worse than any other 
> minor-release upgrade -- you should test upgrades before committing to them, 
> and if all else fails, roll it back). But at least some of the time it will 
> be a wake-up call and an expired certificate will be replaced, resulting in 
> more security for all.

+1, this makes me unreasonably happy.

> 
> I don't want to start preaching security doom and gloom (the experts are 
> doing enough of that :-), but the scale and sophistication of attacks 
> (whether publicized or not) is constantly increasing, and routine maintenance 
> checks on old software are just one of the small ways that we can help the 
> internet become more secure. (And please let the PSF sysadmin team beef up 
> *.python.org  -- sooner or later some forgotten part of 
> our infrastructure *will* come under attack.)

This is an ongoing effort amongst the Infra team, part of the process is moving 
infrastructure away from hand crafted servers towards servers managed by config 
management as well as making sure all our services are behind TLS as well.

> 
> -- 
> --Guido van Rossum (python.org/~guido )
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/donald%40stufft.io

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Antoine Pitrou]

On Wed, 3 Sep 2014 10:54:55 -0700
Guido van Rossum  wrote:
> 
> Let's take the plunge on this issue for the next 2.7 release (3.5 being a
> done deal).

I'm entirely against this.

> Yes, some people will find that they have an old script
> accessing an old service which breaks. Surely some of the other changes in
> the same 2.7 bugfix release will also break some other scripts. People deal
> with it. Probably 90% of the time it's an annoyance (but no worse than any
> other minor-release upgrade -- you should test upgrades before committing
> to them, and if all else fails, roll it back).

Python is routinely updated to bugfix releases by Linux distributions
and other distribution channels, you usually have no say over what's
shipped in those updates. This is not like changing the major version
used for executing the script, which is normally a manual change.

> Today (working at Dropbox, a much smaller company!) I don't
> even remember the last time I had to deal with such a browser
> complaint -- internal services here all redirect to SSL, and not a
> browser that can find fault with their certs.

Good for you. I still sometimes get warnings about expired certificates
- and sometimes ones that don't exactly match the domain being
fetched (for example, the certificate wouldn't be valid for that
specific subdomain - note that CAs often charge a premium for multiple
subdomains, which why small or non-profit Web sites sometimes skimp on
them).

You shouldn't assume that the experience of well-connected people in
the Silicon Valley is representative of what people over the world
encounter. Yes, where there's a lot of money and a lot of accumulated
domain competence, security procedures are updated and followed more
scrupulously...

> But at least some of the
> time it will be a wake-up call and an expired certificate will be replaced,
> resulting in more security for all.

Only if you are actually the one managing that certificate and the
machine it's installed one...

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Guido van Rossum]

On Wed, Sep 3, 2014 at 8:58 AM, R. David Murray 
wrote:

> I'm OK with letting go of this invalid-cert issue myself, given the lack
> of negative feedback Twisted got.  I'll just keep my fingers crossed.
>

I'm with this sentiment (cautiously +1) -- and not just because of
Twisted's experience or Glyph's passion.

Network security is much more important now than it was five years ago --
and yet Python 2.7 is at least that old. My own experience has changed a
lot: five years ago (when I worked at Google!) it was common to find
internal services that required SSL but had a misconfigured certificate,
and the only way to access those services was to override the browser
complaints. Today (working at Dropbox, a much smaller company!) I don't
even remember the last time I had to deal with such a browser complaint --
internal services here all redirect to SSL, and not a browser that can find
fault with their certs. If I did get a complaint about a certificate I
would fire off an email to a sysadmin alerting them to the issue.

Let's take the plunge on this issue for the next 2.7 release (3.5 being a
done deal). Yes, some people will find that they have an old script
accessing an old service which breaks. Surely some of the other changes in
the same 2.7 bugfix release will also break some other scripts. People deal
with it. Probably 90% of the time it's an annoyance (but no worse than any
other minor-release upgrade -- you should test upgrades before committing
to them, and if all else fails, roll it back). But at least some of the
time it will be a wake-up call and an expired certificate will be replaced,
resulting in more security for all.

I don't want to start preaching security doom and gloom (the experts are
doing enough of that :-), but the scale and sophistication of attacks
(whether publicized or not) is constantly increasing, and routine
maintenance checks on old software are just one of the small ways that we
can help the internet become more secure. (And please let the PSF sysadmin
team beef up *.python.org -- sooner or later some forgotten part of our
infrastructure *will* come under attack.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sad status of Python 3.x buildbots

[francis]

[...] But it

does mean a measure of trust in some external entity, or else some
very careful rules (mainly firewall), which not every coder will know
about.


Just curious, is there a way to mount the infrastructure the oder way 
around? One sets a system polling for sources changes, if so it starts

a build an sends per e-mail the results to some address.

Thanks in advance!
francis


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Ethan Furman]

On 09/03/2014 10:15 AM, Alex Gaynor wrote:

Ethan Furman writes:


I apologize if I missed this point, but if we have the source code then it is
possible to go in and directly modify the application/utility to be able to
talk over https to a router with an invalid certificate?  This is an option
when creating the ssl_context?


Yes, it's totally possible to create (and pass to ``http.client``) an
``SSLContext`` which doesn't verify various things. My proposal is only about
changing what happens when you don't explicitly pass a context.


Excellent.  Last question (I hope): it is possible to (easily) create an SSLContext that will verify against a 
self-signed certificate?


--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7

[Chris Barker]

On Sun, Aug 31, 2014 at 3:00 PM, Nick Coghlan  wrote:
>
> However, we still think we should start providing pip by default to Python
> 2.7 users as well, at least as part of the Windows and Mac OS X installers.
>
serious +1 here.

Just last night I was writing up notes for an intro to python class on
getting started. (py2, :-( )

The "go download get-pip.py and run it with python" step(s) is a serious
hiccup. Better than it's been for years, but sure would be nice to just
"install python" then "use pip to install packages"

As for the feature freeze of py2.7 -- this is really an addition to teh
installers, not to python itself (or it can be seen that way, anyway)

Thanks Ned for offering to back port for OS-X !

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Alex Gaynor]

Ethan Furman  stoneleaf.us> writes:

> 
> I apologize if I missed this point, but if we have the source code then it is
> possible to go in and directly modify the application/utility to be able to
> talk over https to a router with an invalid certificate?  This is an option
> when creating the ssl_context?
> 
> --
> ~Ethan~
> 


Yes, it's totally possible to create (and pass to ``http.client``) an
``SSLContext`` which doesn't verify various things. My proposal is only about
changing what happens when you don't explicitly pass a context.

Cheers,
Alex

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sad status of Python 3.x buildbots

[Shorya Raj]

As mentioned, I don't mind sysadmining a bit, if required. My primary joy
would be helping code python, but can't seem to figure out the ideal place
to start doing so. Therefore, helping out as sysadmin would be a good start.


On Wed, Sep 3, 2014 at 4:58 PM, Cameron Simpson  wrote:

> On 03Sep2014 11:47, Stephen J. Turnbull  wrote:
>
>> Nick Coghlan writes:
>> > Sorry, I haven't been a very good maintainer for that buildbot (the main
>> > reason it never graduated to the "stable" list). If you send me your
>> public
>> > SSH key, I can add it (I think - if not, I can ask Luke to do it).
>> > Alternatively, CentOS 6 may exhibit the same problem.
>>
>> I wonder how many of these buildbots could be maintained by the kind
>> of folks who show up on core-mentorship asking "how can I help?"
>>
>> Just a thought -- I wouldn't be surprised if the reaction is universal
>> horror and the answer is "Are you crazy?  Zero!  Z-E-R-O!!"
>>
>> And of course most want to write code, not sysadm.
>>
>
> I do both. Happy to help in a small way if wanted.
>
> Cheers,
> Cameron Simpson 
>
> Maintainer's Motto: If we can't fix it, it ain't broke.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> rajshorya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Ethan Furman]

On 09/03/2014 08:58 AM, R. David Murray wrote:


I'm OK with letting go of this invalid-cert issue myself, given the lack
of negative feedback Twisted got.  I'll just keep my fingers crossed.


I apologize if I missed this point, but if we have the source code then it is possible to go in and directly modify the 
application/utility to be able to talk over https to a router with an invalid certificate?  This is an option when 
creating the ssl_context?


--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[R. David Murray]

On Wed, 03 Sep 2014 16:31:13 +0200, Antoine Pitrou  wrote:
> On Tue, 02 Sep 2014 21:29:16 -0400
> "R. David Murray"  wrote:
> > 
> > The top proposal so far is an sslcustomize.py file that could be used to
> > either decrease or increase the default security.  This is a much less
> > handy solution than application options (eg, curl, wget) that allow
> > disabling security for "this cert" or "this CLI session".  It also is
> > more prone to unthinking abuse since it is persistent.  So perhaps
> > it is indeed not worth it.  (That's why I suggested an environment
> > variable...something you could specify on the command line for a one-off.)
> 
> I'll be fine with not adding any hooks at all, and letting people
> configure their application code correctly :-)

Again, the problem arises when it is not *their* application code, but
a third party tool that hasn't been ported to 3.5.

I'm OK with letting go of this invalid-cert issue myself, given the lack
of negative feedback Twisted got.  I'll just keep my fingers crossed.

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Antoine Pitrou]

On Tue, 02 Sep 2014 21:29:16 -0400
"R. David Murray"  wrote:
> 
> The top proposal so far is an sslcustomize.py file that could be used to
> either decrease or increase the default security.  This is a much less
> handy solution than application options (eg, curl, wget) that allow
> disabling security for "this cert" or "this CLI session".  It also is
> more prone to unthinking abuse since it is persistent.  So perhaps
> it is indeed not worth it.  (That's why I suggested an environment
> variable...something you could specify on the command line for a one-off.)

I'll be fine with not adding any hooks at all, and letting people
configure their application code correctly :-)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Antoine Pitrou]

On Wed, 3 Sep 2014 20:34:32 +1000
Nick Coghlan  wrote:
> 
> The backwards compatibility argument only applies to Python 2 maintenance
> releases (where dreid indicated an intention to request backporting the
> change), and there I'm quite happy to take the position of "use requests,
> Twisted or Python 3.5+ to get HTTPS done right".

or asyncio.

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Nick Coghlan]

On 3 Sep 2014 18:28, "Cory Benfield"  wrote:

> This is definitely true, and this change is both. The only question
> that matters is whether we believe we're doing users a service by
> breaking their code. I'd argue, along with Glyph, Alex and Donald,
> that we are. I've been on the losing side of this debate a number of
> times though, and I expect I will be again.

The default stdlib behaviour will change in 3.5, I don't think anyone is
disputing that. While I earlier said that should depend on the sslcustomize
PEP, I now think they should be made orthogonal so the SSL customisation
PEP can focus on its potential for *increasing* security in properly
configured environments rather than deliberately decreasing it after
upgrading to Python 3.5 in improperly configured ones.

The backwards compatibility argument only applies to Python 2 maintenance
releases (where dreid indicated an intention to request backporting the
change), and there I'm quite happy to take the position of "use requests,
Twisted or Python 3.5+ to get HTTPS done right".

There are a variety of reasons not to use the Python 2 stdlib for modern
networking, and making better tools more readily accessible to Python 2
users by backporting ensurepip is my preferred answer.

Regards,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sad status of Python 3.x buildbots

[Christian Staffa]

Hi all

I am using buildbot now for some time and i would be willing to contribute on 
that. I had small work on openstack buildbot slave but had not the proper 
infrastructure to get more value out of it. I like that project and automation. 
Anyway, if i could be of help let me know (;
Short to my person: i am christian staffa and actually living in germany.

   Chris

Sent from my Sony Xperia™ smartphone

 Nick Coghlan wrote 

>___
>Python-Dev mailing list
>Python-Dev@python.org
>https://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe: 
>https://mail.python.org/mailman/options/python-dev/christian.staffa%40gmx.de
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

[Cory Benfield]

On 3 September 2014 01:19, Antoine Pitrou  wrote:
> Keeping saying it doesn't make it magically true.

Sure, but it *is* true, at the very least for HTTP.

RFC 2818 (HTTP over TLS) has the following language in section 3.1:

> If the hostname is available, the client MUST check it against the
> server's identity as presented in the server's Certificate message,
> in order to prevent man-in-the-middle attacks.
>
> If the client has external information as to the expected identity of
> the server, the hostname check MAY be omitted.

The default behaviour of httplib is in contravention of the normative
language of this specification and is therefore bugged. (For those
unclear about the relevance of RFC 2818, it's normatively referenced
by RFC 7230, which is the HTTP/1.1 spec.)

This should silence the debate about whether or not httplib's
behaviour is a bug or not.

> Besides, it can perfectly well be a bug fix *as well as* a break in
> backwards compatibility.

This is definitely true, and this change is both. The only question
that matters is whether we believe we're doing users a service by
breaking their code. I'd argue, along with Glyph, Alex and Donald,
that we are. I've been on the losing side of this debate a number of
times though, and I expect I will be again.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com