Re: [PATCH] Set behavior of sprintf-like functions with overlapping source and destination

[Zack Weinberg <zackw at panix dot com>]

On Thu, Dec 27, 2018 at 10:27 AM Florian Weimer <fw@deneb.enyo.de> wrote:
> Historically, we have used symbol versioning (in the sense that we
> changed the default symbol version) for two different situations:
>
> (1) A type changed size or a function changed its prototype in a
>     binary-incompatible way, usually prompted by a desire to increase
>     standards conformance.
>
> (2) A function changed behavior and existing software broke.
>
> memcpy@GLIBC_2.14 is clearly in the second category.  A more recent
> example is glob@GLIBC_2.27.
>
> The key difference between (1) and (2) is that rebuilding existing
> software for (1) either works as before, or you get at a compiler
> error and have to apply a simple fix.  For (2), on the other hand, the
> bug is still there, and recompilation reintroduces it.
>
> Over the years, I have come to the realization that (2) really only
> benefits proprietary software, and unmaintained proprietary software
> at that.  We still receive bug reports about the glob@GLIBC_2.27
> transition because people try to build the wrong version of GNU make
> on glibc 2.27 or later.  I would say that using symbol versioning to
> make such backwards-incompatible changes is very confusing and may not
> be worth it.  Instead, we should make the change without introducing a
> symbol version (to treat everyone the same), or not make the change at
> all.

I agree with this and I also think we have historically been too
aggressive about breaking programs that depend on behavior that is
formally undefined in the C standard but has been well-defined for
many years in the GNU ecosystem.  In this case I am particularly
concerned about breaking programs that are distributed as source but
not carefully maintained.  It's really easy to miss one more warning
in a program that already has lots.

> The sprintf change clearly is in category (2).  However, there's a
> mitigation circumstance: Distributions already build with
> _FORTIFY_SOURCE (at least they try to), so they are largely exposed to
> the new behavior.  So I'd expect that in this particular case, the
> recompilation problem would largely affect unpackaged, in-house
> software.  Maybe this makes the change more acceptable and could
> actually justify introducing a symbol version in this case?

It seems to me it's the other way around: distribution-packaged
software is more likely to receive fixes for this type of problem than
unpackaged in-house stuff is.

zw