undefined | Better HN

0 pointsblibble3y ago0 comments

obviously, but it allows delegation of trust onto other systems (like the DNS)

example: the package named "aws" on pypi was created by some random guy and has been abandoned for years

if pypi/pip supported namespacing that would be info.randomdude.aws instead

and amazon's packages would be under com.amazon

not being able to namespace internal packages is another security issue that is substantially improved with proper namespacing

to be blunt: not supporting it at this point is reckless and irresponsible

(I note you're part of pypa!)

0 comments

woodruffw3y ago

DNS isn't a particularly secure root of trust; Java is somewhat unique among package ecosystems for picking it as their trust anchor.

It also just kicks the can down the road: Amazon is the the easy case with `com.amazon`, but it isn't clear a priori whether you should trust `net.coolguy.importantpackage` or `net.cooldude.importantpackage`. These kinds of trust relationships require external communication of a kind that package indices are not equipped to supply, and should not attempt to solve haphazardly.

> (I note you're part of pypa!)

I am a member of PyPA, but I don't represent anyone's opinions but my own. It's a very loose collection of projects, and it would be incorrect to read a general opinion from mine.

charrondev3y ago

I will note even namespaces for package management that don’t use DNS are a big step up over none.

For example in PHP/composer/packagist and node/npm they just have a vendor name that can be reserved.

It makes it very easy to distinguish “this package is from the (trusted vendor name here)” and prevents issues with namesquatting.

blibbleOP3y ago

> Amazon is the the easy case with `com.amazon`, but it isn't clear a priori whether you should trust `net.coolguy.importantpackage` or `net.cooldude.importantpackage`

this is a classic example of not letting perfect be the enemy of good

there is no perfect solution, there never will be

piggybacking off of DNS works extremely well for Java and Go (and the tooling is a pleasure to work with)

meanwhile Python continues to be a complete disaster

woodruffw3y ago

I agree there is no perfect solution. But I want a good solution, and I disagree that DNS is a good one.

1 more reply

georgyo3y ago

I like the way golang handled this. Imports are the URL to the resource. No central distribution mechanism at all. In the past few years they implemented a optional catching layer so you a dependencies going offline doesn't necessarily mean that it unavailable anymore.

dpedu3y ago

Who's to say mr randomdude won't claim com.amazon first?

sophacles3y ago

Let's encrypt solved this by doing a proof of control over the domain name, and in an automated way.

Pypi could do this. Or, they could require that someone demonstrate proof of ownership for a namespace by signing it with a certificate tied to the domain name (so you couldn't claim the com.bigco namespace without having the certs, which you can't get without owning that domain). There could even be signature requirements/proof for each package and/or version uploaded.

dpedu3y ago

I would need to spend money to purchase a domain and some kind of server before I can publish a python module? That doesn't seem right. And I presume I would need to keep paying for it as long as I want my modules available and verified. Attaching required monetary purchases to an open source ecosystem is not a good idea.

1 more reply

natpalmer17763y ago

Well, in theory you could have a namespace schema that differentiates between user-submitted and organization-submitted packages such that randomdude's would appear as 'public.randomdude.aws' and organization-owned namespaces verified by a DNS record would appear as 'com.amazon.aws'

dragonwriter3y ago

You could in principle do proof-of-ownership checks like Google does for things like Webmaster Tools, so you’d need to control a domain to have thr corresponding namespace.

pphysch3y ago

It's much easier to correct the ownership of a single namespace than N packages in the global namespace

j / k navigate · click thread line to collapse

0 comments

woodruffw3y ago

DNS isn't a particularly secure root of trust; Java is somewhat unique among package ecosystems for picking it as their trust anchor.

> (I note you're part of pypa!)

I am a member of PyPA, but I don't represent anyone's opinions but my own. It's a very loose collection of projects, and it would be incorrect to read a general opinion from mine.

charrondev3y ago

I will note even namespaces for package management that don’t use DNS are a big step up over none.

For example in PHP/composer/packagist and node/npm they just have a vendor name that can be reserved.

It makes it very easy to distinguish “this package is from the (trusted vendor name here)” and prevents issues with namesquatting.

blibbleOP3y ago

> Amazon is the the easy case with `com.amazon`, but it isn't clear a priori whether you should trust `net.coolguy.importantpackage` or `net.cooldude.importantpackage`

this is a classic example of not letting perfect be the enemy of good

there is no perfect solution, there never will be

piggybacking off of DNS works extremely well for Java and Go (and the tooling is a pleasure to work with)

meanwhile Python continues to be a complete disaster

woodruffw3y ago

I agree there is no perfect solution. But I want a good solution, and I disagree that DNS is a good one.

1 more reply

georgyo3y ago

dpedu3y ago

Who's to say mr randomdude won't claim com.amazon first?

sophacles3y ago

Let's encrypt solved this by doing a proof of control over the domain name, and in an automated way.

dpedu3y ago

1 more reply

natpalmer17763y ago

dragonwriter3y ago

You could in principle do proof-of-ownership checks like Google does for things like Webmaster Tools, so you’d need to control a domain to have thr corresponding namespace.

pphysch3y ago

It's much easier to correct the ownership of a single namespace than N packages in the global namespace

j / k navigate · click thread line to collapse