2 ms·

> When it comes down to it, it's nobody else's business what python code-modules I'm downloading, it might give them enough information to attack my servers, so

> When it comes down to it, it's nobody else's business what python code-modules I'm downloading, it might give them enough information to attack my servers, so secrecy isn't a bad thing either. There is much bigger issue there: nobody verifies package signatures. Most packages do not even have ones. So you fundamentally have no way to verify that what you downloaded is what you wanted. Someone could have stolen my PyPI access credentials and uploaded a broken package under one of my releases. Or I'm just a bad person and would ship you bad code. SSL does not solve that problem.

Nursie 12y ago
>> There is much bigger issue there: nobody verifies package signatures. Most packages do not even have ones. This is bad practice, and is not solved by less integrity and authenticity checking! >> Or I'm just a bad person and would ship you bad code. Nobody said it solves everything, but it does help prevent unrelated third parties getting in on the act, actively or passively.
- the_mitsuhiko 12y ago
  > This is bad practice, and is not solved by less integrity and authenticity checking! No, it's a completely orthogonal issue which was my point. But you were bringing up a potential security issue which is that people might know what packages you are using. I'm bringing up that you are installing completely untrusted packages which is your actual issue there, not that someone might be able to know what you are using. Let alone that with AGPL libraries for instance you are required to disclose that anyways.
  - Nursie 12y ago
    >> I'm bringing up that you are installing completely untrusted packages which is your actual issue there, not that someone might be able to know what you are using. There are multiple 'actual' issues here. One, you have identified, is that the content on the server is not very well verified. This is a problem I agree, and solutions are likely non-trivial. TLS will not fix this for you. The second one is making sure that what is on the server is accurately replicated on the client. Authentication (am I talking to the real server?) and integrity checking (did I really get what the server tried to send me?) are important here. TLS can address this. The third is giving away information about modules installed, which may be another risk. TLS will mitigate this. You're right that the AGPL would require you to disclose to any user which modules are in use and give over the source to anyone that uses your service and asks for it, and in general security by obscurity is a bad idea anyway - however I may not have users, I may be setting up a server only for me to access, and I may not want passive traffic sniffers to know that my experimental server is likely to be running an easily-compromised version of a service for the next five minutes until I patch it.
- grincho 12y ago
  I'll just leave this here: https://pypi.python.org/pypi/peep/ https://pypi.python.org/pypi/peep/. (It verifies Python package downloads against local hashes.)
  - Nursie 12y ago
    That certainly helps repeatability of install, but it doesn't (so far as I can tell) help if you've been MITM'd on first download. So it's a bit like a self-signed certificate at that point.

Nursie 12y ago

>> There is much bigger issue there: nobody verifies package signatures. Most packages do not even have ones. This is bad practice, and is not solved by less integrity and authenticity checking! >> Or I'm just a bad person and would ship you bad code. Nobody said it solves everything, but it does help prevent unrelated third parties getting in on the act, actively or passively.

the_mitsuhiko 12y ago
> This is bad practice, and is not solved by less integrity and authenticity checking! No, it's a completely orthogonal issue which was my point. But you were bringing up a potential security issue which is that people might know what packages you are using. I'm bringing up that you are installing completely untrusted packages which is your actual issue there, not that someone might be able to know what you are using. Let alone that with AGPL libraries for instance you are required to disclose that anyways.
- Nursie 12y ago
  >> I'm bringing up that you are installing completely untrusted packages which is your actual issue there, not that someone might be able to know what you are using. There are multiple 'actual' issues here. One, you have identified, is that the content on the server is not very well verified. This is a problem I agree, and solutions are likely non-trivial. TLS will not fix this for you. The second one is making sure that what is on the server is accurately replicated on the client. Authentication (am I talking to the real server?) and integrity checking (did I really get what the server tried to send me?) are important here. TLS can address this. The third is giving away information about modules installed, which may be another risk. TLS will mitigate this. You're right that the AGPL would require you to disclose to any user which modules are in use and give over the source to anyone that uses your service and asks for it, and in general security by obscurity is a bad idea anyway - however I may not have users, I may be setting up a server only for me to access, and I may not want passive traffic sniffers to know that my experimental server is likely to be running an easily-compromised version of a service for the next five minutes until I patch it.
grincho 12y ago
I'll just leave this here: https://pypi.python.org/pypi/peep/ https://pypi.python.org/pypi/peep/. (It verifies Python package downloads against local hashes.)
- Nursie 12y ago
  That certainly helps repeatability of install, but it doesn't (so far as I can tell) help if you've been MITM'd on first download. So it's a bit like a self-signed certificate at that point.