On May 9, 2014, at 11:41 AM, Paul Moore <p.f.mo...@gmail.com> wrote:
> OK, basically I get what you mean now. > > On 9 May 2014 16:37, Donald Stufft <don...@stufft.io> wrote: >> You’re unlikely to ever encounter an issue where adding —allow-external >> actually helps you, but adding it does make it more likely you’ll be hurt. > > Well, it helps me in that I never need to think about whether I mean > allow-external or allow-unverifiable. That's a win, IMO... > Paul Right, but I think a similar win can be had just by folding —allow-external into —allow-unverifiable and make it —allow-off-pypi (needs a better name, maybe just keep it as --allow-external?). This would effectively mean that an end user cannot say "allow safe downloading X externally but disallow downloading it unsafely externally". I'm normally someone who advocates towards better decisions on the security side of things, however if most people are going to need to use the --allow-unverifiable flag anyways then I think the benefits of having the two separated isn't very large. There is still a benefit to not installing externally hosted things by default which is why I think that just rolling the two options together is better. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
