Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>

It seemed before that it would insert man*.sh into Makefiles, but it did
not. With the fix in 4da5f85c

 "Rework the manpages thing" this became an
FTBFS like:

configure.ac: installing './ylwrap'
configure.ac:371: error: required file 'man/nbd-client.8.sh.in' not found
configure.ac:371: error: required file 'man/nbd-server.5.sh.in' not found
configure.ac:371: error: required file 'man/nbd-server.1.sh.in' not found
configure.ac:371: error: required file 'man/nbd-trdump.1.sh.in' not found
configure.ac:371: error: required file 'man/nbdtab.5.sh.in' not found
autoreconf: error: automake failed with exit status: 1

Those files are no manpage files, they will be built in man/mans.mk
and cleans in man/Makefile via MAINTAINERCLEANFILES. No need to list
them here.

Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>

Tagging NBD 3.23

Tagging NBD 3.22

Using OPT_SET_META_CONTEXTS is stateful (it is documented to wipe out
any previously-requested contexts, and we just tightened the spec to
clarify that starting TLS also wipes it out).  But
OPT_LIST_META_CONTEXTS is not stateful; and in fact, with a
SELECTIVETLS server, it can be handy to list the meta contexts
available on an unencrypted export, then enable encryption, and then
further list what contexts are available on encrypted exports (as the
server is permitted to let those lists differ).  Although such a
client must negotiate structured replies after starttls if it is going
to actually connect to an export, this change permits the client to
shorten the handshake by two commands if it is only being used to list
available exports and their meta contexts before disconnecting.

When using -u but not -H, we were ending up calling
gnutls_session_set_verify_cert() with the Unix socket's path name,
which is bound to fail (hostnames don't start with /).  Saner is to
only default tlshostname when using TCP sockets.

See also https://gitlab.com/nbdkit/nbdkit/-/issues/1

, as this was
detected during an attempt to prove TLS interoperability between
nbd-client and nbdkit.  Pre-patch, I have to add '-H localhost' to the
nbd-client command line when using nbdkit with a Unix socket, but not
when using a TCP socket; post-patch, I can omit -H and still connect
/dev/nbd0 over TLS using either TCP or Unix.

Signed-off-by: Eric Blake <eblake@redhat.com>

glib now recommends that we use g_memdup2() to avoid accidental 32-bit
truncation bugs on platforms where g_size is larger than guint:

https://discourse.gnome.org/t/port-your-module-from-g-memdup-to-g-memdup2-now/5538

and failure to do so causes noisy compilation due to deprecation
warnings with glib 2.68:

nbd-server.c: In function ‘parse_cfile’:
nbd-server.c:1010:25: warning: ‘g_memdup’ is deprecated: Use 'g_memdup2' instead [-Wdeprecated-declarations]
 1010 |                         SERVER *srv = serve_inc_ref(g_memdup(&s, sizeof(SERVER)));
      |                         ^~~~~~
In file included from /usr/include/glib-2.0/glib.h:82,
                 from nbd-server.c:117:
/usr/include/glib-2.0/glib/gstrfuncs.h:257:23: note: declared here
  257 | gpointer              g_memdup         (gconstpointer mem,
      |                       ^~~~~~~~

Of course, we still want to build on platforms with older glib that
lack g_memdup2().  Thankfully, it's easy enough to audit that all our
current uses of g_memdup() do not overflow 32 bits.

Codify the fact that downgrade attacks are possible not only by
manipulation of NBD_OPT_STARTTLS, but also by manipulation of the
NBD_FLAG[_C]_* handshake flags.  To ensure we don't accidentally
introduce a new MitM attack vector, we want the specification to
clearly document that controlling any new protocol changes prior to
TLS is unwise, and therefore we are unlikely to add any new handshake
flags.

Viewed from another perspective, the 16 bits for handshake flags
control the protocol used during NBD_OPT_*, but what we have with
NBD_FLAG_FIXED_NEWSTYLE is already fairly robust for future extension
(since all but NBD_OPT_EXPORT_NAME encode a length, and we've gone to
great lengths to document what servers and clients should do with
unknown requests).  Meanwhile, any extension that wants to affect the
protocol used by transmission phase, such as structured replies, is
fine waiting until after TLS is started.

The expense of an extra round trip or two during NBD_OPT_ haggling
pales in comparison to the amount of data that will go over the wire
during transmission phase; and if startup efficiency really matters,
we could add a new NBD_OPT_ that does more things in one round trip
(where the fallback is still the older one-at-a-time approach).

Consider a SELECTIVETLS server and a MitM attacker, under the
following NBD_OPT_ handshake scenario:

 client:                  mitm:                    server:
 > _STARTTLS
                          > _STRUCTURED_REPLY
                                                   < _REP_ACK
                          > _STARTTLS
                                                   < _REP_ACK
                          < _REP_ACK
 > _GO
                          > _GO
                                                   < _REP_ACK
                          < _REP_ACK
 > NBD_CMD_READ

In this scenario, the client is NOT expecting structured replies from
the server, but if the server feels obligated to send them based on
the plaintext negotiation, it may confuse the client.  The MitM
attacker was thus able to corrupt the connection, even without having
any encryption keys.  The only sane approach is to forbid ALL stateful
negotiations from having any effect post-encryption (the MitM's
injected packet is effectively ignored, and the client proceeds
without structured replies).

Unfortunately, nbdkit 1.26.0 is buggy in this regards - a CVE will be
opened against that product.  nbd-server does not yet understand
NBD_OPT_STRUCTURED_REPLY, and qemu as server does not use SELECTIVETLS
mode, so they are immune.

Consider a SELECTIVETLS server and a MitM attacker, under the
following NBD_OPT_ handshake scenario:

 client:                  mitm:                    server:
 > _STARTTLS
                          > _SET_META_CONTEXT("A")
                                                   < _REP_META_CONTEXT
                                                   < _REP_ACK
                          > _STARTTLS
                                                   < _REP_ACK
                          < _REP_ACK
 > _SET_META_CONTEXT("B")
                          < _REP_META_CONTEXT
                          < _REP_ACK
 > _GO
                          > _GO
                                                   < _REP_ACK
                          < _REP_ACK
 > NBD_CMD_BLOCK_STATUS

While this scenario requires the MitM to be able to use encryption to
speak to the client (and thus a less likely scenario than a true
protocol downgrade or plaintext buffering attack), it results in a
situation where the client is asking for information on context "B",
but where the server only saw a request for context "A", which may
result in the client interpreting the results of BLOCK_STATUS
incorrectly even though it is coming over an encrypted connection.

The safest fix to this is to require that a server cannot use any meta
context requests from prior to enabling encryption with any successful
NBD_OPT_GO after encryption.  At this point, the spec already states
that the server should then return an error (the client is asking for
block status without proper negotiation), which is better than letting
the client blindly misinterpret a response sent for a different meta
context.

To date, the only known server that has implemented TLS with
SELECTIVETLS mode as well as support for NBD_OPT_SET_META_CONTEXT is
nbdkit (qemu-nbd only has FORCEDTLS mode, and nbd-server lacks meta
context support); thankfully, that implementation is in already line
with this stricter requirement.

Especially useful in light of the recent publishing of
https://nostarttls.secvuln.info/, which documents a variety of
implementations vulnerable to downgrade attacks in SMTP and IMAP, as
well as its caution that that any protocol with a STARTTLS operation
(which includes NBD) needs to be aware of the potential for downgrade
attacks.

The NBD protocol documentation already covers what is necessary to
avoid the effects of a downgrade attack, and all known implementations
of NBD servers and clients with working NBD_OPT_STARTTLS have at least
one mode where TLS is mandatory rather than opportunistic.  So I don't
see this as a CVE against the NBD protocol itself, so much as a worry
about the potential for future poor implementations that disregard the
documentation.

New file generated as part of the bison support in autotools

Our hand-written parser for /etc/nbdtab was buggy. Trying to fix it
seems like too much of an effort, and automatic stuff exists to do this
better -- so use those instead.

Closes: gh-119

We should really use something like bison/flex to do this, rather than
build our own parser, but that's for later.

Somehow, we only moved the parse pointer to the next field if there was
an unknown field. That is very very wrong...

Fix.

Closes: gh-118

Graham R. Cobb authored Feb 08, 2021 and Wouter Verhelst committed Feb 24, 2021

This patch adds support for using IPv4 addresses in the nbd-server auth file
even if the socket provides v6-mapped addresses. It extends the comparison
code in address_matches to handle the two cases where the auth file and the
socket use different address families.

This Fixes: gh-35.

Signed-off-by: Graham R. Cobb <g.nbd@cobb.uk.net>
[updated commit message to talk to github]
Signed-off-by: Wouter Verhelst <w@uter.be>

Closes: gh-91

Josh Triplett authored Jul 01, 2020 and Wouter Verhelst committed Oct 06, 2020

Add an option to skip negotiation. Add an option to specify the device
size, required if using preinit.

Josh Triplett authored Jul 01, 2020 and Wouter Verhelst committed Oct 06, 2020

This allows forcing the block device to be read-only even if the server
would allow writes.

This list is no longer maintained, while the repology badge that we show
is updated automatically.

Jonathan Liu authored Mar 15, 2020 and Wouter Verhelst committed Mar 17, 2020

The netmask line can fail to parse when passed to getaddrinfo if it
contains whitespace such as newline when using glibc 2.29 and later.
This results in clients being denied access even though their IP
address is listed in the authorization file.

Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Wouter Verhelst <w@uter.be>

"not available on this platform" is rather weird, and probably too narrow a
choice. "not enabled at compile time" might be slightly more useful, and
nbd-server uses that for STARTTLS when it was disabled currently.

This might be a good idea, so explicitly allow for it.

Vladimir Sementsov-Ogievskiy authored Feb 04, 2020 and Wouter Verhelst committed Feb 07, 2020

max-block restriction make sense for NBD_CMD_WRITE and NBD_CMD_READ to
avoid big data transfer and long io operations at server side.
NBD_CMD_WRITE_ZEROES still may be realized on server through direct
writing zeroes, which may lead to long operation and huge allocation
and should be restricted by max-block.
Same for NBD_CMD_CACHE: long operation / big allocation.

Still, NBD_CMD_TRIM, NBD_CMD_BLOCK_STATUS and NBD_CMD_WRITE_ZEROES with
NBD_CMD_FLAG_FAST_ZERO set are over-restricted by it. So, for better
performance, drop these restrictions.

Note, that Qemu nbd server already works accordingly to this patch: it
doesn't check the restriction for NBD_CMD_TRIM, NBD_CMD_BLOCK_STATUS
and NBD_CMD_WRITE_ZEROES.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>

Fix some issues reported by lintian

See merge request wouter/nbd!2

Fixes lintian: xc-package-type-in-debian-control
See https://lintian.debian.org/tags/xc-package-type-in-debian-control.html for more details.