@GrahamcOfBorg test dnscrypt-wrapper

FWIW, this was removed in #78543.

Personally, I'm not sure how I feel about re-packaging a security-sensitive codebase in a memory-unsafe language that's been abandoned by the original owner and hasn't been actively maintained since; a single flick of the scrollbar on the forked repository gets you back into commits from the original author in 2017, and at least one of the security fixes since seems to have only happened because the original author dropped in to patch them, so I don't think it's a great idea to encourage using it over the new version.

It seems it's only used for key rotation; would it be difficult to port this to using dnscrypt-proxy2 instead?

It seems it's only used for key rotation; would it be difficult to port this to using dnscrypt-proxy2 instead?

That's correct: it's only used to make a connection to localhost so I can't think of any security issue.

Unfortunately yes, It's no possibile to use dnscrypt-proxy2 because the function is simply not implemented. It was added at some point but reverted soon after. Apparently the author doesn't care about dnscrypt that much anymore.

If you are worried about users picking this up over v2 I guess I could move the attribute out of all-packages.nix.

Fair enough; seeing as dnscrypt-wrapper itself is based on the dnscrypt-proxy 1.x code, I don't think it makes much difference security-wise to use it here, though it would be nice in the long run if there was a standalone tool or dnscrypt-wrapper had something upstream, rather than having to keep the package around just for key rotation. I'll let people who actually have commit access decide what they think about the maintenance burden of that, though.

Huuuh. I'm also not a fan of introducing a package with known security issues, even if it's just used in a localhost context.

@rnhmjoj Has there been any discussion with upstream about why DNSCrypt/dnscrypt-proxy@519af2e#diff-882438215b589ae5bb3f1b4ab0f2f512 has happened?

Maybe you could explain your usecase, and there's another way, instead of using an unmaintained older package version.

Honestly, while packaging dnscrypt-proxy1 or not is its own decision, its codebase is probably not worth worrying about too much in the context of a dnscrypt-wrapper module, because dnscrypt-wrapper is itself a fork of the dnscrypt-proxy 1.x code that has barely been touched in years; the fork of dnscrypt-proxy 1.x re-added in this commit is not really any less active and I wouldn't be surprised if it actually has security fixes that dnscrypt-wrapper hasn't inherited.

Personally, I think this mostly means that it might not be the greatest idea to have integration with dnscrypt-wrapper upstream, but I feel bad about responding "maybe we should just remove this" when someone has gone out of their way to fix it 😅

@rnhmjoj Has there been any discussion with upstream about why DNSCrypt/dnscrypt-proxy@519af2e#diff-882438215b589ae5bb3f1b4ab0f2f512 has happened?

No, I don't think so.

Maybe you could explain your usecase, and there's another way, instead of using an unmaintained older package version.

Yes, I could open an issue but the author expressed the -verify feature would better be in an external tool so it doesn't look like there's going to be one in dnscrypt-proxy 2. It's probably better to open an issue in dnscrypt-wrapper, which is directly affected.

In any case I'm pretty sure the only option is to write a tool to verify the keys. I'm probably going to write it myself but it will take time.

dnscrypt-wrapper is itself a fork of the dnscrypt-proxy 1.x code that has barely been touched in years;

Yeah, the world seems to have chosen (once again) the technically messier solution (DNS over HTTP/TLS). I may be the only one still using this but given the program has not been officially deprecated and is still working I don't see why it should be removed.

I'll move the definition of dnscrypt-proxy1 out of all-packages.nix to make it only available to dnscrypt-wrapper.

• Moved dnscrypt-proxy1 inside the dnscrypt-wrapper module
• Rebased and fixed conflict
• Opened an issue at Provide a tool/option to verify certificates cofyc/dnscrypt-wrapper#171

I'm going to merge this since we have agreed that dnscrypt-proxy1 limited to this module is not a security concern and no other solution exists.

I'll also backport the change to 20.03 since the module is broken there.