Bug 199459 - www/squid 3.5.3 wrong handling of GSSAPI
Summary: www/squid 3.5.3 wrong handling of GSSAPI
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords: needs-patch, needs-qa
Depends on:
Blocks:
 
Reported: 2015-04-15 07:10 UTC by Konstantin Belousov
Modified: 2015-06-08 07:51 UTC (History)
1 user (show)

See Also:


Attachments
options file for the squid (1.49 KB, text/plain)
2015-04-15 07:10 UTC, Konstantin Belousov
no flags Details
ldd output of the squid binary (1.04 KB, text/plain)
2015-04-15 07:13 UTC, Konstantin Belousov
no flags Details
patch (536 bytes, patch)
2015-04-17 13:39 UTC, Pavel Timofeev
no flags Details | Diff
patch (538 bytes, patch)
2015-04-17 14:28 UTC, Pavel Timofeev
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Belousov freebsd_committer freebsd_triage 2015-04-15 07:10:20 UTC
Created attachment 155600 [details]
options file for the squid
Comment 1 Konstantin Belousov freebsd_committer freebsd_triage 2015-04-15 07:13:22 UTC
Created attachment 155601 [details]
ldd output of the squid binary
Comment 2 Konstantin Belousov freebsd_committer freebsd_triage 2015-04-15 07:15:23 UTC
Squid 3.5.3 on a stable/9 machine was configured with explicit request to not link against any gssapi libraries.  Despite that, it was linked against base gssapi.  See the attached options and ldd output.

Since the machine has openssl installed from ports, and squid linked to openssl, the image now depends on both base and port openssl, which is broken.
Comment 3 Pavel Timofeev 2015-04-15 08:09:26 UTC
At first glance it looks like it's rather a bug in squid itself, not in the port.
Because everything needed to switch off the kerberos was passed to squid's configure script, i.e  --without-heimdal-krb5 --without-mit-krb5 --without-gss and --enable-auth-negotiate=none.

I'll create a PR in squid bugzilla and see what happens.
Comment 4 Pavel Timofeev 2015-04-15 08:23:14 UTC
(In reply to timp87 from comment #3)

http://bugs.squid-cache.org/show_bug.cgi?id=4228
Comment 5 Pavel Timofeev 2015-04-17 13:39:12 UTC
Created attachment 155671 [details]
patch

The krb5-config is guilty.

Just put that file to /usr/ports/www/squid/files and rebuild port.
Comment 6 Pavel Timofeev 2015-04-17 13:45:12 UTC
Comment on attachment 155671 [details]
patch

Dang! It's wrong >:(
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2015-04-17 13:49:43 UTC
Note: This port has no maintainer, and submitter is committer.
Comment 8 Pavel Timofeev 2015-04-17 14:28:12 UTC
Created attachment 155672 [details]
patch

Make it ~never use pkg-config or krb5-config for detecting krb5 since we handle all of the krb5 options properly and pass the right paths to them.

Checked on 8, 9 and 10. All of them are amd64.
Comment 9 Konstantin Belousov freebsd_committer freebsd_triage 2015-04-19 09:02:33 UTC
(In reply to timp87 from comment #8)
I suppose this patch, even if works, cannot be upstreamed.  The configure.ac should be fixed to do the right thing, and then configure regenerated.

IMO such bug must be fixed in the upstream.
Comment 10 Pavel Timofeev 2015-04-19 10:07:25 UTC
(In reply to Konstantin Belousov from comment #9)
> I suppose this patch, even if works, cannot be upstreamed.

Definitely yes.

> The configure.ac should be fixed to do the right thing, and then configure regenerated.
>
> IMO such bug must be fixed in the upstream.

I agree again. And I hope they will fix it, but it seems to me they won't change anything in krb5 detection stuff before the next major release.
Comment 11 Pavel Timofeev 2015-04-22 07:06:44 UTC
(In reply to Konstantin Belousov from comment #9)
I suggest to apply my ugly patch now and wait when upstream fix it.
So, when they fix it we will remove ugly and apply their patch.
Comment 12 Pavel Timofeev 2015-05-08 15:00:53 UTC
Any objection? I would apply this ugly piece in next minor update for this port. Im gonna make it in a few days.
Comment 13 Konstantin Belousov freebsd_committer freebsd_triage 2015-05-08 16:13:48 UTC
(In reply to timp87 from comment #12)
Are you asking me ?  I have no opinion, and I am not a port committer.  Ideally, some fix would come from upstream, but what is there now is probably fine for the temporal measure.
Comment 14 Pavel Timofeev 2015-06-08 05:09:56 UTC
Hi! Squid-3.5.5 has just been committed with workaround for this problem. Try it, please.
Comment 15 Konstantin Belousov freebsd_committer freebsd_triage 2015-06-08 07:51:06 UTC
(In reply to timp87 from comment #14)
Freshly rebuilt squid 3.5.5. Output of ldd /usr/local/sbin/squid:

/usr/local/sbin/squid:
        librt.so.1 => /usr/lib/librt.so.1 (0x800d33000)
        libcrypt.so.5 => /lib/libcrypt.so.5 (0x800f38000)
        libssl.so.8 => /usr/local/lib/libssl.so.8 (0x801157000)
        libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x8013c9000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x8017fa000)
        libm.so.5 => /lib/libm.so.5 (0x801b01000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801d22000)
        libthr.so.3 => /lib/libthr.so.3 (0x801f30000)
        libc.so.7 => /lib/libc.so.7 (0x802153000)

Seems it worked, thanks.