similar to: [PATCH v2 nbdkit] tls: Implement Pre-Shared Keys (PSK)

This is ready for review but needs a bit more real-world testing before I'd be happy about it going upstream. It also needs tests. It does interoperate with qemu, at least in my limited tests. Rich.

On 06/25/2018 12:01 PM, Richard W.M. Jones wrote: > --- > docs/nbdkit.pod.in | 45 +++++++++-- > src/crypto.c | 234 +++++++++++++++++++++++++++++++++++++---------------- > src/internal.h | 1 + > src/main.c | 8 +- > 4 files changed, 210 insertions(+), 78 deletions(-) > > +Create a PSK file containing one or more C<username:key> pairs.

--- docs/nbdkit.pod.in | 45 +++++++++-- src/crypto.c | 234 +++++++++++++++++++++++++++++++++++++---------------- src/internal.h | 1 + src/main.c | 8 +- 4 files changed, 210 insertions(+), 78 deletions(-) diff --git a/docs/nbdkit.pod.in b/docs/nbdkit.pod.in index 42e6e6b..80d1ecd 100644 --- a/docs/nbdkit.pod.in +++ b/docs/nbdkit.pod.in @@ -11,7 +11,7 @@ nbdkit - A

On Thu, Jun 28, 2018 at 6:56 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > On Thu, Jun 28, 2018 at 10:18:25AM -0500, Eric Blake wrote: > > On 06/25/2018 12:01 PM, Richard W.M. Jones wrote: > > > --- > > > docs/nbdkit.pod.in | 45 +++++++++-- > > > src/crypto.c | 234 > +++++++++++++++++++++++++++++++++++++---------------- > > >

On Thu, Jun 28, 2018 at 10:18:25AM -0500, Eric Blake wrote: > On 06/25/2018 12:01 PM, Richard W.M. Jones wrote: > > --- > > docs/nbdkit.pod.in | 45 +++++++++-- > > src/crypto.c | 234 +++++++++++++++++++++++++++++++++++++---------------- > > src/internal.h | 1 + > > src/main.c | 8 +- > > 4 files changed, 210 insertions(+), 78

We're still seeing sporadic failures of 'nbdkit nbd tls=', and I'm still trying to come up with a root cause fix (it may involve smarter use of gnutls_bye() in libnbd). In the meantime, here's what we know: when the hang/failure happens, the 'nbdkit nbd tls=' client process is stuck in a poll() waiting to see EOF from the server, while the 'nbdkit example1'

libnbd-0.1.4-1 is now available in Fedora 29/30 updates testing. Diffs since v2 - rebase to master, bump from libnbd 0.1.2 to 0.1.3+, add tests to TLS usage which flushed out the need to turn relative pathnames into absolute, doc tweaks Now that the testsuite covers TLS and libnbd has been fixed to provide the things I found lacking when developing v2, I'm leaning towards pushing this on

Another series on top of my exportname filter, marking off another todo bullet point. With this, you can now use the NBD plugin as a transparent passthrough of all export names served by the remote server in both directions (list advertisement server to client, and export name from client to server). Eric Blake (3): nbd: Implement .default_export, .export_description nbd: Add

On 9/17/19 5:35 PM, Richard W.M. Jones wrote: > This neutral refactoring adds -DTLS_MODE. We can in future change the > requested TLS mode, but not in this commit. > > It also checks that nbd_get_tls_negotiated returns true after > connecting, when the requested mode was set to LIBNBD_TLS_REQUIRE. > --- > interop/Makefile.am | 4 ++++ > interop/interop.c | 26

On Thu, Mar 26, 2020 at 02:34:41PM -0500, Eric Blake wrote: > We're still seeing sporadic failures of 'nbdkit nbd tls=', and I'm > still trying to come up with a root cause fix (it may involve smarter > use of gnutls_bye() in libnbd). In the meantime, here's what we know: > when the hang/failure happens, the 'nbdkit nbd tls=' client process is > stuck in

Hi Andreas, I don''t know if the WRV200 is running freeswan or openswan. We use the newest US-version of the linksys firmware 1.0.32.2 from 2.5.2007. Another problem is in accessing the vpn-Gateway itself with ssh for instance, I get a freezing windows, whenever I tranfer more than just a few bytes. I can type my login-name and my password, then get a prompt ... but if I call,

Where qemu-img 4.0 used to say 'virtual size: 100M', the 4.1 release now says 'virtual size: 100 MiB'. Similarly, '5.0G' turned into '5 GiB'. But rather than worry about potential future changes to the human-readable output, we can just use --output=json (at which point we no longer even have to force qemu-img to the C locale). It might be slightly more robust to

Where qemu-img 4.0 used to say 'virtual size: 100M', the 4.1 release now says 'virtual size: 100 MiB'. Similarly, '5.0G' turned into '5 GiB'. Update expected test output to tolerate either version of qemu. Signed-off-by: Eric Blake <eblake@redhat.com> --- I already know I want to send a v2; on IRC, Rich pointed out that 'qemu-img info --output=json'

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 be improved if they actually checked for this

I fixed the deadlock - turned out to be an actual bug in the nbd plugin (see patch 8). I changed the command syntax so it's now: nbdkit nbd command=qemu arg=-f arg=qcow2 arg=/path/to/disk.qcow2 Nir wrote: 18:08 < nsoffer> rwmjones: regarding the nbd proxy patches, did you have specific flow that help us? 18:08 < nsoffer> rwmjones: or this is just a way to support qcow2 in the

Patch 1 played with an early draft of Rich's Fedora 30 libnbd package: https://bugzilla.redhat.com/show_bug.cgi?id=1713767#c17 Note that comment 21 provides a newer package 0.1.1-1 with a different API; and that libnbd has more unreleased API changes in the pipeline (whether that will be called 0.2 or 0.1.2); so we'll have to tweak things based on what is actually available in distros.

Previous discussion: https://www.redhat.com/archives/libguestfs/2019-August/msg00102.html Last night I experimentally added support for URIs that contain the query parameter tls-psk-file, as part of rewriting the tests to cover more of the URI code. So you can now have a URI like: nbds://alice@localhost/?tls-psk-file=keys.psk However there's an obvious security problem here because now

>>>>>> facing [ no shared cipher ] error with EC private keys. >>>>> the client connecting to your instance has to support ecdsa >>>>> >>>>> >>>> It does - Thunderbird 60.0b10 (64-bit) >>>> >>>> [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ] >>>> >>>> It seems there is

>>>> facing [ no shared cipher ] error with EC private keys. >>> the client connecting to your instance has to support ecdsa >>> >>> >> It does - Thunderbird 60.0b10 (64-bit) >> >> [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ] >> >> It seems there is a difference between the private key (rsa vs. ecc -> >>

v1 was here: https://listman.redhat.com/archives/libguestfs/2022-October/030216.html Since then, I've incorporated changes based on Rich's feedback: swap order of patches 2 and 3 less change in patch 1 (including no unsafe eval(%s) for --uri) in patch 2, include -c in list of snippets to store, and use dict of lambdas to map back to the desired action Eric Blake (3): nbdsh: