<andi->
tokudan: I just merged it... It feels so wrong having to merge my own PRs :/
<tokudan>
yeah, i know that feeling in other projects :)
<tokudan>
important to get that one merged quickyl though, it's a potential unauthenticated remote code execution...
<andi->
yeah
<tokudan>
thanks for catching pigeonhole btw, i missed that yesterday, as I had to do the PR completely through the github weg interface :/
<andi->
is there a PoC yet? I only saw the perl snippet to cause out of bounds access. Haven't read further.
<tokudan>
don't know. i'm pretty sure there is someone that has one, as it's valuable right now, but I don't think it's public yet
<andi->
I used to write those myself for a while last year so I could write a nixos test to verify before/after but not sure I do have the time to do that right now :/
<andi->
That docker container escape was a fun one :-)
<tokudan>
the mail on the ML mentioned that it doesn't necessarily cause a crash and may need valgrind to observe, so it's probably complicated
<tokudan>
not using docker, so i'm not bothered ;)
<tokudan>
i'm wondering if it's probably easier to just upgrade dovecot to the latest version on 19.03. that way we can be sure that we did not miss anything
<tokudan>
just picking out the patches may be fine, but if we're on a random version instead of the typical supported versions by the vendor, we actually may miss something
<andi->
yeah, technically our version is already unsupported by the vendor.
<andi->
Fixed version: 2.3.7.2, 2.2.36.4
<andi->
so 2.3.7.x and 2.2.36.x seem to be supported right now
<tokudan>
dovecot isn't known for unstable releases, so that's probably the better solution
<tokudan>
i guess i'll open a PR to do that
<andi->
I am not so sure if that is a good idea... It might break in ways that we can't verify since they might have introduced config changes and users would expect it to continue working while on the same (stable) channel.
<tokudan>
let's ask the guys who should know that about their version scheme :)
<tokudan>
andi-, well, i guess you can read it in their channel, it shouldn't cause any issues while we're in the same major version and an update to 2.3.7.2 is the same major version
<tokudan>
so I'll open that PR
<andi->
ok
<andi->
In the last weeks/months I've come across a bunch of packages where I thought that before branch-off we might want to mark them as unsupported (not yet insecure) just so people know what they get themselfes into
<andi->
tokudan: ping me once you opened that PR
<tokudan>
andi-, will do, wont happen before evening though, as i have to work right now
<adisbladis>
andi-: Speaking of Docker container escape... I'm tempted to migrate the Nixos declarative Docker container stuff to Podman/runc
<adisbladis>
At least I think it's worth to explore the option
<andi->
adisbladis: it is definitly an attractive alternative. I saw some issues with that lately (as are to be expected) but mostly it seems to work just fine.
<andi->
adisbladis: what are your issues with systemd-nspawn?
<adisbladis>
andi-: What's cool is that we could further contain podman with systemd, so even in the case of a container escape you'd still end up in a pretty restricted environment
<adisbladis>
andi-: Hmm, nothing.
<adisbladis>
I just tend to forget they now support OCI
<adisbladis>
systemd-nspawn is also an appealing option
<andi->
the documentation isn't that great. I tried to find something on that a few months ago
<adisbladis>
Either way I _really_ dislike our current implementation
<andi->
go for it :-)
<flokli>
adisbladis: while changing it, make sure to fix networking too :-D