Specify which network interface to use for ACME requests about uacme

[ddevault]

https://curl.se/libcurl/c/CURLOPT_INTERFACE.html

[ndilieto]

If you are on Linux you could achieve this by running uacme as a dedicated user, FWMARKing packets based on the owner module and routing through the intended interface, something like

iptables -t mangle -A OUTPUT -m owner --uid-owner UID -j MARK --set-mark 2
ip rule add fwmark 2 table 3
ip route add default via xxx.xxx.xxx.xxx table 3

If you have reverse path validation enabled in your distribution, you'll need to disable it via sysctl

[ddevault]

That seems like significantly more work and moving parts than what I assume is about a +5/-1 patch to set the relevant curl option from -I.

[ndilieto]

To be honest I think your use case is rather peculiar and I am very reluctant to embark on the slippery slope of feature bloat. Since it can be achieved by other means (as explained above, or alternatively by creating a virtual interface in a new network namespace and running uacme in it, check manpages of veth/nsenter), I'd rather not implement it.

[ddevault]

I think it's wise of you to avoid feature bloat, and it's for this reason that I choose uacme. However, I don't feel that this qualifies. It would be a very small change: one getopt flag which calls one curl function. Features of more concern would be more along the lines of certbot's magic config editing nonsense. The suggested workaround is very hacky, platform-specific, and requires a lot more work and moving parts: the simplest solution to this problem is a simple patch for uacme. Moving parts are the worst thing an acme client could have; they are the easiest way to kill reliability for a mission-critical tool.

[ndilieto]

Another platform independent way. Run tinyproxy, which has Bind option for outgoing connections, on port 8888 then
env ALL_PROXY=localhost:8888 uacme ...

[ddevault]

Running and managing an entirely separate daemon is also a complex and fragile "solution" to this problem, especially compared with what uacme could do to support it -- effectively a single setsockopt syscall with SO_BINDINTERFACE.

I understand that scope management is important and the fact that uacme thinks about it is the reason I'm here. But these workarounds are much, much worse than the patch would be: a more appropriate workaround if such a feature is not acceptable upstream would be to patch uacme downstream and run that.