[Python-ideas] Remote package/module imports through HTTP/S

Chris Angelico rosuav at gmail.com
Wed Aug 23 13:49:17 EDT 2017


On Thu, Aug 24, 2017 at 3:37 AM, John Torakis <john.torakis at gmail.com> wrote:
>
>
> On 23/08/2017 20:36, John Torakis wrote:
>> Yeah, I am a security researcher, I am keen on backdoor programming and
>> staging and all that! It is my official job and research topic! I go to
>> the office and code such stuff! I am not a blackhat, nor a security
>> enthusiast, it is my job.
>>
>>
>> First of all, let's all agree that if someone can run Python code in
>> your computer you are 100% hacked! It is irrelevant if "httpimport" is a
>> core python feature or not in that case.
>>
>> Now, I agree that this can be exploited if used under plain HTTP, it is
>> a MiTM -> Remote code execution case. I admit that this is not bright.
>> But I mention that this can be used in testing.
>>
>> On the topic of HTTPS, man-in-the-middle is not possible without
>> previous Trusted Certificate compromise. Github can be trusted 100%
>> percent for example. A certificate check has to take place in the HTTPS
>> remote loading for sure!

Right, but that just pushes the problem one level further out: you
need to have a 100% dependable certificate chain. And that means
absolutely completely trusting all of your root certificates, and it
also means either not needing to add any _more_ root certificates, or
being able to configure the cert store. As we've seen elsewhere, this
is nontrivial.

>> When I said a "core feature" I meant that the "httpimport" module would
>> deliver with the core modules. Not that the Finder/Loader has to be in
>> the list of Finders/Loaders that are used by default! For god sake, I
>> wouldn't like my PC to start probing for modules just because I mistyped
>> an import line!

Glad we agree about that! I have seen people wanting all sorts of
things to become core features (usually for the sake of interactive
work), and a lot of it is MUCH better handled as a non-core feature.

Though a lot of what you're saying here - especially this:

>> I know that pip works nicely, especially when paired with virtual
>> environments, but ad-hoc importing is another another thing. It isn't
>> meant for delivering real projects. Just for testing modules without the
>> need to download them, maybe install them, and all.

could be equally well handled by pip-installing httpimport itself, and
using that to bootstrap your testing procedures. Unless, of course,
you're wanting to httpimport httpimport, in which case you're going to
run into bootstrapping problems whichever way you do it :)

I think we're on the same page here, but it definitely needs some more
text in the README to explain this - particularly how this is not a
replacement for pip. For example, my first thought on seeing this was
"wow, that's going to be abysmally slow unless it has a cache", but
the answer to that is: if you need a cache, you probably should be
using pip to install things properly.

Still -1 on this becoming a stdlib package, as there's nothing I've
yet seen that can't be done as a third-party package. But it's less
scary than I thought it was :)

ChrisA


More information about the Python-ideas mailing list