#113 New package: dnscrypt-proxy2

Open
opened 2 months ago by dllud · 10 comments
dllud commented 2 months ago

Could you please add the dnscrypt-proxy2 package?

Would be handy as the regular dnscrypt-proxy is now on "maintenance mode", and brings in an outdated resolvers list. Effort seems to be now focused on the Go based dnscrypt-proxy2.

Could you please add the [dnscrypt-proxy2](https://github.com/openwrt/packages/tree/master/net/dnscrypt-proxy2) package? Would be handy as the regular [dnscrypt-proxy](https://github.com/openwrt/packages/tree/master/net/dnscrypt-proxy) is now on ["maintenance mode"](https://github.com/dyne/dnscrypt-proxy), and brings in an [outdated resolvers list](https://github.com/openwrt/packages/blob/master/net/dnscrypt-proxy/files/dnscrypt-resolvers.csv). Effort seems to be now focused on the [Go based dnscrypt-proxy2]( https://github.com/DNSCrypt/dnscrypt-proxy).
RISCI_ATOM commented 2 months ago
Collaborator

The project is not able to provide or include any packages that have a dependency on the Go programming language. Google's patent grant on Go is too weak and only applies to approved implementations. dnscrypt-proxy was only included as a compromise.

The project is not able to provide or include any packages that have a dependency on the Go programming language. Google's patent grant on Go is too weak and only applies to approved implementations. `dnscrypt-proxy` was only included as a compromise.
dllud commented 2 months ago
Poster

Oh, thanks for letting me know about the patent issue.

Anyway, it seems to me that using Go in this case does not constitute a freedom issue (i.e. a FSDG compliance problem). The Go implementation available in OpenWrt, and used to build dnscrypt-proxy2, is the official one by Google, licensed under BSD-3-Clause and covered by Google's patent grant.

Why do you still opt to have libreCMC Go-free?

Oh, thanks for letting me know about the [patent issue](https://golang.org/PATENTS). Anyway, it seems to me that using Go in this case does not constitute a freedom issue (i.e. a [FSDG](https://www.gnu.org/distros/free-system-distribution-guidelines.html) compliance problem). The [Go implementation available in OpenWrt](https://github.com/openwrt/packages/tree/master/lang/golang), and used to build dnscrypt-proxy2, is the [official one by Google](https://go.googlesource.com/go), licensed under BSD-3-Clause and covered by Google's patent grant. Why do you still opt to have libreCMC Go-free?
dllud commented 2 months ago
Poster

Let me add in some context about patents.

Being an ISO standard does not mean that C or C++ are not covered by patents. Actually, it is common for ISO standard contributors to fill for patents, and there are many ISO standards covered by patents. If you do a search for patents pertaining to C or C++ you'll find stuff such as this:

Thus, if you write your own compiler for C or C++ you may be infringing such patents. This patent world is a mess.

The point here is to demonstrate that, if the goal was to have libreCMC free of languages that may be encumbered by patents, then you've failed already. Go does not constitute any more of a threat than C or C++.

Let me add in some context about patents. Being an ISO standard does not mean that C or C++ are not covered by patents. Actually, it is common for ISO standard contributors to fill for patents, and there are many [ISO standards covered by patents](https://en.wikipedia.org/wiki/Category:Open_standards_covered_by_patents). If you do a search for patents pertaining to C or C++ you'll find stuff such as this: - [Method and apparatus for generating executable code from object-oriented C++ source code](https://data.epo.org/gpi/EP0752650A3) - [Incremental compilation of c++ programs](https://worldwide.espacenet.com/publicationDetails/biblio?CC=EP&NR=0805391A3&KC=A3&FT=D#) Thus, if you write your own compiler for C or C++ you may be infringing such patents. This patent world is a mess. The point here is to demonstrate that, if the goal was to have libreCMC free of languages that may be encumbered by patents, then you've failed already. Go does not constitute any more of a threat than C or C++.
dllud commented 2 months ago
Poster

The only sane way to deal with this world scenario is to rely on free software compiler implementations which grant patent usage. GCC (GPLv3) and Clang (Apache 2.0) are a good examples.

And it seems that Go too. That's precisely what Google does on that PATENTS file. They grant you patent usage in a wording that is very similar to Apache 2.0. Why they didn't chose a license with explicit patent grants (e.g. Apache 2.0 as used in Android) is something that boggles me. Perhaps they don't expect external contributors to have any patents that apply to Go.

Anyway, even on Apache 2.0 or GPLv3, patent grants only apply to the actual work/code (the thing that is copyrightable). Do remember that all these software licenses only work because of the existence of copyright laws, and thus can only be attached to copyrightable works. Therefore, with it's definition of "This implementation" as

copyrightable works distributed by Google as part of the Go project

Google seems to be going as far as it could go.

PS. Sorry for the long and split reply. I hope it helps.

The only sane way to deal with this world scenario is to rely on free software compiler implementations which grant patent usage. GCC (GPLv3) and Clang (Apache 2.0) are a good examples. And it seems that Go too. That's precisely what Google does on that [PATENTS](https://golang.org/PATENTS) file. They grant you patent usage in a wording that is very similar to [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0). Why they didn't chose a license with explicit patent grants (e.g. Apache 2.0 as used in Android) is something that boggles me. Perhaps they don't expect external contributors to have any patents that apply to Go. Anyway, even on Apache 2.0 or GPLv3, patent grants only apply to the actual work/code (the thing that is copyrightable). Do remember that all these software licenses only work because of the existence of copyright laws, and thus can only be attached to copyrightable works. Therefore, with it's definition of "This implementation" as > copyrightable works distributed by Google as part of the Go project Google seems to be going as far as it could go. PS. Sorry for the long and split reply. I hope it helps.
dllud commented 2 months ago
Poster

To further backup my interpretation above: someone just pointed me to existence of gccgo. All in all, Go seems safe both freedom-wise and patent-wise :)

To further backup my interpretation above: someone just pointed me to existence of [gccgo](https://gcc.gnu.org/onlinedocs/gccgo/). All in all, Go seems safe both freedom-wise and patent-wise :)
RISCI_ATOM commented 2 months ago
Collaborator

After further consideration, the libreCMC project will not provide or package dnscrypt-proxy2. After building and stripping, the resulting binary is over 9M in size. To put things into perspective, the majority of devices that libreCMC supports have 4M - 8M of flash. While some hacks could be used to get the size down, it most likely will not be enough.

Also, the way that upstream chose to bootstrap Go is not suitable for the libreCMC project. The libreCMC project uses ppc64el for final builds and the bootstrapping compiler used only supports i386,amd64 and arm. This issue could be fixed, but it is not worth the effort for one package.

After further consideration, the libreCMC project will not provide or package `dnscrypt-proxy2`. After building and stripping, the resulting binary is over 9M in size. To put things into perspective, the majority of devices that libreCMC supports have 4M - 8M of flash. While some hacks could be used to get the size down, it most likely will not be enough. Also, the way that upstream chose to bootstrap Go is not suitable for the libreCMC project. The libreCMC project uses `ppc64el` for final builds and the bootstrapping compiler used only supports `i386`,`amd64` and `arm`. This issue could be fixed, but it is not worth the effort for one package.
dllud commented 2 months ago
Poster

Thanks for looking into it. 9 MiB in size is something I won't argue with. Case closed.

I will reopen this issue if/when the regular dnscrypt-proxy becomes totally unusable. I hope this happens far into the future, when libreCMC routers all get to 32 MiB flash or so.

Thanks for looking into it. 9 MiB in size is something I won't argue with. Case closed. I will reopen this issue if/when the regular `dnscrypt-proxy` becomes totally unusable. I hope this happens far into the future, when libreCMC routers all get to 32 MiB flash or so.
RISCI_ATOM commented 2 months ago
Collaborator

...brings in an outdated resolvers list.

I would agree that the default resolvers list should be revisited. Usually, the project would not provide them, given that the project does not control or have the ability to verify all of them. But I could look into updating it.

> ...brings in an outdated resolvers list. I would agree that the default resolvers list should be revisited. Usually, the project would not provide them, given that the project does not control or have the ability to verify all of them. But I could look into updating it.
dllud commented 2 months ago
Poster

Yes, it should be up to the user to maintain the resolvers list. Instead of using that csv file with the resolvers list, dnscrypt-proxy in OpenWrt/libreCMC should rather allow users to define resolvers through UCI and into /etc/config/dnscrypt-proxy. Unfortunately this is a problem imported from upstream and thus harder to fix.

As a workaround, perhaps the csv list should be placed into some user editable directory like /etc/dnscrypt-proxy/dnscrypt-resolvers.csv. The default resolvers list could then point there, and the user should be alerted to the need to insert the resolvers there.

Yes, it should be up to the user to maintain the resolvers list. Instead of using that csv file with the resolvers list, `dnscrypt-proxy` in OpenWrt/libreCMC should rather allow users to define resolvers through UCI and into `/etc/config/dnscrypt-proxy`. Unfortunately this is a problem imported from [upstream](https://github.com/dyne/dnscrypt-proxy) and thus harder to fix. As a workaround, perhaps the csv list should be placed into some user editable directory like `/etc/dnscrypt-proxy/dnscrypt-resolvers.csv`. [The default resolvers list](https://github.com/openwrt/packages/blob/master/net/dnscrypt-proxy/files/dnscrypt-proxy.init#L38) could then point there, and the user should be alerted to the need to insert the resolvers there.
dllud commented 2 months ago
Poster

After all, it is already possible to add custom resolvers into /etc/config/dnscrypt-proxy. It just wasn't documented at the OpenWrt user guide for dnscrypt-proxy. I've now added examples into it. Here's one:

config dnscrypt-proxy 'dnscryptdkv6'
       option address '[::1]'
       option port '5356'
       option providername '2.dnscrypt-cert.resolver2.dnscrypt.eu'
       option providerkey '3748:5585:E3B9:D088:FD25:AD36:B037:01F5:520C:D648:9E9A:DD52:1457:4955:9F0A:9955'
       option resolveraddress '[2001:1448:243::dc2]:443'

I guess this issue can now be closed.

After all, it is already possible to add custom resolvers into `/etc/config/dnscrypt-proxy`. It just wasn't documented at the [OpenWrt user guide for dnscrypt-proxy](https://openwrt.org/docs/guide-user/services/dns/dnscrypt-proxy). I've now added [examples](https://openwrt.org/docs/guide-user/services/dns/dnscrypt-proxy#examples) into it. Here's one: ```bash config dnscrypt-proxy 'dnscryptdkv6' option address '[::1]' option port '5356' option providername '2.dnscrypt-cert.resolver2.dnscrypt.eu' option providerkey '3748:5585:E3B9:D088:FD25:AD36:B037:01F5:520C:D648:9E9A:DD52:1457:4955:9F0A:9955' option resolveraddress '[2001:1448:243::dc2]:443' ``` I guess this issue can now be closed.
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.