Re: [Python-Dev] PYTHONHTTPSVERIFY env var
On 12.05.2015 05:03, Nick Coghlan wrote: On 12 May 2015 at 04:49, M.-A. Lemburg m...@egenix.com wrote: On 11.05.2015 12:15, Nick Coghlan wrote: By contrast, the configuration file shouldn't provide a new attack vector (or simplify any existing attack vector), as if you have the permissions needed to modify the config file, you likely also have the permissions needed to modify the system certificate store, and the latter is a *far* more interesting attack vector than a downgrade attack solely against Python. Thus the environment variable based off switch is neither necessary (as an administrator controlled configuration file can do the job), nor sufficient (it can't handle the -E switch), *and* it represents an increase in the attack surface area relative to a Python implementation without the capability. Whether or not -E will have an effect on the env var depends on the implementation. At the moment, -E only has an effect on the C runtime, while the stdlib happily reads from os.environ without taking the flag into account. I had an off-list discussion with Christian Heimes about that in relation to the OpenSSL flags, and he pointed out the reason -E specifically needs to be a command line switch is because that is the only way to affect how environment variables are processed during interpreter startup. Once an application is up and running, further environment variable sanitisation can be handled at an application level by whitelisting entries in os.environ and deleting everything else. As proposed, the PYTHONHTTPSVERIFY would only affect the ssl module and only be checked when loading this module, i.e. not at Python startup time. Right, the same is true for the configuration file proposal. It would be nice to hear from ActiveState, Enthought Continuum Analytics as well, but if they don't chime in here, I don't see any particular need to go chasing them explicitly. I think the approach to only consider a subset of redistributors as viable targets for such a switch is a bit too narrow. You are leaving out all the parties which use custom Python installations to run their applications, e.g. the Plone and Zope community, the ZenOSS community, the many Windows applications built on Python, etc. No, they already have a solution: monkeypatch (or just plain patch) the SSL module. That's an upstream supported technique, which is why it's documented in the PEP. Again, this is not a proper solution for your friendly sys admin. They won't go in and patch Python, but rather consider it broken, if it doesn't provide a configuration option and simply stay with 2.7.8. We've had that discussion already, so I won't go into details again. The problem we (as in Red Hat) ran into was that that technique *doesn't work* for the case of backporting PEP 476 to Python 2.7.5 as an opt-in feature. And neither does it work for people deploying Windows apps built on Python (where the code is usually hidden away in a ZIP archive or even compiled into a DLL), or people deploying Plone or ZenOSS. It's not only Red Hat's customers that are affected :-) to fix this regression in 2.7.9. We made the decision when PEP 476 was accepted that this change turned a silent security failure into a noisy one, rather than being a regression in its own right. PEP 493 isn't about disagreeing with that decision, it's about providing a smoother upgrade path in contexts where letting the security failure remain silent is deemed to be preferred in the near term. The change wasn't regression. The missing downgrade path is a regression. It's a shame we don't have -X options in Python 2, as that would be a nice hard-to-attack option (although it wouldn't play well with subprocesses) Some other comments on PEP 493: * I don't think we really want to add the overhead of having to parse an INI file every time Python starts up. Please remember that we just parsing of the sysconfig data not long ago because we wanted to avoid this startup time. Compared to the overhead of reading from the system cert database, reading a config file at ssl module import time should be trivial. The cert database is only read when importing the ssl module, not with each Python startup, so that makes a big difference. The INI file would have to parsed at ssl module load time as well to work around this. * I don't see why the attack surface of using an INI file somewhere in the system should be smaller than e.g. using sitecustomize.py You can put sitecustomize.py in a user directory, and if there's no system wide sitecustomize, Python will read it automatically (unless user site directories are turned off). In a user based installation (which most applications shipping their own Python installation are), you can always do this provided you can gain the application user permissions. For a system installed Python, you'd always have to run Python with -E -S -s to avoid
Re: [Python-Dev] PYTHONHTTPSVERIFY env var
- Original Message -
From: Donald Stufft don...@stufft.io
To: Nick Coghlan ncogh...@gmail.com
Cc: python-dev python-dev@python.org, M.-A. Lemburg m...@egenix.com
Sent: Monday, May 11, 2015 1:16:58 PM
Subject: Re: [Python-Dev] PYTHONHTTPSVERIFY env var
On May 11, 2015, at 6:47 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 11 May 2015 at 20:23, Donald Stufft don...@stufft.io wrote:
On May 11, 2015, at 6:15 AM, Nick Coghlan ncogh...@gmail.com wrote:
We made the decision when PEP 476 was accepted that this change turned
a silent security failure into a noisy one, rather than being a
regression in its own right. PEP 493 isn't about disagreeing with that
decision, it's about providing a smoother upgrade path in contexts
where letting the security failure remain silent is deemed to be
preferred in the near term.
I don't really agree that the decision to disable TLS is an environment
one,
it's really a per application decision. This is why I was against having
some
sort of global off switch for all of Python because just because one
application needs it turned off doesn't mean you want it turned off for
another
Python application.
The scenario I'm interested in is the one where it *was* off globally
(i.e. you were already running Python 2.7.8 or earlier) and you want
to manage a global rollout of a new Python version that supports being
configured to verify HTTPS certificates by default, while making the
decision on whether or not to enable HTTPS certificate verification on
a server-by-server basis, rather than having that decision be coupled
directly to the rollout of the updated version of Python.
I agree that the desired end state is where Python 3 is, and where
upstream Python 2.7.9+ is, this is solely about how to facilitate
folks getting from point A to point B without an intervening window of
I broke the world and now my boss is yelling at me about it :)
Oh, another issue that I forgot to mention--
A fair number of people had no idea that Python wasn't validating TLS before
2.7.9/3.4.3 however as part of the processing of changing that in 2.7.9 a lot
of people became aware that Python's before 2.7.9 didn't validate but that
Python 2.7.9+ does. I worry that if Redhat (or anyone) ships a Python 2.7.9
that doesn't verify by default then they are going to be shipping something
which defies the expectations of those users who were relying on the fact
that
Python 2.7.9+ was supposed to be secure by default now. You're
(understandibly)
focusing on I already have my thing running on Python 2.7.8 and I want to
yum update and get 2.7.9 and have things not visibly break, however there is
the other use case of I'm setting up a new environment, and I installed RHEL
and got 2.7.9, I remembered reading in LWN that 2.7.9 verifies now so I must
be safe. If you *do* provide such a switch, defaulting it to verify and
having
We (Red Hat) will not update python to 2.7.9, we ship 2.7.5 and backport
bugfixes/features based on users demand.
people where that breaks go in and turn it off is probably a safer mechanism
since the cases where 2.7.9 verification breaks things for people is a
visible
change where the case that someone expects 2.7.9 to verify and it doesn't
isn't
a visible change and is easily missed unless they go out of their way to try
and test it against a server with an invalid certificate.
Either way, if there is some sort of global off switch, having that off
switch
set to off should raise some kind of warning (like urllib3 does if you use
the unverified HTTPS methods). To be clear, I don't mean that using the built
in ssl module APIs to disable verification should raise a warning, I mean the
hypothetical make my Python insecurely access HTTPS configuration file (or
environment variable) that is being proposed.
---
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/rkuska%40redhat.com
Regards
Robert Kuska
{rkuska}
___
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] anomaly
* Mark Rosenblitt-Janssen dreamingforw...@gmail.com [2015-05-10 11:34:52
-0500]:
Here's something that might be wrong in Python (tried on v2.7):
class int(str): pass
int(3)
'3'
What's so odd about this? class int is an assignment to int, i.e.
what you're doing here is basically:
int = str
int(3) # really str(3)
* Mark Rosenblitt-Janssen dreamingforw...@gmail.com [2015-05-10 19:14:18
-0500]:
In case the example given at the start of the thread wasn't
interesting enough, it also works in the other direction:
class str(int): pass
str('2')
2 #- an integer!!!
Same thing. You're shadowing the builtin.
Florian
--
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
I love long mails! | http://email.is-not-s.ms/
pgp4DcbzxrzoZ.pgp
Description: PGP signature
___
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] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On Tue, May 12, 2015 at 1:05 PM Larry Hastings la...@hastings.org wrote: [SNIP] What do you think? My votes are as follows: Workflow 0: -0.5 Workflow 1: +1 Workflow 2: +0.5 Please cast your votes, Workflow 0: -0 Workflow 1: +1 Workflow 2: +0 ___ 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] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
Python 3.5 beta 1 is coming up soon. After beta is rc; after rc is 3.5.0 final. During the beta and rc periods the Python developer workflow changes a little--what sorts of checkins are permissible, and how to get something accepted and merged generally becomes more complicated. I was the release manager for Python 3.4, and the way I ran the rc period for 3.4 was miserable. Everyone hated it--and that includes me. I'm absolutely not doing it that way for 3.5. But that leads one to the question: okay, how *am* I going to run it? I have three ideas for workflows for the beta and rc periods for 3.5, below. But first let's talk about what I/we hope to achieve. Traditionally during the beta and rc periods, development of new features stops completely. Obviously, after feature freeze no new features can go into the beta / rc releases. But why can't people develop new features for the *next* release? The reason given is that we're trying to guide the core dev community in the right direction--they should concentrate on fixing bugs in the new release. I suspect the real reason for this is that back in the bad old days of Subversion (and CVS!) branching and merging were painful. This social engineering policy is a justification after-the-fact. But Mercurial makes branching and merging nearly effortless. Mercurial also makes it painless to develop new features in private. So consider: anyone who wants to work on new features during beta and rc can easily do so. All our no new features during beta and rc policy really does is drive such development away out of public view. I think it's time we experimented with lifting that policy. The trick is finding a good place for us to check in the work. You see, during the 3.5 rc period, we arguably want to accept checkins for *three* different revisions: 3.5.0 3.5.1 3.6 3.5.1? Yep. During the rc period for 3.4--and particularly after the last rc was tagged--there were a lot of minor fixes that were desirable, but I didn't want to accept into 3.4 just to avoid destabilizing the release. I still wanted those checkins, I just didn't want them in 3.4.0. So the way it worked was, developers would check those bugfixes in to trunk, then I'd cherry-pick the revisions I wanted into the rc branch. In other words, during the rc period for 3.4, trunk effectively represented 3.4.1. This was valuable and I absolutely want to do it again. So here are the workflows. Workflow 0 most resembles what we've done in the past. Workflow 1 is my favorite and the most ambitious. All three give us a public place to put revisions for 3.5.0 and 3.5.1; Workflow 1 also gives us a place to check in work for 3.6 during the beta and rc periods for 3.5. Workflow 2 is a less ambitious compromise. Workflow 0 == When I ship beta 1, trunk remains 3.5. When I ship rc 1, trunk becomes 3.5.1. I create a publically visible read-only repo that represents 3.5.0, and any checkins that I want to accept into 3.5.0 I must manually cherry-pick from trunk. When I ship Python 3.5.0 final, we branch 3.5, and trunk becomes 3.6. Workflow 1 == When I ship beta 1, we create the 3.5 branch. trunk become 3.6. When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically visible repo /on bitbucket/ for 3.5.0, and we use bitbucket pull requests for cherry-picks from 3.5.1 into 3.5.0. This gives us a pilot project to try out a web GUI for merging. It makes my workflow easier, as I can push a button to accept cherry-picks. (If they don't apply cleanly I can tell the author to go fix the conflict and resubmit it.) The downside: it requires core devs to have and use bitbucket accounts. Workflow 2 == When I ship beta 1, trunk remains 3.5. When I ship rc 1, we create the 3.5 branch. The 3.5 branch is 3.5.0 and trunk is 3.5.1. Only blessed stuff gets cherry-picked from 3.5.1 back into 3.5.0. What do you think? My votes are as follows: Workflow 0: -0.5 Workflow 1: +1 Workflow 2: +0.5 Please cast your votes, //arry/ ___ 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] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On May 12, 2015, at 10:04, Larry Hastings la...@hastings.org wrote: Workflow 1 == When I ship beta 1, we create the 3.5 branch. trunk become 3.6. When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically visible repo on bitbucket for 3.5.0, and we use bitbucket pull requests for cherry-picks from 3.5.1 into 3.5.0. This gives us a pilot project to try out a web GUI for merging. It makes my workflow easier, as I can push a button to accept cherry-picks. (If they don't apply cleanly I can tell the author to go fix the conflict and resubmit it.) The downside: it requires core devs to have and use bitbucket accounts. One possible issue with Workflow 1 is that there would need to be an additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA trunk), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3.4 support ends, which following recent past practice, would be relatively soon after 3.5.0. Workflow 2 == When I ship beta 1, trunk remains 3.5. When I ship rc 1, we create the 3.5 branch. The 3.5 branch is 3.5.0 and trunk is 3.5.1. Only blessed stuff gets cherry-picked from 3.5.1 back into 3.5.0. Where does 3.6.x fit into Workflow 2? -- Ned Deily n...@acm.org -- [] ___ 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] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On Wed, May 13, 2015 at 3:04 AM, Larry Hastings la...@hastings.org wrote: Workflow 1 == When I ship beta 1, we create the 3.5 branch. trunk become 3.6. When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically visible repo on bitbucket for 3.5.0, and we use bitbucket pull requests for cherry-picks from 3.5.1 into 3.5.0. As a non-core-dev, I would be in favour of this model. I use the CPython trunk as my build branch for give me the absolute latest CPython, and this means that that will always be the case. Same with the 3.5 branch always meaning the absolute latest CPython 3.5. Whether the 3.5.0 branch is on the main hg.python.org or bitbucket makes no difference to me, as I wouldn't be building against it, so do whatever makes sense for you and the core dev team. Testing a patch off the issue tracker would normally want to be done on trunk, I presume. Will this model be plausibly extensible to every release? For instance, when a 3.5.1 rc is cut, will the 3.5 branch immediately become 3.5.2, with a new 3.5.1 branch being opened on bitbucket? This model seems the easiest to explain. Every branch is the latest of whatever it describes; to access anything earlier, including proposed versions, you seek a different branch. 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] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On 05/12/2015 10:23 AM, Chris Angelico wrote: Will this model be plausibly extensible to every release? For instance, when a 3.5.1 rc is cut, will the 3.5 branch immediately become 3.5.2, with a new 3.5.1 branch being opened on bitbucket? Yes, we could always do it that way, though in the past we haven't bothered. Development on previous versions slows down a great deal after x.y.1. //arry/ ___ 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] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On Tue, 12 May 2015 10:04:39 -0700 Larry Hastings la...@hastings.org wrote: Workflow 1 == When I ship beta 1, we create the 3.5 branch. trunk become 3.6. When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically visible repo /on bitbucket/ for 3.5.0, and we use bitbucket pull requests for cherry-picks from 3.5.1 into 3.5.0. This gives us a pilot project to try out a web GUI for merging. It makes my workflow easier, as I can push a button to accept cherry-picks. (If they don't apply cleanly I can tell the author to go fix the conflict and resubmit it.) The downside: it requires core devs to have and use bitbucket accounts. Only if they want to submit cherry-picks, of course. What do you think? My votes are as follows: Workflow 0: -0.5 Workflow 1: +1 Workflow 2: +0.5 Please cast your votes, Well, since you're the one doing the work, and you seem to be ok with the most complicated workflow, I'll vote exactly as you :) Another entirely different approach, though, is to rework the release cycle and shorten the time between feature releases. Then we can have shorter freeze periods (the current freeze durations are really long). 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] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On 05/12/2015 10:23 AM, Ned Deily wrote: One possible issue with Workflow 1 is that there would need to be an additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA trunk), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3.4 support ends, which following recent past practice, would be relatively soon after 3.5.0. Good point. Though I could concievably push the 3.5.0 rc repo up to an hg.python.org server-side clone and kick off the buildbots from there. Where does 3.6.x fit into Workflow 2? It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after 3.5.0 final ships, as per tradition. //arry/ ___ 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] PYTHONHTTPSVERIFY env var
On 05/12/2015 04:19 AM, Nick Coghlan wrote: It occurs to me that the subtitle of PEP 493 could be All software is terrible, but it's often a system administrator's job to make it run anyway :) +1 QoTW -- ~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] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On May 12, 2015, at 10:38, Larry Hastings la...@hastings.org wrote: On 05/12/2015 10:23 AM, Ned Deily wrote: One possible issue with Workflow 1 is that there would need to be an additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA trunk), 3.4, and 2.7 ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3.4 support ends, which following recent past practice, would be relatively soon after 3.5.0. Good point. Though I could concievably push the 3.5.0 rc repo up to an hg.python.org server-side clone and kick off the buildbots from there. I wasn't worrying about the 3.5.0rc branch, but, yeah, we could probably improvise ones for that as you suggest. So, buildbots would be: 3.5 branch (-3.5.1 as of beta1), 3.5rc (as needed from rc1 to final), along with the current 3.x (-3.5.0 today, - 3.6.0, as of beta1), 3.4, and 2.7 buildbots. I like the idea of experimentally trying the push workflow but, if we are all doing our jobs right, there should be very few changes going in after rc1 so most committers won't need to push anything to the 3.5.0rc repo and, if for some reason they aren't able to use Bitbucket, someone could do it for them. In other words, while nice, the use of Bitbucket is not a critical feature of Workflow 1. I think 1 is the best choice with or without the use of Bitbucket. But we should also recognize that adopting it can make more work for committers fixing bugs over the next few months (between beta1 and final), as we need to consider testing and pushing each fix to default (for 3.6.0), 3.5 (for 3.5.0 until rc1, then for 3.5.1), 3.4 (for 3.4.4), and/or 2.7 (for 2.7.11). That's the tradeoff for allowing feature work to be committed, integrated, and tested during the beta and rc periods. Where does 3.6.x fit into Workflow 2? It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after 3.5.0 final ships, as per tradition. Workflow 0 = -1 Workflow 1 = +1 Workflow 2 = -0.5 -- Ned Deily n...@acm.org -- [] ___ 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] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On 05/12/2015 10:04 AM, Larry Hastings wrote: Workflow 1: +1 -- ~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] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
In article 55523adb.4000...@hastings.org, Larry Hastings la...@hastings.org wrote: On 05/12/2015 10:23 AM, Chris Angelico wrote: Will this model be plausibly extensible to every release? For instance, when a 3.5.1 rc is cut, will the 3.5 branch immediately become 3.5.2, with a new 3.5.1 branch being opened on bitbucket? Yes, we could always do it that way, though in the past we haven't bothered. Development on previous versions slows down a great deal after x.y.1. Well, we *could*. But that is hardly worth it as we don't do long-term maintenance of each maintenance release. In other words, from a python-dev perspective, 3.5.1 is dead the moment 3.5.2 goes out the door; we only maintain the most recent maintenance release of a major release cycle. So there is no need for a 3.5.x branch other than possibly during the typically very short rc cycle of a maintenance release and even then we usually see at most a couple of rc fixes and usually none, as expected. -- Ned Deily, n...@acm.org ___ 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] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On May 12, 2015, at 10:38 AM, Larry Hastings wrote: It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after 3.5.0 final ships, as per tradition. I still think it's a good idea to focus primarily on 3.5 while it's in the beta/rc period, but if you want to allow for landings on what will be 3.6, then going with workflow 1 will be an interesting social experiment. I'm fine with any of them as long as the workflow is *well documented*, preferably in the devguide. Cheers, -Barry pgpr_x4ASMLvd.pgp Description: OpenPGP digital signature ___ 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] Mac popups running make test
On Tue, May 12, 2015 at 4:14 PM, Skip Montanaro skip.montan...@gmail.com wrote: Twice now, I've gotten this popup: ... Let me improve my request, as it seems there is some confusion about what I want. I'm specifically not asking that the popups not be displayed. I don't mind dismissing them. When they appear, I would, however, like to glance over at the stream of messages emitted by the test runner and see a message about it being expected. It seems that the tests which can trigger the crash reporter do this. In my case, the popups appear but then disappear within a fraction of a second, and this happens about 10-20 times when running the full test suite. So I don't have a chance to interact with the popups, and this causes test failures. Also, when running a large suite of tests, I may not be looking at the screen by the time these popups appear. I wouldn't want the tests to fail nor would I want the test run to stall. I can't test this right now, but does disabling the network resource avoid these popups? Though even if it does we'll still need a way to run network-related tests on OSX. Regards, - Tal Einat ___ 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] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On 05/12/2015 11:18 AM, Jesus Cea wrote: Larry, could you comment about the impact in the buildbots?. I suppose option #1 could allows us to test both 3.5 and 3.6 changes. Would you confirm this? Workflow #1 gets us automatic buildbot testing for the 3.5 branch (betas and 3.5.1) and trunk (3.6). It doesn't get us testing of the 3.5.0 release candidates automatically, because those would be hosted at bitbucket. However: hg.python.org allows creating server-side clones which can manually run tests against the buildbots. So if I create a server-side clone, then push the release candidate branch there, I can kick off buildbot tests. Who knows, maybe I'd even automate that process. //arry/ ___ 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] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On Tue, May 12, 2015 at 4:36 PM, Larry Hastings la...@hastings.org wrote: BTW, this workload was exacerbated by my foolish desire to keep the revision DAG nice and clean. So I was actually starting over from scratch and redoing all the cherry-picking every couple of days, just so I could get all the cherry-picked revisions in strict chronological order. By the end I had evolved a pretty elaborate guided-process automation script to do all the cherry-picking, which you can see here if you're curious: Couldn't you just keep this as a branch that you then keep rebasing (without unlinking the original branch)? It doesn't seem like something that needs a one-off script, to me. Cheers, Dirkjan ___ 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] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On 05/12/2015 05:11 PM, Dirkjan Ochtman wrote: Couldn't you just keep this as a branch that you then keep rebasing (without unlinking the original branch)? It doesn't seem like something that needs a one-off script, to me. Probably. It's water under the bridge now--that all happened last February and I'm not doing it that way again. //arry/ ___ 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] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On 13 May 2015 03:47, Brett Cannon br...@python.org wrote: On Tue, May 12, 2015 at 1:05 PM Larry Hastings la...@hastings.org wrote: [SNIP] What do you think? My votes are as follows: Workflow 0: -0.5 Workflow 1: +1 Workflow 2: +0.5 Please cast your votes, Workflow 0: -0 Workflow 1: +1 Workflow 2: +0 Workflow 0: -0 Workflow 1: +1 Workflow 2: +0 That's taking into account the clarification that the buildbots will be set up to track the 3.5.x branch after the beta is forked, and that Larry will also push the 3.5rcX repo to hg.python.org for branch testing. (Possible alternative plan for the latter: rc1 isn't until August, and I could aim to have a pilot Kallithea instance set up by then that uses bugs.python.org credentials to log in. If we didn't get that up and running for some reason, BitBucket could still be a fallback plan) Cheers, Nick. ___ python-committers mailing list python-committ...@python.org https://mail.python.org/mailman/listinfo/python-committers ___ 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] PYTHONHTTPSVERIFY env var
If you control the app you don't need to do that. All relevant api accept the context parameter. The shims are only useful when you don't control the app. So an app shipping their own python doesn't fall under that. On May 12, 2015, at 6:56 AM, M.-A. Lemburg m...@egenix.com wrote: On 12.05.2015 12:04, Donald Stufft wrote: On May 12, 2015, at 3:57 AM, M.-A. Lemburg m...@egenix.com wrote: In a user based installation (which most applications shipping their own Python installation are), you can always do this provided you can gain the application user permissions. Of course, if the application is shipping it’s own Python then it has to actually do something to update to 2.7.9 and it can add it’s own option to disable TLS verification. I personally think that the application providing that option is the *right* way and all these other things are, at best, just temporary shims until the applications do that. I still believe that requiring to monkeypatch Python is a very poor approach in terms of quality software design. We can do better and we should. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 12 2015) Python Projects, Coaching and Consulting ... http://www.egenix.com/ mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] PYTHONHTTPSVERIFY env var
On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote: On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io wrote: If you control the app you don't need to do that. All relevant api accept the context parameter. The shims are only useful when you don't control the app. So an app shipping their own python doesn't fall under that. I think the bundled Python scenario MAL is interested in is this one: 1. An application with a bundled CPython runtime is using the verification defaults 2. Upgraded the bundled Python to 2.7.9 3. Didn't provide new configuration settings to disable certificate verification 4. Is being upgraded in an environment where verifying certificates makes the app unusable for environmental reasons related to certificate management The PyRun single-file Python interpreter has a similar need, where some apps than ran fine under 2.7.8 will need a way to disable cert verification in 2.7.9+ on a per-application basis, *without* modifying the applications. Both of those make sense to me as cases where the environment variable based security downgrade approach is the least bad answer available, which is why I eventually agreed it should be one of the recommendations in the PEP. Why is without modifying the app a reasonable goal? If Python is bundled with the app then you have direct control over when that upgrade happens, so you can delay the upgrade to 2.7.9 until your application which is bundling Python has the relevant switches. This is distinctly different from a situation like downstream distributors where the version of Python being provided is being provided by a group different than the person providing the application. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] PYTHONHTTPSVERIFY env var
On 12.05.2015 13:21, Donald Stufft wrote: On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote: On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io wrote: If you control the app you don't need to do that. All relevant api accept the context parameter. The shims are only useful when you don't control the app. So an app shipping their own python doesn't fall under that. I think the bundled Python scenario MAL is interested in is this one: 1. An application with a bundled CPython runtime is using the verification defaults 2. Upgraded the bundled Python to 2.7.9 3. Didn't provide new configuration settings to disable certificate verification 4. Is being upgraded in an environment where verifying certificates makes the app unusable for environmental reasons related to certificate management The PyRun single-file Python interpreter has a similar need, where some apps than ran fine under 2.7.8 will need a way to disable cert verification in 2.7.9+ on a per-application basis, *without* modifying the applications. Both of those make sense to me as cases where the environment variable based security downgrade approach is the least bad answer available, which is why I eventually agreed it should be one of the recommendations in the PEP. Why is without modifying the app a reasonable goal? If Python is bundled with the app then you have direct control over when that upgrade happens, so you can delay the upgrade to 2.7.9 until your application which is bundling Python has the relevant switches. This is distinctly different from a situation like downstream distributors where the version of Python being provided is being provided by a group different than the person providing the application. Take a Plone Intranet as example: The unified installer downloads and installs Python 2.7 for you. As of Plone 4.3.3 the version is Python 2.7.6. Now say you are a sys admin and your Intranet users are affected by some bug in 2.7.6 which is fixed in 2.7.9. The natural approach would be to upgrade the bundled Python to 2.7.9. Because it's an Intranet and Plone is used to aggregate information from other systems which use self-signed certificates, you don't want to risk breaking your Plone installation and need a way to disable the cert checks. The best way to do this is by configuring the bundled Python to disable the checks, since you would not want to mess with the Plone application itself. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 12 2015) Python Projects, Coaching and Consulting ... http://www.egenix.com/ mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] PYTHONHTTPSVERIFY env var
On 12 May 2015 at 17:57, M.-A. Lemburg m...@egenix.com wrote: The point here is that sys admins should not have to patch Python to make things work again, in case an application is not prepared for the certificate verification - which is rather likely, since the pre-Python 2.7.9 doesn't even provide the necessary APIs to pass certificate locations to urllib or urllib2. You've persuaded me that we should describe *both* configuration mechanisms in the recommendations PEP (one for a cross-platform environment variable based approach that also works for embedded Python instances and user level distributions, one for a configuration file based approach that only covers *nix system Python installations), and leave the decision to redistributors as to which approach makes the most sense for their particular audience. Neither goes into upstream CPython 2.7, and neither goes into any version of Python 3. Yes, getting an administrative application to the point where -S can be used means getting it to a point where it has *no* Python dependencies outside the standard library. It can certainly be done, but often won't be worth the hassle. As a result, using -s to turn off the user site directory and -E to turn off PYTHONPATH processing are the more common sys.path related hardening techniques in Python 2.7. Overall, I find the config file approach a too big a hammer to solve this simple problem. The problem of managing this security issue on behalf of customers without risking breaking their world is in no way simple - hence why most redistributors lobbed it into the too hard basket instead, and why we've been discussing possible UX improvements with upstream on-and-off for a couple of months now :) If there were more use cases for a Python config file, the added overhead could pay off, but then we should put more thought into optimizing the config file load time and probably end up using a Python module as config file (which provides these optimizations for free). This is why the proposal is for an SSL specific configuration file, loaded only when the SSL module is imported. In the end, we'd be introducing another sitecustomize.py, usercustomize.py and perhaps localcustomize.py - only with fixed locations rather than importing them via sys.path. It won't come to that, as Linux system package managers don't support any of these - that's what containers are for. 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] PYTHONHTTPSVERIFY env var
On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io wrote: If you control the app you don't need to do that. All relevant api accept the context parameter. The shims are only useful when you don't control the app. So an app shipping their own python doesn't fall under that. I think the bundled Python scenario MAL is interested in is this one: 1. An application with a bundled CPython runtime is using the verification defaults 2. Upgraded the bundled Python to 2.7.9 3. Didn't provide new configuration settings to disable certificate verification 4. Is being upgraded in an environment where verifying certificates makes the app unusable for environmental reasons related to certificate management The PyRun single-file Python interpreter has a similar need, where some apps than ran fine under 2.7.8 will need a way to disable cert verification in 2.7.9+ on a per-application basis, *without* modifying the applications. Both of those make sense to me as cases where the environment variable based security downgrade approach is the least bad answer available, which is why I eventually agreed it should be one of the recommendations in the PEP. 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] PYTHONHTTPSVERIFY env var
On 12 May 2015 at 21:21, Donald Stufft don...@stufft.io wrote: On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote: On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io wrote: If you control the app you don't need to do that. All relevant api accept the context parameter. The shims are only useful when you don't control the app. So an app shipping their own python doesn't fall under that. I think the bundled Python scenario MAL is interested in is this one: 1. An application with a bundled CPython runtime is using the verification defaults 2. Upgraded the bundled Python to 2.7.9 3. Didn't provide new configuration settings to disable certificate verification 4. Is being upgraded in an environment where verifying certificates makes the app unusable for environmental reasons related to certificate management The PyRun single-file Python interpreter has a similar need, where some apps than ran fine under 2.7.8 will need a way to disable cert verification in 2.7.9+ on a per-application basis, *without* modifying the applications. Both of those make sense to me as cases where the environment variable based security downgrade approach is the least bad answer available, which is why I eventually agreed it should be one of the recommendations in the PEP. Why is without modifying the app a reasonable goal? If Python is bundled with the app then you have direct control over when that upgrade happens, so you can delay the upgrade to 2.7.9 until your application which is bundling Python has the relevant switches. This is distinctly different from a situation like downstream distributors where the version of Python being provided is being provided by a group different than the person providing the application. Because of the way redistribution works. MAL was right that I was thinking specifically in terms of the Linux distributor case, where we're the OS vendor, so we need a way to offer off by default, opt-in on a per-server basis. Once I got past that perspective, I was able to figure out where he was coming from as someone that offers explicit support for the redistribution for bundling use case. When apps bundle Python, what's usually happening is that they'll just bundle whatever version is used on the build server that does the bundling. If the app developer's testing all uses valid HTTPS certificates (or simply doesn't test HTTPS at all), they won't see any problems with the 2.7.9 upgrade, and hence will ship that along to their customers, where it may break if that customer's environment turns out to be relying on the lack of certificate verification in 2.7.8 and earlier. If that scenario happens with unmodified upstream 2.7.9, the redistributor has no workaround they can pass along to app developers to in turn pass on to customers - the app developer simply has to tell their customers to downgrade back to the previous release, and then issue an updated version with a configuration setting to disable HTTPS verification as fast as they can. Customers tend to get rather grouchy about things like that :) By contrast, if the redistributor for the bundled version of Python has injected PYTHONHTTPSVERIFY support, then the app developers can at least pass along set PYTHONHTTPSVERIFY=0 in the environment to their customers as an interim workaround until they get a release out the door with a proper configuration setting to control whether or not the app verifies certificates (assuming they don't decide the environment variable is a good enough workaround). 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] PYTHONHTTPSVERIFY env var
On 12.05.2015 12:04, Donald Stufft wrote: On May 12, 2015, at 3:57 AM, M.-A. Lemburg m...@egenix.com wrote: In a user based installation (which most applications shipping their own Python installation are), you can always do this provided you can gain the application user permissions. Of course, if the application is shipping it’s own Python then it has to actually do something to update to 2.7.9 and it can add it’s own option to disable TLS verification. I personally think that the application providing that option is the *right* way and all these other things are, at best, just temporary shims until the applications do that. I still believe that requiring to monkeypatch Python is a very poor approach in terms of quality software design. We can do better and we should. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 12 2015) Python Projects, Coaching and Consulting ... http://www.egenix.com/ mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] PYTHONHTTPSVERIFY env var
On 12 May 2015 at 21:17, Nick Coghlan ncogh...@gmail.com wrote: Both of those make sense to me as cases where the environment variable based security downgrade approach is the least bad answer available, which is why I eventually agreed it should be one of the recommendations in the PEP. It occurs to me that the subtitle of PEP 493 could be All software is terrible, but it's often a system administrator's job to make it run anyway :) 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
[Python-Dev] Tracker reviews look like spam
Gmail dumps patch review email in my junk box. The problem seems to be the spoofed From: header. Received: from psf.upfronthosting.co.za ([2a01:4f8:131:2480::3]) by mx.google.com with ESMTP id m1si26039166wjy.52.2015.05.12.00.20.38 for tjre...@udel.edu; Tue, 12 May 2015 00:20:38 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning storch...@gmail.com does not designate 2a01:4f8:131:2480::3 as permitted sender) client-ip=2a01:4f8:131:2480::3; Tracker reviews are the only false positives in my junk list. Otherwise, I might stop reviewing. Verizon does not even deliver mail that fails its junk test, so I would not be surprised if there are people who simply do not get emailed reviews. Tracker posts are sent from Person Name rep...@bugs.python.org Perhaps reviews could come 'from' Person Name rev...@bugs.python.org Even direct tracker posts just get a neutral score. Received-SPF: neutral (google.com: 2a01:4f8:131:2480::3 is neither permitted nor denied by best guess record for domain of roundup-ad...@psf.upfronthosting.co.za) client-ip=2a01:4f8:131:2480::3; SPF is Sender Policy Framework https://en.wikipedia.org/wiki/Sender_Policy_Framework Checkins mail, for instance, gets an SPF 'pass' because python.org designates mail.python.org as a permitted sender. -- 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] Tracker reviews look like spam
SPF only covers the envelope sender, so it should be possible to set that to something that validates with SPF, keep the RFC822 From: header as it is, and maybe(?) include a separate Sender: header matching the envelope address. David On Tue, May 12, 2015 at 06:08:30PM -0400, Terry Reedy wrote: Gmail dumps patch review email in my junk box. The problem seems to be the spoofed From: header. Received: from psf.upfronthosting.co.za ([2a01:4f8:131:2480::3]) by mx.google.com with ESMTP id m1si26039166wjy.52.2015.05.12.00.20.38 for tjre...@udel.edu; Tue, 12 May 2015 00:20:38 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning storch...@gmail.com does not designate 2a01:4f8:131:2480::3 as permitted sender) client-ip=2a01:4f8:131:2480::3; Tracker reviews are the only false positives in my junk list. Otherwise, I might stop reviewing. Verizon does not even deliver mail that fails its junk test, so I would not be surprised if there are people who simply do not get emailed reviews. Tracker posts are sent from Person Name rep...@bugs.python.org Perhaps reviews could come 'from' Person Name rev...@bugs.python.org Even direct tracker posts just get a neutral score. Received-SPF: neutral (google.com: 2a01:4f8:131:2480::3 is neither permitted nor denied by best guess record for domain of roundup-ad...@psf.upfronthosting.co.za) client-ip=2a01:4f8:131:2480::3; SPF is Sender Policy Framework https://en.wikipedia.org/wiki/Sender_Policy_Framework Checkins mail, for instance, gets an SPF 'pass' because python.org designates mail.python.org as a permitted sender. ___ 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] Fwd: Coverity Scan update
On 2015-05-12 17:28, Guido van Rossum wrote: -- Forwarded message -- From: Dakshesh Vyas dv...@coverity.com mailto:dv...@coverity.com Date: May 12, 2015 1:08 AM Subject: Coverity Scan update To: gu...@python.org mailto:gu...@python.org gu...@python.org mailto:gu...@python.org Cc: Hello Guido van Rossum, Thank you for using Coverity Scan. With more than 4000 open source projects now registered at Coverity Scan, we are committed to help the open source community find quality and security issues early in development. We would like to inform you that you can now nominate your favorite defect! Tell us which defects you are glad were found using Coverity Scan and get special gifts like a Samsung Gear 2 Smartwatch, Code Black Drone or Tile for iOS and Android. Gifts will be distributed every month based on defect nomination! We recently added new hardware resource and upgraded our Scan server to our latest 7.6 version, which includes great new features: Thanks Guido, I didn't get the mail although I'm a project admin. Dakshesh must have sent it out to the initial project owner. I'm planning to do a final round of fixes when the first beta is out. Currently CPython is down to about 5 issues. The new version might reveal additional problems or false-positives. Let's see if I can get it down to zero again. 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] Tracker reviews look like spam
On 12May2015 22:15, David Wilson dw+python-...@hmmz.org wrote: SPF only covers the envelope sender, so it should be possible to set that to something that validates with SPF, keep the RFC822 From: header as it is, and maybe(?) include a separate Sender: header matching the envelope address. David Indeed. That sounds sane to me too. Google's complaint is SPF specific, so hopefully that is the criterion for the spam rating. It looks like bugs.python.org does not have an SPF record at all - neither SPF not TXT. (You really want both, same format, to support older DNS clients). I'm not sure you need a Sender: (though it wouldn't hurt), given that the From: is already a system like address (report@) and not a forged From: eg Terry Reedy tjre...@udel.edu as a mailing list would do. Cheers, Cameron Simpson c...@zip.com.au On Tue, May 12, 2015 at 06:08:30PM -0400, Terry Reedy wrote: Gmail dumps patch review email in my junk box. The problem seems to be the spoofed From: header. Received: from psf.upfronthosting.co.za ([2a01:4f8:131:2480::3]) by mx.google.com with ESMTP id m1si26039166wjy.52.2015.05.12.00.20.38 for tjre...@udel.edu; Tue, 12 May 2015 00:20:38 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning storch...@gmail.com does not designate 2a01:4f8:131:2480::3 as permitted sender) client-ip=2a01:4f8:131:2480::3; Tracker reviews are the only false positives in my junk list. Otherwise, I might stop reviewing. Verizon does not even deliver mail that fails its junk test, so I would not be surprised if there are people who simply do not get emailed reviews. Tracker posts are sent from Person Name rep...@bugs.python.org Perhaps reviews could come 'from' Person Name rev...@bugs.python.org Even direct tracker posts just get a neutral score. Received-SPF: neutral (google.com: 2a01:4f8:131:2480::3 is neither permitted nor denied by best guess record for domain of roundup-ad...@psf.upfronthosting.co.za) client-ip=2a01:4f8:131:2480::3; SPF is Sender Policy Framework https://en.wikipedia.org/wiki/Sender_Policy_Framework Checkins mail, for instance, gets an SPF 'pass' because python.org designates mail.python.org as a permitted sender. ___ 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/cs%40zip.com.au ___ 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] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On 05/12/2015 11:21 AM, Ned Deily wrote: I like the idea of experimentally trying the push workflow but, if we are all doing our jobs right, there should be very few changes going in after rc1 so most committers won't need to push anything to the 3.5.0rc repo and, if for some reason they aren't able to use Bitbucket, someone could do it for them. For 3.4, I had an amazing number of cherry-picked revisions. By the end it was... 72? over 100? I'm no longer even sure. Granted, 3.4 had the new module asyncio, and I got a deluge of cherry-pick requests just for that one module. I permitted 'em because a) they wanted it to be ready for prime time when 3.4 shipped, b) there was no installed base, and c) a healthy percentage of those changes were doc-only. (But if Victor tries that again during the 3.5 betas, he may have another thing coming!) BTW, this workload was exacerbated by my foolish desire to keep the revision DAG nice and clean. So I was actually starting over from scratch and redoing all the cherry-picking every couple of days, just so I could get all the cherry-picked revisions in strict chronological order. By the end I had evolved a pretty elaborate guided-process automation script to do all the cherry-picking, which you can see here if you're curious: https://hg.python.org/release/file/b7529318e7cc/3.4/threefourtool.py I have since given up this foolish desire. I'll be happy to have a nice grubby revision DAG if it means I can spend more time on the internet cruising for funny cat videos. In short, as release manager, I'm pretty stoked by the idea of pressing a big shiny button on a website exactly once when I accept a cherry-pick request. //arry/ ___ 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] PYTHONHTTPSVERIFY env var
On 12 May 2015 at 21:45, Donald Stufft don...@stufft.io wrote: On May 12, 2015, at 7:40 AM, Nick Coghlan ncogh...@gmail.com wrote: On 12 May 2015 at 21:21, Donald Stufft don...@stufft.io wrote: On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote: On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io wrote: If you control the app you don't need to do that. All relevant api accept the context parameter. The shims are only useful when you don't control the app. So an app shipping their own python doesn't fall under that. I think the bundled Python scenario MAL is interested in is this one: 1. An application with a bundled CPython runtime is using the verification defaults 2. Upgraded the bundled Python to 2.7.9 3. Didn't provide new configuration settings to disable certificate verification 4. Is being upgraded in an environment where verifying certificates makes the app unusable for environmental reasons related to certificate management The PyRun single-file Python interpreter has a similar need, where some apps than ran fine under 2.7.8 will need a way to disable cert verification in 2.7.9+ on a per-application basis, *without* modifying the applications. Both of those make sense to me as cases where the environment variable based security downgrade approach is the least bad answer available, which is why I eventually agreed it should be one of the recommendations in the PEP. Why is without modifying the app a reasonable goal? If Python is bundled with the app then you have direct control over when that upgrade happens, so you can delay the upgrade to 2.7.9 until your application which is bundling Python has the relevant switches. This is distinctly different from a situation like downstream distributors where the version of Python being provided is being provided by a group different than the person providing the application. Because of the way redistribution works. MAL was right that I was thinking specifically in terms of the Linux distributor case, where we're the OS vendor, so we need a way to offer off by default, opt-in on a per-server basis. Once I got past that perspective, I was able to figure out where he was coming from as someone that offers explicit support for the redistribution for bundling use case. When apps bundle Python, what's usually happening is that they'll just bundle whatever version is used on the build server that does the bundling. If the app developer's testing all uses valid HTTPS certificates (or simply doesn't test HTTPS at all), they won't see any problems with the 2.7.9 upgrade, and hence will ship that along to their customers, where it may break if that customer's environment turns out to be relying on the lack of certificate verification in 2.7.8 and earlier. If that scenario happens with unmodified upstream 2.7.9, the redistributor has no workaround they can pass along to app developers to in turn pass on to customers - the app developer simply has to tell their customers to downgrade back to the previous release, and then issue an updated version with a configuration setting to disable HTTPS verification as fast as they can. Customers tend to get rather grouchy about things like that :) By contrast, if the redistributor for the bundled version of Python has injected PYTHONHTTPSVERIFY support, then the app developers can at least pass along set PYTHONHTTPSVERIFY=0 in the environment to their customers as an interim workaround until they get a release out the door with a proper configuration setting to control whether or not the app verifies certificates (assuming they don't decide the environment variable is a good enough workaround). Honestly, this reads like If the person bundling 2.7.9 with their app doesn't bother to pay attention to what 2.7.9 means then things might break, but that's hardly special to TLS, there are lots of things that change in a release that may end up breaking in certain cases. Cert verification is a special case, as cert management in intranets tends to rely on two things: * browser users just click through SSL security warnings * automated internal tools don't check certs at all Organisations with a specific interest in network security may have their systems in a happier state, but I wouldn't bet on them being a substantial minority of organisations, let alone a signficant majority. It's hard to overstate how big a mindset shift getting intranet network security right isn't optional represents in our industry, and it's going to take years for that attitude change to filter out through the later parts of the technology adoption curve. Looking at Marc-Andre's latest email though, it appears we're using bundling in a different context? I'm thinking of things like PyInstaller or such where you're distributing Python + your own App, but this appears to just be some third party tool is installing Python and an App? I'm personally
Re: [Python-Dev] PYTHONHTTPSVERIFY env var
On May 12, 2015, at 7:40 AM, Nick Coghlan ncogh...@gmail.com wrote: On 12 May 2015 at 21:21, Donald Stufft don...@stufft.io wrote: On May 12, 2015, at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote: On 12 May 2015 at 21:09, Donald Stufft don...@stufft.io wrote: If you control the app you don't need to do that. All relevant api accept the context parameter. The shims are only useful when you don't control the app. So an app shipping their own python doesn't fall under that. I think the bundled Python scenario MAL is interested in is this one: 1. An application with a bundled CPython runtime is using the verification defaults 2. Upgraded the bundled Python to 2.7.9 3. Didn't provide new configuration settings to disable certificate verification 4. Is being upgraded in an environment where verifying certificates makes the app unusable for environmental reasons related to certificate management The PyRun single-file Python interpreter has a similar need, where some apps than ran fine under 2.7.8 will need a way to disable cert verification in 2.7.9+ on a per-application basis, *without* modifying the applications. Both of those make sense to me as cases where the environment variable based security downgrade approach is the least bad answer available, which is why I eventually agreed it should be one of the recommendations in the PEP. Why is without modifying the app a reasonable goal? If Python is bundled with the app then you have direct control over when that upgrade happens, so you can delay the upgrade to 2.7.9 until your application which is bundling Python has the relevant switches. This is distinctly different from a situation like downstream distributors where the version of Python being provided is being provided by a group different than the person providing the application. Because of the way redistribution works. MAL was right that I was thinking specifically in terms of the Linux distributor case, where we're the OS vendor, so we need a way to offer off by default, opt-in on a per-server basis. Once I got past that perspective, I was able to figure out where he was coming from as someone that offers explicit support for the redistribution for bundling use case. When apps bundle Python, what's usually happening is that they'll just bundle whatever version is used on the build server that does the bundling. If the app developer's testing all uses valid HTTPS certificates (or simply doesn't test HTTPS at all), they won't see any problems with the 2.7.9 upgrade, and hence will ship that along to their customers, where it may break if that customer's environment turns out to be relying on the lack of certificate verification in 2.7.8 and earlier. If that scenario happens with unmodified upstream 2.7.9, the redistributor has no workaround they can pass along to app developers to in turn pass on to customers - the app developer simply has to tell their customers to downgrade back to the previous release, and then issue an updated version with a configuration setting to disable HTTPS verification as fast as they can. Customers tend to get rather grouchy about things like that :) By contrast, if the redistributor for the bundled version of Python has injected PYTHONHTTPSVERIFY support, then the app developers can at least pass along set PYTHONHTTPSVERIFY=0 in the environment to their customers as an interim workaround until they get a release out the door with a proper configuration setting to control whether or not the app verifies certificates (assuming they don't decide the environment variable is a good enough workaround). Honestly, this reads like If the person bundling 2.7.9 with their app doesn't bother to pay attention to what 2.7.9 means then things might break, but that's hardly special to TLS, there are lots of things that change in a release that may end up breaking in certain cases. Looking at Marc-Andre's latest email though, it appears we're using bundling in a different context? I'm thinking of things like PyInstaller or such where you're distributing Python + your own App, but this appears to just be some third party tool is installing Python and an App? Ultimately, as long as it doesn't end up in upstream CPython the PEP can recommend any approach and I'm OK with it in the sense that it won't affect me. Though the PEP should be clear it's for 2.7 only and not 3.x or 2.8 if that ever gets reversed and we end up with a 2.8. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Tracker reviews look like spam
On Wed, May 13, 2015 at 8:15 AM, David Wilson dw+python-...@hmmz.org wrote: SPF only covers the envelope sender, so it should be possible to set that to something that validates with SPF, keep the RFC822 From: header as it is, and maybe(?) include a separate Sender: header matching the envelope address. As Cameron says, Sender: isn't necessary - just have the envelope address be bounces@ or something and it should be fine. This is how SPF and (eg) mailing lists interact. 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] What's missing in PEP-484 (Type hints)
re: comprehension
Perhaps PEP can, at least, have a short list/summary of limitations?
I recall something was mentioned, but I can't find a section like that in PEP.
re: example
following https://github.com/JukkaL/mypy/blob/master/stubs/3.2/socket.py
# socket.pyi python2
class _socketobject:
family = 0 # inferred from initializer (?)
type = 0 # type: int # explicit
# socket.pyi python3
class socket:
family = AddressFamily.AF_UNSPEC # inferred I presume?
def settimeout(timeout: Union[int, float, None]) - None: pass #
negative arguments illegal
timeout = -1.0 # yet, that's what you get by default (set None)
Perhaps, after all, socket module is a bad example.
I suppose you have a point that well-written modules are
self-documenting anyway...
Here's another try:
# _sqlite3.pyi python2 version
# warning, readonly: module allows reassignment, but you really shouldn't!
# instead use sqlite3.register_xxx functions
converters = {} # type: Dict[str, Callable[[str], Any]]
adapters = {} # type: Dict[Tuple[Type, SomethingInternal],
Callable[[Any], str]]
On 7 May 2015 at 17:39, Guido van Rossum gu...@python.org wrote:
On Thu, May 7, 2015 at 7:25 AM, Dima Tisnek dim...@gmail.com wrote:
On 30 April 2015 at 14:33, Steven D'Aprano st...@pearwood.info wrote:
On Thu, Apr 30, 2015 at 01:41:53PM +0200, Dima Tisnek wrote:
# internal vs external
@intify
def foo() - int:
b = 42
return b # check 1
x = foo() // 2 # check 2
Does the return type apply to implementation (str) or decorated
callable (int)?
I would expect that a static type checker would look at foo, and flag
this as an error. The annotation says that foo returns an int, but it
clearly returns a string. That's an obvious error.
Is this per PEP, or just a guess?
I think PEP needs to be explicit about this.
The PEP shouldn't have to explain all the rules for type inferencing.
There's a section What is checked? that says (amongst other things):
The body of a checked function is checked for consistency with the
given annotations. The annotations are also used to check correctness
of calls appearing in other checked functions.
Normally local variables will have their type inferred from the
operations done to them:
s = arg[1:] # s has the same type as arg
Good point, should be mentioned in PEP.
Again, what do you want the PEP to say? I am trying to keep the PEP shorter
than the actual code that implements the type checker. :-)
Technically, type can be empty list, mixed list or custom return type
for overloaded __getitem__ that accepts slices.
I'm sorry if I was not clear. My question was how should type of
ephemeral `x` be specified.
In other words, can types be specified on anything inside a comprehension?
That's actually a good question; the PEP shows some examples of #type:
comments in peculiar places, but there's no example using list
comprehensions. Your best bet is to leave it to the type inferencer; if your
comprehension is so complex that need to put type annotations on parts of
it, you may be better off rewriting it as a regular for-loop, which offers
more options for annotations.
Stub is better (required?) because it allows to specify types of
attributes that are not assigned in class scope, but that are expected
to be there as result of __init__ or because it's a C extension.
Note that the PEP does not explicitly say whether the information of a stub
might be *merged* with the information gleaned from the source code. The
basic model is that if a stub is present the implementation source code is
not read at all by the type checker (and, conversely, information from stubs
is not available at all at runtime). But it is possible for some type
checker to improve upon this model.
An example in PEP would be good.
Can you give an example that I can edit and put in the PEP?
--
--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] PYTHONHTTPSVERIFY env var
On 12 May 2015 at 20:56, M.-A. Lemburg m...@egenix.com wrote: On 12.05.2015 12:04, Donald Stufft wrote: On May 12, 2015, at 3:57 AM, M.-A. Lemburg m...@egenix.com wrote: In a user based installation (which most applications shipping their own Python installation are), you can always do this provided you can gain the application user permissions. Of course, if the application is shipping it’s own Python then it has to actually do something to update to 2.7.9 and it can add it’s own option to disable TLS verification. I personally think that the application providing that option is the *right* way and all these other things are, at best, just temporary shims until the applications do that. I still believe that requiring to monkeypatch Python is a very poor approach in terms of quality software design. We can do better and we should. It's a deliberate design choice to actively discourage people from doing it - your Ewww reaction to monkeypatching is exactly the one we want. There's no technical reason for people to be bothered by it, since it's a documented and supported technique covered by the relevant PEP - it just so happens that the configuration being done is to switch a function alias between two different functions. Both of the recommended options I'm putting in the PEP (essentially the Red Hat design and the eGenix design, since we cover two different use cases) still adopt that same basic implementation model, they just provide ways for redistributors to move the configuration inside the SSL module itself if they decide it is in their users' interests for them to do so. 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] PYTHONHTTPSVERIFY env var
On 12.05.2015 13:19, Nick Coghlan wrote: On 12 May 2015 at 21:17, Nick Coghlan ncogh...@gmail.com wrote: Both of those make sense to me as cases where the environment variable based security downgrade approach is the least bad answer available, which is why I eventually agreed it should be one of the recommendations in the PEP. It occurs to me that the subtitle of PEP 493 could be All software is terrible, but it's often a system administrator's job to make it run anyway :) +1 :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 12 2015) Python Projects, Coaching and Consulting ... http://www.egenix.com/ mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] Mac popups running make test
Twice now, I've gotten this popup: ... Let me improve my request, as it seems there is some confusion about what I want. I'm specifically not asking that the popups not be displayed. I don't mind dismissing them. When they appear, I would, however, like to glance over at the stream of messages emitted by the test runner and see a message about it being expected. It seems that the tests which can trigger the crash reporter do this. If I get a chance, I will look into where the crash reporter messages are displayed. Something similar for the network tickling tests should also be possible. Skip ___ 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] PYTHONHTTPSVERIFY env var
On May 12, 2015, at 3:57 AM, M.-A. Lemburg m...@egenix.com wrote: In a user based installation (which most applications shipping their own Python installation are), you can always do this provided you can gain the application user permissions. Of course, if the application is shipping it’s own Python then it has to actually do something to update to 2.7.9 and it can add it’s own option to disable TLS verification. I personally think that the application providing that option is the *right* way and all these other things are, at best, just temporary shims until the applications do that. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Fwd: Coverity Scan update
-- Forwarded message -- From: Dakshesh Vyas dv...@coverity.com Date: May 12, 2015 1:08 AM Subject: Coverity Scan update To: gu...@python.org gu...@python.org Cc: Hello Guido van Rossum, Thank you for using Coverity Scan. With more than 4000 open source projects now registered at Coverity Scan, we are committed to help the open source community find quality and security issues early in development. We would like to inform you that you can now nominate your favorite defect! Tell us which defects you are glad were found using Coverity Scan and get special gifts like a Samsung Gear 2 Smartwatch, Code Black Drone or Tile for iOS and Android. Gifts will be distributed every month based on defect nomination! We recently added new hardware resource and upgraded our Scan server to our latest 7.6 version, which includes great new features: * New security and quality checkers with version 7.6. * You can now setup automatic approval for viewing defects in read-only mode for everyone. * See charts showing defects outstanding vs. fixed over a period of time, and sort high impact defects by category. * Support for standard SSL port 443 instead of 8443. * Subscribe to email notifications for your entire open source project or for specific components or modules within your project. * You can now submit builds more frequently. * Please download the latest Coverity Build tool from https://scan.coverity.com/download * The old Coverity Build tool will still continue to work, but it may not be able to find some security and quality defects that could be found using our new and improved checkers as a part of 7.6 upgrade. * Important note for projects that uses automation or a script to submit build to Coverity Scan: The old URL to upload build on scan5.coverity.com is no longer supported. It is applicable to and used by some of the old projects on Coverity Scan. * Please sign-in to Coverity Scan to find the updated URL under automation section of Submit Build. * Finally, don't forget to nominate your favorite defects to receive special gifts like a Samsung Gear 2 Smartwatch, Code Black Drone or Tile for iOS and Android every month! Post your technical questions at https://communities.coverity.com/community/scan-(open-source)/content Please email us at scan-ad...@coverity.com if you have any question or concerns, and we would be happy to help you. Thanks Dakshesh Vyas | Technical Manager - Coverity Scan Office: 415.935.2957 | dv...@coverity.com https://scan.coverity.com/ Coverity by Synopsys To manage Coverity Scan email notifications, click https://scan.coverity.com/subscriptions/edit?email=guido%40python.orgtoken=8ba34039b1e46cc590ce8f06179fccdc ___ 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] anomaly
On 5/11/2015 3:40 AM, Florian Bruhin wrote: [snip] This trollish thread was cross-posted to python-list, where it was semi-ok, at least in the beginning, and pydev, where it is not. It has continued on python-list with pydev removed. Please do not continue it here (on pydev). -- 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
