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

[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

>>   2) Decide that if even one package needs an API in mit-krb5 but not
>>   heimdal, that krb5.buildlink3.mk should only allow mit-krb5.  Decide
>>   that any base lib that includes any heimdal lib is not allowed as
>>   builtin.  This is more or less what we did for sqlite3.
>> 
>>   3) Don't use base heimdal but patch in the new API to pkgsrc heimdal.
>> 
>>   4) Do nothing, leaving people who want to run qgis/postgis to do step
>>   1 locally, and risking an increasing number of official binaries being
>>   broken.
>
> 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.

Therefore, if building binary packages for general use, one has to avoid
heimdal for all of them.  Which is my option 2.


How do you propose to have bulk builds, so that

  - assuming we change pgsql default to 16
  - assuming someone makes pgsql default on in gdal

  - qgis will work


As I read your suggestion, it will be broken, but someone could do their
own builds putting GSSAPI_REQD+= credstoreext in mk.conf, so that
everything uses it.

Either way, we'd probably need to stop allowing builtin impls of things
that link with base heimdal.