[07:21] <luis220413> amurray: Are you there?
[08:00] <luis220413> Is anyone from the Ubuntu Security Team here'
[08:00] <luis220413> Is anyone from the Ubuntu Security Team here?
[08:02] <ebarretto> luis220413, yes
[08:03] <luis220413> ebarretto: I have completed testing for my updates in bug 1986627 (regression: incomplete fix for CVE-2020-11653) and bug 1982670. Alex Murray said he would look today in the morning but it is already 17:33 in his timezone.
[08:03] <ubottu> Bug 1986627 in varnish (Ubuntu) "Incomplete fix for CVE-2020-11653" [Undecided, Confirmed] https://launchpad.net/bugs/1986627
[08:03] <ubottu> Bug 1982670 in jupyter-notebook (Debian) "Multiple vulnerabilities in Bionic, Focal, Jammy and Kinetic" [Unknown, Confirmed] https://launchpad.net/bugs/1982670
[08:03] <ubottu> An issue was discovered in Varnish Cache before 6.0.6 LTS, 6.1.x and 6.2.x before 6.2.3, and 6.3.x before 6.3.2. It occurs when communication with a TLS termination proxy uses PROXY version 2. There can be an assertion failure and daemon restart, which causes a performance loss. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11653>
[08:03] <ebarretto> we already have someone looking at the varnish issue 
[08:04] <ebarretto> jupyter-notebook we will get to it when we get to it, it is already queued up, please be patient 
[08:16] <luis220413> ebarretto: What are the priorities of the Ubuntu Security Team now?
[08:18] <ebarretto> luis220413, we do way more than security patching. Everyone in the team is busy doing something.
[08:24] <luis220413> ebarretto: On Friday I requested two CVE status changes. I will repeat them but with an explanation.
[08:25] <luis220413> Can you set the status of CVE-2022-38150 for trusty/esm to not-affected (code not present) because it only affects Varnish >= 7.0, and of CVE-2021-32798 for jammy to not-affected (6.4.8-2) because this version includes the fix made upstream?
[08:25] <ubottu> In Varnish Cache 7.0.0, 7.0.1, 7.0.2, and 7.1.0, it is possible to cause the Varnish Server to assert and automatically restart through forged HTTP/1 backend responses. An attack uses a crafted reason phrase of the backend response status line. This is fixed in 7.0.3 and 7.1.1. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38150>
[08:25] <ubottu> The Jupyter notebook is a web-based notebook environment for interactive computing. In affected versions untrusted notebook can execute code on load. Jupyter Notebook uses a deprecated version of Google Caja to sanitize user inputs. A public Caja bypass can be used to trigger an XSS when a victim opens a malicious ipynb document in Jupyter Notebook. The XSS allows an attacker t... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32798>
[08:30] <ebarretto> done, thanks 
[08:38] <luis220413> ebarretto: Thanks for the status changes!
[08:41] <luis220413> What are your priority public updates right now and what else you do besides security patching and MIR review?
[08:45] <luis220413> By "you" and "your" I mean the Ubuntu Security Team.
[08:59] <ebarretto> we do security reviews for other teams, apparmor development, snap reviews, certifications (fips, cis, stig), oval generation, cve triage, bug triage, improve our own infrastructure, deal with issues from cloud customers and lots of other tasks
[09:07] <luis220413> Thanks! What public updates do you have in the queue?
[09:19] <ebarretto> that's not the kind of information we advertise. Keep an eye on USNs and you will know what we were working on for Ubuntu releases 
[11:17] <mitya57> Hi! Can someone please take a look at my proposed debdiff for jammy-security in bug 1981807 (comment #13)?
[11:17] <ubottu> Bug 1981807 in qtbase-opensource-src (Ubuntu Jammy) "qt5-network openssl3 armhf does not support tls1.3" [Undecided, Confirmed] https://launchpad.net/bugs/1981807
[11:45] <luis220413> mitya57: I will take a look. Can you update the debdiff to fix these CVEs? https://ubuntu.com/security/cves?q=&package=qtbase-opensource-src&priority=&version=jammy&status=
[11:51] <mitya57> luis220413: jammy package already has debian/patches/CVE-2021-38593.diff and debian/patches/CVE-2022-25255.diff
[11:51] <ubottu> Qt 5.x before 5.15.6 and 6.x through 6.1.2 has an out-of-bounds write in QOutlineMapper::convertPath (called from QRasterPaintEngine::fill and QPaintEngineEx::stroke). <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38593>
[11:51] <ubottu> In Qt 5.9.x through 5.15.x before 5.15.9 and 6.x before 6.2.4 on Linux and UNIX, QProcess could execute a binary from the current working directory when not found in the PATH. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25255>
[11:55] <luis220413> The binary packages built from this source package have 2096 reverse dependencies.
[11:56] <luis220413> in Ubuntu 22.04 amd64
[11:56] <teward> luis220413: fwiw you are not Security team
[11:56] <teward> mitya57: ^^
[11:56] <teward> ebarretto: because i was poking you earlier - see above
[11:57] <teward> i also am interested because Qt is used by Lubuntu so it's on my radar as well now
[11:57] <mitya57> teward: ok, thanks
[11:57] <teward> i'm not security team either ;)
[11:57] <mitya57> :))
[11:58] <teward> luis220413: yes, Qt is a huge library set.  no TLS1.3 support sounds like it's  just a no change rebuild + patches, but i'll wait for ebarretto or amurray to confirm that for me
[11:58] <teward> (we had the same issue for NGINX with no TLS 1.3 support right when OpenSSL landed with it, a no chnage rebuild against the latest libssl in the repo at the time fixed that chaos)
[11:58] <teward> (but that wasn'ta sec issue)
[11:59] <mitya57> No rebuilds of reverse dependencies are needed. Just a fix in qtbase.
[11:59] <teward> yep, but then a hard watch on all the autopkgtests to make sure it doesn't explode
[11:59] <teward> cc tsimonq2 in case youre bored ^^
[12:00] <teward> (because Lubuntu)
[12:01] <ebarretto> yes, that's more likely a bug fix that should go through SRU, it could go to the security pocket if we deem it worth it
[12:08] <teward> ebarretto: i'll handle that then, because it's on the Lubuntu radar (aka mine)
[12:08] <teward> luis220413: ^^ since i can get this into the SRU process a bit faster ;)
[12:09] <teward> cc also mitya57 because
[12:09] <tsimonq2> I'm curious, why?
[12:09] <teward> tsimonq2: tls1.3 is good?
[12:09] <teward> in case you're bored on the other stack of crap you ahve you might want to do an SRU ;)
[12:09] <teward> (qtbase affects our stuff too)
[12:09] <tsimonq2> (Why originally treat as an SRU?)
[12:10] <teward> that's an ebarretto question ;)
[12:10] <mitya57> I can do the SRU myself as well.
[12:10] <teward> mitya57: oh, well then have fun :)
[12:11] <teward> i'mma go back to stabbing Windows (which is evil) at FT job.  >.<
[12:11] <teward> (can anyone say with me, "Microsoft Exchange Sucks [CENSORED]"?
[12:11] <teward> )
[12:12] <tsimonq2> <teward> "cc Simon Quigley in case youre..." <- I'm very rarely bored these days unfortunately... but if you ping me here I make time ;)
[12:16] <luis220413> mitya57, teward: I only mentioned reverse dependencies to show the importance of this source package.
[12:16] <teward> luis220413: helpful hint again from a seasoned dev: rdeps alone don't determine the importance of the package for an update/sru/etc.
[12:16] <teward> there's a ton of other factors
[12:17] <teward> rdeps also can be a *hindrance* if we're doing an update that would break the entire stack;)
[12:17] <luis220413> teward: I know. Examples are actual usage, being seeded in Ubuntu flavors, and so on.
[12:19] <ebarretto> tsimonq2, it might go through the security pocket as I mentioned, it will depend on who reviews it more deeply, but I didn't review it, just glanced over the bug
=== ChanServ changed the topic of #ubuntu-security to: Twitter: @ubuntu_sec || https://usn.ubuntu.com || https://wiki.ubuntu.com/SecurityTeam || https://wiki.ubuntu.com/Security/Features || Community: sbeattie
[12:30] <tsimonq2> Ah, no worries then
[12:30] <tsimonq2> Not my first universe security update, I'll take a look at this either before or after $dayjob, but today. Expect pings before EOD US time :)
[12:51] <luis220413> ebarretto: Can you explain why CVE-2022-30067 was rated as low?
[12:51] <ubottu> GIMP 2.10.30 and 2.99.10 are vulnerable to Buffer Overflow. Through a crafted XCF file, the program will allocate for a huge amount of memory, resulting in insufficient memory or program crash. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30067>
[12:54] <ebarretto> luis220413, probably Steve set this as low because you need to have a crafted xcf file from an untrusted source and this will only cause a crash in the program
[12:55] <ebarretto> sorry but I am quite busy with other stuff right now and won't do much investigation 
[12:56] <luis220413> OK. But deeper investigation is needed and will be done at another time.
[12:56] <luis220413> OK. But deeper investigation is needed and will be done later.
[12:57] <ebarretto> not by me, I trust my colleagues choice and if you think it otherwise then you should give us your reasoning. Do not that priority and severity are two different things 
[12:57] <ebarretto> note*
[13:07] <luis220413> ebarretto: Can you mark qtbase-opensource-src in jammy as not vulnerable to CVE-2021-38593 and CVE-2022-25255 due to the message by mitya57?
[13:07] <ubottu> Qt 5.x before 5.15.6 and 6.x through 6.1.2 has an out-of-bounds write in QOutlineMapper::convertPath (called from QRasterPaintEngine::fill and QPaintEngineEx::stroke). <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38593>
[13:07] <ubottu> In Qt 5.9.x through 5.15.x before 5.15.9 and 6.x before 6.2.4 on Linux and UNIX, QProcess could execute a binary from the current working directory when not found in the PATH. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25255>
[13:09] <luis220413> Can anyone else patch these CVEs for Focal? https://ubuntu.com/security/cves?q=&package=qtbase-opensource-src&priority=&version=focal&status=
[13:09] <luis220413> mitya57: Does your bug affect Ubuntu 18.04 or 20.04 on any architecture? (qtbase-opensource-src is in main in Ubuntu 18.04.)
[13:10] <luis220413> I will return in 45 minutes but remain online.
[13:13] <mitya57> luis220413: It doesn't, because it happens only with openssl 3.
[14:02] <luis220413> I am back.
[14:56] <luis220413> I will return in 10 minutes but remain online.
[15:06] <luis220413> I am back.
[15:14] <luis220413> teward: Are autopkgtests run automatically for stable releases?
[15:27] <luis220413> tsimonq2: What security updates have you made to packages in the universe component?
[15:36] <teward> luis220413: i would avoid bugging tsimonq2 on anything non urgent
[15:37] <teward> for reasons I'm not at liberty to disclose
[15:37] <teward> as for 'stablereleases' yes autopkgtests still trigger for those updates, it's how additional regression testing happens.
[15:37] <teward> but that's not a security related question here ;)
[15:38] <teward> i also strongly suggest you dial back the amount of pings you send people here, i tend to notice you like to ping people **a lot** - a lot more than you probably should be doing.
[15:49] <trench> luis220413: we don't care if you are away ..
[17:08] <luis220413> OK
[17:10] <luis220413> teward: I always ping to send replies, but others do not do so in most or all replies. From now on, I will not ping when not appropriate in a reply, by modifying the nick of the target user (for example, "t_eward: ...").
[17:29] <tsimonq2> luis220413: Why do you need to know how many security updates I've done when a) the number is more than 5 and b) as a core developer in the Ubuntu project I'm stepping up and volunteering to do work that will benefit everyone. All that question does is create FUD
[17:31] <tsimonq2> Anyway, besides dealing with that, I'll hop on this later tonight and at least get something pushed to Bileto or similar by US EOD, if mitya57 hasn't already beat me to the punch (which he often does nowadays, thanks!! :) )
[17:38] <Eickmeyer[m]> luis220413: Once again, I need to remind you that Ubuntu is a meritocracy, and here you are, questioning the qualifications of seasoned developers and their contributions within the project when you haven't been contributing for very long and have been acting in a very demanding and outright rude manner toward those who have.
[17:38] <Eickmeyer[m]> luis220413: This is your final warning to stop this behavior before I go to the rest of the Ubuntu Community Council to recommend you be banned from contributing to Ubuntu. Do I make myself clear?
[17:40] <luis220413> tsimonq2: I did not expect that my question will create FUD. I would happily say that I have done 8.
[17:40] <luis220413> Anyway, thanks for your security updates for stable releases!
[17:43] <teward> ebarretto: can i borrow your hammer please?
[17:43] <tsimonq2> Keep on flexing dude, you're already on thin ice, there's nothing more I can say or do here :)
[17:43] <teward> for two reasons.
[17:44] <luis220413> Eickmeyer[m]: Yes.
[17:44] <luis220413> I will prepare the qtbase-opensource-src security update for Ubuntu 20.04.
[17:45] <luis220413> in this week
[17:49] <tsimonq2> Nope, sorry, someone already volunteered. There's plenty else to do, the Ubuntu Qt Team has this one under control.
[18:00] <luis220413> ebarretto: Can you mark CVE-2021-38593 for qtbase-opensource-src in Focal as released (5.12.8+dfsg-0ubuntu2.1)?
[18:00] <ubottu> Qt 5.x before 5.15.6 and 6.x through 6.1.2 has an out-of-bounds write in QOutlineMapper::convertPath (called from QRasterPaintEngine::fill and QPaintEngineEx::stroke). <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38593>
[18:00] <luis220413> s/mark/set the status of/
[18:02] <luis220413> s/as released/to released/
[18:31] <luis220413> Bug 1987336
[18:31] <ubottu> Bug 1987336 in qtbase-opensource-src (Ubuntu) "Multiple vulnerabilities in Focal" [Undecided, New] https://launchpad.net/bugs/1987336
[18:34] <mitya57> tsimonq2: I have just uploaded the SRU :)
[18:35] <tsimonq2> >:D
[18:35] <tsimonq2> Thank you!!!!!!!!!
[18:44] <ahasenack> sarnold: hm, I tried using netplan to configure wireguard, but that didn't work: https://discourse.ubuntu.com/t/netplan-with-wireguard/30168
[18:45] <ahasenack> found a related bug in systemd-networkd, apparently fixed, but unclear if it needs an extra configuration (that netplan isn't doing) out of the box or not
[18:45] <sarnold> hey! an html anchor to the netplan docs! i've wanted those for ages
[18:45] <ahasenack> I had to "view source" to find it...
[18:45] <ahasenack> I was dearly hoping there would be one
[18:46] <sarnold> well, dang, it's still not the granularity I was hoping for -- eg the `key` a bit lower down doesn't appear to have an anchor point :( oh well..
[18:46] <ahasenack> the systemd docs say an extra route section is needed
[18:46] <ahasenack> let me update my post with links to that
[18:46] <sarnold> alright, back to netplan / wireguard, hehe
[18:48] <ahasenack> updated
[18:48] <ahasenack> I'm about to file a bug with netplan
[18:49] <ahasenack> now that I collected it all together in a post, it looks more and more like a bug
[18:49] <ahasenack> or unsupported feature
[18:49] <ahasenack> thing is, I can't even easily add the route myself in the .network file, because netplan would just rewrite it
[18:49] <ahasenack> so it would have to be something external
[18:52] <sarnold> oh my goodness this systemd issue gets complex
[18:52] <ahasenack> in systemd, what doesn't :)
[18:52] <ahasenack> I still can't figure out dns resolver
[18:52] <ahasenack> sometimes it works as I think it should, sometimes it surprises me
[18:52] <sarnold> wireguard seems simple, maybe even too simple, when you're configuring it via ip and wireguard commands, but translating all that into netplan configs to translate into systemd configs that then get executed .. oof
[18:53] <ahasenack> personally I have decided against netplan for wireguard, mainly because "netplan apply" disrupts everything
[18:53] <ahasenack> not just the wg interface
[18:53] <sarnold> never mind that I never got the hang of the multiple routing tables business
[18:53] <ahasenack> at this point I'm considering not documenting netplan + wireguard, for now
[18:53] <ahasenack> maybe just point at it, but "beware dragons"
[18:54] <sarnold> hmm. I can appreciate trying to leave breadcrumbs behind for the adventurous folks who want to try it out; but my experience with the apparmor wiki, which documents *lots* of things that don't yet exist, is that people *will* find it, they *will* try it, and they *will* ask for help and file bug reports when it doesn't work perfectly
[18:55] <ahasenack> true
[18:56] <ahasenack> right now this isn't working out of the box, at least not for me
[18:56] <ahasenack> let me just add the missing route manually, see if that is the only thing missing
[18:56]  * ahasenack goes to this cheat sheet about ip route commands
[18:57] <ahasenack> root@laptop-coffee-shop:~# telnet 10.10.10.90 22
[18:57] <ahasenack> Trying 10.10.10.90...
[18:57] <ahasenack> Connected to 10.10.10.90.
[18:57] <ahasenack> Escape character is '^]'.
[18:57] <ahasenack> SSH-2.0-OpenSSH_8.9p1 Ubuntu-3
[18:57] <ahasenack> ok, worked
[18:57] <ahasenack> had to add `ip route add 10.10.10.0/24 via 10.10.11.2`
[18:58] <ahasenack> I'm on the "wireguard on the router" part of https://gist.github.com/panlinux/2bc62c10799284590e577de0640d2767
[18:58] <ahasenack> (diagram-wise)
[18:59] <sarnold> heh, I'm glad I'm not hte only one who needs the cheetsheets :) if it requires more than ip a ; ip l ; ip r   .. then help is required :)
[18:59] <ahasenack> "ip a show dev <nic>" is my strongest ip-foo that I know from memory
[18:59] <ahasenack> I also like "ip get route <ip>"
[18:59] <ahasenack> that's very handy
[19:00] <ahasenack> er, ip route get
[19:00]  * ahasenack blushes
[19:00] <sarnold> ahh, see, I never know the name of my nics any more ;( so it's hard to be confident there. ip route get <ip> is my headliner :)
[19:05] <ahasenack> well, without tab-complete, I wouldn't know either :)
[19:06] <sarnold> oh hey!
[19:14] <sdeziel> ahasenack: out of curiosity, howdid you end up with a wg0 MTU of 1378? The default is supposed to be 1420 IIRC
[19:14] <sdeziel> pppoe should shave 8 bytes but still ;)
[19:15] <ahasenack> I didn't mess with any of that
[19:15] <ahasenack> where did you see that again?
[19:15] <sdeziel> interesting, so that might suggest PMTU going on.
[19:15] <ahasenack> I just checked `ip a` and the mtu on the home0 wg interface is 1420
[19:16] <ahasenack> pmtu is working? *gasp*
[19:16] <sdeziel> https://gist.github.com/panlinux/2bc62c10799284590e577de0640d2767#testing has "ip link set mtu 1378 up dev wg0"
[19:16] <ahasenack> hmmm
[19:16] <ahasenack> wg-quick?
[19:16] <ahasenack> indeed
[19:16] <ahasenack> my other endpoing, which I brought up using wg-quickj, has an mtu of 1378
[19:17] <ahasenack> the one I brought up using netplan (via systemd-networkd), has an mtu of 1420
[19:18] <sdeziel> I use the systemd instance template (`wg-quick@%i`) and for those, the `[Interface]` section has to have a `MTU = XYZ` to no inherit the 1420 default
[19:18] <sarnold> hmm why do you need to change it?
[19:19] <ahasenack> sdeziel: tjat
[19:19] <ahasenack> sdeziel: that's what I have at the other endpoint
[19:19] <sdeziel> ahasenack: OK, so no PMTU ;)
[19:19] <ahasenack> sdeziel: https://pastebin.ubuntu.com/p/xtPkB7mVr2/
[19:20] <sdeziel> sarnold: I usually tweak it to 1440 when I'm 100% sure I won't tunnel stuff over IPv6
[19:20] <ahasenack> just the normal privatekey, listenport, address in [Interface]
[19:20] <ahasenack> btw, via netplan/systemd one does not have the hooks options, afaik
[19:21] <ahasenack> PostUp and stuff
[19:21] <sdeziel> ahasenack: hmm, maybe your default route has a lower MTU itself?
[19:21] <ahasenack> oh, its nic does have a lower mtuy
[19:21] <ahasenack> mtu
[19:21] <ahasenack> 1458
[19:21] <ahasenack> it's an openstack vm
[19:22] <ahasenack> ¯\_(ツ)_/¯
[19:22] <sdeziel> ahasenack: probably vxlan or geneve eating some MTU away
[19:23] <ahasenack> ok, well, no netplan for wireguard for now
[19:24] <sarnold> thanks for giving it a *really* good shot :)
[19:25] <ahasenack> I kept the text I wrote
[19:25] <Unit193> sarnold: But the systemd template is so easy. :3
[19:26] <ahasenack> https://gist.github.com/panlinux/49444e54ab109fe8399912a43553e105 is where I stopepd
[19:26] <ahasenack> Unit193: yeah, it is
[19:26] <ahasenack> I struggled to find a scenario where someone wouldn't use it
[19:26] <sarnold> Unit193: you mean the wg-quick@ thingy?
[19:27] <ahasenack> just wrote "if for some reason you cannot install wireguard-tools, or don't want to, then  you can ...."
[19:27] <ahasenack> I do see this flexibility a nice point in favor of wireguard, though
[19:27] <ahasenack> not that netplan or systemd-networkd are better, but just the fact you *could* use them, is something nice to have, and in favor of the design I think
[19:28] <sarnold> yeah,it's just too bad it's not there yet
[19:28] <ahasenack> I could try network-manager next
[19:29] <ahasenack> let's see how it is in jammy
[19:33] <ahasenack> hm, the integration isn't super nice, it doesn't show up in the top right network menu as one interface to activate or deactivate
[19:33] <ahasenack> presumably it can only be driven via the nm cli
[19:44] <Unit193> It shows up as a VPN option.
[19:44] <ahasenack> I don't see it
[19:44] <ahasenack> maybe I'm missing a package?
[19:44] <ahasenack> I had to use nm-connection-editor
[19:45] <ahasenack> then I deactivated it with nmcli 
[19:45] <ahasenack> and now it doesn't show up in the nmcli devices list anymore, but is still in nm-connection-editor
[19:46] <ahasenack> it doesn't look like it's saving the private key
[19:47] <ahasenack> but yeah, I don't see it in the network menu on the top right of gnome-shell desktop
[19:54] <Unit193> I use network-manager-gnome.
[19:54] <ahasenack> yeah, it's what I have. Do you see the wireguard connection in the top right menu, that one that shows the network status?
[19:55] <ahasenack> I see wired, wifi, openvpn, and bluetooth
[20:00] <Unit193> I specifically wanted to hide it, as it had the VPN locked icon when I use that VPN for vLAN instead.
[20:00] <Unit193> But it had the lock icon when activated and it was in the VPN submenu of the tray icon.
[20:02] <ahasenack> Unit193: which ubuntu release?
[20:03] <Unit193> It's Xfce, I didn't know GNOME still used network-manager-gnome even.
[20:03] <ahasenack> ah, well, we are comparing different things then
[20:05] <Unit193> A bit, but nm does have it, and -gnome does expose it.  Weird that GNOME doesn't.
[20:19] <ahasenack> Unit193: what's the best practice to add another peer to an existing config without disrupting the existing connections? Write a config snippet with just the new [Peer] section, and use wg addconf, and then wg syncconf to merge it back to the main config?
[20:19] <ahasenack> or just update the main config with the new [Peer] and run wg setconf?
[20:19] <ahasenack> or something else?
[20:30] <Unit193> ahasenack: I'd do it just by adding it to the main config and systemctl reload wg-quick@wg0
[20:33] <ahasenack> I just tested:
[20:33] <ahasenack> a) add the new [Peer] to the wg0.conf file
[20:33] <ahasenack> b) run wg-quick strip wgnet0
[20:33] <ahasenack> well, wg0
[20:33] <ahasenack> that shows the new peer
[20:33] <ahasenack> and then maybe some wg command to set it on the interface, live
[20:33] <Unit193> ExecReload=/bin/bash -c 'exec /usr/bin/wg syncconf %i <(exec /usr/bin/wg-quick strip %i)'
[20:34] <ahasenack> ah, reload does that already
[20:34] <Unit193> Yes, that's why I said just reload. :>
[20:35] <Unit193> I poked zx2c4 about adding that a while ago.
[20:35] <ahasenack> and here I was doubting it would all work out of the box
[20:35] <ahasenack> nice packaging
[20:35] <sarnold> :D
[20:36] <ahasenack> cool, I had `watch wg` running elsewhere, and the reload action added the new peer
[20:37] <ahasenack> and the existing one still shows "latest handshake" about 48min ago, so it wasn't disrupted
[20:37] <Unit193> The goal is kinda to make it easy enough anyone can use it.  Looking at WireGuard and OpenVPN, the former is seemingly faster and seems easier to me, so why not? :3
[20:37] <Unit193> I know an IRC network that links it's servers over WireGuard, sooo...there's that.
[20:37] <ahasenack> indeed, nobody likes netsplits
[20:38] <Unit193> sarnold: No, not Libera either. :P
[20:39] <sarnold> hehe, I was going through that in my mind .. "on the one hand it's pretty cool, on the other hand, that's a lot of host keys to juggle"
[20:39] <Unit193> You say that as if the TLS certs aren't already that.
[20:41] <sarnold> "let acme sort it out"
[20:43] <ahasenack> what one could say is annoying is that the key has no metadata associated with it, at all
[20:43] <ahasenack> so unless you organize yourself, just inspecting the key won't tell you who it belongs to
[20:43] <ahasenack> which can be a plus too
[20:43] <Unit193> Yeah, adding an alias in the config for it to show in `wg` output would be nice.
[20:44] <ahasenack> compounded with the fact that you don't use files for the keys in the config
[20:44] <ahasenack> just the content itself
[20:44] <ahasenack> yeah, a Description= or Name= field in the config
[20:44] <ahasenack> which, if present, would be shown in the wg output
[20:45] <sarnold> sticking keys in the config feels pretty dangerous imho; people pastebin configs *all the time* and remembering to strip out the keys first is asking for trouble
[20:45] <sarnold> or throw configs in git..
[20:46] <Unit193> wg | grep -c peer: → 11 :(
[20:46] <sarnold> wow :)
[20:47] <ahasenack> Unit193: I was just reminded in #wireguard that the systemd reload action won't create any routes, for example, like wg-quick would when bringing the interface up from scratch
[20:48] <ahasenack> Unit193: yeah, good point, I'll add that to the doc
[20:48] <Unit193> Good point?  What point?
[20:49] <ahasenack> about the private key being in the config file, and people pasting the config thinking it has only config, not secrets
[20:49] <Unit193> And yeah that's noteworthy indeed.  I wouldn't say I'm a WireGuard expert, btw.  I only use it.
[20:49] <Unit193> ...If I can take credit for sarnold's ideas, I'm going to look *so* much smarter very quickly. :D
[20:50] <sarnold> only if I can offload the doozies, too!
[20:50] <ahasenack> oops, true
[20:50] <ahasenack> sorry sarnold 
[20:53] <sdeziel> ahasenack: re private keys in config files, I instead do: `PostUp = wg set %i private-key /etc/wireguard/%i.key` and the .key file is root accessible only
[20:54] <ahasenack> good point, I've seen that in some config examples
[20:54] <sdeziel> that still leaves PresharedKey directly under each [Peer] though...
[20:55] <ahasenack> the same trick doesn't apply?
[20:55] <ahasenack> [preshared-key <file path>]
[20:55] <ahasenack> looks like it can be uset with "wg set" too, same command line, just one more parameter?
[20:55] <sdeziel> you can possibly load it but then it's harder because you don't have the `%i` trick
[20:56] <ahasenack> ah, it's under a peer
[20:56] <ahasenack> ofc
[20:56] <sdeziel> yeah :/
[20:58] <ahasenack> and `wg showconf <interface>` strips out the wg-quick bits (it doesn't know about them)
[20:59] <ahasenack> this overloading of wg and wg-quick configs is a bit odd
[20:59] <ahasenack> s/overloading/mixing up/
[21:01] <sarnold> it certainly confuses me, heh
[21:02] <ahasenack> it's what allowed all these other tools to exist
[21:02] <ahasenack> wg-quick does what systemd-networkd does, netplan, network-manager, cloud-init even
[21:02] <Unit193> ifupdown!
[21:02] <ahasenack> actually, I don't know what tool cloud-init does, I doubt it interacts directly with the kernel
[21:02] <ahasenack> hehe
[21:02] <ahasenack> oh yeah, debian
[21:03] <ahasenack> just checked, cloud-init is relying on wg-quick@<if>
[21:04] <sarnold> ifupdown2!
[21:04] <ahasenack> and just saw something we could make better: https://github.com/canonical/cloud-init/pull/1570/files#diff-2bd8283d4911d29b15ad597ad65cf85e585b9ff285df6b766d0708fad8d8d4acR42
[21:04] <ubottu> Pull 1570 in canonical/cloud-init "Feature: Wireguard" [Merged]
[21:04] <ahasenack> they are sayhing to install resolvconf, but we can use resolvectl in postup hooks