Rephrase section on distutil's security#100
Conversation
There was a problem hiding this comment.
"Only recently" is deceptive and either needs to be expanded or there needs to be a footnote explaining what that even means. Expecting people to read a bpo issue to try to determine when it stopped does not seem reasonable to me. Further, not using HTTP simply isn't enough to make distutils secure.
There was a problem hiding this comment.
"Only recently" is deceptive and either needs to be expanded
I thought the Versions field of the linked bugreport would be informative enough while not distracting the user from twine's rationale. I have updated the whole paragraph though.
Further, not using HTTP simply isn't enough to make distutils secure.
I didn't write that anywhere. Even the commit message doesn't, although I tried hard to keep that line within 50 chars.
untitaker
force-pushed
the
distutils-is-secure-now
branch
2 times, most recently
from
44fb240 to
fb9bf2d
Compare
There was a problem hiding this comment.
We should probably also say "easily sniffed" because there's no verification of the connection and someone using a tool like mitmproxy could easily sniff the credentials over TLS that is not verified.
There was a problem hiding this comment.
there's no verification of the connection
Are you saying that twine doesn't check SSL certificates?
There was a problem hiding this comment.
Are you saying that twine doesn't check SSL certificates?
No. distutils (even thought it uses HTTPS) does not check SSL certificates. Twine does.
There was a problem hiding this comment.
Sorry, brainfart. Will fix.
There was a problem hiding this comment.
Just did s/sniffed/easily sniffed/g.
untitaker
force-pushed
the
distutils-is-secure-now
branch
from
fb9bf2d to
0dc6dda
Compare
Rephrase section on distutil's security
|
Thanks @untitaker |
2 participants
See #93