svn commit: r366962 - in head: include usr.bin/calendar

[Stefan Esser]

Am 27.10.20 um 08:37 schrieb Alex Kozlov:
> On Mon, Oct 26, 2020 at 12:11:56AM -0600, Warner Losh wrote:
>> So, first off, it's already hard coded. Stefan's changes change the hard
>> coding from 'impossible to change' to 'changeable with a recompile' which
>> is an improvement. It might even wind up as a build variable (or not, doing
>> that has some really ugly, nasty dependencies).
>>
>> But even in ports-land, it's a compile time constant. Quite a large number
>> of ports will allow you to change it at compile / build time, but not
>> after. You have to rebuild if you want to change PREFIX...
>>
>> So I'm a bit puzzled what makes this the wrong approach?
> 1) Making it buildtime instead of fixing a few regression cases which as
> simple as reading environment variable before fallback to hardcoded /usr/local,
> or make it kernel variable/sysctl if security is a concern.

Please provide patches that make the affected programs use a run-time
value for LOCALBASE (start with the base system, but do apply this to
ports that are extensions of the base system functionality to be able
to use packages on such a system with non-default LOCALBASE).

And please show that there are no security issues, that there is no
negative impact on the run-time for the huge majority of installations
that use the default value of LOCALBASE, and that there is no added
complexity to maintain such a system (starting from documentation that
needs to be adapted to a dynamically changeable LOCALBASE).

A compiled-in path is protected against manipulation by an attacker,
and, while a sysctl value could be as well, you ought to be able to
use different LOCALBASE values in jails, to make this really universal.

Please provide an architectural draft that accounts for all these points
and an estimate of the effort required to implement it and be assured
we'll openly discuss it.

> 2) Codifying LOCALBASE = /usr/local, so from now more people will use
> it because it's in defines.

No, the _PATH_LOCALBASE makes it easier to refer to port provided files
*without* hard-coding /usr/local!

But LOCALBASE == /usr/local has been the default for so many decades
that I cannot remember when it started. Probably before BSD-4.2 already,
but we have committers that don't have to guess but have been there ;-)
(I've been a BSD user starting with BSD-4.2, and we have already used
/usr/local for the programs distributed over USENET at that time ...)

A verbatim /usr/local occurs in more than 1700 individual files in base,
and I'm going to remove some 20 of them that get compiled into binaries.

You are welcome to bring this number further down and we are awaiting
your patches.

We do not move base components to ports for fun, but to be able to
disconnect them from the release cycle, to ease outside contributions,
and to reduce the maintenance effort for release-agnostic components
(no need to MFC updates to the calendar files, for example).

And we have to compare the effort caused for the project with the effort
it takes to make FreeBSD use a non-default LOCALBASE for users that
really need it. Those will probably have forked off their own repository
to be able to make much bigger changes to the code base - adjusting the
_PATH_LOCALBASE before building the world is really a minor effort for
them.

And we want to make such a change of LOCALBASE easier than it used to
be for a long time.

If you are affected and the above does not apply to you, then please
provide the patches you probably already have ready since you relied
on them before the introduction of _PATH_LOCALBASE.

Regards, STefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20201027/9033c485/attachment.sig>