Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#555980: debian-policy: No policy on statically linked binaries

1 view
Skip to first unread message

Russ Allbery

unread,
Nov 12, 2009, 8:00:02 PM11/12/09
to
Package: debian-policy
Version: 3.8.3.0
Severity: wishlist

Unless I'm missing something, and I did a text search through Policy,
Policy is currently silent on the topic of statically linked binaries
other than a brief mention in a footnote on convenience copies of code.

I believe we should say that they're discouraged in general and are
normally only appropriate for shared library maintenance and recovery
tools (ldconfig, etc.) or for security tools.

ftpmaster currently requires that any statically linked binaries be
documented with a Lintian override.

-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686-bigmem (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii doc-base 0.9.5 utilities to manage online documen

-- no debconf information

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

Bill Allombert

unread,
Nov 15, 2009, 5:50:01 AM11/15/09
to
On Thu, Nov 12, 2009 at 04:43:18PM -0800, Russ Allbery wrote:
> Package: debian-policy
> Version: 3.8.3.0
> Severity: wishlist
>
> Unless I'm missing something, and I did a text search through Policy,
> Policy is currently silent on the topic of statically linked binaries
> other than a brief mention in a footnote on convenience copies of code.

Please note that "statically linked binaries" can cover:
1) static executable statically linked with the glibc (they do not work well
due to glibc plugins)

2) dynamic executable dynamically linked with the glibc but statically linked
with some other C libraries.

3) static executables not linked at all with the glibc. (I think e3 and
freepascal binaries are this way).

> I believe we should say that they're discouraged in general and are
> normally only appropriate for shared library maintenance and recovery
> tools (ldconfig, etc.) or for security tools.
>
> ftpmaster currently requires that any statically linked binaries be
> documented with a Lintian override.

What are they actually checking ?

Cheers,
--
Bill. <ball...@debian.org>

Imagine a large red swirl here.

Julien Cristau

unread,
Nov 15, 2009, 5:50:02 AM11/15/09
to
On Sun, Nov 15, 2009 at 18:55:45 +0900, Charles Plessy wrote:

> Where was announced the requirement from the FTP team ?
>
http://lists.debian.org/debian-devel-announce/2009/10/msg00004.html

Cheers,
Julien

Kurt Roeckx

unread,
Nov 15, 2009, 6:00:02 PM11/15/09
to
On Thu, Nov 12, 2009 at 04:43:18PM -0800, Russ Allbery wrote:
> Package: debian-policy
> Version: 3.8.3.0
> Severity: wishlist
>
> Unless I'm missing something, and I did a text search through Policy,
> Policy is currently silent on the topic of statically linked binaries
> other than a brief mention in a footnote on convenience copies of code.
>
> I believe we should say that they're discouraged in general and are
> normally only appropriate for shared library maintenance and recovery
> tools (ldconfig, etc.) or for security tools.

I agree to that.

But that should not mean we should discourage shipping static
libraries.


Kurt

Russ Allbery

unread,
Nov 15, 2009, 9:10:02 PM11/15/09
to
Bill Allombert <Bill.Al...@math.u-bordeaux1.fr> writes:
> On Thu, Nov 12, 2009 at 04:43:18PM -0800, Russ Allbery wrote:

>> Unless I'm missing something, and I did a text search through Policy,
>> Policy is currently silent on the topic of statically linked binaries
>> other than a brief mention in a footnote on convenience copies of code.

> Please note that "statically linked binaries" can cover:
> 1) static executable statically linked with the glibc (they do not work well
> due to glibc plugins)

This is the case that we're talking about here. In other words,
*entirely* static binaries. What you get with gcc -static.

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

Bill Allombert

unread,
May 19, 2014, 1:40:01 PM5/19/14
to
On Sun, Nov 15, 2009 at 06:00:13PM -0800, Russ Allbery wrote:
> Bill Allombert <Bill.Al...@math.u-bordeaux1.fr> writes:
> > On Thu, Nov 12, 2009 at 04:43:18PM -0800, Russ Allbery wrote:
>
> >> Unless I'm missing something, and I did a text search through Policy,
> >> Policy is currently silent on the topic of statically linked binaries
> >> other than a brief mention in a footnote on convenience copies of code.
>
> > Please note that "statically linked binaries" can cover:
> > 1) static executable statically linked with the glibc (they do not work well
> > due to glibc plugins)
>
> This is the case that we're talking about here. In other words,
> *entirely* static binaries. What you get with gcc -static.

Thus I propose the attached patch.
(I used 'must' instead of 'should' since the FTP masters are rejecting
such packages). I explicitely mentionned the GNU C libraries.
Binaries linked with some other C libraries are a completly different
kind of fish.
patch

Jonathan Nieder

unread,
May 19, 2014, 2:00:02 PM5/19/14
to
Hi,

Bill Allombert wrote:

> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -8466,7 +8466,11 @@ fi
> renamed. If a consensus cannot be reached, <em>both</em>
> programs must be renamed.
> </p>
> -
> + <p>
> + Binary executables must not be statically linked with the
> + GNU C library, unless there is technical requirement for
> + doing so.
> + </p>

What does it mean for there to be a technical requirement? For
example, is there a technical requirement for bash-static to be
statically linked? (A rescue disk could always include the libc
shared library instead of using a statically linked binary.)

xzdec contains binaries statically linked against liblzma but not
against libc. That means they wouldn't run afoul of this requirement.
Is that within the spirit of this policy?

What is the purpose of this change?

* avoiding nss pain when libc gets upgraded?
* license compliance, it being too hard to remember to use
Built-Using?
* security, missing out on fixes when libc gets upgraded?
* something else?

Thanks,
Jonathan

Bill Allombert

unread,
May 19, 2014, 2:10:04 PM5/19/14
to
On Mon, May 19, 2014 at 10:46:48AM -0700, Jonathan Nieder wrote:
> Hi,
>
> Bill Allombert wrote:
>
> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -8466,7 +8466,11 @@ fi
> > renamed. If a consensus cannot be reached, <em>both</em>
> > programs must be renamed.
> > </p>
> > -
> > + <p>
> > + Binary executables must not be statically linked with the
> > + GNU C library, unless there is technical requirement for
> > + doing so.
> > + </p>

(Please read the original bug log for the full story)

> What does it mean for there to be a technical requirement? For
> example, is there a technical requirement for bash-static to be
> statically linked? (A rescue disk could always include the libc
> shared library instead of using a statically linked binary.)

I would say that a -static package is required to be static.
(though of course the FTP matsers can veto the addition of
such a package).

> xzdec contains binaries statically linked against liblzma but not
> against libc. That means they wouldn't run afoul of this requirement.
> Is that within the spirit of this policy?

I think so.

> What is the purpose of this change?
>
> * avoiding nss pain when libc gets upgraded?
> * license compliance, it being too hard to remember to use
> Built-Using?
> * security, missing out on fixes when libc gets upgraded?
> * something else?

My purpose is for policy to be inline with the FTP masters practice.
For the FTP masters purpose it is a different story, though you are
raising valid points.

Cheers,
--
Bill. <ball...@debian.org>

Imagine a large red swirl here.


Russ Allbery

unread,
May 19, 2014, 2:20:01 PM5/19/14
to
Something of a pet peeve of mine in standards language is to have an
absolute requirement ("must") with a somewhat vague and subjective
exception. It's not that this is wrong, per se, but I feel like the
subjective exception and the absolute requirement cancel each other out.

Usually I argue for relaxing it to a should. In this case, I think we can
flesh out the exception somewhat better and preserve the must.

Binary executables must not be statically linked with the GNU C
library, since this prevents the binary from benefiting from
fixes and improvements to the C library without being rebuilt
and complicates security updates. This requirement may be
relaxed for binary executables whose intended purpose is to
diagnose and fix the system in situations where the GNU C
library may not be usable (such as system recovery shells or
utilities like ldconfig) or for binary executables where the
security benefits of static linking outweigh the drawbacks.

Jonathan Nieder

unread,
May 19, 2014, 2:40:01 PM5/19/14
to
Hi,

Russ Allbery wrote:

> Usually I argue for relaxing it to a should. In this case, I think we can
> flesh out the exception somewhat better and preserve the must.
>
> Binary executables must not be statically linked with the GNU C
> library, since this prevents the binary from benefiting from
> fixes and improvements to the C library without being rebuilt
> and complicates security updates. This requirement may be
> relaxed for binary executables whose intended purpose is to
> diagnose and fix the system in situations where the GNU C
> library may not be usable (such as system recovery shells or
> utilities like ldconfig) or for binary executables where the
> security benefits of static linking outweigh the drawbacks.

Seconded.

If the goal is to align with ftpmaster requirements, another possibility
is to explicitly say

* packages must not install binaries or object files statically
linked against glibc unless:

* the package has a name ending with -static,
* the final has a name ending with -static or .static, or
* the package installs a Lintian override file explaining why the
statically linked object is needed.

I think I prefer your suggestion, though.

Thanks,
Jonathan

Bill Allombert

unread,
May 19, 2014, 3:00:02 PM5/19/14
to
On Mon, May 19, 2014 at 11:26:03AM -0700, Jonathan Nieder wrote:
> Hi,
>
> Russ Allbery wrote:
>
> > Usually I argue for relaxing it to a should. In this case, I think we can
> > flesh out the exception somewhat better and preserve the must.
> >
> > Binary executables must not be statically linked with the GNU C
> > library, since this prevents the binary from benefiting from
> > fixes and improvements to the C library without being rebuilt
> > and complicates security updates. This requirement may be
> > relaxed for binary executables whose intended purpose is to
> > diagnose and fix the system in situations where the GNU C
> > library may not be usable (such as system recovery shells or
> > utilities like ldconfig) or for binary executables where the
> > security benefits of static linking outweigh the drawbacks.
>
> Seconded.

Seconded. Thus, let start a ten days discussion period.
signature.asc
0 new messages