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

[Nick Coghlan]

On 2 September 2014 07:17, Matthew Woodcraft  wrote:
>
> (The program handles SIGTERM so that it can do a bit of cleanup before
> exiting, and it uses the signal-handler-sets-a-flag technique. The call
> that might be interrupted is sleep(), so the program doesn't strictly
> _rely_ on the existing behaviour; it would just become very slow to
> exit.)

Making an exception for sleep() (i.e. still letting it throw EINTR)
sounds like a reasonable idea to me.

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] https:bugs.python.org -- Untrusted Connection (Firefox)

[Nick Coghlan]

On 2 September 2014 10:34, John Wong  wrote:
> As of today I still am getting untrusted cert thought I would re-ping to see
> if there is an ETA.

Thanks for the ping - I got sidetracked by other things, and didn't
follow up on this one. I've kicked things into motion again, and it
will hopefully be resolved before too long.

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] RFC: PEP 475, Retry system calls failing with EINTR

[Antoine Pitrou]

On Mon, 1 Sep 2014 21:17:33 + (UTC)
Matthew Woodcraft  wrote:
> 
> > If such applications exist, they are not portable and are subject to
> > race conditions (deadlock if the signal comes before the system call).
> 
> The program is certainly not portable (which is not any kind of a
> problem), and as pselect is unavailable there is indeed the usual
> theoretical race (which has not been a problem in practice in the ten
> years it's been running).
> 
> (The program handles SIGTERM so that it can do a bit of cleanup before
> exiting, and it uses the signal-handler-sets-a-flag technique. The call
> that might be interrupted is sleep(), so the program doesn't strictly
> _rely_ on the existing behaviour; it would just become very slow to
> exit.)

So, if it's just for process exit, just let the signal handler raise an
exception and catch the exception at the top-level.

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] https:bugs.python.org -- Untrusted Connection (Firefox)

[Terry Reedy]

On 9/2/2014 1:49 AM, Oleg Broytman wrote:

Hi!

On Mon, Sep 01, 2014 at 08:32:27PM -0500, Skip Montanaro 
 wrote:

I got the same in Chrome on my Mac.

Skip
On Sep 1, 2014 8:00 PM, "John Wong"  wrote:


As of today I still am getting untrusted cert thought I would re-ping to
see if there is an ETA.


The signing certificate is still CAcert. One can install their root
certificate from http://www.cacert.org/index.php?id=3


This seems not to work for Firefox. "Windows installer package for 
browsers that use the Windows certificate store (for example Internet 
Explorer, Chrome on Windows and Safari on Windows)"


I installed it anyway, closed and reopened Firefox (but not rebooted) 
and https://bugs.python.org still gives Untrusted message.


--
Terry Jan Reedy

___
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!

[Glyph Lefkowitz]

On Aug 29, 2014, at 7:44 PM, Alex Gaynor  wrote:
>  Disabling verification entirely externally to the program, through a CLI flag
>  or environment variable. I'm pretty down on this idea, the problem you hit is
>  that it's a pretty blunt instrument to swing, and it's almost impossible to
>  imagine it not hitting things it shouldn't; it's far too likely to be used in
>  applications that make two sets of outbound connections: 1) to some internal
>  service which you want to disable verification on, and 2) some external
>  service which needs strong validation. A global flag causes the latter to
>  fail silently when subjected to a MITM attack, and that's exactly what we're
>  trying to avoid. It also makes things much harder for library authors: I
>  write an API client for some API, and make TLS connections to it. I want
>  those to be verified by default. I can't even rely on the httplib defaults,
>  because someone might disable them from the outside.


I would strongly recommend against such a mechanism.

For what it's worth, Twisted simply unconditionally started verifying 
certificates in 14.0 with no "disable" switch, and (to my knowledge) literally 
no users have complained.

Twisted has a very, very strict backwards compatibility policy.  For example, I 
once refused to accept the deletion of a class that raised an exception upon 
construction, on the grounds that someone might have been inadvertently 
importing that class, and they shouldn't see an exception until they've seen a 
deprecation for one release.

Despite that, we classified failing to verify certificates as a security bug, 
and fixed it with no deprecation period.  When users type the 's' after the 'p' 
and before the ':' in a URL, they implicitly expect browser-like certificate 
verification.

The lack of complaints is despite the fact that 14.0 has been out for several 
months now, and, thanks to the aforementioned strict policy, users tend to 
upgrade fairly often (since they know they can almost always do so without fear 
of application-breaking consequences).  According to PyPI metadata, 14.0.0 has 
had 273283 downloads so far.

Furthermore, "disable verification" is a nonsensical thing to do with TLS.  
"select a trust root" is a valid configuration option, and OpenSSL already 
provides it via the SSL_CERT_DIR environment variable, so there's no need for 
Python to provide anything beyond that.

-glyph

___
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]

Nick Coghlan   wrote:
>On 2 September 2014 07:17, Matthew Woodcraft  wrote:
>> (The program handles SIGTERM so that it can do a bit of cleanup before
>> exiting, and it uses the signal-handler-sets-a-flag technique. The call
>> that might be interrupted is sleep(), so the program doesn't strictly
>> _rely_ on the existing behaviour; it would just become very slow to
>> exit.)

> Making an exception for sleep() (i.e. still letting it throw EINTR)
> sounds like a reasonable idea to me.

I think people who use sleep() in their programs could benefit from not
having to worry about EINTR as much as anyone else.

And I don't think there's any reason to suppose that programs using
sleep() are more likely than others to want to see EINTR. I think
blocking network operations are more likely to be involved.

-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] RFC: PEP 475, Retry system calls failing with EINTR

[Matthew Woodcraft]

Antoine Pitrou   wrote:
>Matthew Woodcraft  wrote:
>> (The program handles SIGTERM so that it can do a bit of cleanup before
>> exiting, and it uses the signal-handler-sets-a-flag technique. The call
>> that might be interrupted is sleep(), so the program doesn't strictly
>> _rely_ on the existing behaviour; it would just become very slow to
>> exit.)

> So, if it's just for process exit, just let the signal handler raise an
> exception and catch the exception at the top-level.

I wouldn't recommend that anyone take this advice. The signal might come
at some time other than the sleep(), and introducing an exception which
can mysteriously appear at abitrary points is not a way to make life
easier.

Nonetheless I'm sure my program would be easy enough to fix to use
set_wakeup_fd() or signalfd() if necessary.

I'm not saying we shouldn't make this backwards-incompatible change
because it will be hard to update existing programs to cope; I'm saying
we shouldn't pretend it doesn't count as a backwards-incompatible
change.


In any case I think PEP 475 should be explaining what is going to happen
to signal.siginterrupt(). Will setting flag=True be supported? 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 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.)

-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] https:bugs.python.org -- Untrusted Connection (Firefox)

[Oleg Broytman]

On Tue, Sep 02, 2014 at 04:14:25PM -0400, Terry Reedy  wrote:
> On 9/2/2014 1:49 AM, Oleg Broytman wrote:
> >On Mon, Sep 01, 2014 at 08:32:27PM -0500, Skip Montanaro 
> > wrote:
> >>I got the same in Chrome on my Mac.
> >>
> >>Skip
> >>On Sep 1, 2014 8:00 PM, "John Wong"  wrote:
> >>
> >>>As of today I still am getting untrusted cert thought I would re-ping to
> >>>see if there is an ETA.
> >
> >The signing certificate is still CAcert. One can install their root
> >certificate from http://www.cacert.org/index.php?id=3
> 
> This seems not to work for Firefox. "Windows installer package for
> browsers that use the Windows certificate store (for example
> Internet Explorer, Chrome on Windows and Safari on Windows)"
> 
> I installed it anyway, closed and reopened Firefox (but not
> rebooted) and https://bugs.python.org still gives Untrusted message.

   Did you install it in the Firefox own certificate manager?

http://wiki.cacert.org/FAQ/BrowserClients#Mozilla_Firefox

   "Firefox uses it's own Certificate Manager. So even if your Windows
(and other Microsoft) applications already use a root certificate
Firefox still might not."

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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, 2 Sep 2014 14:00:02 -0700
Glyph Lefkowitz  wrote:
> 
> I would strongly recommend against such a mechanism.
> 
> For what it's worth, Twisted simply unconditionally started verifying 
> certificates in 14.0 with no "disable" switch, and (to my knowledge) 
> literally no users have complained.

And how many people are using Twisted as an HTTPS client?
(compared to e.g. Python's httplib, and all the third-party libraries
building on it?)

> Furthermore, "disable verification" is a nonsensical thing to do with TLS.

It's not. For example, if you have an expired cert, all you can do
AFAIK is to disable verification.

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] RFC: PEP 475, Retry system calls failing with EINTR

[Victor Stinner]

2014-09-02 23:02 GMT+02:00 Matthew Woodcraft :
> I think people who use sleep() in their programs could benefit from not
> having to worry about EINTR as much as anyone else.


The behaviour of time.sleep() is worse than what I expected. On UNIX,
if select() fails with EINTR, time.sleep() calls PyErr_CheckSignals().
If the signal handler doesn't raise an exception, time.sleep() returns
None and just simply ignores the error.

But on Windows, it's the opposite. If time.sleep() is interrupt by
CTRL+c, time.sleep() raises an InterruptedError...

Good luck to write portable code :-p

With the PEP 475, time.sleep(secs) now has a well defined behaviour.
It sleeps at least "secs" seconds, retry the syscall on EINTR, and
raises an exception if the signal handler raises an exception.

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] RFC: PEP 475, Retry system calls failing with EINTR

[Victor Stinner]

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.

> (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?

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!

[Nick Coghlan]

On 1 Sep 2014 16:05, "Nick Coghlan"  wrote:
>
> The final change would be to seed the context factory map
> appropriately for the standard library modules where we wanted to keep
> the *old* default:
>
> for modname in ("nntplib", "poplib", "imaplib", "ftplib",
> "smtplib", "asyncio.selector_events", "urllib.request",
> "http.client"):
> named_contexts[modname] = create_legacy_context
>
> The list I have above is for *all* current uses of
> "sss._create_stdlib_context". The backwards incompatible part of PEP
> 476 would then just be about removing names from that list (currently
> just "http.client", but I'd suggest "asyncio.selector_events" as
> another candidate, taking advantage of asyncio's provisional API
> status).

Update on this: Christian & I both like the SSL named context and
customisation idea independently of the proposal to change the default
behaviour, so we're going to write it up as a separate PEP.

Changing the default behaviour would then be reduced to a proposal to take
a couple of module names off the "uses legacy SSL settings" list.

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

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

[Victor Stinner]

Hi,

I'm using Python buildbots to ensure that my changes don't fail on
some platform. It's important for changes close to the operation
system. The problem is that many buildbots are ill.

Before, only a few buildbots had sporadic failures. Now most buildbots
are always fail (are red).

Here is an incomplete list of failures seen on buildbots. Before I
opened an issue for each bug, but usually nobody takes care of them.
So today I'm trying the mailing list.

How can we fix all these issues to have more "green" buildbots? Can
anyone help on this task?


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.

AMD64 Snow Leop 3.x: many tests are not reliable (stable) on this
platform. For example, test_logging.test_race() sometimes fail with
PermissionError(1, "Operation not permitted:
'/tmp/test_logging-3-bjulw8iz.log'"). Another example,
test_asyncio.test_stdin_broken_pipe() sometimes fail with an assertion
error because BrokenPipeError was not raised. Do we still support this
old version of Mac OS X? Released in 2009, it is 5 years old. Is
upgrading to Maverick (10.9) free and possible on old Mac computers? I
don't have access to this old OS.

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.

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.

x86 Windows7 3.x: test_nntplib fails with OSError("cannot read from
timed out object").

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.


AMD64 Solaris 11 [SB] 3.x: sometimes, tests fail with MemoryError.
test_uuid.test_uuid4() fails with an assertion error. ctypes has issue
with the sign of integer numbers (bug in libffi?).

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

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

x86 FreeBSD 6.4 3.x: test_urllib2net.test_urlwithfrag() fails with
urllib.error.URLError: .
test_tcl has many issues. test_multiprocessing_spawn fails whereas the
test should be skipped.

x86 OpenBSD 5.5 3.x: many failing tests.

x86 OpenIndiana 3.x: MemoryError. TestReadline.test_init() also fails.

x86 Tiger 3.x: test_nntplib fails with OSError("cannot read from timed
out object".

I skipped "SPARC Solaris 10 OpenCSW 3.x" and "PPC64 AIX 3.x" in my
list, I'm not really interested by these platforms.

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]

Antoine Pitrou  pitrou.net> writes:

> 
> And how many people are using Twisted as an HTTPS client?
> (compared to e.g. Python's httplib, and all the third-party libraries
> building on it?)
> 

I don't think anyone could give an honest estimate of these counts, however
there's two factors to bare in mind: a) It's extremely strongly recommended to
use requests to make any HTTP requests precisely because httplib is negligent
in certificate and hostname checking by default, b) We're talking about
Python3, which has fewer users than Python2.

> > Furthermore, "disable verification" is a nonsensical thing to do with TLS.
> 
> It's not. For example, if you have an expired cert, all you can do
> AFAIK is to disable verification.
> 

It really is a nonsensical operation, accepting any random TLS certificate
without pinning or use of a certificate authorities makes a valid connection
completely indistinguishable from a MITM attack.

If I were the emperor of the universe (or even just Python ;-)) I wouldn't
allow this operation at all, however, I'm not and you can still disable any and
all verification. It just requires you to pass a different argument, which
doesn't seem overly burdensome.

This whole scenario seems to be predicated on a siutation where: You have a
peer whose certificate you can't change, and you have a piece of code you can't
change, and you're going to upgrade your Python installation, and you want to
talk to this peer, and you need to use an encrypted channel, but don't really
care if it's being MITM'd. It doesn't seem to me that this is reasonably
Python's responsibility to deal with the fact that you have no ability to
upgrade any of your infrastructure, except your Python version.

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] PEP 476: Enabling certificate validation by default!

[Antoine Pitrou]

On Tue, 2 Sep 2014 22:16:18 + (UTC)
Alex Gaynor  wrote:
> > > Furthermore, "disable verification" is a nonsensical thing to do with TLS.
> > 
> > It's not. For example, if you have an expired cert, all you can do
> > AFAIK is to disable verification.
> 
> It really is a nonsensical operation, accepting any random TLS certificate
> without pinning or use of a certificate authorities makes a valid connection
> completely indistinguishable from a MITM attack.

It's still distinguishable from a passively-eavesdroppable clear-text
connection, though.

> This whole scenario seems to be predicated on a siutation where: You have a
> peer whose certificate you can't change, and you have a piece of code you 
> can't
> change, and you're going to upgrade your Python installation, and you want to
> talk to this peer, and you need to use an encrypted channel, but don't really
> care if it's being MITM'd. It doesn't seem to me that this is reasonably
> Python's responsibility to deal with the fact that you have no ability to
> upgrade any of your infrastructure, except your Python version.

Oh, I agree that whoever upgrades their Python version should be able
to fix any of their applications should they start failing. That's why
I don't want to let new command-line options and environment variables
proliferate in the name of damage control.

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!

[Christian Heimes]

On 02.09.2014 23:32, Antoine Pitrou wrote:
>> Furthermore, "disable verification" is a nonsensical thing to do with TLS.
> 
> It's not. For example, if you have an expired cert, all you can do
> AFAIK is to disable verification.

It's possible to ignore or just warn about expired certs with simple
verify callback. The callback looks like this:

int verify_callback(int ok, X509_STORE_CTX *ctx)
{
if (X509_STORE_CTX_get_error(ctx) == X509_V_ERR_CERT_HAS_EXPIRED)
return 1;
return ok;
}

It's installed like this:

PySSLContext *self;
X509_STORE *store = SSL_CTX_get_cert_store(self->ctx);
X509_STORE_set_verify_cb(store, verify_callback);

The X509_STORE_CTX struct is created when a certificate chain is
verified. It holds all sorts of states like chain, leaf cert, current
cert that is tested, validation depth, error flags and more. In order to
write useful verify callbacks me or somebody else has to write a
X509_STORE_CTX type and X509 cert type. It's something I want to do for
more than a year but I don't find any spare time. :(

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] Sad status of Python 3.x buildbots

[Nick Coghlan]

On 3 Sep 2014 08:15, "Victor Stinner"  wrote:
>
> 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.

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.

>From a completely different perspective, does anyone have experience with
using BuildBot with OpenStack hosted clients? We may be able to take
advantage of the PSF's new(ish) Rackspace infrastructure to provide more
stable test VMs.

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] Sad status of Python 3.x buildbots

[Brian Curtin]

On Tue, Sep 2, 2014 at 5:53 PM, Nick Coghlan  wrote:

>
> On 3 Sep 2014 08:15, "Victor Stinner"  wrote:
> >
> > 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.
>
> 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.
>
> From a completely different perspective, does anyone have experience with
> using BuildBot with OpenStack hosted clients? We may be able to take
> advantage of the PSF's new(ish) Rackspace infrastructure to provide more
> stable test VMs.
>
Is this a Buildbot feature (as in Buildbot master spins up VMs fresh for a
test run, or something), or do you just want to spin up a bunch of VMs,
give access, and we configure them the same as we do today?
___
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 08:18, "Alex Gaynor"  wrote:
>
> Antoine Pitrou  pitrou.net> writes:
>
> >
> > And how many people are using Twisted as an HTTPS client?
> > (compared to e.g. Python's httplib, and all the third-party libraries
> > building on it?)
> >
>
> I don't think anyone could give an honest estimate of these counts,
however
> there's two factors to bare in mind: a) It's extremely strongly
recommended to
> use requests to make any HTTP requests precisely because httplib is
negligent
> in certificate and hostname checking by default, b) We're talking about
> Python3, which has fewer users than Python2.

Creating *new* incompatibilities between Python 2 & Python 3 is a major
point of concern. One key focus of 3.5 is *reducing* barriers to migration,
and this PEP would be raising a new one.

It's a change worth making, but we have time to ensure there are easy ways
to do things like skipping cert validation, or tolerate expired
certificates.

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

[Nick Coghlan]

On 3 Sep 2014 09:00, "Brian Curtin"  wrote:
>
> On Tue, Sep 2, 2014 at 5:53 PM, Nick Coghlan  wrote:
>>
>> From a completely different perspective, does anyone have experience
with using BuildBot with OpenStack hosted clients? We may be able to take
advantage of the PSF's new(ish) Rackspace infrastructure to provide more
stable test VMs.
>
> Is this a Buildbot feature (as in Buildbot master spins up VMs fresh for
a test run, or something), or do you just want to spin up a bunch of VMs,
give access, and we configure them the same as we do today?

The former would be better, but I have no idea if BuildBot supports it
natively. The latter may still help if it replaces resource constrained VMs
(and would also mean the PSF infra team could grant access for
investigations).

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!

[David Reid]

Nick Coghlan  gmail.com> writes:

> Creating *new* incompatibilities between Python 2 & Python 3 is a major point
> of concern. 

Clearly this change should be backported to Python2.

-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!

[R. David Murray]

On Tue, 02 Sep 2014 22:16:18 -, Alex Gaynor  wrote:
> This whole scenario seems to be predicated on a siutation where: You have a
> peer whose certificate you can't change, and you have a piece of code you 
> can't
> change, and you're going to upgrade your Python installation, and you want to
> talk to this peer, and you need to use an encrypted channel, but don't really
> care if it's being MITM'd. It doesn't seem to me that this is reasonably
> Python's responsibility to deal with the fact that you have no ability to
> upgrade any of your infrastructure, except your Python version.

I would say that is an excellent summary, except that you are sometimes
*forced* to use an encrypted channel (the device only opens the https port).
That is, in the real messy world of network devices, accepting an
invalid cert is not a nonsensical operation.  (Of course, what I really
want is to be able to say "I know this cert has invalid fields, accept
it anyway, but warn me if it changes when I connect again".)

It's a good point that the actual number of people who will be hit by
this and can't hack the code in question will be (possibly vanishingly)
small, especially if you only consider python3.  But we've already had
one call for a backport :)

--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!

[Glyph Lefkowitz]

On Sep 2, 2014, at 4:01 PM, Nick Coghlan  wrote:

> 
> On 3 Sep 2014 08:18, "Alex Gaynor"  wrote:
> >
> > Antoine Pitrou  pitrou.net> writes:
> >
> > >
> > > And how many people are using Twisted as an HTTPS client?
> > > (compared to e.g. Python's httplib, and all the third-party libraries
> > > building on it?)
> > >
> >
> > I don't think anyone could give an honest estimate of these counts, however
> > there's two factors to bare in mind: a) It's extremely strongly recommended 
> > to
> > use requests to make any HTTP requests precisely because httplib is 
> > negligent
> > in certificate and hostname checking by default, b) We're talking about
> > Python3, which has fewer users than Python2.
> 
> Creating *new* incompatibilities between Python 2 & Python 3 is a major point 
> of concern. One key focus of 3.5 is *reducing* barriers to migration, and 
> this PEP would be raising a new one.
> 
No.  Providing the security that the user originally asked for is not a 
"backwards incompatible change".  It is a bug fix.  And believe me: I care a 
_LOT_ about reducing barriers to migration.  This would not be on my list of 
the top 1000 things that make migration difficult.
> It's a change worth making, but we have time to ensure there are easy ways to 
> do things like skipping cert validation, or tolerate expired certificates.
> 

The API already supports both of these things.  What I believe you're 
implicitly saying is that there needs to be a way to do this without editing 
code, and... no, there really doesn't.  Not to mention the fact that you could 
already craft a horrific monkeypatch to allow operators to cause the ssl module 
to malfunction by 'pip install'ing a separate package, which is about as 
supported as this should be.

-glyph

___
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 09:08, "David Reid"  wrote:
>
> Nick Coghlan  gmail.com> writes:
>
> > Creating *new* incompatibilities between Python 2 & Python 3 is a major
point
> > of concern.
>
> Clearly this change should be backported to Python2.

Proposing to break backwards compatibility in a maintenance release would
require an *even better* migration story for handling legacy
infrastructure. There's a reason the Py3 compatibility break was
accompanied by a long term support commitment for Python 2 (and why that
commitment was extended another 5 years when it became clear the
implications of the binary and text handling were more significant than we
originally realised).

It's important to remember that the tech industry in general, and open
source focused companies in particular, tend to be amongst the best of the
best when it comes to infrastructure management (and we're still pretty
terrible at it).

The vast majority of infrastructure in the world *isn't* in the hands of
those companies though - it's in the hands of companies where having any
kind of computing infrastructure at all is merely a cost of doing business.

Alex's "ridiculous" scenario doesn't sound ridiculous to me - it sounds
like a typical corporate computing environment.

Regards,
Nick.

>
> -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/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!

[Glyph Lefkowitz]

On Sep 2, 2014, at 4:28 PM, Nick Coghlan  wrote:

> On 3 Sep 2014 09:08, "David Reid"  wrote:
> >
> > Nick Coghlan  gmail.com> writes:
> >
> > > Creating *new* incompatibilities between Python 2 & Python 3 is a major 
> > > point
> > > of concern.
> >
> > Clearly this change should be backported to Python2.
> 
> Proposing to break backwards compatibility in a maintenance release (...)
> 

As we keep saying, this is not a break in backwards compatibility, it's a bug 
fix.  Yes, systems might break, but that breakage represents an increase in 
security which may well be operationally important.  Not everyone with a 
"working" application has the relevant understanding an expertise to know that 
Python's HTTP client is exposing them to surveillance.  These applications 
should break. That is the very nature of the fix.  It is not a "compatibility 
break" that the system starts correctly rejecting invalid connections.

By way of analogy, here's another kind of breach in security: an arbitrary 
remote code execution vulnerability in XML-RPC.  I think we all agree that any 
0day RCE vulnerabilities in Python really ought to be fixed and could be 
legitimately included without worrying about backwards compatibility breaks.  
(At least... gosh, I hope so.)

Perhaps this arbitrary remote execution looks harmless; the use of an eval() 
instead of an int() someplace.  Perhaps someone discovered that they can do "3 
+ 4" in their XML-RPC and the server does the computation for them.  Great!  
They start relying on this in their applications to use symbolic values in 
their requests instead of having explicit enumerations.  This can save you 
quite a bit of code!

When the RCE is fixed, this application will break, and that's fine.  In fact 
that's the whole point of issuing the fix, that people will no longer be able 
to make arbitrary computation requests of your server any more.  If that 
server's maintainer has the relevant context and actually wants the XML-RPC 
endpoint to enable arbitrary RCE, they can easily modify their application to 
start doing eval() on the data that they received, just as someone can easily 
modify their application to intentionally disable all connection security.  
(Let's stop calling it "certificate verification" because that sounds like some 
kind of clerical detail: if you disable certificate verification, TLS 
connections are unauthenticated and unidentified and therefore insecure.)

For what it's worth, on the equivalent Twisted change, I originally had just 
these concerns, but my mind was changed when I considered what exactly the 
user-interface ramifications were for people typing that 's' for 'secure' in 
URLs.  I was convinced, and we made the change, and there have been no ill 
effects that I'm aware of as a result.  In fact, there has been a renewed 
interest in Twisted for HTTP client work, because we finally made security work 
more or less like it's supposed to, and the standard library is so broken.

I care about the health of the broader Python community, so I will passionately 
argue that this change should be made, but for me personally it's a lot easier 
to justify that everyone should use Twisted (at least since 14+) because 
transport security in the stdlib is such a wreck and even if it gets fixed it's 
going to have easy options to turn it off unilaterally so your application can 
never really be sure if it's getting transport security when it's requesting 
transport security.

-glyph

___
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 2, 2014, at 7:47 PM, Glyph Lefkowitz  wrote:
> 
> 
> On Sep 2, 2014, at 4:28 PM, Nick Coghlan  > wrote:
> 
>> On 3 Sep 2014 09:08, "David Reid" mailto:dr...@dreid.org>> 
>> wrote:
>> >
>> > Nick Coghlan  gmail.com > writes:
>> >
>> > > Creating *new* incompatibilities between Python 2 & Python 3 is a major 
>> > > point
>> > > of concern.
>> >
>> > Clearly this change should be backported to Python2.
>> 
>> Proposing to break backwards compatibility in a maintenance release (...)
>> 
> 
> As we keep saying, this is not a break in backwards compatibility, it's a bug 
> fix.  Yes, systems might break, but that breakage represents an increase in 
> security which may well be operationally important.  Not everyone with a 
> "working" application has the relevant understanding an expertise to know 
> that Python's HTTP client is exposing them to surveillance.  These 
> applications should break. That is the very nature of the fix.  It is not a 
> "compatibility break" that the system starts correctly rejecting invalid 
> connections.
> 
> By way of analogy, here's another kind of breach in security: an arbitrary 
> remote code execution vulnerability in XML-RPC.  I think we all agree that 
> any 0day RCE vulnerabilities in Python really ought to be fixed and could be 
> legitimately included without worrying about backwards compatibility breaks.  
> (At least... gosh, I hope so.)
> 
> Perhaps this arbitrary remote execution looks harmless; the use of an eval() 
> instead of an int() someplace.  Perhaps someone discovered that they can do 
> "3 + 4" in their XML-RPC and the server does the computation for them.  
> Great!  They start relying on this in their applications to use symbolic 
> values in their requests instead of having explicit enumerations.  This can 
> save you quite a bit of code!
> 
> When the RCE is fixed, this application will break, and that's fine.  In fact 
> that's the whole point of issuing the fix, that people will no longer be able 
> to make arbitrary computation requests of your server any more.  If that 
> server's maintainer has the relevant context and actually wants the XML-RPC 
> endpoint to enable arbitrary RCE, they can easily modify their application to 
> start doing eval() on the data that they received, just as someone can easily 
> modify their application to intentionally disable all connection security.  
> (Let's stop calling it "certificate verification" because that sounds like 
> some kind of clerical detail: if you disable certificate verification, TLS 
> connections are unauthenticated and unidentified and therefore insecure.)
> 
> For what it's worth, on the equivalent Twisted change, I originally had just 
> these concerns, but my mind was changed when I considered what exactly the 
> user-interface ramifications were for people typing that 's' for 'secure' in 
> URLs.  I was convinced, and we made the change, and there have been no ill 
> effects that I'm aware of as a result.  In fact, there has been a renewed 
> interest in Twisted for HTTP client work, because we finally made security 
> work more or less like it's supposed to, and the standard library is so 
> broken.
> 
> I care about the health of the broader Python community, so I will 
> passionately argue that this change should be made, but for me personally 
> it's a lot easier to justify that everyone should use Twisted (at least since 
> 14+) because transport security in the stdlib is such a wreck and even if it 
> gets fixed it's going to have easy options to turn it off unilaterally so 
> your application can never really be sure if it's getting transport security 
> when it's requesting transport security.
> 

I completely agree with everything Glyph has said in this post. (To the shock 
of everyone involved I’m sure!).

---
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] Sad status of Python 3.x buildbots

[Cameron Simpson]

On 03Sep2014 00:13, Victor Stinner  wrote:

AMD64 Snow Leop 3.x: many tests are not reliable (stable) on this
platform. For example, test_logging.test_race() sometimes fail with
PermissionError(1, "Operation not permitted:
'/tmp/test_logging-3-bjulw8iz.log'"). Another example,
test_asyncio.test_stdin_broken_pipe() sometimes fail with an assertion
error because BrokenPipeError was not raised. Do we still support this
old version of Mac OS X? Released in 2009, it is 5 years old. Is
upgrading to Maverick (10.9) free and possible on old Mac computers? I
don't have access to this old OS.


As a negative data point, my GF runs Snow Leopard by choice and will not 
upgrade that machine; we've both got Mavericks laptops and there are major 
regressions in the UI and OS behaviour (Apple UI and apps, not Python). I would 
imagine she's not alone in resisting change.


Cheers,
Cameron Simpson 

Life IS pain, highness...  anyone who tries to tell you different is
trying to sell you something.   - Wesley, The_Princess_Bride
___
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, 2 Sep 2014 16:47:35 -0700
Glyph Lefkowitz  wrote:
> 
> On Sep 2, 2014, at 4:28 PM, Nick Coghlan  wrote:
> 
> > On 3 Sep 2014 09:08, "David Reid"  wrote:
> > >
> > > Nick Coghlan  gmail.com> writes:
> > >
> > > > Creating *new* incompatibilities between Python 2 & Python 3 is a major 
> > > > point
> > > > of concern.
> > >
> > > Clearly this change should be backported to Python2.
> > 
> > Proposing to break backwards compatibility in a maintenance release (...)
> > 
> 
> As we keep saying, this is not a break in backwards compatibility, it's a bug 
> fix.

Keeping saying it doesn't make it magically true.
Besides, it can perfectly well be a bug fix *as well as* a break in
backwards compatibility. Which is why we sometimes choose to fix bugs
only in the feature development branch.

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] Sad status of Python 3.x buildbots

[Antoine Pitrou]

On Wed, 3 Sep 2014 00:13:22 +0200
Victor Stinner  wrote:
> 
> AMD64 Snow Leop 3.x: many tests are not reliable (stable) on this
> platform. For example, test_logging.test_race() sometimes fail with
> PermissionError(1, "Operation not permitted:
> '/tmp/test_logging-3-bjulw8iz.log'"). Another example,
> test_asyncio.test_stdin_broken_pipe() sometimes fail with an assertion
> error because BrokenPipeError was not raised. Do we still support this
> old version of Mac OS X? Released in 2009, it is 5 years old.

5 years old is not that old. I don't know what the upgrade expectations
are on OS X, but I'm sure Python runs well on 5-yeard old Windows,
Linuces and perhaps even FreeBSDs.

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] Sad status of Python 3.x buildbots

[Antoine Pitrou]

On Wed, 3 Sep 2014 08:53:51 +1000
Nick Coghlan  wrote:
> On 3 Sep 2014 08:15, "Victor Stinner"  wrote:
> >
> > 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.
> 
> 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.
> 
> From a completely different perspective, does anyone have experience with
> using BuildBot with OpenStack hosted clients? We may be able to take
> advantage of the PSF's new(ish) Rackspace infrastructure to provide more
> stable test VMs.

I'm not sure that's an answer to the problem. What we need is not more
machines, but dedicated buildbot maintainers. That also means being
willing to diagnose issues themselves rather than kindly offer SSH
access, by the way ;-) (I can't speak for Victor, but being offered SSH
access when I point out an issue on a remote machine is really a
depressing answer to get, as far as I'm concerned)

And, we also need some people to look after the master configuration
and status - yes, that would have been me, but I've not been very
motivated recently :-)

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!

[Terry Reedy]

On 9/2/2014 7:47 PM, Glyph Lefkowitz wrote:


On Sep 2, 2014, at 4:28 PM, Nick Coghlan mailto:ncogh...@gmail.com>> wrote:


On 3 Sep 2014 09:08, "David Reid" mailto:dr...@dreid.org>> wrote:



> Clearly this change should be backported to Python2.

Proposing to break backwards compatibility in a maintenance release (...)


For code that depends on a bug, fixing the bug breaks compatibility 
between releases without and with the fix.  Nothing new.  We 
occasionally don't backpart disruptive bugfixes because of that. We also 
backport some security fixes to otherwise unmaintained versions.



As we keep saying, this is not a break in backwards compatibility, it's
a bug fix.


Disagreement on whether changing the default for certificate validation 
is a 'bugfix' or 'enhancement' (and in the colloquial or python tracker 
sense) the seems like the crux of the disagreement here.  The case for 
'bug', at least in the colloquial meaning, is at least plausible. On the 
other hand, the tracker meaning of 'behavior' issue (contrary to 
intention and doc) is more strict in including implementation bugs but 
not necessarily design bugs.


--
Terry Jan Reedy

___
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 Tue, 02 Sep 2014 20:59:54 -0400, Terry Reedy  wrote:
> On 9/2/2014 7:47 PM, Glyph Lefkowitz wrote:
> >
> > On Sep 2, 2014, at 4:28 PM, Nick Coghlan  > > wrote:
> >
> >> On 3 Sep 2014 09:08, "David Reid"  >> > wrote:
> 
> >> > Clearly this change should be backported to Python2.
> >>
> >> Proposing to break backwards compatibility in a maintenance release (...)
> 
> For code that depends on a bug, fixing the bug breaks compatibility 
> between releases without and with the fix.  Nothing new.  We 
> occasionally don't backpart disruptive bugfixes because of that. We also 
> backport some security fixes to otherwise unmaintained versions.
> 
> > As we keep saying, this is not a break in backwards compatibility, it's
> > a bug fix.
> 
> Disagreement on whether changing the default for certificate validation 
> is a 'bugfix' or 'enhancement' (and in the colloquial or python tracker 
> sense) the seems like the crux of the disagreement here.  The case for 
> 'bug', at least in the colloquial meaning, is at least plausible. On the 
> other hand, the tracker meaning of 'behavior' issue (contrary to 
> intention and doc) is more strict in including implementation bugs but 
> not necessarily design bugs.

Up to this point the suggestion has been to change the default only in
3.5, and what we are arguing about is what kind of and how much aid to
give to those for whom 3.5 breaks backward compatibility.  So arguing
about feature versus bug is irrelevant.

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.)

The more I think about it the less I like sslcustomize.  I think I'd
rather do without the ability to turn off checking without modifying
code rather than introduce an intentional vector for a system-wide
decrease in security.

--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!

[Stephen J. Turnbull]

Antoine Pitrou writes:
 > On Tue, 2 Sep 2014 16:47:35 -0700
 > Glyph Lefkowitz  wrote:

 > > As we keep saying, this is not a break in backwards
 > > compatibility, it's a bug fix.
 > 
 > Keeping saying it doesn't make it magically true.

It's not "magically" true, it is "just" true.  What the hardliners
fail to acknowledge is that this is *not a bug in Python, it's a bug
in the whole system*, and *mostly* in the environment.  Changing
Python will not change the environment, and applications will fail,
with unknown consequences.  Saying they "should" fail *right* now is
bogus when you don't even know what those applications are, or what
other security measures may be in place:

Now is better than never.
Although never is often better than *right* now.

On the other hand, I commend the Twisted developers for putting their
values into their code with their reputation on the line.  I hope they
win big with this move!  Shouldn't we all hope for that?

Steve
___
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

[Stephen J. Turnbull]

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.

___
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 Wed, Sep 3, 2014 at 12:47 PM, 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.

Maintaining a buildbot isn't hard. (Although one thing I'm not sure
of: If my bot goes down for an extended period of time, is any sort of
automated email sent to me? I don't often check their status.) 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.

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] Sad status of Python 3.x buildbots

[Shorya Raj]

Hello all
I don't mind helping out with maintaining buildbots / other build machines.
Although I don't have a lot of experience with this sort of thing (I
usually just ran a Jenkins for my own work), I think it would be a useful
way to contribute. Let me know what I should do if you are all fine with
this.



Thanks
Shorya Raj


On Wed, Sep 3, 2014 at 2:52 PM, Chris Angelico  wrote:

> On Wed, Sep 3, 2014 at 12:47 PM, 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.
>
> Maintaining a buildbot isn't hard. (Although one thing I'm not sure
> of: If my bot goes down for an extended period of time, is any sort of
> automated email sent to me? I don't often check their status.) 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.
>
> 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/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] Sad status of Python 3.x buildbots

[Cameron Simpson]

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/archive%40mail-archive.com