Bug 247940
| Summary: | Introduce gssapi=.. in DEFAULT_VERSIONS like for ssl=... | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Michael Osipov <michael.osipov> |
| Component: | Ports Framework | Assignee: | Port Management Team <portmgr> |
| Status: | Open --- | ||
| Severity: | Affects Some People | CC: | arrowd, hrs, jrm, lwhsu, me, michael.osipov, michaelo, ports-bugs, tcberner |
| Priority: | --- | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277650 | ||
| Attachments: | |||
|
Description
Michael Osipov
2020-07-12 22:29:14 UTC
CC Uses/gssapi.mk maintainer. Moin moin This looks like something that could be done -- could you provide a patch with your proposed change? mfg Tobias (In reply to Tobias C. Berner from comment #2) In theory yes, but it will require some time. I need first to study how other DEFAULT_VERSIONS work. Don't expect a patch before November. (In reply to Michael Osipov from comment #3) Sounds good, thanks for looking into it :) Michael,
tl;dr I don't think using Mk/bsd.default-versions.mk for building ports with different Kerberos implementations is feasible.
For the default versions feature to make sense, we need ports to have USES=gssapi without specifying a Kerberos implementation. That way, a value set for DEFAULT_VERSIONS+=gssapi= can be used, or if that isn't set, we can fall back to the default of using Kerberos from base. However, this isn't how our 58 ports with USES=gssapi currently work.
Twelve ports have USES=gssapi without an OPTION, but they all hardcode the Kerberos implementation.
Of the remaining ports, the ones that have OPTION knobs for all of the Kerberos implementations could, in theory, be converted to use a default version, but there are complications. For example, many of them require different configure flags. For example, here is what we have in security/cyrus-sasl2-gssapi/Makefile
GSSAPI_HEIMDAL_USES= gssapi:heimdal,flags
GSSAPI_HEIMDAL_CONFIGURE_ON= --enable-gssapi="${GSSAPIBASEDIR}" \
--with-gss_impl=heimdal
but other ports like security/samba416 have
GSSAPI_HEIMDAL_CONFIGURE_ON= --with-system-heimdalkrb5 ${GSSAPIBASEDIR}
GSSAPI_HEIMDAL_USES= gssapi:heimdal
GSSAPI_HEIMDAL_PREVENTS= AD_DC
GSSAPI_HEIMDAL_PREVENTS_MSG= GSSAPI_HEIMDAL and AD_DC enable conflicting options
A workaround is to specify something like this in /etc/make.conf.
.if ${.CURDIR:M*/net/samba*}
WITHOUT=GSSAPI_BUILTIN
WITH=GSSAPI_MIT
.endif
You still have to think about individual ports, but at least you can share this configuration between systems, and you won't have to go through the configuration dialogs manually.
I hope this helps.
Joe
(In reply to Joseph Mingrone from comment #5) I reread the comments in Mk/bsd.options.mk. Rather than setting WITH and WITHOUT in /etc/make.conf, it's recommended to use something like this: net_samba416_UNSET+=GSSAPI_BUILTIN net_samba416_SET+=GSSAPI_MIT WITH= and WITHOUT= can be set on the command line, and the values override those set in /etc/make.conf. (In reply to Joseph Mingrone from comment #5) This I have partially assumed, but there is still room for improvement even if it cannnot be fully generalized. Consider that we have gssapi=base|mit|heimdal which can first define the OPTIONS and their descriptions, much like with X11 AND the options can globally be preset in make.conf and all ports follow suit the way they think is right. I have plenty of ports which should have MIT Kerberos, instead of doing gssapi=mit, I need to touch every single options file. I don't explicitly strive to set the exact same flags for the every Kerberos flavor to all ports, but pull up that flavor decision globally. At least these I need to touch instead of setting it globally. Yet another benefit could be that if gssapi=base is the default, all default packages provided by FreeBSD.org would link against base Heimdal. Those, like me, who need something else can use ports. dns/bind-tools ftp/curl security/cyrus-sasl2-gssapi sysutils/msktutil www/serf databases/postgresql13-server www/mod_auth_gssapi security/py-gssapi At least some of them are automatic dependencies which I still need to document because I need to provide an options file in /var/db/ports. May a call would be better to discuss this further? (In reply to Michael Osipov from comment #8) A call sounds good. I'll contact you by email. (In reply to Michael Osipov from comment #7) Based on your latest comment, there may be a few improvements we can make. - Update the default options for some ports, so hopefully you have fewer packages to build yourself. - Ensure that more ports use standardized names for the GSSAPI/Kerberos options. Of the ports you listed, most have the option names GSSAPI_BASE GSSAPI_HEIMDAL GSSAPI_MIT, so we're close. A few also have GSSAPI_NONE. This is good because it means you can put something like what's below in make.conf to configure most ports that have a GSSAPI knob and avoid the port dialogues. OPTIONS_SET_FORCE+=GSSAPI_MIT OPTIONS_UNSET_FORCE+=GSSAPI_BASE GSSAPI_HEIMDAL GSSAPI_NONE If there is a specific port, like ftp/curl, that you want configured differently, you also add this to make.conf. ftp_curl_SET_FORCE+=GSSAPI_HEIMDAL ftp_curl_UNSET_FORCE+=GSSAPI_BASE GSSAPI_MIT GSSAPI_NONE I tested by putting these lines in /usr/local/etc/poudriere.d/15amd64-make.conf and built the ports without answering any dialogues. This is the result. % pkg info dns/bind918 | grep GSSAPI GSSAPI_BASE : off GSSAPI_HEIMDAL : off GSSAPI_MIT : on GSSAPI_NONE : off # pkg info curl | grep GSSAPI GSSAPI_BASE : off GSSAPI_HEIMDAL : on GSSAPI_MIT : off GSSAPI_NONE : off Is this helpful? Joe (In reply to Joseph Mingrone from comment #10) Yes, this is helpful, but still circumvents DEFAULT_VERSIONS. This causes another question: Can't make it even simpler by defining the OPTIONS (4) in gssapi.mk and remove them from the Makefile so they are injected into the port with USES=gssapi. Similar I do with X11, I just say that I need it, that's it. WDYT? Adding to this discussion due to a new issue that comes up with the move to OpenSSL 3 in FreeBSD 14. I use heimdal as my preferred kerberos implementation. Heimdal upstream hasn't seen a release in a while (current version is 7.8), and heimdal-devel (tracking git HEAD) fixes a bunch of issues related to OpenSSL 3 support. I'd ideally like to use heimdal-devel as my gssapi provider in all ports that support it. Currently, I don't see an option to use heimdal-devel (or even MIT krb5-devel) as the gssapi provider in any ports. I do mostly see the following OPTIONS being supported across the board in a mostly-standard way as comment #10 suggests: * GSSAPI_NONE * GSSAPI_BASE * GSSAPI_HEIMDAL * GSSAPI_MIT I'd additionally like to see the following: * GSSAPI_HEIMDAL_DEVEL * GSSAPI_MIT_DEVEL But instead of adding support for these to every port that can support them, I'd like to see support for choosing the version added to the DEFAULT_VERSIONS framework. I am in support of the proposal to: * Replace all port OPTIONS of the form GSSAPI_* to simply GSSAPI, which will enable or disable GSSAPI support in a given port * Move the choice of the GSSAPI provider to the DEFAULT_VERSIONS framework in the form of 'gssapi=(heimdal|heimdal-devel|mit|mit-devel)' If there is consensus, I can help prepare a patchset (if one doesn't already exist as a work-in-progress) for converting all ports, along with adding the support to the DEFAULT_VERSIONS framework. Created attachment 247505 [details]
[PATCH] USES=gssapi: allow provider choice using DEFAULT_VERSIONS
Here is a patch that adds gssapi to DEFAULT_VERSIONS and makes the necessary changes to an example port (in this case, mail/dovecot) for end-users to use DEFAULT_VERSIONS to select their gssapi provider instead of port OPTIONS.
Let me know if this is suitable and I will make the necessary changes to all ports that enable GSSAPI support and submit a patchset for it.
Created attachment 247558 [details]
[PATCH v2] USES=gssapi: allow provider choice using DEFAULT_VERSIONS
Fixed the patch to correctly read all USES arguments
(In reply to Siva Mahadevan from comment #12) Any feedback on this proposal? I now have the bandwidth to work on moving all ports to use the gssapi DEFAULT_VERSIONS change (with my patch from comment #14 as an example of what I mean). I can work on it and submit a patchset if it sounds good to everyone. Hi Siva, Thanks for your submission. I think we need to hear from osipov@ (OP and heavy kerberos user) and hrs@ (gssapi.mk maintainer). Let's give it another week and if we don't hear back from them, I'll try taking a closer look. Cy Shubert is working on importing MIT Kerberos into base. This should probably allow us to get rid of USES=gssapi altogether, if I understand it right. (In reply to Gleb Popov from comment #17) Wouldn't this just change the default base version from 'heimdal' to 'mit'? We would still need some way of choosing the GSSAPI provider for ports that depend on it right? I thought USES=gssapi allows passing in args to choose the provider. That's right, but I remember someone saying that most ports are actually using MIT implementation as it is more contemporary. I hope we can just get rid of Heimdal at some point. (In reply to Gleb Popov from comment #19) I don't necessarily think we can make this conclusion. Heimdal is still actively developed, with a new release soon to come with a lot of fixes. I still personally use it in all my projects, and if I understand correctly, some very crucial ports like net/samba* only officially support Heimdal (with experimental support for MIT). In fact, the purpose of my patch is to allow users to choose heimdal-devel and mit-devel as GSSAPI providers. Ok, the change makes sense and looks pretty good to me. I don't like the idea of changing the default based on some file presence. I think the default should be just "base" - it is simple and foolproof. Another little nitpick is a bit a misleading name of the GSSAPI_VER variable. But I don't have an idea how to name it better. Thanks for working on this! The patch does not apply to the current tree, can you please rebase? I will get back to this next week. Currently absent. Created attachment 249611 [details]
[PATCH] USES=gssapi: allow provider choice using DEFAULT_VERSIONS
Rebased and added changes based on feedback. Still keeping mail/dovecot as an example change. If accepted, I'll prepare the patchset for all ports that need this change.
GSSAPI_PROJECT should be renamed to GSSAPI_VENDOR just like "krb5-config --vendor". There is a problem with the patch. mail/dovecot was likely a bad example neither after not before the match "make debug-krb" work.
I have also patched ftp/curl and I see:
root@deblndw011x:/var/poudriere/ports/default-head/ftp/curl (main *%=)
# make debug-krb
make: "/var/poudriere/ports/default-head/Mk/Uses/gssapi.mk" line 110: Unknown directive "GSSAPI"
make: "/var/poudriere/ports/default-head/Mk/Uses/gssapi.mk" line 153: Unknown directive "GSSAPI"
make: "/var/poudriere/ports/default-head/Mk/Uses/gssapi.mk" line 160: Unknown directive "GSSAPI"
make: Fatal errors encountered -- cannot continue
make: stopped in /var/poudriere/ports/default-head/ftp/curl
after removing the dangling GSSAPI_PROVIDER I am able to call (gssapi=mit):
root@deblndw011x:/var/poudriere/ports/default-head/ftp/curl (main *%=)
# make debug-krb
cc -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -o /tmp/debug-krb.x -I"/usr/local/include" -lkrb5 -lgssapi_krb5 -L"/usr/local/lib" -Wl,-rpath,/usr/local/lib /tmp/debug-krb.c && ldd /tmp/debug-krb.x; /bin/rm -f /tmp/debug-krb.x
/tmp/debug-krb.x:
libkrb5.so.3.3 => /usr/local/lib/libkrb5.so.3.3 (0x3071b77d5000)
libgssapi_krb5.so.2.2 => /usr/local/lib/libgssapi_krb5.so.2.2 (0x3071b7d90000)
libc.so.7 => /lib/libc.so.7 (0x3071b92fb000)
libk5crypto.so.3.1 => /usr/local/lib/libk5crypto.so.3.1 (0x3071b8057000)
libcom_err.so.3.0 => /usr/local/lib/libcom_err.so.3.0 (0x3071b8465000)
libkrb5support.so.0.1 => /usr/local/lib/libkrb5support.so.0.1 (0x3071ba5bb000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x3071bb43d000)
[vdso] (0x7ffffffff000)
PREFIX: /usr/local
GSSAPIBASEDIR: /usr/local
GSSAPIINCDIR: /usr/local/include
GSSAPILIBDIR: /usr/local/lib
GSSAPILIBS: -lkrb5 -lgssapi_krb5
GSSAPICPPFLAGS: -I/usr/local/include
GSSAPILDFLAGS: -L/usr/local/lib
GSSAPI_PROJECT: mit
GSSAPI_PROVIDER: mit
GSSAPI_CONFIGURE_ARGS: CFLAGS=-I/usr/local/include -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing LDFLAGS=-L/usr/local/lib -L/usr/local/lib -L/usr/lib -L/usr/lib -fstack-protector-strong LIBS=-lkrb5 -lgssapi_krb5 -lkrb5 -lgssapi_krb5 -L/usr/local/lib KRB5CONFIG=/usr/local/bin/krb5-config
KRB5CONFIG: /usr/local/bin/krb5-config
CFLAGS: -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing
LDFLAGS: -L/usr/local/lib -L/usr/lib -L/usr/lib -fstack-protector-strong
LDADD:
Please double check
Created attachment 249668 [details]
[PATCH v3] USES=gssapi: allow provider choice using DEFAULT_VERSIONS
Sorry about that, somehow all the ".else" directives in my patch got replaced with GSSAPI_PROVIDER. I think it was a bad merge :)
I tested this one with building dovecot and choosing different providers with DEFAULT_VERSIONS works. Please test on your end as well.
(In reply to Siva Mahadevan from comment #27) Did some basic testing on my end, at least for those two ports it does work. I'll modify some more ports I need with Kerberos support and run a poudriere build of them: dns/bind-tools security/cyrus-sasl2-gssapi www/serf ftp/curl net/openldap26-client sysutils/msktutil Created attachment 249682 [details] My attempt So I took your patch and gave it a spin with the mentioned ports. See my incomplete patch to those ports. In general it does magically and actually the way I wanted it in the first place: one knob and there you go. There are a few problems though and I don't know whether they exist as of today already especially with Heimdal from ports and base. I issues I have observed: cyrus-sasl2-gssapi: heimdal no plugin, order of configure args is a problem (tricky) serf: heimdal ports libs is mixed with base (ldd output) mit-devel worked. Moreover, this will also need a patch for https://docs.freebsd.org/en/books/porters-handbook/book/#uses-gssapi To move this foward this needs several reviewers: jrm@, cy@, several port maintainers and some kind of exp-run with those args. Can you identify all affected ports? Thanks for working on this. Created attachment 250138 [details]
List of affected ports using GSSAPI
At a first glance, here's the list of affected ports. For the large majority of them, it's trivial to add support for DEFAULT_VERSIONS. I already have a patchlist that covers most of them. I can easily make commits for all the affected ports and send a `git request-pull` here for everyone to review. I'll also add a commit to the docs tree for the requested porters handbook change.
(In reply to Siva Mahadevan from comment #30) Please do so. |
