New submission from Donald Stufft :
Upgrade the bundled pip/setuptools to the latest version.
Making this issue because blurb gets mad at me if I try to add a news entry
without a bpo issue.
--
assignee: dstufft
components: Library (Lib)
messages: 330096
nosy: dstufft
priority
Change by Donald Stufft :
--
keywords: +patch
pull_requests: +9843
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35277>
___
___
Py
Donald Stufft added the comment:
It doesn't bother me if you want to make that change, I don't currently have
the time to do it. I just figured I'd throw the update PRs up since I can do it
quickly.
--
___
Python tracker
<https
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue14621>
___
___
Python-bugs-list mailing list
Unsubscribe:
Donald Stufft added the comment:
I would +! backporting this, but It's not massively required since it only
protects against passive attacks.
It would however make things a little nicer.
--
___
Python tracker
<http://bugs.python.org/is
Donald Stufft added the comment:
Uploading always hits the backend servers and thus has the same logging as
before
Merely switching to HTTPS only provides protections against passive attacks.
You need verification to protect against active attacks (which are simple and
easy to do as well
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue16487>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Donald Stufft:
Currently the Python SSL module requires the full chain, including all
intermediaries, to be served in order to validate a TLS connection. This isn't
*wrong* however a number of folks have had issues trying to setup a custom PyPI
index in pip due to mi
Donald Stufft added the comment:
Just to be explicit, ``open("/dev/urandom")`` only works on POSIX platforms
while ``os.usrandom`` should work on any supported platform that has an OS
level source of randomness. So advocating *for* simply using ``open()`` is
probably a bad idea
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue16190>
___
___
Python-bugs-list mailing list
Unsubscribe:
Donald Stufft added the comment:
Looking at random.SystemRandom it appears it would suffer from the same FD
exhaustion problem.
So as of right now afaik none of the sources of cryptographically secure random
in the python stdlib offer a way to open a persistent FD. The primary question
on my
Donald Stufft added the comment:
haypo: It's been suggested by a number of security professionals that using the
OpenSSL random (or really any random) instead of urandom is likely to be a
smarter idea. The likelyhood that urandom is broken is far less than any other
source of random. Thi
New submission from Donald Stufft:
I noticed today that the builtin reversed() requires an explicit sequence and
won't work with an iterator instead it throws a TypeError like:
>>> reversed(x for x in [1, 2, 3])
TypeError: argument to reversed() must be a sequence
It would be r
Donald Stufft added the comment:
As an additional note this works how I would expect it to work if you're using
sorted() instead of reversed() which I think is a stronger point in the favor
of making reversed() work this way as well.
>>> sorted(x for x in [1, 2
Donald Stufft added the comment:
Lazily opening urandom and holding it open sounds like a sane thing to do to me
+1
--
___
Python tracker
<http://bugs.python.org/issue18
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue18582>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue17134>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue9146>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue17128>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue18233>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue14518>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue18454>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue8813>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue13655>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue16113>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue8106>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Donald Stufft :
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue18709>
___
___
Python-bugs-list mailing list
Unsubscribe:
Donald Stufft added the comment:
-1
This essentially gives the ability for an XMLRPC server to crash any python
code that interfaces with them unless you catch _every_ single exception
including ones like SystemExit, KeyboardInterupt, SyntaxError, StopIteration
etc.
An XMLRPC server is not
Donald Stufft added the comment:
Well you could possibly whitelist some exceptions although I still think that's
ultimately a bad idea because it means to prevent the remote server (or someone
in the middle of the connection) from being able to crash your program with an
arbitrary exce
New submission from Donald Stufft:
The Python tutorial tells, and even recommends, new users that they can use the
pickle module to serialize arbitrary objects. However it does not provide any
warning about the insecurity of unpickling arbtirary data. The text even goes
so far as to mention
Donald Stufft added the comment:
The section to me just seems to be about how to handle more than just strings,
it mentions numbers, lists, dictionaries, and class instances. Of those it
mentions, only the class instances are not able to handled out of the box by
JSON.
However like I said
Donald Stufft added the comment:
Further more the tutorial claims it's the standard way of persisting data which
in my experience it's far from that due to the security concerns. I've seen
very little actual use of pickle in the wild (and when it was used it was often
use
Donald Stufft added the comment:
A description of the pickle module itself does not equate to the purpose of the
section. Given that this is a tutorial and previous section taught how to read
and write from files I would suggest that the purpose of the section was to
give them the next step
Donald Stufft added the comment:
It would also break some 2/3 compatible projects who have a python3 and a
python2 file sitting next to each other and dynamically selected and imported
based on Python version.
--
nosy: +dstufft
___
Python tracker
Donald Stufft added the comment:
I'm sure y'all know my name already but since Eric asked on the pip tracker for
us, I'm dstufft :)
--
___
Python tracker
<http://bugs.pyt
Donald Stufft added the comment:
To be clear, to get SNI with requests on 2.x you need requests, pyopenssl,
ndg-httpsclient, and pyasn1 (which also pulls in cryptography, six, cffi, and
pycparser). So that's 8 dependencies to get SNI on Python 2.x.
At least it's doable but it's
Donald Stufft added the comment:
It's somewhat of a grey area of security feature. It's not directly a security
feature but if you don't have SNI and you hit a site that requires it then your
error message is going to be something like what people run into with PyPI[1]
which is
New submission from Donald Stufft:
Since Python 3.3 the ssl module has supported the ability to opt in to
disabling TLS Compression [1]. However TLS Compression has the problem that it
typically leaks data through an attack known as CRIME. CRIME is specific to
HTTP but the type of attack it
Donald Stufft added the comment:
Ah, I hadn't noticed the OP_ALL thing, in 3.3+ adding OP_NO_COMPRESSION to
OP_ALL would be reasonable. That would disable TLS Compression by default,
still provide people the ability to disable TLS Compression if they don't use
OP_ALL, and provid
New submission from Donald Stufft:
As of right now the default cipher list for the ssl module is
DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2, additionally on Python 3.4 when you
use create_default_context() then you also additionally get
HIGH:!aNULL:!RC4:!DSS.
I think we should change this to
New submission from Donald Stufft:
Python 3.4 has constants and code to enable forcing the ssl_version to TLS 1.1
or 1.2. As it stands now Python 2.7, 3.2, and 3.3 can successfully connect and
will use a TLS 1.1 or 1.2 connection if it's available (new enough OpenSSL) but
cannot _for
Donald Stufft added the comment:
To be specific it doesn't require any remote code execution to work, it just
requires you to be able to influence the content of the responses that the
client is receiving.
--
___
Python tracker
Donald Stufft added the comment:
Yea I noticed that, so I was doing some more testing, here's what I think we
should be using (It Adds back in RC4):
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:ECDH+RC4:DH+RC4:RSA+RC4!aNULL
Donald Stufft added the comment:
This is a simple patch, it simple disables TLS Compression by default. If a
user wants to add it back they can create their own SSLContext and do
ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
ctx.options &= ~ssl.OP_NO_COMPRESSION
This should be able to a
Donald Stufft added the comment:
Here's the same patch for Python 2.7, it's basically the same thing just at a
different location.
--
Added file: http://bugs.python.org/file34532/disable-ssl-compression-2.7.diff
___
Python trac
Donald Stufft added the comment:
Another bit of maintenance here:
If a new cipher suite is added to OpenSSL it won' be generally available for a
long while so very few if any services are going to be willing to depend on
*only* it. For the very rare and unlikely case that somebody does
Donald Stufft added the comment:
Why? At best users will get yet another secure algorithm and at worst they'll
get an insecure algorithm.
--
___
Python tracker
<http://bugs.python.org/is
Donald Stufft added the comment:
> This doesn't parse. If the system OpenSSL isn't maintained properly, it's not
> Python's job to workaround that. And we certainly don't have the required
> knowledge and dedication anyway.
Please let's not have a repe
Donald Stufft added the comment:
Oh and don't confuse me that I think Python's current situation is as bad as
Ruby's was, but that attitude is dangerous and wrong :/
--
___
Python tracker
<http://bugs.pyt
Donald Stufft added the comment:
I'm still looking into what "HIGH" entails across all the various OpenSSLs that
are in production that I can access. That "FUD" was responding to the attitude
that it's not Python's job to do this. Python is exposing a secu
Donald Stufft added the comment:
> I disagree. Python only provides an interface to OpenSSL, so the OpenSSL
> system defaults should be used.
Python is already changing the OpenSSL defaults, also you're advocating that
Python should support 40bit encryption that can be brute forced
Donald Stufft added the comment:
> > Again, Python is already forcing a set of ciphers. I don't know what sort of
> > Systems you use, but even RHEL 6.5 has *horrible* ciphers by in the OpenSSL
> > default set. Things like DES (not 3DES, DES) and 40bit RC4.
>
>
Donald Stufft added the comment:
Ok Antoine I've looked around.
Using a string like this:
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:ECDH+RC4:DH+RC4:RSA+RC4:ECDH+HIGH:DH+HIGH:RSA+HIGH:!aNULL:!eNULL:!MD5:!DSS
The
Donald Stufft added the comment:
Oh, additionally OpenSSL makes no promises what the meaning of "HIGH" will be
in the future. So you can only look at what it means now and what it means in
the past.
OpenSSL is not a good library and it's unfortunate that they don't att
Donald Stufft added the comment:
Oh, Additionally Marc:
Even if some system administrator or some system out there does patch their
OpenSSL to actually be safe by default Python changing it's cipher string only
adds to the potential security (or at worst does nothing). If even one system
Donald Stufft added the comment:
> > However I still content that using HIGH in the cipherstring actually
> > adds additional maintenance burden. In order to know if that
> > cipherstring is still safe you must run it against every target
> > OpenSSL you want to make
Donald Stufft added the comment:
> Again: the point is maintenance later, not breakage now.
Ok, well I don't agree that it's more maintenance later to be explicit and not
include HIGH, but whatever it's not insecure at the moment so.
Attached is a patch against 3.5 f
Donald Stufft added the comment:
> >
> >> We shouldn't do this in Python for the same reason we're not including
> >> a predefined set of CA root certificates with the distribution.
> >
> > The difference here is that there are properly mai
Donald Stufft added the comment:
Updated the patch to change the priority slightly to ensure that all the secure
PFS ciphers come first and that non PFS AES comes before the other Non PFS HIGH
ciphers
--
Added file: http://bugs.python.org/file34546/better-ciphers-better-priority.diff
Donald Stufft added the comment:
> It shows the effect of the additional !DSS - which I don't understand;
> DSA is part of the X.509 standard, so it's removing support will break
> compatibility. Could you perhaps explain you're reasoning ?
Well DSA has problems with we
Donald Stufft added the comment:
As I said earlier Antoine, doing that puts PFS RC4 before non PFS AES. That
isn't good because RC4 key stream bias makes it extremely fragile. RC4 needs to
be in the default ciphers for compatibility sake but it should be dead last so
that it's only
Donald Stufft added the comment:
With regard to PSK and SRP. Seeing as how Python doesn't currently support
them, SRP had a patch that hasn't been worked on since 2011 and PSK doesn't
have a patch at all that this cipher string shouldn't concern itself with
something that
Donald Stufft added the comment:
Yup :) Just being explicit in that!
--
___
Python tracker
<http://bugs.python.org/issue20995>
___
___
Python-bugs-list mailin
Donald Stufft added the comment:
Right now you can do ``pip install --download some/path --no-use-wheel
`` and then ``pip install --no-index --find-links some/path ``
In the future that'll be ``pip download`` instead probably.
--
nosy: +ds
Donald Stufft added the comment:
Note: The RC4 and DSS exclusion existed previously on the restricted ciphers so
we'd have to ask Christian why he did that. For me personally the restricted
ciphers are intended to be best practice ciphers and that means no RC4. DSS
here I'm kind of
Donald Stufft added the comment:
Forgot to add! If you think splitting between "restricted" server and client
ciphers I can split them like that and upload a new patch.
--
___
Python tracker
<http://bugs.python.o
Donald Stufft added the comment:
Not sure what you mean by client issue. Do you mean to keep RC4?
--
___
Python tracker
<http://bugs.python.org/issue20
Donald Stufft added the comment:
Er, I typed issue and meant usage. Right now the only difference between
restricted ciphers and the default ciphers is restricted ciphers have no RC4
and no DSS. You wanted this issue limited to client changes and I'm not sure
how to do that without ena
Donald Stufft added the comment:
Nah it should be fine to enable that, and it's preferable to do so. The server
selects the cipher anyways in the TLS handshake. That just tells the server to
prefer it's list for precedence and not the c
Donald Stufft added the comment:
I can add that.
--
___
Python tracker
<http://bugs.python.org/issue20995>
___
___
Python-bugs-list mailing list
Unsubscribe:
Donald Stufft added the comment:
Hmm, I'm not sure what needs updated. The docs only say that ssl module
disabled certain weak ciphers by default which is still the case. Was there
some specific place or wording you were looking for?
--
___
P
Donald Stufft added the comment:
Ah yes, I skipped over that looking for a place where we were detailing what
ciphers were picked. Ok Thanks!
--
___
Python tracker
<http://bugs.python.org/issue20
Donald Stufft added the comment:
Added the docs changes
--
Added file: http://bugs.python.org/file34558/better-ciphers-with-docs.diff
___
Python tracker
<http://bugs.python.org/issue20
Donald Stufft added the comment:
Heh, I was just getting ready to figure out if I should write this ticket or
not :)
I think we should do this. Nginx also defaults to prime256v1 (which is NIST
P-256), DJB seems to think that's an unsafe curve though
(http://safecurves.cr.
Donald Stufft added the comment:
Ok, looks like everyone just uses prime256v1, so we should use that!
--
___
Python tracker
<http://bugs.python.org/issue21
Donald Stufft added the comment:
I don't have a new enough OpenSSL to test against SSL_CTX_set_ecdh_auto and I
don't really know C very well so I didn't want to do try to handle that.
That being said, here is a patch that allows you to call
SSLContext().set_ecdh_curve() witho
Donald Stufft added the comment:
I always have to do things the hard way ;)
Note that my patch changes the set_ecdh_curve() method to no longer require a
name. If that is too big of a change for Python 3.4 we can just hardcode the
same name inside of ssl.py for 3.4
Donald Stufft added the comment:
The reason I made a default argument to set_ecdh_curve is that I couldn't find
any information about what happens if you set a ecdh curve _twice_ within a a
OpenSSL SSL Context. So I played it safe and made it a default argument that
only gets called i
Donald Stufft added the comment:
I know it doesn't segfault or raise an error if you do that, but I don't know
if it:
1) Replaces the already called ECDH Curve
2) Adds to the already called ECDH Curve
3) Silently Does Nothing.
If it's 2 or 3 then your patch will
Donald Stufft added the comment:
Works for me, that's what it appears like to me too. +1
--
___
Python tracker
<http://bugs.python.org/issue21015>
___
___
Donald Stufft added the comment:
Looks good to me, do you want to commit it Antoine?
--
___
Python tracker
<http://bugs.python.org/issue21015>
___
___
Python-bug
Donald Stufft added the comment:
Attached is a patch that:
* Switches the protocol to SSLv23 so that we can negotiate a TLS1.1 or TLS1.2
connection.
* Sets OP_CIPHER_SERVER_PREFERENCE for Purpose.CLIENT_AUTH so that our
carefully selected cipher priority gives us better encryption and PFS
Donald Stufft added the comment:
Yes
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20995>
___
___
Pyth
Donald Stufft added the comment:
I'll do that :)
To be clear about this patch, it raises the upper bounds of security by
enabling TLS 1.1, and 1.2 as well as the single use for (EC)DH and preferring
the server ciphers.
However it also lowers the lower bounds of security and includes
Donald Stufft added the comment:
That's not entirely true unfortunately :(
There are downgrade attacks that work all the way up through TLS 1.2. These are
not strictly a problem of the protocol specs but instead of the implementations.
See:
https://crypto.stackexchange.com/questions/
Donald Stufft added the comment:
To be clear though, a lot of TLS servers out there still have SSL3.0 enabled by
default, primarily because of IE6 / XP. I'm on the fence about what the right
answer is for create_default_context. From a strictly "best practices for
security" se
Donald Stufft added the comment:
Attached is a new patch. It has:
* Switches the protocol to SSLv23 so that we can negotiate a TLS1.1 or TLS1.2
connection.
* Sets OP_CIPHER_SERVER_PREFERENCE for Purpose.CLIENT_AUTH so that our
carefully selected cipher priority gives us better encryption and
Donald Stufft added the comment:
I think I'm happy with this patch, if anyone has a chance to review it and see
if it looks OK I'd love that and then I can commit it :)
--
___
Python tracker
<http://bugs.python.o
Donald Stufft added the comment:
Added guards to protect against constants not existing.
--
Added file:
http://bugs.python.org/file34590/ssl-context-defaults-ssl3-guards.diff
___
Python tracker
<http://bugs.python.org/issue21
Donald Stufft added the comment:
I completely agree, it seems less than good to recommend CACert.
--
___
Python tracker
<http://bugs.python.org/issue21
Donald Stufft added the comment:
It's quite old (that paragraph) likely it was written that way because back
then Python didn't have a way to load certificates.
--
___
Python tracker
<http://bugs.python.o
Donald Stufft added the comment:
The latest patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue21043>
___
___
Python-bugs-list mailin
Changes by Donald Stufft :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue21043>
___
___
Python-bugs-list
Donald Stufft added the comment:
I don't really feel real strongly one way or another about this patch fwiw. Not
sure it makes anything easier but I don't think it makes anything harder either.
--
___
Python tracker
<http://bu
Donald Stufft added the comment:
Ah, sure it'd probably be useful in that context.
--
___
Python tracker
<http://bugs.python.org/issue21068>
___
___
Pytho
Donald Stufft added the comment:
I agree that this change makes a lot of sense.
--
nosy: +dstufft
___
Python tracker
<http://bugs.python.org/issue21288>
___
___
Donald Stufft added the comment:
try:
data = data.encode("ascii")
except UnicodeEncodeError:
raise TypeError("comparing unicode with non-ASCII characters is not
supported")
?
--
___
Python tracker
<http://bug
Donald Stufft added the comment:
I'm not sure that the timing leakage in an encode is actually something to be
worried about. I'm not sure what secret information would be getting leaked in
a way that you could determine it by examining the timing.
However I think the bigger thing
Donald Stufft added the comment:
The cipher string includes HIGH, so if ChaCha20Poly1305 or another cipher suite
is added to OpenSSL it'll get included in the cipher string by default.
So the major difference of what you suggest would be no longer prioritizing
ciphers. However I would
Donald Stufft added the comment:
> I think performance isn't really relevant, except perhaps on very busy
> servers. A smartphone acting as a *client* certainly shouldn't need to
> download 20 MB/s of encrypted data.
Well, if you factor out performance then ChaCha20Poly1305 a
301 - 400 of 700 matches
Mail list logo
