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

[Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost>]

> Date: Wed, 04 Sep 2024 07:46:58 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost> writes:
> 
> > 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
> 
> Interesting, but that won't help, because we'd have to have:
> 
>   heimdal release
>   import into pkgsrc
>   import into netbsd base (plausible up to here)
>   pull up to 9
>   pull up to 10
>   declare that pkgsrc only supports netbsd-9 and netbsd-10, not the 9.0/10.0

Yes.  I didn't mean to suggest this would resolve the issue.

> > I don't think any of these answers is right.  Mixing gssapi
> > implementations is doomed to failure.  Instead, pkgsrc should have
> > some way to request krb5/gssapi extensions.  And if the implementation
> > chosen can't satisfy them, the package build should noisily fail.
> > Builders can change the _treewide_ krb5/gssapi implementation choice
> > in order to make this consistent.
> 
> > For example, maybe something like:
> >
> > GSSAPI_REQD+=	credstoreext
> > .include "../../mk/krb5.buildlink3.mk"
> 
> That is essentially open-coded right now, and lead to a bad failure.
> pgsql16 direct-includes mit-krb5; if we added that variable and put
> logic to require mit in krb5.buildlink3.mk, it would be the same.
> 
> The problem is that if one package needs this, and some other package
> doesn't, and then you link libs from both together, it explodes.

No -- what I meant is that krb5.buildlink3.mk would set
PKG_FAIL_REASON if it cannot be satisfied, not that it would silently
swap in a library that breaks everything downstream.

This is what already happens when a package uses the mechanism it
turns out we already have for this kind of thing:

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

So I intend to commit a change to databases/postgresql16-client
shortly that does this.

> How do you propose to have bulk builds, so that
> [...] 
>   - assuming someone makes pgsql default on in gdal

I believe we can put this assumption off indefinitely, based on the
following comment you wrote in 2014 which has persisted for a decade:

# By default, omit database support, because there isn't an
# articulated use case and dependency management becomes very painful.
# For example, depending on pgsql fixes a version, but doesn't put it
# in the name, and then building postgis fails for all but that one
# chosen version.

So, since pgsql is not default in gdal-lib (for reasons, other than
the gssapi one, which have evidently been stable for a decade):

1. Right now, binary packages don't have pgsql or mysql support in
   gdal-lib.  Applying the change

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

   to databases/postgresql16-client will not change this.

   => No regression.

2. Right now, if you configure custom packages with

PKG_OPTIONS.gdal-lib+=	pgsql

   in mk.conf without also setting KRB5_TYPE=mit-krb5 in mk.conf on
   NetBSD, what you will get is packages that fail mysteriously at
   run-time (as you observed).  But if we apply the change

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

   then they will fail obviously at build-time.

   => Improvement.

3. Right now, if you configure custom packages with

PKG_OPTIONS.gdal-lib+=	pgsql
KRB5_TYPE=		mit-krb5

   in mk.conf, what you will get (I suspect) is working packages.  And
   if we apply the change

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

   then that will continue to work with no change.

   => No regression.

So under all three of these scenarios the situation is not worse than
before.  And in the one scenario you hit a problem in, with a certain
combination of custom build options, the situation is improved by
turning mysterious failure at run-time into obvious failure at
build-time.