proposal: vanity domain support

[rogpeppe]

This proposal tracks adding support for custom ("vanity") domains to the Central Registry.
The initial design document is at https://github.com/cue-lang/proposal/blob/main/designs/3954-vanity-domains.md

Note: the initial design is already implemented and deployed as an experiment.
This discussion should be used for feedback on both the current implementation and for any ideas about its future.

[mxey]

I mentioned this in person at KubeCon but I want to reiterate: I would recommend against supporting DNS. Doing it via HTTPS provides cryptographic integrity. DNS only provides it if using DNSSEC which is not widely deployed. If I do not have DNSSEC on my domain, somebody else could spoof my DNS zone and provide a TXT record to their code, even if I do not want to use DNS for this.

[rogpeppe]

If someone can spoof your DNS zone, surely they can spoof the A record too, and acquire an SSL cert via LetsEncrypt and thus spoof the HTTPS site too? I'm not entirely convinced that either is more secure than the other, but happy to hear arguments otherwise.

[mxey]

OK by that logic HTTPS would be worthless ;) You are not wrong, but CAs take extra care to avoid their DNS being spoofed, like using multiple network paths. If they issue a wrong certificate, that's on them. There is no need to take this on yourself :)

Also any issued certificates will show up in Certificate Transparency logs, so that attack is impossible to hide.

[snuxoll]

I'd like to chime in here if there's a proposal for a well-known URL for cue at all, that it would be nice to have a webfinger-style discovery endpoint for module path to registry mapping (which CUE Lab's central registry could extend with permission information if so desired). I actually implemented such a thing as a proof-of-concept myself a couple weeks ago with a custom modconfig.Registry implementation that took a base32 encoded module URI, then queried https://hostpart/.well-known/cue/%encodedpath to get a JSON blob containing an OCI registry (optionally including a base path) to use for module resolution. This had the benefit of a more decentralized go-style import path to source mapping without making what I consider the big mistake from the Go team (cramming it into an arbitrary HTML document that needs to get parsed to look up a tag, and all the potential security headaches that come with it).

[rogpeppe]

For the record, we did seriously consider this kind of arbitrary mapping of module path to source location
(essentially the Go approach) but decided against it. Reasons for this include:

• it preserves the property that one should not have to open a CUE client up to the entire network in order to be able to fetch modules. Instead, the client is strictly bounded by the registries mentioned in $CUE_REGISTRY. That is, there is always an indirection between the name of a module and its location. This makes it feasible to run CUE in air-gapped or network-limited environments, or to limit module availability to some "blessed" set of modules.
• it becomes much more feasible to provide private modules: when a module can be fetched from any location, it's much harder to implement a standard access scheme. Note that Go still does not have a good story for private modules with respect to the Go proxy.
• a registry does not itself need to reach out to arbitrary parts of the network: because it's the source of truth itself, it can always reply immediately with a definitive answer; see Go issues #73403 #66653 #65704 #50158 #49916 for context on the alternative approach.

All this does not mean that you can't implement schemes like this yourself (as witness your experiment), but hopefully it does make it clearer why the design is the way that it is, and the advantages of that.