undefined | Better HN

0 pointsinsanitybit9d ago0 comments

What stops someone from just squatting the namespace? What is the concrete value? Who gets a namespace? Who gets "apache"'s namespace? Is it a problem if a user takes "apache" or "anthropic"? Do you use domain registration to determine who owns a namespace?

I'll read the article soon fwiw, but those questions come to mind. I'm definitely open to it.

For now I have:

1. Minimum "typo distance" between package names, unless within the same author.

2. Trusted Publishing + 2FA to promote from "published" to "released" required, no API keys.

3. 1 day dependency cooldown by default.

4. The language (and the build system, built in the language) has explicit capabilities model so you can statically verify what build scripts are allowed to do.

I feel like the benefit of namespacing must be quite low at this point but perhaps I need to reevaluate.

0 comments

4 comments · 1 top-level

vlovich1239d ago· 3 in thread

If you can’t be bothered to read the paper that covers all of it, why should I be bothered to respond? Do whatever you want, I’m just highlighting this space is well studied and you’re insisting on retreading ground where the consequences are well-studied.

insanitybitOP9d ago

As I said, I will read it (in fact, right now!). Perfectly reasonable to say "that's all addressed in the post", of course.

edit: I'll have to reread it perhaps. I feel like the article largely motivates my points about how complex namespace registration is and how it just punts the problem (or adds new problems like "you hijacked the entire namespace"). It doesn't seem like there's a strong proposal in the article other than to make namespaces support built-in by default to make later migrations easier if a solution does come about, which is reasonable and something I can do.

I'll read the linked PEP/RFCs to learn more about how others are solving this but I think my opinion is still mostly that registries trade some problems for other (worse?) problems.

At minimum it seems notable to restrict package names in general as it allows more options for denotation in the future.

vlovich1238d ago

Right. I think the strongest is to tie the namespace into the language’s module system if possible like what cargo is trying to do. It depends on the language. DNS namespaces also work provided you add a key to guarantee a DNS takeover doesn’t take over the package namespace.

But the important point is to reserve support to add namespacing in the future even if you punt on it initially. Although I still argue as a security measure it’s better to support namespacing from the get go. Trust and authorship are valuable. There’s also all sorts of cryptographically strong ways to guarantee namespace owenrship that haven’t been explored (eg how tor can do vanity domain name creation)

insanitybitOP8d ago

My current thinking is that if there's Trusted Publishing then you can embed something from the OIDC claim into the namespace, like a github username, or whatever the subject would be. So that would give you `github.username` or, for some other OIDC provider, `<provider-name>.<claim>`.

DNS feels like it's asking a lot of maintainers idk, I'm very hesitant to do that one.

The rust proposal feels somewhat clean at least due to module names mapping cleanly, I think I kinda like that so far.

j / k navigate · click thread line to collapse