[th/wireguard-pt3 (v2)] #295
Merged
Conversation
This file contains 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
lkundrak
force-pushed
the
th/wireguard-pt3
branch
8 times, most recently
from
c697299
to
896b171
Compare
bengal
reviewed
Feb 11, 2019
lkundrak
force-pushed
the
th/wireguard-pt3
branch
5 times, most recently
from
ff66c2b
to
e7709d9
Compare
thom311
force-pushed
the
th/wireguard-pt3
branch
from
e7709d9
to
aaf7fb3
Compare
lkundrak
force-pushed
the
th/wireguard-pt3
branch
from
aaf7fb3
to
cdf47b1
Compare
thom311
force-pushed
the
th/wireguard-pt3
branch
from
cdf47b1
to
dc1baa8
Compare
lkundrak
force-pushed
the
th/wireguard-pt3
branch
from
dc1baa8
to
489a6ab
Compare
|
Change in binary size when building with on x64_86, Fedora 29 commit 9a4cd1e (before) vs 489a6ab (after): |
lkundrak
force-pushed
the
th/wireguard-pt3
branch
5 times, most recently
from
ef55e09
to
c674633
Compare
For now only add the core settings, no peers' data. To support peers and the allowed-ips of the peers is more complicated and will be done later. It's more complicated because these are nested lists (allowed-ips) inside a list (peers). That is quite unusual and to conveniently support that in D-Bus API, in keyfile format, in libnm, and nmcli, is a effort. Also, it's further complicated by the fact that each peer has a secret (the preshared-key). Thus we probably need secret flags for each peer, which is a novelty as well (until now we require a fixed set of secrets per profile that is well known).
…rd profile Use the script to test how GObject introspection with libnm's WireGuard support works. Also, since support for WireGuard peers is not yet implemented in nmcli (or other clients), this script is rather useful.
Configuring peers (and allowed-ips of the peers) is not yet supported.
That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
|
Thanks @fgiudici. Addresses your comments and repushed. |
thom311
force-pushed
the
th/wireguard-pt3
branch
from
c674633
to
6d5aa85
Compare
|
LGTM |
thom311
added a commit
that referenced
this pull request
Feb 22, 2019
|
Thanks!! merged. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This resurrects the work from #281 and is based on #293.
I think this is ready to merged. A few things are still missing. They are documented in
TODOcomments insrc/devices/nm-device-wireguard.c. But these things should not block this branch. And I don't even think they would block a1.16.0release (with this branch in).Please test and review. Thanks