On 4/4/22 16:58, Christian Grothoff wrote:
I don't see how either is terribly relevant for the (limited) GNUnet
use-cases of HTTPS. Users would have to work pretty hard on a very
customized curl/GNUnet setup to make themselves theoretically
vulnerable --- and even then the impact would seem negligible. Worst I
can imagine is a network-level adversary doing a MiTM for every
hostlist request to force a peer to bootstrap only against malicious
nodes the adversary controls. But such a network-level adversary can
likely achieve this almost as well by simply dropping traffic.
Thanks! I'll see if I can apply the upstream patches then, even if it's
not very likely to be an issue.
Regardless, you should be able to build GNUnet against vanilla libcurl
these days, so that might be a better way to avoid worrying about this.
In the context of pkgsrc, the problem is that I can not enforce a change
of setting in curl (for example built against gnutls) for the defaults.
Or maybe you can explain how a gnunet built against curl and gnurl would
differ these days in terms of functionality and features.
On 4/4/22 16:47, Nikita Ronja Gillmann wrote:
Hi,
finishing the gnunet package for pkgsrc might require merging back
the inactive gnurl into the pkgsrc tree from pkgsrc-wip.
I've looked at the current CVEs for curl, and I have open questions
for 2 of them. Could someone take a look at them and tell me if they
apply in the context of how gnunet makes use of gnurl?
I guess the 2 CVEs aren't applicable in our context, but I'd like to
be sure before I decide if I merge it back or not, or if I let the
security team add an CVE to our security db.
https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob_plain;f=gnurl/gnurl-CVEs;h=190a57f1d3e672ae53a1ee8f799ab0068d94b1a0;hb=HEAD
https://curl.se/docs/CVE-2021-22924.html
https://curl.se/docs/CVE-2021-22890.html
Thanks!
