Re: [PATCH v2 4/8] CryptoPkg/Crt: satisfy "inet_pton.c" dependencies (CVE-2019-14553)

["Laszlo Ersek" <lersek@redhat.com>]

On 10/28/19 14:06, David Woodhouse wrote:
> On Sat, 2019-10-26 at 07:37 +0200, Laszlo Ersek wrote:
>> In a later patch in this series, we're going to resurrect "inet_pton.c"
>> (originally from the StdLib package). That source file has a number of
>> standard C and BSD socket dependencies. Provide those dependencies here:
>>
>> - The header files below will simply #include <CrtLibSupport.h>:
>>
>>   - arpa/inet.h
>>   - arpa/nameser.h
>>   - netinet/in.h
>>   - sys/param.h
>>   - sys/socket.h
>>
>> - EAFNOSUPPORT comes from "StdLib/Include/errno.h", at commit
>>   e2d3a25f1a31; which is the commit immediately preceding the removal of
>>   StdLib from edk2 (964f432b9b0a).
>>
>>   Note that the other error macro, which we alread #define, namely EINVAL,
>>   has a value (22) that also matches "StdLib/Include/errno.h".
>>
>> - The AF_INET and AF_INET6 address family macros come from
>>   "StdLib/Include/sys/socket.h".
>>
>> - The NS_INT16SZ, NS_INADDRSZ and NS_IN6ADDRSZ macros come from
>>   "StdLib/Include/arpa/nameser.h".
>>
>> - The "u_int" and "u_char" types come from "StdLib/Include/sys/types.h".
> 
> Hm.
> 
> If you're porting a whole standard C library to EDK2 then I suppose it
> makes sense to build up all this infrastructure for it.
> 
> But in this case when it's only the single inet_pton() function that
> you need, perhaps it makes more sense to 'port' that one function to
> UEFI (or just reimplement it looking like EDK2 code), instead of
> bringing all this stuff along with it?

I didn't want to take responsibility for touching any of that code -- I
wanted it to be a piece of the puzzle that we'd just drop in. Its coding
style is very foreign to edk2 norms, so once we started, we wouldn't
stop before rewriting it more or less completely. (For example it quite
frequently consumes the values that assignment expressions evaluate to,
which is a huge no-no in edk2, as far as I understand.) I have no
capacity for such a rework (or additional ownership / responsibility),
sorry.

I worked from Friday evening to Saturday ~6-7AM as my "second sprint" on
this code and its testing, until I was satisfied with the test coverage.
I apologize but I simply cannot repeat that. This is all I can
contribute code-wise (and testing-wise) to fixing this issue.

Thanks
Laszlo