Bug#439039: Bug#495163: useless static library due to libkrb5
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. --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#439039: Bug#495163: useless static library due to libkrb5
Sam Hartman hartm...@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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#439039: Bug#495163: useless static library due to libkrb5
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: 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. --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#439039: Bug#495163: useless static library due to libkrb5
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 On Wed, May 15, 2013 at 08:06:23AM -0400, Sam Hartman wrote: 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. --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#439039: Bug#495163: useless static library due to libkrb5
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.
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#439039: Bug#495163: useless static library due to libkrb5
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#439039: Bug#495163: useless static library due to libkrb5
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. --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495163: useless static library due to libkrb5
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#439039: Bug#495163: useless static library due to libkrb5
[ 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.
Cheers
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#439039: Bug#495163: useless static library due to libkrb5
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#439039: Bug#495163: useless static library due to libkrb5
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.
Cheers
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#439039: Bug#495163: useless static library due to libkrb5
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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495163: useless static library due to libkrb5
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.
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#495163: useless static library due to libkrb5
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.
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#495163: useless static library due to libkrb5
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495163: useless static library due to libkrb5
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495163: useless static library due to libkrb5
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.
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#495163: useless static library due to libkrb5
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495163: useless static library due to libkrb5
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495163: useless static library due to libkrb5
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495163: useless static library due to libkrb5
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'
signature.asc
Description: Digital signature
Bug#495163: useless static library due to libkrb5
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495163: useless static library due to libkrb5
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495163: useless static library due to libkrb5
* Trent W. Buck ([EMAIL PROTECTED]) [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495163: useless static library due to libkrb5
* Andreas Schuldei ([EMAIL PROTECTED]) [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@/[EMAIL PROTECTED]@ @LDFLAGS@ @LIBCURL_LIBS@ @LIBS@ which contains LDFLAGS. this needs to go away. so this is my bug after all. is this relevant for lenny? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495163: useless static library due to libkrb5
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495163: useless static library due to libkrb5
Hi Andreas. On Fri, Aug 15, 2008 at 12:58 PM, Andreas Schuldei [EMAIL PROTECTED] wrote: * Andreas Schuldei ([EMAIL PROTECTED]) [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@/[EMAIL PROTECTED]@ @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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495163: useless static library due to libkrb5
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 | hurdnone (no description available) pn libldap2-dev none (no description available) pn libssh2-1-dev none (no description available) pn libssl-devnone (no description available) pn zlib1g-devnone (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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
