Re: [Nbd] [PATCH/RFC 0/3] Introduce TLS on nbdserver

[Wouter Verhelst <w@...112...>]

On Mon, Apr 11, 2016 at 11:47:00PM +0100, Alex Bligh wrote:
> Wouter,
> 
> >> just found ANOTHER reason for that - see below for the bad news.
> >> 
> >> I think I'd quite like to get this in as is and get the refactoring
> >> done later (given SSL is in the standard now :-) )
> > 
> > Sure. Like I said, I'm not opposed to what you're suggesting. It's just
> > that it adds more work for me later (experience tells me that
> > "refactoring" is mostly my job), and I'd like to avoid that if we can.
> 
> :-)
> 
> >> I think I understood about 70% of that.
> > 
> > Can you be a bit more specific than that? Which parts aren't entirely
> > clear?
> 
> Let me look at that again in the cold light of day tomorrow. I suspect
> (given your comment below) I may have missed bits.
> 
> >> 1. The individual functions in nbdserver.c do their own bitbanging.
> >>   (i.e. sending things to the wire).
> > 
> > Yes, that's what my brain dump above is trying to fix, too.
> 
> OK
> 
> >>   This is partly a result of
> >>   history where there was not much commonality and structure between
> >>   nbd options. This isn't entirely true (see e.g. send_reply()).
> >>   Another approach would be to have the entire option consumed
> >>   or not in one place, and the entire reply sent or not in one place.
> > 
> > While that would be an improvement, it will retain the status quo where
> > function X has a hard coded call to function Y at the end. I'd like to
> > get rid of that.
> > 
> > My brain dump of above, if implemented, would result in something along
> > the following lines (pseudo code):
> > 
> > int copyonwrite_write(CLIENT* client, METHODS* next, int active_fd, off_t offset, size_t len, char* databuf) {
> > 	assert(next->next != NULL);
> > 	next = next->next;
> > 	if(offset is in copyonwrite map) {
> > 		active_fd = copyonwrite_difffile;
> > 	}
> > 	return next->write(client, next, active_fd, offset, min(len, length of current extent in copyonwrite map), databuf);
> > }
> 
> Ah, so something like a layered set of backend drivers?

That's the idea, yeah.

> This is pretty much what qemu's block layer does, except without the
> scary coroutines.

Heh.

> I was actually talking about bitbanging the network protocol side.

I know.

It's just that this approach would work equally well for the network
side of things, but in that case would be simpler (because it needs less
handler functions), and would thus be a good testbed, so it's what I had
been working on for implementing TLS.

[...]
> >>> I now notice that PKG_PROG_PKG_CONFIG is in the wrong place (it needs
> >>> to be before all those AC_CHECK_* calls), but other than that...
> >> 
> >> .... oh, it's already there?
> > 
> > No, my (local, not pushed anywhere) starttls branch from which this
> > patch was pulled puts it in the wrong location.
> 
> I mean "the dependency on PKG_CONFIG is already there?"

Yes, I know that's what you meant. No, it isn't. The patch I sent added
the PKG_PROG_PKG_CONFIG macro in the wrong place (and that's what the
above refers to), but there isn't pkg-config in any released version of
nbd (or of nbd master, for that matter)

> >>> The requirement to have gnutls >= 3.3.0 (released in 2014, so old enough
> >>> that most distributions should have it by now) allows to skip
> >>> gnutls_global_init() at startup -- always nice to not to have to track
> >>> that.
> >> 
> >> Nope. I'm running Ubuntu 14.04 (which is a reasonable OS I think) and
> >> you *definitely* need gnutls_global_init() there. There's no harm in
> >> callign it.
> > 
> > 14.04 isn't going to get a new nbd-server with TLS support. I don't
> > think supporting ages-old versions of GnuTLS because "people might want
> > to compile it on ubuntu 4.04" is a particularly bright idea.
> > 
> > Then again, if you're writing the support, who am I to complain?
> 
> No sure, but's it's a reasonable target to compile on. 16.04
> is either not out yet or only just out,

Not for another week or so :-)

https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule

But my point is that I think it's fine if I depend on "whatever's in
most current development releases of distributions". People use
nbd-server *mostly* through their distribution, not by downloading it
from sourceforge and compiling themselves. If they're doing that anyway,
they can compile dependencies, too.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12