On 25 Jul 2014 02:05, "Donald Stufft" wrote:
>
> Sorry, I think the provides functionality is outside of the scope of what
we would use TUF for. It is *only* respected if you have that project
installed. In other words if there is a package “FakeDjango” which provides
“Django”, then ``pip install
Also, reject uploads that are not released under a DFSG license or lack man
pages.
On Jul 24, 2014 11:57 AM, "Donald Stufft" wrote:
> On July 24, 2014 at 7:28:55 AM, Richard Jones (r1chardj0...@gmail.com)
> wrote:
>
> Several great ideas came out of today's meetup. Some of those I'll leave
> to t
Got it. Thanks for clearing this up. Glad to hear that virtual
dependencies are not an issue. It simplifies things a lot!
Justin
On Thu, Jul 24, 2014 at 12:03 PM, Donald Stufft wrote:
> On July 24, 2014 at 11:58:01 AM, Justin Cappos (jcap...@nyu.edu) wrote:
>
> FYI: PEP 458 provides a wa
FYI: PEP 458 provides a way to address most of the security issues with
this as well. (We call these "provides-everything" attacks in some of our
prior work: https://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.pdf)
One way of handling this is that whomever registers the name can choose
wh
On July 24, 2014 at 7:28:55 AM, Richard Jones (r1chardj0...@gmail.com) wrote:
Several great ideas came out of today's meetup. Some of those I'll leave to the
proponents themselves to post about, but a couple of little nuggets for thought:
1. reject wheel uploads in the absence of an sdist in the
On July 24, 2014 at 11:58:01 AM, Justin Cappos (jcap...@nyu.edu) wrote:
FYI: PEP 458 provides a way to address most of the security issues with this as
well. (We call these "provides-everything" attacks in some of our prior work:
https://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.pdf)
On July 24, 2014 at 8:23:59 AM, Stefan Krah (ste...@bytereef.org) wrote:
Richard Jones wrote:
> There still remains the usability issue of unsophisticated users running into
> external indexes and needing to cope with that in one of a myriad of ways as
> evidenced by the PEP. One solution propo
On July 24, 2014 at 7:26:11 AM, Richard Jones (r1chardj0...@gmail.com) wrote:
Even ignoring the malicious possibility there is a probably greater chance of
accidental mistakes:
- company sets up internal index using pip's multi-index support and hosts
various modules
- someone quite innocently u
On July 24, 2014 at 6:40:47 AM, Vladimir Diaz (vladimir.v.d...@gmail.com) wrote:
In metadata 2.0 even with package signing you end up where I can have you
install “django-foobar” which depends on “FakeDjango”, which provides “Django”,
and then for all intents and purposes you have a “Django” pack
On Jul 24, 2014, at 01:28 PM, Richard Jones wrote:
>1. reject wheel uploads in the absence of an sdist in the index (the linux
>guys were really happy about that as a proposal ;)
+1 :)
-Barry
signature.asc
Description: PGP signature
___
Distutils-SIG
On July 24, 2014 at 4:55:42 AM, Richard Jones (r1chardj0...@gmail.com) wrote:
Thanks for responding, even from your sick bed.
This message about users having to view and understand /simple/ indexes is
repeated many times. I didn't have to do that in the case of PIL. The tool told
me "use --allow
Richard Jones wrote:
> There still remains the usability issue of unsophisticated users running into
> external indexes and needing to cope with that in one of a myriad of ways as
> evidenced by the PEP. One solution proposed and refined at the EuroPython
> gathering today has PyPI caching package
Several great ideas came out of today's meetup. Some of those I'll leave to
the proponents themselves to post about, but a couple of little nuggets for
thought:
1. reject wheel uploads in the absence of an sdist in the index (the linux
guys were really happy about that as a proposal ;)
2. add a sy
Even ignoring the malicious possibility there is a probably greater chance
of accidental mistakes:
- company sets up internal index using pip's multi-index support and hosts
various modules
- someone quite innocently uploads something with the same name, never
version, to pypi
- company installs n
In metadata 2.0 even with package signing you end up where I can have you
install “django-foobar” which depends on “FakeDjango”, which provides
“Django”, and then for all intents and purposes you have a “Django” package
installed.
Can you go into more detail? Particularly, the part where "FakeDja
Thanks for responding, even from your sick bed.
This message about users having to view and understand /simple/ indexes is
repeated many times. I didn't have to do that in the case of PIL. The tool
told me "use --allow-external PIL to allow" and then when that failed it
told me "use --allow-unveri
16 matches
Mail list logo
