Option to disable signature check in containerized setting

[Mainfrezzer]

With the Alpine Linux 3.23 release, their docker image ships with version 3.17.0 which enforces signature checks.
The addition of the signature check causes wg-tools, for example, to exit with errors due to no being able to set dns server, if they are specified and thus, doesnt establish a connection.
Running the -u command seperately will break dns resolution as the dns servers are changed before the container is able to establish the tunnel and the container is unable to connect to the specified dns server. (for various reasons, the declared dns might be in another private network, the dns server might be target of goverment censorship. dns resolution is enforced to the local network only. who knows)
If the tunnel loses connection, so far, from what ive seen, its also impossible to get the "old"/"original" config restored and thus are stuck in a limbo.(meaning the tools itself did handle it perfectly so far but are now unable to)

It would abolutely be delightful to see an option added to disable the signature checks to restore the old functionality in containerized setups.

Edit: i just checked some lxc setups. which are certainly more "hands on" but the same story there. I think the amount of Alpine as desktop is limited, but i can see that its frustrating there as as well.

Anything that manages your dns will break. Which is an issue as you manually need to babysit it and hopefully have backups/know which dns you supposed to have. As if you run resolvconf -u manually, after a failed run of wg-tools for example, which is horrible as an idea to run a program into an error to successfully change your dns config and then subsequently be stuck with a wrong config as wg-tools doesnt change the file back to its original state, which also doesnt happen after a second resolvconf -u run. Its a huge regression.

[rsmarples]

Anything that manages your dns will break. Which is an issue as you manually need to babysit it and hopefully have backups/know which dns you supposed to have. As if you run resolvconf -u manually, after a failed run of wg-tools for example, which is horrible as an idea to run a program into an error to successfully change your dns config and then subsequently be stuck with a wrong config as wg-tools doesnt change the file back to its original state, which also doesnt happen after a second resolvconf -u run. Its a huge regression.

I am going to challenge this assertion.
The initial setup:

$ cat /etc/resolv.conf
# resolvconf does not have control
nameserver 1.1.1.1

$ resolvconf -l
$

resolvconf -a and -d will just store records but not do anything due to an invalid signature

$ echo "nameserver 5.6.7.8" | doas resolvconf -a foo
resolvconf: signature mismatch: /etc/resolv.conf
resolvconf: run `resolvconf -u` to update
$ cat /etc/resolv.conf
# resolvconf does not have control
nameserver 1.1.1.1

OK, lets allow resolvconf to now take control without breaking DNS - the above step added a record to 5.6.7.8 which may not work as the vpn is not up yet.
Our first step is to purge any stale resolvconf files and then copy the system DNS into resolvconf.
Then, we force an update to take control.

$ doas resolvconf -I
$ cat /etc/resolv.conf | doas resolvconf -a control
resolvconf: signature mismatch: /etc/resolv.conf
resolvconf: run `resolvconf -u` to update
$ doas resolvconf -u
$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 1.1.1.1
$

At this point you can now start and stop vpn interfaces and the nameservers will be updated accordingly, provided everything that wants to touch dns uses resolvconf.

Does this fix it for you, and if not can you explain why?

[Mainfrezzer]

Lovely! That does seem to do the trick from my quick testing.
For a docker container straight forward to integrate, for a lxc a bit annoying to having to setup a script at boot now for it. Would still be handy to have a setting for it. (i havent tested any of my alpine cloud init server yet but im sure i would need to put a script at boot there too)

[rsmarples]

I'm not sure we could put that into a setting. Let me explain:

• If resolvconf -I is needed to invalidate stale resolvconf records then your docker image needs cleaning.
• resolvconf cannot guess that the current /etc/resolv.conf has valid anything if the signature is not there or if it should be placed into a resolvconf record or not. For example a blank /etc/resolv.conf is fine and libc will use 127.0.0.1 in the background. And if it's blank then resolvconf will just work as that passes the signature check.
• overloading -a with any of the above is dangerous and imho the wrong thing to do. It's not the job of a vpn to take over system dns, but to augment it.

The issue is that these containers do not start resolvconf friendly and a few extra steps is needed to make them happy.
But this is no different from say changing from systemd-resolvd to openresolv - the needed steps are the same and the logic is the same. It's just that here we are saying "take over DNS from docker" rather than "take over DNS from systemd-resolvd".

[Mainfrezzer]

Lets just say i hate systemd with a passion, so im not sure what it does. But on the systems where im forced to use it, it runs and does what its supposed to do, it changes to whatever dns servers are set in the config file. As the old pre signature check behavior. (with the exception of the pi5, there theres no resolvconf)

As far as i can tell. it updates the file by inserting the new dns server at the top without stripping the prior dns server, so it could still leak. Not great really. But thats what made alpine great in the past for that type of application. But i dont really use these kind of distros to know enough how they behave in a docker enviroment. But from the couple images i have, they lack any resolvconf and you have to set them up by hand like a caveman. Horrid, if there is a tool for the job that does it for you.(even on windows it does it)