Created attachment 234531 [details] [patch] accomodate krb5 1.20 Recently security/krb5 was updated to 1.20. The older sssd we have in the ports tree does not look for versions more than 1.19 Results from 'make -C security/sssd install': pkg-static: Unable to access file /z1/local/users/jhein/.nobak/wd/usr/ports/security/sssd/work-default/stage/usr/local/lib/krb5/plugins/authdata/sssd_pac_plugin.so:No such file or directory Or from 'make -C security/sssd stage check-plist': ===> Checking for items in pkg-plist which are not in STAGEDIR Error: Missing: lib/krb5/plugins/authdata/sssd_pac_plugin.so Error: Missing: libexec/sssd/sssd_pac ===> Error: Plist issues found. *** Error code 1 The attached patch fixes the problem by allowing krb5-1.20 to be an acceptable version. Alternately updating the port to a newer version of sssd could be beneficial as well.
The krb5-1.20 update was committed May 27. The sssd commit on June 3 should have failed if it was tested against the latest ports tree at the time.
^Triage: fernape added a message for checking sssd when updating krb in ports 11964e74b916 via bug 244778, potentially relevent here. Request feedback from fernape and krb maintainer
(In reply to Kubilay Kocak from comment #2) Yes, it is the same problem. When updating security/krb5, security/sssd *must* be at least build-tested. That is why I added the comment. I'm open to ideas on how to really force/encourage this check.
(In reply to Fernando Apesteguía from comment #3) Maybe add a build of sssd to a 'test' target? When someone does an upgrade, generally a 'make test' (if available) should be executed. I realize not everyone does a 'make test' (maybe with poudriere [[1]]), but at least it might be a little better than relying on people reading a comment. Alternatively (or in addition), there could be something in the Makefile that turns on when 'DEVELOPER=yes' is turned on. For example, a DEV_WARNING could be defined: DEV_WARNING= 'When updating the krb5 port, please make sure that security/sssd can build & install with all options combinations.' [[1]] I didn't see an option to run 'make test' for poudriere testport or bulk commands - seems like that should be an option (or maybe I missed it).
I can't reproduce this problem in a virgin 14-CURRENT jail. Can you list uname -a please.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d48f9f56aef74f7953e8cbd1783589cc053cf940 commit d48f9f56aef74f7953e8cbd1783589cc053cf940 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2022-06-08 20:05:27 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2022-06-08 20:19:55 +0000 security/sssd: Fix package after d33c01d9cc18 security/sssd fails to package with krb5 1.20 PR: 264526 Submitted by: John Hein <jcfyecrayz@liamekaens.com> Reported by: John Hein <jcfyecrayz@liamekaens.com> security/sssd/files/patch-src__external__pac_responder.m4 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
sssd should be updated to 2.2.3 as well.
(In reply to Cy Schubert from comment #5) % uname -a FreeBSD j12-64 12.3-STABLE FreeBSD 12.3-STABLE 1203500 amd64 To reproduce, you should build with the SMB option on (or FLAVOR=smb). That detail was missed in the original report - sorry about that. Thanks for committing the change. (In reply to Cy Schubert from comment #7) Updating to a different version was touched on in comment 0. Separate discussion that this bug, of course. 2.2.3 is from 2019. 2.7.1 was released a week ago - github is now the distribution site (the pagure site seems to be deprecated - it only has releases up to 2.2.3). FWIW, 2.7.1 still only references krb5 up to 1.19 in the pac_responder.m4 file. 1.16.* releases are on the long-term maintenance (LTM) branch, I believe, and are still supported. I think the 2.* releases are on the ssd "stable" track. I did not find clear documentation about the state of the LTM and stable release branches, including expected EOL time frames. Maybe I missed it in my searching. If we create a sssd port for a 2.* release, I would probably shoot for 2.7.1 - and maybe create a security/sssd-stable or security/sssd-ltm port in addition to security/sssd. I guess I would lean toward creating security/sssd-ltm ("repo copy" from the current 1.16.5 sssd port), and update sssd to 2.7.1 It may be that upstream is moving away from an LTM branch altogether - it's just not clear. This probably requires an upstream devel mailing list query. If they are moving away from the LTM concept, then just updating to 2.7.1 might be the way to go. That could be a big change for sssd users, however. Maybe a phab review with a call for testing would be in order.
(In reply to commit-hook from comment #6) Cy, it looks like the patch you committed is malformed - make patch fails. I just noticed this after fetching the latest and merging in your commit with my local ports tree. The @@ line update from the original patch was missed. This diff should fix it: --- a/security/sssd/files/patch-src__external__pac_responder.m4 +++ b/security/sssd/files/patch-src__external__pac_responder.m4 @@ -9,7 +9,7 @@ AC_MSG_CHECKING(for supported MIT krb5 version) KRB5_VERSION="`$KRB5_CONFIG --version`" case $KRB5_VERSION in -@@ -19,7 +19,9 @@ then +@@ -19,7 +19,10 @@ then Kerberos\ 5\ release\ 1.14* | \ Kerberos\ 5\ release\ 1.15* | \ Kerberos\ 5\ release\ 1.16* | \
(In reply to John Hein from comment #9) Geez. I can't add, can I.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=adcec87925971b825179437178ec402aa1ad3431 commit adcec87925971b825179437178ec402aa1ad3431 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2022-06-09 21:44:15 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2022-06-09 21:58:22 +0000 security/sssd: Fix patch Fix asimple off-by-one arthmetic error. PR: 264526 Reported by: John Hein <jcfyecrayz@liamekaens.com> Fixes: d48f9f56aef74f7953e8cbd1783589cc053cf940 security/sssd/files/patch-src__external__pac_responder.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to John Hein from comment #8) Closest I can find to a discussion of the latest upstream versioning thinking is: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/thread/VEYKBVASD4A4IDZGVOK3O47OFZDTMG6G/ No mention of LTM. To me that (and no updates to 1.16.* in a couple years) seems to imply the LTM branch concept is history. And the freebsd sssd should be updated to track the latest (2.7.1 now) after some testing from users. After that, updating to x.y.0 should be done conservatively and updates to x.y.z where z != 0 will generally be bug/security fixes and can probably be done quickly. Still a sssd devel mailing list query to confirm that line of reasoning would be prudent.
(In reply to John Hein from comment #12) I'd like to see the maintainer (lukas.slebodnik@intrak.sk) weigh in on this.
(In reply to John Hein from comment #8) Agreed. 2.7.1 should be imported.