Re: Someone using COMPAT_SVR4(_32) ?

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 31/07/2017 à 08:19, Maxime Villard a écrit :
> Hi,
> Recently, a number of security issues were found in COMPAT_SVR4 and
> COMPAT_SVR4_32. Due to lack of maintenance and interest from developers, these
> options are not reliable, and undermine the overall code quality of the system.
>
> I would like to know whether someone here actively uses COMPAT_SVR4 and/or
> COMPAT_SVR4_32, and if this use case justifies keeping these options in the
> system. I plan to remove both of them, but I'd like some feedback.
>
> Note that these options are now disabled by default.

It has been stated by core@ that removing a functionality in the system has
to follow a set of guidelines. I am therefore summing up and reformulating
my proposal accordingly.

Reasons for removal of compat_svr4 and compat_svr4_32:
 * They are known to be buggy, and critical vulnerabilities are regularly
   discovered in them.
 * They are not maintained, in the sense that no commit in the last five
   years or more demonstrates an interest from someone - either a developer
   committing patches or a user submitting them.
 * They are seemingly of an inexistent use case, taken into account the fact
   that an interested user may not be subscribed to this mailing list, or
   any other list where this proposal could be sent. (Note: the issue of
   whether compat_svr4 and compat_svr4_32 are used by someone has already
   been raised in the past on different lists, with no affirmative answer.)
 * They undermine the overall code quality of the system. Said otherwise,
   they find themselves close to native code, the quality of which is
   decreased by intrusive, unmaintained bits from compat_svr4 and
   compat_svr4_32. (Note: it is a little less the case now that the support
   for these features on i386 has been removed. What is still glaring,
   however, is that they are not well compartmentalized.)

If someone is interested in keeping these features, he or she has to show
up within a month starting from now (date of the proposal). The minimum
requirement that such a maintainer would have to reach is demonstrating,
via patches or commits, that work is being done on improving the security of
the features - fixing basic bugs, via audit for example - as well as their
reliability - being able to show the functioning of an SVR4 binary being
increased as a result of this work -.

If no maintainer is forthcoming after a month, or the maintenance threshold
is not met within a month, the code may be removed. It is to be noted that
the code will still be in the source code repository, should people wish to
re-instate it in the future. If that should happen, the reasons for removing
the code in the first place will have been addressed.

Regards,
Maxime