Bug#495163: useless static library due to libkrb5

[Trent W. Buck]

Package: libcurl4-openssl-dev
Severity: normal

Darcs can no longer be statically built with curl on Debian. This
appears to be due to

http://bugs.debian.org/439039
libkrb5-dev: static libraries no longer supported

It appears that this can be resolved by building libcurl's static
version *without* kerberos support. Therefore I recommend this.

Please refer to this upstream bug for more information:

http://bugs.darcs.net/issue806
Cannot build static Darcs 2 on Debian (krb static lib missing)

-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libcurl4-openssl-dev depends on:
ii libc6-dev [libc-dev] 2.7-13 GNU C Library: Development Librari
ii libcurl3 7.18.2-5 Multi-protocol file transfer libra
pn libidn11-dev <none> (no description available)
pn libkrb5-dev | hurd <none> (no description available)
pn libldap2-dev <none> (no description available)
pn libssh2-1-dev <none> (no description available)
pn libssl-dev <none> (no description available)
pn zlib1g-dev <none> (no description available)

libcurl4-openssl-dev recommends no packages.

Versions of packages libcurl4-openssl-dev suggests:
pn libcurl3-dbg <none> (no description available)

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Andreas Schuldei]

* Trent W. Buck (tren...@gmail.com) [080815 03:05]:

> Package: libcurl4-openssl-dev
> Severity: normal
>
> Darcs can no longer be statically built with curl on Debian. This
> appears to be due to
>
> http://bugs.debian.org/439039
> libkrb5-dev: static libraries no longer supported

i suggest that it is because curl stopped linking against libs that it
does not need. especially there was a whole lot of kerberos libs that
got pulled in from the kerberos configure (krb5-config) binary that were
not actually needed within curl. So we pruned both the the list of libs
that got pulled in for no good and also we stopped exporting libs in
libcurl.pc and libcurl.la that were not needed in order to link against
curl. So most likely you now run into problems when using libs that got
pulled in via curl and are used in some other context. my recommendation
is to figure out your dependencies (gssapi_krb5 is a hot candidate!),
add them to your build-depends and link to them.

i am not sure what package this bug should be filed against. i think it
is either darcs or kerberos.

/andreas

[Andreas Schuldei]

* Andreas Schuldei (and...@schuldei.org) [080815 10:14]:

> i am not sure what package this bug should be filed against. i think it
> is either darcs or kerberos.

after closer inspection i find this in curl-config.in:

echo @libdir@/libcurl.@libext@ @LDFLAGS@ @LIBCURL_LIBS@ @LIBS@

which contains LDFLAGS. this needs to go away. so this is my bug after
all.

is this relevant for lenny?

[Trent W. Buck]

On Fri, Aug 15, 2008 at 10:58:54AM +0200, Andreas Schuldei wrote:
> is this relevant for lenny?

Within Debian, the darcs package is only ever dynamically linked. The
issue was raised by users who are creating statically linked versions
of the current Darcs release on Lenny, to run on Etch.

I assume that this IS NOT relevant to Lenny's release, since once
Lenny becomes Stable I think the users will be building static
binaries on Lenny+1 for use on Lenny.

[Dmitry Kurochkin]

Hi Andreas.

On Fri, Aug 15, 2008 at 12:58 PM, Andreas Schuldei <and...@schuldei.org> wrote:
> * Andreas Schuldei (and...@schuldei.org) [080815 10:14]:
>> i am not sure what package this bug should be filed against. i think it
>> is either darcs or kerberos.
>
> after closer inspection i find this in curl-config.in:
>
> echo @libdir@/libcurl.@libext@ @LDFLAGS@ @LIBCURL_LIBS@ @LIBS@
>
> which contains LDFLAGS. this needs to go away. so this is my bug after
> all.

I am afraid the bug is not as simple as removing -lgssapi_krb5 from
'curl-config --static-libs' output. I tried compiling static darcs
with gssapi_krb5 library removed and I get a bunch of undefined
symbols (like gss_unseal) referenced from libcurl.a.

My understanding is that static libcurl really uses these functions.
And to resolve the bug we need to build static libcurl without gssapi
support.

Regards,
Dmitry

[Hannes von Haugwitz]

Hi,

What is the state of this bug?

I would like to add curl support to the aide pkg (which is statically
linked).

Thanks

Hannes

[Trent W. Buck]

Hannes von Haugwitz wrote:
> What is the state of this bug? I would like to add curl support to
> the aide pkg (which is statically linked).

AFAIK, no change.

If it were a private package, I'd advise you to reroll curl without
kerberos support, so it can be statically linked into aide. To do
that within Debian, I guess you'd need the curl maintainer to provide
an alternative libcurl-static-dev or something.

[Alessandro Ghedini]

tags 495163 confirmed
kthxbye

On Fri, Aug 15, 2008 at 10:58:31AM +1000, Trent W. Buck wrote:
> Package: libcurl4-openssl-dev
> Severity: normal
>
> Darcs can no longer be statically built with curl on Debian. This
> appears to be due to
>
> http://bugs.debian.org/439039
> libkrb5-dev: static libraries no longer supported
>
> It appears that this can be resolved by building libcurl's static
> version *without* kerberos support. Therefore I recommend this.

An alternative solution would be to build curl with Heimdal (AFAICT they do
provide the static library) instead of the MIT kerberos implementation.

I'm not sure on the consequences of such change though, and I will need to
do some testing first.

Cheers

--
perl -E'$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'

[Hannes von Haugwitz]

Hello,

On Sat, Feb 18, 2012 at 05:01:14PM +0100, Alessandro Ghedini wrote:
> An alternative solution would be to build curl with Heimdal (AFAICT they do
> provide the static library) instead of the MIT kerberos implementation.
>
> I'm not sure on the consequences of such change though, and I will need to
> do some testing first.

Is there any progress with this issue?

Best regards

Hannes

[Alessandro Ghedini]

On Tue, Apr 10, 2012 at 11:14:25AM +0200, Hannes von Haugwitz wrote:
> Hello,
>
> On Sat, Feb 18, 2012 at 05:01:14PM +0100, Alessandro Ghedini wrote:
> > An alternative solution would be to build curl with Heimdal (AFAICT they do
> > provide the static library) instead of the MIT kerberos implementation.
> >
> > I'm not sure on the consequences of such change though, and I will need to
> > do some testing first.
>
> Is there any progress with this issue?

Not much. I'm still quite uncomfortable on replacing MIT kerberos, the reference
implementation of Kerberos and the default one on Debian, with another, less
used and tested, alternative.

[Trent W. Buck]

Alessandro Ghedini wrote:
> On Tue, Apr 10, 2012 at 11:14:25AM +0200, Hannes von Haugwitz wrote:
> > Hello,
> >
> > On Sat, Feb 18, 2012 at 05:01:14PM +0100, Alessandro Ghedini wrote:
> > > An alternative solution would be to build curl with Heimdal (AFAICT they do
> > > provide the static library) instead of the MIT kerberos implementation.
> > >
> > > I'm not sure on the consequences of such change though, and I will need to
> > > do some testing first.
> >
> > Is there any progress with this issue?
>
> Not much. I'm still quite uncomfortable on replacing MIT kerberos, the reference
> implementation of Kerberos and the default one on Debian, with another, less
> used and tested, alternative.

Would it be possible to use MIT krb for the dynamic libcurl, and *no*
krb for the static libcurl? The krb part is, after all, only used for
SPNEGO, and the set intersection of "people who want static libcurl"
and "people who need krb" is probably pretty small.

[Hannes von Haugwitz]

On Thu, Apr 12, 2012 at 12:36:21AM +1000, Trent W. Buck wrote:
> Alessandro Ghedini wrote:
> > Not much. I'm still quite uncomfortable on replacing MIT kerberos, the reference
> > implementation of Kerberos and the default one on Debian, with another, less
> > used and tested, alternative.
>
> Would it be possible to use MIT krb for the dynamic libcurl, and *no*
> krb for the static libcurl? The krb part is, after all, only used for
> SPNEGO, and the set intersection of "people who want static libcurl"
> and "people who need krb" is probably pretty small.

I second that. A static library without krb is better than the current
one which is not usable at all.

Best regards

Hannes

[Alessandro Ghedini]

On Wed, Apr 11, 2012 at 05:44:01PM +0200, Hannes von Haugwitz wrote:
> On Thu, Apr 12, 2012 at 12:36:21AM +1000, Trent W. Buck wrote:
> > Alessandro Ghedini wrote:
> > > Not much. I'm still quite uncomfortable on replacing MIT kerberos, the reference
> > > implementation of Kerberos and the default one on Debian, with another, less
> > > used and tested, alternative.
> >
> > Would it be possible to use MIT krb for the dynamic libcurl, and *no*
> > krb for the static libcurl? The krb part is, after all, only used for
> > SPNEGO, and the set intersection of "people who want static libcurl"
> > and "people who need krb" is probably pretty small.
>
> I second that. A static library without krb is better than the current
> one which is not usable at all.

That's just not true. Nothing stops you from using the static libcurl library
and linking to the shared krb5, which is installed on pretty much every Debian
system, being it priority standard.

[Alessandro Ghedini]

On Thu, Apr 12, 2012 at 12:36:21AM +1000, Trent W. Buck wrote:
> Alessandro Ghedini wrote:
> > On Tue, Apr 10, 2012 at 11:14:25AM +0200, Hannes von Haugwitz wrote:
> > > Hello,
> > >
> > > On Sat, Feb 18, 2012 at 05:01:14PM +0100, Alessandro Ghedini wrote:
> > > > An alternative solution would be to build curl with Heimdal (AFAICT they do
> > > > provide the static library) instead of the MIT kerberos implementation.
> > > >
> > > > I'm not sure on the consequences of such change though, and I will need to
> > > > do some testing first.
> > >
> > > Is there any progress with this issue?
> >
> > Not much. I'm still quite uncomfortable on replacing MIT kerberos, the reference
> > implementation of Kerberos and the default one on Debian, with another, less
> > used and tested, alternative.
>
> Would it be possible to use MIT krb for the dynamic libcurl, and *no*
> krb for the static libcurl? The krb part is, after all, only used for
> SPNEGO, and the set intersection of "people who want static libcurl"
> and "people who need krb" is probably pretty small.

Shipping a not compatible static library would be even worse. Not to mention the
fact that every libcurl flavour would need to be re-built multiple times only
for removing a dependency on the static library.

Anyway, as a first step I can upload a curl package that lists heimdal as an
alterative build dependency. krb5 would remain the default choice for now, but
at least it would make re-building curl with heimdal much easier (just like
openssh does). If nothing bad happens I can re-consider switching to heimdal by
default.

[Trent W. Buck]

Alessandro Ghedini wrote:

> Hannes von Haugwitz wrote:
>> A static library without krb is better than the current one which
>> is not usable at all.
>
> That's just not true. Nothing stops you from using the static
> libcurl library and linking to the shared krb5, which is installed
> on pretty much every Debian system, being it priority standard.

My original purpose in building a static Darcs binary was so I could
run it on a system that was too old to support a Haskell compiler --
probably Fedora Core 3 and RHEL 4.

I assumed that people normally built static binaries for that reason,
i.e. because they needed a program to run on a legacy host. I'm not
sure such legacy hosts would have a libkrb installed that would be
compatible with what a statically-linked-curl/dynamically-linked-krb
binary would expect.

The other part of the problem would be how to tell Darcs' build system
to statically link some C libraries, but not others. Of course, that
is not your problem, but it would still need to be dealt with.


PS: since this ticket was opened, I have murdered the FC3/RHEL4 hosts
in question -- all my hosts have OSs from 2008 or later! So I don't
have a burning need for this ticket to be resolved anymore, though I'd
still to help reach a consensus.

[Trent W. Buck]

Alessandro Ghedini wrote:
>> Would it be possible to use MIT krb for the dynamic libcurl, and
>> *no* krb for the static libcurl? The krb part is, after all, only
>> used for SPNEGO, and the set intersection of "people who want
>> static libcurl" and "people who need krb" is probably pretty
>> small.
>

> [...] Not to mention the fact that every libcurl flavour would need

> to be re-built multiple times only for removing a dependency on the
> static library.

Ah, OK, I thought you already had to build multiple times to get the
dynamic and static versions in the first place. I guess that shows my
ignorance of library packaging. If you're not already rebuilding, I
agree that doing so just for this would not be worth it.

[Hannes von Haugwitz]

On Thu, Apr 12, 2012 at 12:36:21AM +1000, Trent W. Buck wrote:
> Alessandro Ghedini wrote:
> > Not much. I'm still quite uncomfortable on replacing MIT kerberos, the reference
> > implementation of Kerberos and the default one on Debian, with another, less
> > used and tested, alternative.
>
> Would it be possible to use MIT krb for the dynamic libcurl, and *no*
> krb for the static libcurl? The krb part is, after all, only used for
> SPNEGO, and the set intersection of "people who want static libcurl"
> and "people who need krb" is probably pretty small.

Is there any progress with this bug?

I'd like to reach a consensus that enables me to provide the statically
linked aide pkg with curl support?

Best regards

Hannes

[Alessandro Ghedini]

[ CCed the krb5 maintainers, see below ]

On ven, mag 10, 2013 at 10:41:29 +0200, Hannes von Haugwitz wrote:
> On Thu, Apr 12, 2012 at 12:36:21AM +1000, Trent W. Buck wrote:
> > Alessandro Ghedini wrote:
> > > Not much. I'm still quite uncomfortable on replacing MIT kerberos, the reference
> > > implementation of Kerberos and the default one on Debian, with another, less
> > > used and tested, alternative.
> >
> > Would it be possible to use MIT krb for the dynamic libcurl, and *no*
> > krb for the static libcurl? The krb part is, after all, only used for
> > SPNEGO, and the set intersection of "people who want static libcurl"
> > and "people who need krb" is probably pretty small.
>
> Is there any progress with this bug?

Nope. Note that in any case, I do not intend to provide static libcurl builds
without the krb5 support (having shared and static builds of the same library
with different features in the same package is just silly).

> I'd like to reach a consensus that enables me to provide the statically
> linked aide pkg with curl support?

I've just looked into the krb5 sources, and I noticed that it does in fact
support static builds. This can be enabled by passing --enable-static to the
configure script (I just tried it, and it seems to work, altough I didn't
actually try to use the generated libraries). The problem with this is that you
can't build both static and shared in the same build cycle (at least, not with
the krb5 version in Debian, maybe the new upstream release supports this?).

The best possible solution as far as I'm concerned, would be that someone
starts providing such krb5 static builds, either as a different source package
(in which case krb5 would have to provide a -source package, like e.g. gcc, and
the new package makes use of it and the Built-Using thingy), or as part of the
krb5 source package itself.

Now, do the krb5 maintainers think that this is actually possible? If so, are
they interested in providing such static builds?

Also CCed #439039 for reference.

[Sam Hartman]

There are reasons that the krb5 upstream build does not include static
libs.

The main problem is that more and more krb5 depends on plugins for
various things.
As an example, preauthentication, KDC location,' GSS-API mechanisms all
support plugins.

In the krb5 in wheezy, you cannot request FAST credentials in some
realms without plugin support. I think it's a different set of things
that fail in krb5 1.11, but generally you cannot assume that a static
build of krb5 will provide acceptable functionality for general use.
The reason the upstream build system supports static is because for
certain test coverage analysis gcc works a lot better with static
objects.

So, I'm open to including static support in a special package (not
libkrb5-dev), but I'd need to understand the use case and be convinced
it's actually a good idea.
Like the curl maintainer I'm very uncomfortable producing builds that
have a different set of functionality between static and
dynamic. However it's more or less inherently true that will be the case
for krb5.

--Sam

[Alessandro Ghedini]

On ven, mag 10, 2013 at 07:33:16 -0400, Sam Hartman wrote:
> So, I'm open to including static support in a special package (not
> libkrb5-dev), but I'd need to understand the use case and be convinced
> it's actually a good idea.

If I understood this, Hannes wants to enable support for libcurl in the aide
package which only provides statically linked binaries. So, not only the
libcurl static build is needed, but also all the libcurl dependencies, and the
only one missing a static library is libgssapi-krb5.

I don't know *why* the aide package needs to be statically linked though.

[Russ Allbery]

Alessandro Ghedini <gh...@debian.org> writes:
> On ven, mag 10, 2013 at 07:33:16 -0400, Sam Hartman wrote:

>> So, I'm open to including static support in a special package (not
>> libkrb5-dev), but I'd need to understand the use case and be convinced
>> it's actually a good idea.

> If I understood this, Hannes wants to enable support for libcurl in the
> aide package which only provides statically linked binaries. So, not
> only the libcurl static build is needed, but also all the libcurl
> dependencies, and the only one missing a static library is
> libgssapi-krb5.

> I don't know *why* the aide package needs to be statically linked though.

aide is an intrusion detection tool, and the old rule of thumb for such
things was to statically link them so that the tool itself couldn't be
compromised via compromised shared libraries or tools like LD_PRELOAD.

It's not really security, as of course the attacker could just replace the
statically linked aide binary with a different one with different
behavior, or use dynamically loaded kernel modules (if they're enabled) to
change behavior at that level. But it's a hurdle that an unsophisticated
attacker may not cross. (Your guess is as good as mine on how many
attackers are sophisticated enough to manipulate shared libraries on a
system to hide an attack from an intrusion detection tool, yet don't know
enough to manipulate the tool itself.)

It's a very specialized use case. If we had installable source packages,
I'd suggest to the aide maintainers that they install src:curl during the
build and just build their own static version of the cURL library with the
support they actually need. Alas, we don't.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

[Sam Hartman]

My recommendation is that we talk to the security team.
The biggest disadvantage of all these static libs running around is the
number of packages they need to do security updates for.
We could ask them about whether it's better to have:

1) no static aide

2) a static libcurl with less functionality, so aide needs to get
libcurl security updates but not krb5 security updates

3) A static aide with libcurl and somewhat crippled Kerberos meaning
that aide needs to get libcurl and krb5 updates.
In addition libcurl might potentially need to get rebuilt on Kerberos
security updates.

I'm happy to go along with whatever they are comfortable with.
I'd stick the static libs probably in a libkrb5-static package.

[Hannes von Haugwitz]

Dear security team,

as suggested by Sam I ask you to comment on the following issue.

I want to statically link my package aide to libcurl, which is
statically linked for security reasons. Since krb5 does not support
static libraries any longer (#439039), the static library of libcurl is
now useless (#495163) and therefor cannot be used by the aide package.

The options so far proposed in the discussion are described in the
quoted message below.

I for one would really dislike to drop the static aide binary and think
a static curl library without krb support is better than the current
one, which is not usable at all.

What is your opinion?

Thanks

Hannes

[Alessandro Ghedini]

On sab, mag 18, 2013 at 11:38:15 +0200, Hannes von Haugwitz wrote:
> Dear security team,
>
> as suggested by Sam I ask you to comment on the following issue.
>
> I want to statically link my package aide to libcurl, which is
> statically linked for security reasons. Since krb5 does not support
> static libraries any longer (#439039), the static library of libcurl is
> now useless (#495163) and therefor cannot be used by the aide package.

It's useless *for aide purposes*. Again. nothing prevents other people from
using the static libcurl and dynamically link to krb5 (which is standard priority
anyway).

> I for one would really dislike to drop the static aide binary and think
> a static curl library without krb support is better than the current
> one, which is not usable at all.

I for one would really dislike to provide a crippled static libcurl (not to
mention the maintainance hell of having to rebuild each curl SSL versions with
and without krb5 support) just for the sake of a single package which doesn't
even really need libcurl to work. I'd rather drop static libcurl completely if
it's really that useless.

> On Wed, May 15, 2013 at 08:06:23AM -0400, Sam Hartman wrote:
> > 3) A static aide with libcurl and somewhat crippled Kerberos meaning
> > that aide needs to get libcurl and krb5 updates.
> > In addition libcurl might potentially need to get rebuilt on Kerberos
> > security updates.

Static libcurl wouldn't need to be rebuilt. aide would "bundle" both libcurl
*and* krb5.

[Sam Hartman]

>>>>> "Alessandro" == Alessandro Ghedini <gh...@debian.org> writes:

>> > 3) A static aide with libcurl and somewhat crippled Kerberos
>> meaning > that aide needs to get libcurl and krb5 updates. > In
>> addition libcurl might potentially need to get rebuilt on
>> Kerberos > security updates.

Alessandro> Static libcurl wouldn't need to be rebuilt. aide would
Alessandro> "bundle" both libcurl *and* krb5.

Static libcurl certainly wouldn't normally need to be rebuilt.

Thinking more the number of situations where static libcurl would
require a rebuild but dynamic libcurl would not is vanishingly small.

[Hannes von Haugwitz]

Hello,

As there is no progress with this issue since nearly two months, I would
now suggest to go along with the third option cited below. I think a
'libkrb5-static package' is a good compromise to solve both bugs and
enable me to use curl with aide.

What do you think?

Best regards

Hannes

On Wed, May 15, 2013 at 08:06:23AM -0400, Sam Hartman wrote:

[Sam Hartman]

For myself I'm unconvinced that it makes sense to have static libraries
used for aid.
I was really hoping the security team would comment on this one way or
another.

I can certainly create libkrb5-static.
But I'd rather have a broader consensus of the project than just the aid
maintainer agreeing that it's worthwhile.

So, we could ask on -devel, ask the TC, whatever, to just get more input
involved.
If we do ask the TC we could do it entirely informally, or we could
defer to their judgment (no override required), although it seems like
we ought to find a way to get more people to chime in without invoking
the TC.

[Russ Allbery]

Sam Hartman <hart...@debian.org> writes:

> For myself I'm unconvinced that it makes sense to have static libraries
> used for aid. I was really hoping the security team would comment on
> this one way or another.

That's kind of where I'm at too. There are enough other tricks that you
can pull to hide files from static binaries that I'm not sure that the
addition of shared library loading really changes the security profile
enough to be worth the extra hassle.

> I can certainly create libkrb5-static. But I'd rather have a broader
> consensus of the project than just the aid maintainer agreeing that it's
> worthwhile.

We've been putting off this decision for a while. Some libraries still
ship static versions, some don't, and there's no real consensus other than
that we've generally followed upstreams who have dropped support for
static linking. There are also various glibc features that are now very
difficult to link statically, and there seems to be a general trend in
glibc development away from support for static linkage.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>