search for: tls_allow

...not available or if the > - * handshake fails. > - */ > +#if TLS > if (nbd_supports_tls (nbd) != 1) { > fprintf (stderr, "skip: compiled without TLS support\n"); > exit (77); > } This skips the test if we are compiled without TLS support, even if TLS_ALLOW was requested. What behavior do we really want there? Is TLS_ALLOW unconditionally falling back to plaintext okay, or do we only want to permit TLS_ALLOW if TLS support is at least plausible? Otherwise, the series is fine. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-9...

...ude \ > + -DSERVER=\"$(NBDKIT)\" \ > + -DSERVER_PARAMS='"--tls=require", "--tls-certificates=../tests/pki", "-s", "--exit-with-parent", "file", tmpfile' \ Is it worth testing nbdkit's --tls=yes (the counterpart to libnbd TLS_ALLOW), to show that a server that permits but does not require encryption can accept a plaintext client? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

.../src/libguestfs.org/libnbd/libnbd_120_set_non_defaults_test.go +++ b/golang/src/libguestfs.org/libnbd/libnbd_120_set_non_defaults_test.go @@ -64,7 +64,7 @@ func Test120SetNonDefaults(t *testing.T) { if err != nil { t.Fatalf("could not get tls state: %s", err) } - if tls != uint(TLS_ALLOW) { + if tls != TLS_ALLOW { t.Fatalf("unexpected tls state") } } -- 2.28.0

I was a little surprised to find that LIBNBD_TLS_ALLOW worked out of the box, so I had to examine the logs whereupon I saw the magic message ... libnbd: debug: nbd1: nbd_connect_command: server refused TLS (policy), continuing with unencrypted connection I don't believe this path has ever been tested before. It's possible the tests could b...

Natural fallout after my recent testsuite additions that fixed a couple of ocaml bugs in the setters. However, on at least the OCaml code, I'm not sure what we should do if a newer libnbd ever returns a bit that an older NBD.mli was not expecting at the time the OCaml compiler ran (see below). I'm also not sure if there is a more efficient way to avoid outputting Val_FOO() converters for

Well, the golang changes (patch 1 and 2/3 of v1) were already committed, all that was left was the OCaml changes. I'm a lot happier with how things turned out with an UNKNOWN constructor in the OCaml variants. Eric Blake (3): tests: Enhance coverage of enum/flag range checking ocaml: Support unknown values for Enum/Flags ocaml: Typesafe returns for REnum/RFlags generator/OCaml.ml