Re: gnurl CVE applicability

[Schanzenbach, Martin]

> On 4. Apr 2022, at 17:35, Mikhail <mp39590@gmail.com> wrote:
> 
> On Mon, Apr 04, 2022 at 05:14:53PM +0200, Christian Grothoff wrote:
>> On 4/4/22 17:09, Nikita Ronja Gillmann wrote:
>>> 
>>>> 
>>>> 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.
>> 
>> Ah, I see. Well, yes, non-gnutls curl is likely still going to cause grief
>> for some parts of GNUnet...
> 
> README says that libgnurl is recommended, but I think in OpenBSD I will
> must use libcurl linked to libressl.
> 
> I was thinking about porting libgnurl, but I suppose it won't find any
> support from OpenBSD committers, because this library can be viewed
> as potential new attack surface, and we will need to support security
> incidents for both, libcurl and libgnurl, and libgnurl site says:
> 
>> gnurl/libgnurl is looking for a new maintainer
> 
> which means new versions of libgnurl probably will lag behind libcurl in
> matter of security incidents.
> 
> Does non-gnutls curl brings some disasters to GNUnet?
> 

The GNS proxy does not work with openssl.
It tries to verify certificates through TLSA records when possible.
And this does not work properly with curl openssl.
No gnutls odd behaviour, I think.
Everything else should just work with curl as well including GNS (without the 
proxy).

BR

signature.asc
Description: Message signed with OpenPGP