Re: kerberos is the new sqlite: disable, force mit, or ?

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Wed, 4 Sep 2024 06:22:44 +0000
> From: nia <nia%NetBSD.org@localhost>
> 
> On Wed, Sep 04, 2024 at 01:46:56AM +0000, Taylor R Campbell wrote:
> > FYI, gss_store_cred_into has been added to Heimdal, but it isn't out
> > in a release yet.
> > 
> > https://github.com/heimdal/heimdal/issues/451
> > https://github.com/heimdal/heimdal/commit/e0bb9c10cad0fd98245caecf8af8fca855b2df49
> 
> This was also mostly the situation with sqlite3.
> The right thing to do would have been to enable the relevant
> features in NetBSD rather than create a two-tier system where
> databases are unreadable depending on the order of $PATH.

libsqlite3.so in base was never meant for all-options-enabled
general-purpose use.  It serves some very specific purposes which are
incompatible with all-options-enabled general-purpose-use, it doesn't
hurt to avoid exposing that to pkgsrc, and it would have been better
not to expose to pkgsrc.  Applications are generally expected by the
sqlite3 authors to statically link their own copy of sqlite3 with
whatever options they need; using the same libsqlite3.so for many
applications is a pkgsrcism that requires pkgsrc-wide coordination.

For convenience the sqlite3 shell was included in /usr/bin, but it was
never part of base system integration (and was, perhaps, a mistake).
And it doesn't affect applications that use pkgsrc sqlite3 -- it just
affects interactive use.  (Scripts in pkgsrc should be patched to use
${PREFIX}/bin/sqlite3 -- if not, that's a bug.)

In contrast, libgssapi.so is designed to be used systematically by any
applications -- servers and clients -- designed to support integration
with the system's single-sign-on authentication.  So exposing the same
libgssapi.so to all applications for system integration is the whole
point.  Which is what made having it link against base's
limited-purpose libsqlite3.so so painful.

And, for the most part (except for this credential store extension
business), the different implementations of libgssapi.so have had a
pretty good track record of API compatibility, so it hasn't been an
issue until recently.

> > For example, maybe something like:
> > 
> > GSSAPI_REQD+=	credstoreext
> > .include "../../mk/krb5.buildlink3.mk"
> 
> +1

I looked closer and it occurs to me that, pending any implementation
of new machinery for this, we could fix postgresql16 by changing:

-.  include "../../security/mit-krb5/buildlink3.mk"
+KRB5_ACCEPTED=		mit-krb5
+.  include "../../mk/krb5.buildlink3.mk"

I will commit this today if there are no objections.

It looks like we have exactly two other direct users of mit-krb5
buildlink3.mk (other than security/mit-krb5-appl) which should maybe
get the same treatment if they really need mit-krb5:

comms/kermit
www/lighttpd

(But I haven't reviewed to see if it matters -- they don't expose
shared libraries, and I haven't checked to see if they ever pull in
base libgssapi.so or libkrb5.so; if not, their explicit use of
mit-krb5 buildlink3.mk may be harmless.)