Re: [Bug-wget] the libidn problem

[Ander Juaristi]

On 06/30/2015 10:24 AM, Daniel Stenberg wrote:
> I would assume that you first need to check that the input is claimed to be a 
> UTF8 locale/encoding since I take it a user can use others and then your check 
> shouldn't discard the input on the same premises. To do that, you need to use 
> the same hueristics and logic libidn uses to find out if it is. And then you 
> risk getting out of synch with libidn as it develops. Or you just get some 
> detail wrong and the problem is back.
>
> I'm not saying wget couldn't do something like this, as "security in depth" and 
> all that and it might be better with this check even if there's a risk that it lets some 
> badness through than to not have the check at all.
>
> But really, the effort should instead be put on the libidn side once and for 
> all. There are MANY programs using libidn that otherwise would need the same 
> check getting implemented.
>
> I have not yet seen any single good reason for why libidn can't do this check 
> itself. That's where it belongs.
Completely true. I have nothing to say against that.

But as I said, the libidn guys don't look very responsive. A patch was proposed 
some time ago by the maintainer of gnutls and it hasn't even received a single 
reply, which is unusual for security vulnerabilities like this. Regular Wget 
users don't care about who should ultimately fix it, they only care about the 
fact that Wget is vulnerable, nothing else. This leaves us no choice other than 
checking the input ourselves.

Another reasonable option would be to disable libidn until the issue is fixed, 
as you advised cURL users. I didn't propose this because you already did, but 
it's a reasonable workaround too.

Now that Tim has sent a patch this will hopefully get solved. At least 
temporarily. We could revert it back once the libidn guys fix it by their side, 
to avoid the synchronization issues you mention. Just suggesting...


--
Regards,
- AJ