Re: [PATCH for discussion] doc: Define a standard URI syntax for NBD URIs.
On Sun, May 26, 2019 at 10:00:18AM +0100, Richard W.M. Jones wrote:
> I intended to write a cover letter, got distracted while sending it
> and forgot ...
>
> Anyway I was going to say:
>
> - There's no way to specify abstract Unix domain sockets. Should
> there be? I'm not aware of any server that supports them. Luckily
> the common approach of using `@` at the beginning should work:
> https://unix.stackexchange.com/questions/206386/what-does-the-symbol-denote-in-the-beginning-of-a-unix-domain-socket-path-in-l
It's probably a good idea, yes, even if indeed no current implementation
supports them.
(That being said, abstract UDSes are a Linux-specific feature, so...)
> - As Wouter already picked up in his review, should we allow a
> default Unix domain socket? The corollary to this is: Should we
> make the authority mandatory for TCP/IP sockets? Are there
> sensible defaults for the authority (localhost:10809 probably).
Yeah, that could be a sensible default, depending on the implementation.
Your document makes it clear that it's implementation-dependent though,
so I shouldn't worry about it too much.
> - I notice that proto.md has a text symlink (proto.txt). Would we
> need one for url.txt -> url.md?
No.
The original protocol definition document was a .txt file. When I
restructured it and converted it to a markdown one, I added a symlink in
place, because there were some locations (QEMU, amongst others) that
linked to the .txt file, and I didn't want to break links.
This would be a new document, so there are no links to break.
(I guess the need for that backcompat symlink has subsided now and I can
remove it, but meh)
> Wouter Verhelst wrote:
> > Should we perhaps also add query parameters for certificate-based
> > authentication?
>
> I think yes, although it could get complicated to define them all.
True, which is why I asked the question rather than suggesting we do ;-)
> qemu's NBD client needs a directory name, which contains certificates
> with particular names (see Dan's second example here:
> https://www.berrange.com/posts/2016/04/05/improving-qemu-security-part-5-tls-support-for-nbd-server-client/
> ). If we were to specify every file by name then it would require
> probably 3 or 4 extra parameters (CA cert, client cert, client private
> key file, and optionally revocation list).
That's what nbd-client and nbd-server expect, FWIW.
> For TLS-PSK it only needs the path to the PSK key file. The username
> is already provided in the userinfo authority field.
Right.
> We might also consider a tls type parameter to switch between X.509
> certs, PSK and anon.
There is that too, yes.
--
To the thief who stole my anti-depressants: I hope you're happy
-- seen somewhere on the Internet on a photo of a billboard
Reply to: