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.
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.
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!
