Open
Conversation
The tls code is now logging the connectins in `connect_info()` just like PlainListener and the coming VsockListener. This way the code becomes more symmetrical.
Our TlsListener::new() code was syncronous - so slow clients could stall/block the server. This commit adds a new AsyncTlsListener that avoids this problem by using tokio::spawn() and a `mpsc` (multi-producer, single-consume) channel. This is very similar to the `tls-listener` crate but that does not implement the axum `serve::Listener` trait so using it is a bit cumbersome and its not much code that we add here.
No need to specify the default for --bind in the unit file. Its already the default so it is redundant.
This commit adds support to use the vsock protocol instead of
tcp. This allows us to run the bridge in VMs even if there is
no networking (yet). Both socket actviation and --bind options
are supported.
Usage examples for the server:
```
$ varlink-httpd --bind=vsock --insecure
varlink-httpd --bind=vsock::5000 --insecure
```
Client examples:
```
$ varlinkctl-http call vsock://3:5000/io.systemd.Hostname/Describe '{}'
```
Because vsock is just a transport we need to provide mTLS auth there too. Its a bit silly to encrypt the traffic over vsock as its not snifable but the mTLS certs are useful and it would be strange to not support all auth methods over all transports.
With rust-vsock/tokio-vsock#72 being merged we can remove the unsafe block and use the From<OwnedFd> in the vsock listener code.
keszybz
requested changes
Apr 15, 2026
|
|
||
| # SSH authorized keys (see systemd.system-credentials(7)) | ||
| ImportCredential=ssh.authorized_keys.root | ||
| ImportCredential=ssh.ephemeral-authorized_keys-all |
Member
There was a problem hiding this comment.
We could add some hardening options here. I guess this needs to run as run, so the effect will be limited, but it'd still be better than nothing.
| # This file is part of varlink-http-bridge. | ||
|
|
||
| [Unit] | ||
| Description=Varlink HTTP Bridge (vsock) |
Member
There was a problem hiding this comment.
So maybe I'm misunderstanding something, but why not have a single .service unit with one or more sockets that are enabled/disabled independently? In other words, I don't think a new service file is needed.
Comment on lines
+1131
to
+1132
| --bind=ADDR address to bind to (default: 0.0.0.0:{DEFAULT_PORT}) | ||
| use vsock::PORT for vsock (e.g. vsock::{DEFAULT_PORT}) |
Member
There was a problem hiding this comment.
I guess we'd need to allow more than one address here. But in practice this is going to be needed anyway, e.g. to bind to a specific IPv4 and IPv6 addresses.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
[build on top of https://github.com//pull/29]
This PR adds vsock support for the varlink-http-bridge. from the user PoV it looks like this:
Inside the vm (there is also a default data/varlink-httpd-vsock.socket so this can start automaticall):
$ varlink-httpd --bind=vsock --authorized-keys=~/.ssh/authorized_keysAnd on the host (assume the right ssh keys are available):
$ varlinkctl call vsock://3/ws/sockets/io.systemd.Hostname iio.systemd.Hostname.Describe '{}'