> On Apr 9, 2018, at 1:33 PM, Erik Bray <erik.m.b...@gmail.com> wrote:
> On Fri, Apr 6, 2018 at 11:36 PM, Chris Jerdonek
> <chris.jerdo...@gmail.com> wrote:
>> On Fri, Apr 6, 2018 at 11:21 AM Donald Stufft <don...@stufft.io> wrote:
>>> No, there’s not. pip makes HTTP requests and there’s no place for extra
>>> metadata attached those requests except in the HTTP status code (which as
>>> you noted, pip swallows by default because historically we didn’t know if
>>> the URL was expected to work or not). The simple API wasn’t really designed,
>>> it evolved out of the primordial ooze.
>> Would it make sense to open an issue for future versions of pip to allow
>> such metadata to be attached and displayed, or is there already such an
>> issue?
> I was going to suggest the same--while it would be too late to help in
> this particular case (and as Donald already convincingly it explained
> it probably won't have huge impact), this case, others I can think of
> before it, and others that are likely to occur in the future would
> have been well-served by the ability of PyPI administrators to set
> arbitrary broadcast messages (a MotD if you will) to send along with
> HTTP responses from PyPI (they could even go in an HTTP header,
> perhaps).
> Best,
> E

It wouldn’t be a pip issue, it’d be a distutils-sig discussion and an amendment 
to PEP 503. The primary concern would be that as we move to a world where 
metadata is signed to prevent a malicious repository from attacking users, that 
this is another avenue that an attacker could take to trick end users (imagine 
a MOTD that says to pip install malicious-package).

That doesn’t make it impossible, or a bad idea though! It just is something to 
consider, and the best avenue is distutils-sig.

Reply via email to