[issue20570] Bundle pip 1.5.3 in Python 3.4rc2

Donald Stufft added the comment: I created issue20713 -- ___ Python tracker <http://bugs.python.org/issue20570> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue20053] venv and ensurepip are affected by default pip config file

Donald Stufft added the comment: pip 1.5.3 is released and I've requested larry cherry-pick it into 3.4.0 with issue20713 -- ___ Python tracker <http://bugs.python.org/is

[issue20721] 3.4 cherry-pick: 005d0678f93c Update pip to 1.5.4

New submission from Donald Stufft: Please cherry-pick 005d0678f93c into 3.4.0. It upgrades pip to 1.5.4, the only change is a fix for an errant deprecation warning which was displaying all the time instead of only when you used the deprecated feature. Sorry for making you need to cherry-pick

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by Donald Stufft : -- nosy: +dstufft ___ Python tracker <http://bugs.python.org/issue13936> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue20855] RFE: change bool(0.0) to evaluate as True

Donald Stufft added the comment: Being passive aggressive is pointless, if you disagree then discuss on the actual issue or on the mailing list thread. Opening up random issues because you're mad just makes you look like a child. -- nosy: +dstufft resolution: -> invalid stat

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: It's not modulo arithmetic. -- ___ Python tracker <http://bugs.python.org/issue13936> ___ ___ Python-bugs-list mailing list

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: I am not even sure what that is supposed to be doing... You're trying to count midnight as the previous day instead of the actual day? That seems extremely contrived. -- ___ Python tracker <http://bugs.py

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: If Midnight is considered the last moment of the day then it evaluating to false makes even less sense since the rationale given is "time is seconds since midnight". However if you're considering it the last moment then time would be "secon

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: Infact I would argue that ``if dt.time() != datetime.time(0):`` *would* be an improvement to that code because it is more accurately describing what you actually intend in the same way that ``if time_or_none is None`` would be an improvement to that code

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: It's actually a bit worse than that Nick. It's midnight UTC, as long as the UTC offset is Positive or Zero. This is because the way the check is implemented is naive. It's implemented as: Take the time portion sans the tzinfo and convert to min

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: To be specific, Guido said that if this 3.0 or 3.1 he'd be all for changing it, and the only question in his mind is how safe it is change. And that his intuition is that it's a nuisance feature and few people have actually relied on it and that

[issue29066] PIP doesn't honor --trusted-host or --cert options

Donald Stufft added the comment: Yea, this is from ``setup_requires`` keyword argument in ``setup.py``. I suspect we're going to see a lot of errors like this from people with 3.6 on the OSX Installers. -- nosy: +dstufft ___ Python tracker

[issue29085] Python 3.6 on Windows doesn't seed Random() well enough

Donald Stufft added the comment: It's presumably failing to read nonblocking random from CrpytGen and falling back to seeding using time and pid. -- nosy: +dstufft ___ Python tracker <http://bugs.python.org/is

[issue29100] Core dump / OverflowError for datetime.fromtimestamp with overly large timestamp in Ubuntu 12.04

Changes by Donald Stufft : -- nosy: +dstufft ___ Python tracker <http://bugs.python.org/issue29100> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies

Donald Stufft added the comment: I haven't updated the bundled copy of ensurepip yet because of this. Most likely the way this will get resolved is that the PEP 518 PR will land in pip and we will no longer require setuptools to be pre-installed at all and ensurepip will go to only bun

[issue29697] Wrong ECDH configuration with OpenSSL 1.1

Changes by Donald Stufft : -- pull_requests: +327 ___ Python tracker <http://bugs.python.org/issue29697> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29697] Wrong ECDH configuration with OpenSSL 1.1

Changes by Donald Stufft : -- pull_requests: +328 ___ Python tracker <http://bugs.python.org/issue29697> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29697] Wrong ECDH configuration with OpenSSL 1.1

Changes by Donald Stufft : -- pull_requests: +330 ___ Python tracker <http://bugs.python.org/issue29697> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29697] Wrong ECDH configuration with OpenSSL 1.1

Changes by Donald Stufft : -- pull_requests: +331 ___ Python tracker <http://bugs.python.org/issue29697> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: I agree with Alex here. The documentation of ``os.urandom`` states: Return a string of n random bytes suitable for cryptographic use. However the old behavior prior to using the ``getrandom()`` call and the behavior with this patch makes that documentation a

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: I also agree with Cory :) If CPython needs a non blocking RNG for start up, then it should add a new function that does that, breaking the promise of ``os.urandom`` cryptographically suitable random is not the way to do that

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > That's pretty much in line with what the implementation now does. Literally the first line of the os.urandom documentation is "Return a string of n random bytes suitable for cryptographic use.". There is absolutely a promise that, as lon

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > Reminder: getrandom() feature is specific to Linux. I understand that all > other operating systems don't warn if the urandom entropy pool is not > initialized yet! As far as I know, all other modern OSs *ALWAYS* block until their entropy pool

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > IMHO you should read http://www.2uo.de/myths-about-urandom/ which explains > that the property of blocking or not blocking doesn't matter for the quality > of the RNG. /dev/urandom is good enough to generate crytographic keys. Can we > pleas

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > I don't think that security matters enough to block Python at startup. > Python has a long history of being a thin wrapper on top of the OS. > Usually, Python doesn't workaround design issues of OSes, but expose > functions as they are.

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: To be clear, I don't have a problem adding ``os.urandom_info`` but I don't think that it solves the problem, we shouldn't force people to introspect ``os.urandom`` to figure out if CPython decided to make it less secure on this in

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > Note how the documentation emphasizes on os.urandom() not blocking. That line about not-blocking was added by the patch that Victor committed that we're objecting to. -- ___ Python tracker <http://bugs

[issue27250] Add os.urandom_block()

Donald Stufft added the comment: This should be add ``os.urandom_noblock`` instead. Don't make every other application change just so the Python interpreter can continue to call ``os.urandom``. -- nosy: +dstufft ___ Python tracker

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: (Basically) nobody should ever use /dev/random (and cryptographers agree!). The thing you want to use is /dev/urandom and the fact that /dev/urandom on Linux doesn't block before the pool is initalized has long been considered by cryptographers to be a f

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: What I'm trying to tell you is that /dev/random is a bad implementation and practically every cryptographer agrees that everyone should use /dev/urandom and they all also agree that on Linux /dev/urandom has a bad wart of giving bad randomness at the sta

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: Since there's obviously contention about what the right answer here is, I suggest we should revert the patch (since the old behavior already exists in 3.5 and is shipped to thousands of people already, and status quo wins) and then continue the discu

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: The patch causes a regression because I'm relying on the 3.5 behavior of getting secure randomness from ``os.urandom`` via the ``getrandom()`` system call (behavior that was documented in the Whats New in 3.5). The 3.5 behavior also makes ``os.urandom`` b

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > My personal preference would be for os.urandom(n) to favor non-blocking > operation over cryptographic security, and either add os.random() or add an > optional parameter to os.urandom() to make the opposite trade-off. Insecure by default is very r

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > The net effect is that *all* invocations of Python will block at startup if > the system RNG is blocking. The only reason this is being called out as > Linux-specific is that the behavior has been noticed in Linux. The fix is Linux specific, be

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > With the greatest respect, you're talking about introducing multi-minute > delays into the startup times of hundreds of millions of systems, regardless > of whether they have a proximate requirement for cryptographically-secure RNG > sou

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > I have no objection to *deliberate* invocations of the system RNG blocking if > needed. Presumably this behavior can be codified into the various APIs. > > My objection is *entirely* to _PyRandom_Init() calling a potentially-blocking > RNG

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > I just don't understand why you are apparently not willing to even consider > compromises. I have one thing that I hold immutable here, That os.urandom should use the best interfaces provided by the OS to ensure that it always returns crypto

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > Please note: this is *not* just a VM/cloud issue. This is observed on > physical standalone systems. But it should only occur on initial boot I believe? AFAIK all of the major linux vendors have stored a seed file once the machine has been booted a

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > ISTM that the happy middle ground would be: > * seed the random module with non-cryptographically-secure random bits > * lazily seed hashlib I don't think it was actually hashlib that was causing the problem, but rather the initialization of Si

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > Possible resolutions: > * accept possible low-entropy initialization of the hash secret; using the > patches supplied here by myself and Victor. > * add a command-line flag to disable "strong" initialization of the hash > secret (

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > I don't follow whose patch does what. But here's what I find acceptable, > from a high level. > > * The semantics as presented by the documentation must be preserved. > os.urandom() and other operations that declare they're

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: I've attached a minimal patch for making it so ``import random`` does not block, it does this by changing what the default instance of Random() is seeded with, from os.urandom() to the time based fallback it currently employs. It does not change the beh

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > As a final note, let me steer you towards this comment in Python/random.c: > > /* Issue #25003: Don' use getentropy() on Solaris (available since > * Solaris 11.3), it is blocking whereas os.urandom() should not block. */ > > Y

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > specifically, early in the boot process, although not I think just on the > first boot of a system; Debian at least by default does not attempt to > preserve its entropy pool across a reboot.) Look at /etc/init.d/urandom in the initscripts package

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: Colm, Great, then I think there's general agreement, we just need someone to review the nonblocking_urandom_noraise.patch (which my C is not strong enough to feel comfortable doing). That still leaves the `import random` issue, but I think we can r

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: > Once this has been done, it will never block again, and happily send you poor > random data if the entropy pool has been completely wiped of any entropy data > - without telling you. This doesn't actually happen in real life, once ur

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: Thanks for weighing in Theodore, I think that matches what Colm's last suggestion was, and what I was personally OK with. To seed our SipHash function using GRND_NONBLOCK since it's likely that will be fine, and worst case we're just using i

[issue27266] Add block keyword-only optional parameter to os.urandom()

Donald Stufft added the comment: I'm pretty sure that getentropy on OpenBSD will block until the pool is initialized. -- nosy: +dstufft ___ Python tracker <http://bugs.python.org/is

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Donald Stufft added the comment: Larry, I would greatly prefer it if we would allow os.urandom to block on Linux, at least by default. This will make os.urandom behavior similarly on most modern platforms. The cases where this is going to matter are extreme edge cases, for most users they&#x

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: To be clear, that was a minimal patch using a method that already existing. It could be made a lot better by mixing in other sources of entropy like PID#, id(self), etc. -- ___ Python tracker <h

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: One of the key take aways though is that MT doesn't really *need* to be initialized with a CSPRNG, all it needs it some moderately random data. So we can eliminate the case all together by just not using it. Though a sticking point is that it's doc

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: It would still be a thin shell around what the OS provides, it'd just be a thin wrapper around getrandom() instead of around /dev/urandom specifically-- but accessing the same content. -- ___ Python tracker

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: I think a new function is a bad idea TBH, os.urandom provides 99% of the right interface on Linux, and 100% of the right interface on other OSes and there is a lot of code out there using os.urandom for it's security properties, and a lot of people educ

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: I also contest the idea that os functions must only be thin shells around system provided calls (even though I don't think that using getrandom instead of reading from /dev/urandom violates that assertion). There are a number of functions in os.py tha

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: > > there is a lot of code out there using os.urandom for it's security > > properties > > This is exactly why we should not change the behavior of os.urandom(). > os.urandom() must not block on Linux. So defaulting to block=True on

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: > The block= parameter confuses the matter greatly, which is why I oppose it. I don't like the block= parameter. > I assert that people are calling os.urandom() because they expect it to > behave like /dev/urandom on their machine. I don'

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: Python should strive do the right thing, and the right thing for something as security sensitive as accessing a CSPRNG is to use the interface that most strongly promises to in fact, give cryptographically secure random numbers. Obsessing over the purity of

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: > Again, I cite #25003: he implicitly ruled there that it's not permissible for > os.urandom() to block on Solaris, so I think he agrees with me. To be clear, that's an entirely different kind of blocking. That made os.urandom on Solaris beh

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: Tim, If MT is used in any of the security sensitive contexts that paper mentions, then it doesn't matter if you seed it with a static zero or a billion bytes read from the purest of purestrain randomness, your application is broken. In other words, it do

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: If seeding from urandom was causing no problems, then I would not care if random.Random() wanted to seed from urandom, even though it doesn't need to. However it is causing problems, and thus it shouldn't. Here's another script, this one runs

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Donald Stufft added the comment: Having os.urandom raise an error instead of blocking is OK with me. It turns an implicit error into an explicit one. However, I prefer to have it block until it has initialized it's entropy pool because that makes Linux behave similarly to all of the

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: > But that's not what real-life programs expose. Are you sure? Searching github pulls up a number of results of people calling it, but I haven't looked through them to see how/why they're calling it. > What do you believe? For example, do

[issue27282] Raise BlockingIOError in os.urandom if kernel is not ready

Donald Stufft added the comment: This proposal is reasonable to me and solves any problems I have with the default behavior of os.urandom. -- nosy: +dstufft ___ Python tracker <http://bugs.python.org/issue27

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: > Sorry, I don't know what "it" refers to. Surely not to a program exposing > the output of .getstate()?! random.getrandbits() -- ___ Python tracker <http://bu

[issue27288] secrets should use getrandom() on Linux

New submission from Donald Stufft: In 3.5.0 and 3.5.1 os.urandom will, where available, use the getrandom() to block rather than get insecure random from the urandom pool on Linux. In 3.5.2 this change is reverted so that os.urandom will return possibly predictable random numbers instead of

[issue27288] secrets should use getrandom() on Linux

Donald Stufft added the comment: As an additional aside, the documentation of secrets references the documentation of random.py for it's secrets.SystemRandom class, however random.py docouments random.SystemRandom as using os.urandom. So the documentation for secrets.SystemRandom shou

[issue27292] Warn users that os.urandom() can return insecure values

Donald Stufft added the comment: I agree that we should add a warning to these, it's easy to see how someone might read the summary of the function "Return a string of n random bytes suitable for cryptographic use." and skip over the nuance in the rest of the body of the fun

[issue27297] Add support for /dev/random to "secrets"

Donald Stufft added the comment: For more information, read http://www.2uo.de/myths-about-urandom/ . -- ___ Python tracker <http://bugs.python.org/issue27

[issue27297] Add support for /dev/random to "secrets"

Donald Stufft added the comment: No we should not use /dev/random (or GRND_RANDOM(. It's numbers are not "more random" than /dev/urandom outside of the narrow window of prior to /dev/urandom being fully seeded. In fact, on Linux both /dev/urandom and /dev/random use the exact

[issue27297] Add support for /dev/random to "secrets"

Donald Stufft added the comment: > So, you assert getrandom(0) and getrandom(GRND_RANDOM) return random bits of > identically high quality? Yes, except the latter will randomly block. > I'm curious about this political pressure you cite. Think about the last 4 days, now

[issue27297] Add support for /dev/random to "secrets"

Donald Stufft added the comment: I will add, /dev/random is not going to *hurt* when generating long lived cryptographic keys (e.g. like your SSH keys) because that's something you're generally going to do once every couple of years and if it takes a few seconds longer because of

[issue27297] Add support for /dev/random to "secrets"

Donald Stufft added the comment: > It's just that the manpage for urandom (and in fact the comments in the > source code for /dev/random and /dev/urandom) both recommend using > /dev/random for these long-lived cryptographic keys. It's a hedge because of the bad behavior

[issue27305] Crash with "pip list --outdated" on Windows 10 with Python 2.7.12rc1

Changes by Donald Stufft : -- priority: normal -> release blocker ___ Python tracker <http://bugs.python.org/issue27305> ___ ___ Python-bugs-list mai

[issue27292] Warn users that os.urandom() can return insecure values

Changes by Donald Stufft : -- nosy: -dstufft ___ Python tracker <http://bugs.python.org/issue27292> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27297] Add support for /dev/random to "secrets"

Changes by Donald Stufft : -- nosy: -dstufft ___ Python tracker <http://bugs.python.org/issue27297> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27288] secrets should use getrandom() on Linux

Changes by Donald Stufft : -- nosy: -dstufft ___ Python tracker <http://bugs.python.org/issue27288> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27250] Add os.urandom_block()

Changes by Donald Stufft : -- nosy: -dstufft ___ Python tracker <http://bugs.python.org/issue27250> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Changes by Donald Stufft : -- nosy: -dstufft ___ Python tracker <http://bugs.python.org/issue27266> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27282] Raise BlockingIOError in os.urandom if kernel is not ready

Changes by Donald Stufft : -- nosy: -dstufft ___ Python tracker <http://bugs.python.org/issue27282> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16113] Add SHA-3 and SHAKE (Keccak) support

Donald Stufft added the comment: > I asked a room full of network engineers about SHAKE and not a single one of > them had heard of it Why would a network engineer know about a new variable length hashing algorithm? It's not really within their pro

[issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183)

Donald Stufft added the comment: +1 from me, as another data point, the PSF infrastructure (which serves things like hg.python.org that aren't behind Fastly) has had 3DES disabled since 2014 without any complaints that I've seen. --

[issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183)

Donald Stufft added the comment: Should we also remove HIGH from the cipher list? If I recall, at the time we added it under the assumption that we might get new, better ciphers automatically but 3DES is considered "HIGH", so we'll get it pulled in via that on

[issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183)

Donald Stufft added the comment: Christian: But that doesn't help all of the existing releases of OpenSSL. -- ___ Python tracker <https://bugs.python.org/is

[issue27850] Remove 3DES from cipher list (sweet32 CVE-2016-2183)

Donald Stufft added the comment: It's not a recompile but it's not a configuration file either, it's a Python level API you can call when you're creating a connection to specify what ciphers you want to allow for that connection. -- __

[issue17538] Document XML Vulnerabilties

New submission from Donald Stufft: Here's a documentation patch (Made against the 2.7 branch) that adds warning to the various xml modules to warn about the insecurity and points towards defusedxml/defusedexpat. -- components: Library (Lib), XML files: xmldocs.diff keywords:

[issue12226] use HTTPS by default for uploading packages to pypi

Donald Stufft added the comment: Using HTTPS without a Certificate prevents passive attacks but not active attacks. It puts things in a _better_ situation but not the ideal situation. -- nosy: +dstufft ___ Python tracker <http://bugs.python.

[issue17538] Document XML Vulnerabilties

Donald Stufft added the comment: Update looks fine to me, I'm not the best at docs I just wanted to get at least a jumping off point. -- ___ Python tracker <http://bugs.python.org/is

[issue17538] Document XML Vulnerabilties

Donald Stufft added the comment: FWIW I put the warning on all the sax pages just because there's no way to know which page a user will go to if they are coming in via google. -- ___ Python tracker <http://bugs.python.org/is

[issue17947] Code, test, and doc review for PEP-0435 Enum

Changes by Donald Stufft : -- nosy: +dstufft ___ Python tracker <http://bugs.python.org/issue17947> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17947] Code, test, and doc review for PEP-0435 Enum

Donald Stufft added the comment: Small nitpick, weakref is imported but not used in the latest patch. -- ___ Python tracker <http://bugs.python.org/issue17

[issue22611] pip needs ctypes

Donald Stufft added the comment: This is no longer the case in the next version of pip. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/i

[issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack)

Donald Stufft added the comment: I think it's fine to disable it all together. Google is planning/hoping to kill SSL 3.0 completely from their clients in the next couple of months. They just don't want to release a patch that disables SSL 3.0 r

[issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack)

Donald Stufft added the comment: I don't know, how many times will it have to be repeated that secure defaults matter? SSL 3.0 can be turned back on easily enough, it isn't a hard shut off. It changes the default just like what was done wi

[issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack)

Donald Stufft added the comment: There's also https://www.trustworthyinternet.org/ssl-pulse/ -- ___ Python tracker <http://bugs.python.org/issue22638> ___ ___

[issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack)

Donald Stufft added the comment: OpenSSL generally doesn't have bad options disabled until they are years old. OpenSSL takes the stance that it's up to the consumers of the OpenSSL API to properly configure themselves. Also it's important to note that TLS_FALLBACK_SCSV isn&#x

[issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack)

Donald Stufft added the comment: Firefox is planning to disable SSL 3.0 as well - https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/ "SSLv3 will be disabled by default in Firefox 34, which will be released on No

[issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack)

Donald Stufft added the comment: I really don't think it's unreasonable to say "SSL 3.0 is insecure, if you rely on it then you need to pass this flag to use it". Passing a flag to do something insecure is hardly onerous. -- __

[issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack)

Donald Stufft added the comment: The naming of SSLv23 is sort of unfortunate, that will negotiate the highest version of SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 that both the client and the server support. You can modify the list of what protocols are supported using the ssl.OP_NO_* flags

[issue22669] Test_venv fails when _ctypes is not available.

Donald Stufft added the comment: It hasn't been released yet, test_venv could be temp disabled if ctypes isn't available though. -- ___ Python tracker <http://bugs.python.o

[issue22669] Test_venv fails when _ctypes is not available.

Donald Stufft added the comment: More or less. You could argue whether it's a defect or not but it unconditionally imports ctypes and apparently that is an optional module (I had no idea it was personally, and I can't find any documentation to say that it is). colorama doesn'

<    1   2   3   4   5   6   7   8   >