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

["Wang, Jian J" <jian.j.wang@intel.com>]

Hi Jiaxin,

> -----Original Message-----
> From: Wu, Jiaxin <jiaxin.wu@intel.com>
> Sent: Tuesday, October 29, 2019 10:45 AM
> To: devel@edk2.groups.io; lersek@redhat.com; David Woodhouse
> <dwmw2@infradead.org>
> Cc: Wang, Jian J <jian.j.wang@intel.com>; Sivaraman Nainar
> <sivaramann@amiindia.co.in>; Lu, XiaoyuX <xiaoyux.lu@intel.com>
> Subject: RE: [edk2-devel] [PATCH v2 4/8] CryptoPkg/Crt: satisfy "inet_pton.c"
> dependencies (CVE-2019-14553)
> 
> > > 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.
> 
> 
> Jian,
> 
> do you think it makes sense to keep the exiting coding style of inet_pton() in
> edk2\CryptoPkg\Library\BaseCryptLib\SysCall? (Personally, I can accept that).
> 

As long as it's kept in SysCall, I'm ok with it.

Regards,
Jian

> >
> > Thanks
> > Laszlo
> >
> >