Re: [PATCH] Implement strlcpy, strlcat [BZ #178]

[Guillem Jover <guillem at hadrons dot org>]

Hi!

[ Just noticed this now, upstream and Debian libbsd maintainer here. ]

On Mon, 2016-05-30 at 17:40:37 +0200, Florian Weimer wrote:
> On 05/20/2016 07:21 PM, Paul Eggert wrote:
> > First, the September 2014 thread motivated strlcpy/strlcat in part by
> > saying that Fedora has over 60 packages which define strlcpy/strlcat[1],
> > the implication being that moving strlcpy/strlcat into glibc would fix
> > more bugs than it would cause and would be worth the effort's cost.
> > Skeptics like me can reasonably counter that the effort would likely
> > just be security theater, in that it would not be of any real help but
> > would merely exhibit activity in the security area, and possibly would
> > even cause more problems than it fixes.

The intention with libbsd has always been to make porting easier, try
to reduce local implementations and embedded code copies, and have a
single place where those functions can be improved if need be, instead
of having to touch stuf all over the place. One additional advantage of
having it in libbsd is that it does not "pollute" more generally used
libraries, and allows to possibly migrate to it incrementally (in case
of locally diverging implementations), or possibly deprecate them
eventually. Although I've not yet had to bump the SOVERSION, and I'd
rather not do that if possible at all.

> I'm not sure if it is possible to easily quantify the security benefits that
> strlcpy/strlcat bring.  Any project we start in this area would prevent us
> from working directly on glibc improvements, due to the resource constraints
> we face.

I'm not going to get into whether any of the interfaces provided by
libbsd are good or not. They are provided because they are used, many
times by projects with very strong BSD origins, which will not stop
using them whether other people consider them bad or other systems
have those interfaces or not, and because the implementation embedded
in other projects are either out-dated, or of lower quality.

That's BTW probably one of the only projects for which I take such
"practical" stance.

> The major omissions are glibc and MSVC.  Most of the other libcs in the “no”
> camp are legacy implementations to various degrees.

Personally I've considered libbsd something that complements glibc,
providing interfaces that might not be suitable for the latter for
whatever reason. So, please feel free to send patches my way or
propose BSD-things that you might not be comfortable providing in glibc.

> > Second, the September 2014 thread said that another way to fortify
> > strlcpy/strlcat, assuming we still want to do it, would be to use
> > libbsd's strlcpy/strlcat implementation and add fortification to it.
> > However, it was argued that this would be a Fedora-only effort and that
> > libbsd contains functions like fgetln that are awkward. But isn't the
> > point of libbsd to provide BSD functions that are awkward or
> > questionable from the glibc point of view?
> 
> fgetln is not questionable at all by itself (except when reading lines from
> a read-only mapping or in-memory source, so that the non-const return value
> is incorrect).  Its awkwardness is the result of the implementation in
> libbsd, on top of stdio interface (and not libio internals).

Indeed, and that's a function libbsd inherited from its vestigial form
in the Debian GNU/kFreeBSD port. Which I've since marked as deprecated
in libbsd and made it warn to switch to getline(3).

And even if the fgetln() implementation in libbsd is "awkward" (which is
a very gentle way to put it), it is still the most robust and less buggy
implementation among all the many other embedded implementatoins I've
seen, given the public interfaces provided by glibc.

  <https://sourceware.org/ml/libc-alpha/2014-09/msg00357.html>
  <https://sourceware.org/ml/libc-alpha/2014-09/msg00424.html>

Florian, you mention you'd like to see libbsd disappear, due to lots of
other gross things in there. Given what I've seen around, I think that
would make the situation worse. I'd rather improve the stuff in libbsd,
and switch more projects to it. Besides fgetln() and fgetwln() what else
do you take issues with? I'm happy to fix, improve or deprecate things
that are broken, either by myself or by accepting patches!

> Once we have a clear picture of the vtable/ABI situation of libio, we can
> implement fgetln in glibc quite easily (with the caveat that writing to the
> returned buffer may not be allowed, depending on the underlying stream, but
> the BSDs have the same problem).  But that's a separate discussion.

I think pointing people to use getline(3), given that it's a
standardized function now is a better approach, and something that even
projects with strong BSD origins might be amenable to switch to.

But I'm happy to switch to anything that glibc provides that makes the
fgetln() implementation sane in libbsd. Although it will probably
still be very awkward to implement on other non-glibc systems that
lack a native implementation.

> > And I don't see how work in
> > libbsd would be Fedora-only, as other distributions like Debian also use
> > libbsd, and whatever methods Fedora uses to merge strlcpy/strlcat into
> > string.h would be methods that other distributions could use as well.

It is shipped in pretty much all major distributions now, AFAIK, see
the downstream list that I track at:

  <https://libbsd.freedesktop.org/wiki/>

> I might be misremembering things, but I think back in 2014, libbsd
> maintainership in Debian languished a bit, and the upstream situation was
> rather unclear.

Since its inception there's been at least a release per year, some
years have seen more activity. I've never received any enquiry about
the upstream or Debian status, so that comment is a bit surprising.

When I have time to scan for embedded code copies, I check for
"standard" BSD interfaces, and might add them if they can be implemented
somewhat sanely, if they seem useful or are used by several projects.

Given that I'd rather not diverge from the BSD interface behavior,
there's been usually not much incentive to do major code rewrites and
similar. At least not until the test suite has way more coverage. But
I'm happy to accept improvements and even rewrites (as long as they
preserve behavior) if that makes people more comfortable with the
implementations provided.

But all in all it's low-maintenance.

> > The Fedora bug report that corresponds to strlcpy/strlcat
> > fortification[2] says that this is "Priority low Severity low", and from
> > the above it appears that this is mainly a packaging problem instead of
> > being a necessary addition to the core libc API.
> 
> We did not invest in libbsd development because the right place to offer
> widely-implemented libc APIs in Fedora is glibc.

As Paul has mentioned, not all BSD interfaces might be acceptable for
glibc, and I think libbsd is the proper place for those.

Thanks,
Guillem