On Tue, May 07, 2019 at 08:15:16PM -0400, Nick Holland wrote:
On 5/7/19 8:32 AM, Dumitru Moldovan wrote:
On Sun, May 05, 2019 at 05:05:11PM +0200, Ingo Schwarze wrote:

Consus wrote on Fri, May 03, 2019 at 02:24:10PM +0300:

Maybe it's a good idea to note this on the upgrade page? Something like
"the upgrade procedure may leave some files behing; you can manually
clean them up using sysclean package"?


For example, it is definitely useful to remove stale Perl libraries.
It is also useful for stale header files if you compile software
from source.  It is useful (but not terribly important) for stale
manual pages.  It is usually detrimental for old versions of shared
libraries, unless you are *really* short on disk space (which is getting
less common nowadays) *and* you are very careful.

For most use cases, we do not recommend using sysclean.

I think there's a less common scenario not covered in this thread.
Suppose you have locally-compiled binaries, linked to previous versions
of libraries, belonging to an older version of the OS.  Those libs will
never get patched after you upgrade, so any vulnerabilities they expose
will remain exploitable in the binaries linked to them.

Ok, I admire your confidence that the problem in your local binaries
are the OpenBSD libraries. :D

This swings both ways.  When doing an upgrade, if the upgrade deleted
all those libraries BEFORE you had a chance to upgrade that binary, it
would quit working.  While I'm all for "Fail Closed", it might be
premature to call it a failure.  Or not.

It is very hard to please all, and even harder to cover all possible

You're mostly right, but just to be clear... Although it's true I'm a
purist on this and would prefer that binaries linked to old libs will
fail after an OS upgrade, there's no confidence to be admired on my
side.  This is why I used "I think" and "suppose you have" above.

Thanks for the understanding!

Reply via email to