Arch Linux

There was an U-turn and original upstream is back with something that smash the old project: https://github.com/jedisct1/dnscrypt-proxy/#current-statusfeatures

It's already available in AUR: https://aur.archlinux.org/packages/dnscrypt-proxy-go/

I recommend to replace this package with 2.0 version after it comes out of beta phase.

https://github.com/jedisct1/dnscrypt-proxy/releases/tag/2.0.0

it's out

Hm, while there has been conflicting information about the initial (and now again current) maintainer Frank Denis, it seems going with the aforementioned version 2.0.6 would be the way to go.
However, the problem with  FS#49881  still remains!

I'm interested in this package. is there any way I can help ?

I install dnscrypt-proxy2 and then it started with system user already with DynamicUser=yes in service file.
Hope that the developer will support version 2 too.

@Severus: I'm currently trying to upstream this and other settings in the service file.

@Severus: Also, plainly using DynamicUser will only work for ports > 1024

@davezerave it doesnot relate to DynamicUser, it works as unix design, only privilege user can bind port < 1024 ( 1024 can be used by non privileges user ).

https://aur.archlinux.org/packages/dnscrypt-proxy-go uses socket activation which should listen on 53 port wit DynamicUser

Socket activation is run by systemd, it requires root privilege, it doesnot relate to DynamicUser.

@Janick.Hauck92: Correct, but that's still not upstream.
@Severus: That's why there is CapabilityBoundingSet and AmbientCapabilities, which can be set to CAP_NET_BIND_SERVICE to explicitely allow that behavior for an unprivileged user.

The new design of the dnscrypt-proxy doesn't really require setting up several services, if one wants to use several distinct servers on separate ports, as it can deal with more than one server (and their disappearance) through its configuration.
Also, it is not required to use socket activation (but it is one possible way to get around the unprivileged port binding issue).

you can use pdnsd then dnscrypt-proxy as backend.

I just see the patch you mention, but I don't think it's good way to fix this issue with systemd.
https://github.com/jedisct1/dnscrypt-proxy/pull/255/commits/a57f6815b5f307418d2ee5c72c48a64fd3b06d44

@Severus
Not sure what you are talking about. Only root can start system-wide systemd services but then they can run unprivileged with DynamiUser option set. With socket activation they can listen on arbitrary defined port at the same time. This is what https://aur.archlinux.org/packages/dnscrypt-proxy-go already does.

@davezerave
You don't need additional capabilities and you don't need to upstream anything as everything is already here in AUR.

https://github.com/jedisct1/dnscrypt-proxy/pull/255/commits/a57f6815b5f307418d2ee5c72c48a64fd3b06d44 will break 99% usecases, I highly doubt it will be accepted.

@Severus/Janick.Hauck92: Pull request 255 is not my contribution.

@Janick.Hauck92: So what keeps you from upstreaming such a general setting then? DynamicUser can be used by any Linux distribution utilizing systemd.
As I wrote before: DynamicUser alone will still not enable you to bind to ports < 1024 (if you're not also using socket activation). If this (socket activation) is meant as the default setup for all use-cases (standalone, as backend for other DNS servers, etc.), then sure, it'll work.
In any case: These settings should be upstreamed.

I don't have need to upstream anything. I'm happy with what downstream currently provides. Everyone is free to send PR.

Socket activation is already in upstream https://github.com/jedisct1/dnscrypt-proxy/blob/master/systemd/dnscrypt-proxy.socket .

@davezerave I see those changes are somewhat upstreamed (commented out by default):
https://github.com/jedisct1/dnscrypt-proxy/commit/bdc32cee90e099a49214c0b5315ea429959ea8c1

@felixonmars A solution to  FS#49881  has been merged upstream. If you find the time, switch to the new version! :)

I seriously doubt that waiting months for update package in repos makes sense when AUR version is updated within hours after upstream release. If maintainer doesn't have time for it, then it's better to drop this.

Can we please update this package yet, this is a bit rediculous...

This is beyond any critique, absolutely no words to describe it:

https://lists.archlinux.org/pipermail/aur-requests/2018-April/023329.html
https://lists.archlinux.org/pipermail/aur-requests/2018-April/023330.html

I just moved dnscrypt-proxy 2.0.8 to community-testing.
Feel free to test and report back!