On Sat, Feb 15, 2025 at 05:43:00PM +0000, Lucas Gabriel Vuotto wrote:
> Hello,
> 
> I friend of mine is learning some C and needed to use b64_ntop, and
> somehow managed to pick the worst possible example usage of b64_ntop in
> the src tree.

I never understood why these resolv.h functions are undocumented.

> - dbuf is treated as a string, despite b64_ntop being able to deal with
>   binary data
> - the encoded length arithmetic is wrong (but it's always >= than the
>   corrent encoded length), plus there is no consideration for the final
>   NUL byte
> - the return value isn't checked and it's used to index a malloc'd
>   region
> 
> The last two items together can make tcpdump print trash or crash when
> l is in the form of 3n + 1, because there is no room for the ending NUL
> byte and b64_ntop returns -1.
> 
> ok?

ok tb

> Also, this lwres protocol thing came from some BIND9, didn't seem to get
> much traction (opinion solely based on how difficult was to find
> information about it online) and was removed from BIND9 in 2015 iirc.
> Does it make sense to keep it at all?

No idea. Maybe we need a simple resolver that supersedes the lightweight
one...

In my ongoing bulk lwres is only mentioned in isc-dhcp (and seemingly
unrelatedly in powerdns_recursor).