Debian Bug report logs - #489771
support for centralized control over hardening-wrapper options

version graph

Package: dpkg-dev; Maintainer for dpkg-dev is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg-dev is src:dpkg.

Reported by: Kees Cook <kees@outflux.net>

Date: Mon, 7 Jul 2008 17:54:01 UTC

Severity: normal

Found in version dpkg/1.14.20

Fixed in version dpkg/1.16.1

Done: Guillem Jover <guillem@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@outflux.net>:
New Bug report received and forwarded. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@outflux.net>
To: Debian Bugs <submit@bugs.debian.org>
Subject: support for centralized control over hardening-wrapper options
Date: Mon, 7 Jul 2008 10:50:13 -0700
[Message part 1 (text/plain, inline)]
Package: dpkg
Version: 1.14.20
Severity: normal
Tags: patch
User: ubuntu-devel@lists.ubuntu.com
Usertags: origin-ubuntu intrepid ubuntu-patch

Hello!

This is a patch that add support for the "hardening-wrapper" package's
set of build flags, in the hopes of merging hardening-wrapper's
functionality into dpkg-buildpackage at some point in the future.

Thanks,

-Kees

-- 
Kees Cook                                            @outflux.net
[dpkg-hardening-wrapper.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@outflux.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #10 received at 489771@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@outflux.net>
To: 489771@bugs.debian.org
Subject: minor documentation adjustment to patch
Date: Mon, 7 Jul 2008 11:03:26 -0700
[Message part 1 (text/plain, inline)]
New patch, minor adjustment to error message.

-- 
Kees Cook                                            @outflux.net
[dpkg-hardening-wrapper.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #15 received at 489771@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Kees Cook <kees@outflux.net>, 489771@bugs.debian.org
Cc: hardening-discuss@lists.alioth.debian.org
Subject: Re: Bug#489771: support for centralized control over hardening-wrapper options
Date: Mon, 7 Jul 2008 23:32:16 +0200
On Mon, 07 Jul 2008, Kees Cook wrote:
> This is a patch that add support for the "hardening-wrapper" package's
> set of build flags, in the hopes of merging hardening-wrapper's
> functionality into dpkg-buildpackage at some point in the future.

Thanks for the patch, but I really dislike the complexity of this whole
setup.

Why couldn't hardening-wrapper use directly the hardening/no-hardening
options from DEB_BUILD_OPTIONS instead of requiring a complete set of 
specific environment variables?

I don't want to have to modify dpkg-buildpackage, I'd rather rely on some
new infrastructure to handle build options that I'm currently working on.

In the end, I would like that:
- maintainers can opt-in/opt-out from building hardened binaries with the
  new Build-Options field in debian/control (same syntax than
  DEB_BUILD_OPTIONS with "hardening", "hardening=no<X>,no<Y>" or
  "no-hardening").
- the builder can override the maintainer choice by setting one of these
  flags in DEB_BUILD_OPTIONS
- the build environment always inherits any hardening options from
  debian/control into DEB_BUILD_OPTIONS (if not overriden)

dpkg-buildpackage would be modified to use a modified Dpkg::BuildOptions
that would do this "intelligent option forwarding" but that's all.

How does that sound to you?

Note that I'm not opposed to have dpkg-buildpackage enable hardening
by default in the future (by auto-setting the option unless instructed
otherwise by Build-Option: / DEB_BUILD_OPTIONS). For now, I just
want to not bloat dpkg-buildpackage with too much specific code like this
one and want to integrate this change in a more generic framework.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #20 received at 489771@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: debian-dpkg@lists.debian.org
Cc: 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Felipe Sateler <fsateler@gmail.com>, Kees Cook <kees@outflux.net>
Subject: New Build-Options field and build-arch option, please review
Date: Fri, 11 Jul 2008 00:02:33 +0200
[Message part 1 (text/plain, inline)]
Hello,

in order to fix #229357 I decided to add a new Build-Options field.
I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
And I added support for a build-arch option, that if present, will let
dpkg-buildpackage call debian/rules build-arch and build-indep.

It's not obvious that this was the right choice when you think of the
currently existing build options but once you start thinking of possible
additions (as requested in #489771), it becomes more evident that it makes
sense. Even if some build options should really only be used in
the field while others should only be used in the environment variable,
the possibility to override the former with the latter is nice.

The current patchset is available in my public repository but I'll attach
it as well so that you can easily review it. I intend to merge it this
week-end after some tests but feel free to test and comment in the mean
time.

http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/bug229357-build-options

The patchset only applies on top of master.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
[0001-Refactor-Dpkg-BuildOptions-to-handle-Build-Options.patch (text/x-diff, attachment)]
[0002-dpkg-buildpackage-use-build-arch-indep-target.-Clos.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Felipe Sateler <fsateler@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #25 received at 489771@bugs.debian.org (full text, mbox):

From: Felipe Sateler <fsateler@gmail.com>
To: debian-dpkg@lists.debian.org, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Thu, 10 Jul 2008 19:19:16 -0400
[Message part 1 (text/plain, inline)]
El 10/07/08 18:02 Raphael Hertzog escribió:
> Hello,
>
> in order to fix #229357 I decided to add a new Build-Options field.
> I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
> And I added support for a build-arch option, that if present, will let
> dpkg-buildpackage call debian/rules build-arch and build-indep.
>
> It's not obvious that this was the right choice when you think of the
> currently existing build options but once you start thinking of possible
> additions (as requested in #489771), it becomes more evident that it makes
> sense. Even if some build options should really only be used in
> the field while others should only be used in the environment variable,
> the possibility to override the former with the latter is nice.

I'm not really sure this is right. There are two things that we want to do 
here: declare that a package supports something, and asking the package to do 
something. This difference is blurred now, and I think it is confusing.
OTOH, it gives the benefit of being able to ignore the package capabilities 
via the environment (ie, unset a given option).
I fear it will give rise to abuses such as setting parallel=n in the control 
file.


Saludos,
Felipe Sateler
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #30 received at 489771@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Felipe Sateler <fsateler@gmail.com>
Cc: debian-dpkg@lists.debian.org, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Fri, 11 Jul 2008 09:10:41 +0200
On Thu, 10 Jul 2008, Felipe Sateler wrote:
> El 10/07/08 18:02 Raphael Hertzog escribió:
> > Hello,
> >
> > in order to fix #229357 I decided to add a new Build-Options field.
> > I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
> > And I added support for a build-arch option, that if present, will let
> > dpkg-buildpackage call debian/rules build-arch and build-indep.
> >
> > It's not obvious that this was the right choice when you think of the
> > currently existing build options but once you start thinking of possible
> > additions (as requested in #489771), it becomes more evident that it makes
> > sense. Even if some build options should really only be used in
> > the field while others should only be used in the environment variable,
> > the possibility to override the former with the latter is nice.
> 
> I'm not really sure this is right. There are two things that we want to do 
> here: declare that a package supports something, and asking the package to do 
> something. This difference is blurred now, and I think it is confusing.

Even if there's only two things, the fact is that the package maintainer
wants not only to decide what is supported but he might also want to
enable some features... if you check the case that I listed above, we also
want to use Build-Options to _enable_ specific hardening measures. Because
the maintainer knows best which hardening measures should be enabled. But
we also want the builder to be able to override them for example to test
if the package now supports a previously disabled hardening measure.

The meaning of each build options is specific to each, there's no global
rule that works for all cases. That's why we have documentation of each
option in dpkg-buildpackage.

> I fear it will give rise to abuses such as setting parallel=n in the control 
> file.

There are dozens of ways to "abuse" any interface if you choose to use
it in a way that contradicts the documentation. But that's not a reason
to limit the flexibility offered by an interface.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #35 received at 489771@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Felipe Sateler <fsateler@gmail.com>
Cc: debian-dpkg@lists.debian.org, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Fri, 11 Jul 2008 11:49:07 +0200
On Thu, Jul 10, 2008 at 07:19:16PM -0400, Felipe Sateler wrote:
> El 10/07/08 18:02 Raphael Hertzog escribió:
> > Hello,
> >
> > in order to fix #229357 I decided to add a new Build-Options field.
> > I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
> > And I added support for a build-arch option, that if present, will let
> > dpkg-buildpackage call debian/rules build-arch and build-indep.
> >
> > It's not obvious that this was the right choice when you think of the

Maybe it is not obvious, but since noone proposed another working
solution in the ten years this issue exists, there is no alternative.

> > currently existing build options but once you start thinking of possible
> > additions (as requested in #489771), it becomes more evident that it makes
> > sense. Even if some build options should really only be used in
> > the field while others should only be used in the environment variable,
> > the possibility to override the former with the latter is nice.
> 
> I'm not really sure this is right. There are two things that we want to do 
> here: declare that a package supports something, and asking the package to do 
> something. This difference is blurred now, and I think it is confusing.
> OTOH, it gives the benefit of being able to ignore the package capabilities 
> via the environment (ie, unset a given option).
> I fear it will give rise to abuses such as setting parallel=n in the control 
> file.

I concur. This also create a namespace problem by conflating the
'Build-Options' namespace with the DEB_BUILD_OPTIONS namespace.
Since a developer can put virtually anything in DEB_BUILD_OPTIONS
(and check for it in debian/rules) even if it is not mentionned 
in policy, this is a real issue.

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

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #40 received at 489771@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Felipe Sateler <fsateler@gmail.com>
Cc: debian-dpkg@lists.debian.org, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Fri, 11 Jul 2008 09:47:51 -0700
Raphael Hertzog <hertzog@debian.org> writes:

> Even if there's only two things, the fact is that the package maintainer
> wants not only to decide what is supported but he might also want to
> enable some features... if you check the case that I listed above, we
> also want to use Build-Options to _enable_ specific hardening
> measures. Because the maintainer knows best which hardening measures
> should be enabled. But we also want the builder to be able to override
> them for example to test if the package now supports a previously
> disabled hardening measure.

This doesn't make sense to me.  The maintainer writes debian/rules; why
would they need to change Build-Options in debian/control to enable
anything about the build?

I'd rather see Build-Options in debian/control be clearly defined as
capabilities that the package supports and not used as a substitute for
the existing DEB_BUILD_OPTIONS method of controlling what the build does
in practice.  (And I'd prefer it to be called Build-Options-Supported or
something along those lines.)  I think this still fits for #489771; the
presence of the hardening option in Build-Options-Supported indicates that
the package can usefully be built with hardening (it doesn't cause the
package build to break or the binaries to malfunction).  If the package
maintainer wants the package to always be built with those options, they
should make that change directly in debian/rules, not via this method.
They're going to have to test each flag that goes into the hardening
options separately anyway to make sure that it works (the current proposed
hardening flags break many packages, and if you follow debian/changelog
files, you'll see that many maintainers have added them blindly and then
had to roll back when they break).

Using a debian/control field to set DEB_BUILD_OPTIONS in dpkg-buildpackage
is a solution looking for a problem, IMO, and I'd rather not see that
tangled up with the much-needed problem of specifying which options a
package supports and finally dealing with the whole build-arch/build-indep
mess.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #45 received at 489771@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Joey Hess <joeyh@debian.org>, Russ Allbery <rra@debian.org>
Cc: debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Sun, 13 Jul 2008 11:18:05 +0200
Hi,

thanks for your answers.

On Fri, 11 Jul 2008, Joey Hess wrote:
> Raphael Hertzog wrote:
> > Even if there's only two things, the fact is that the package maintainer
> > wants not only to decide what is supported but he might also want to
> > enable some features...
> 
> Did you think about having two fields, one to specify the set of
> supported options, and one to allow setting defaults?

This might be possible but the limit is not always very clear: in the case
of build-arch, the simple fact that it's supported means that it's enabled
by default. 

It doesn't really make sense to require the maintainer to put it in
Build-Options-Supported and also in Build-Options.

> For some types of options, it makes sense to not just declare that
> they're supported, but that some particular combinations of options is
> supported, while declaring other combinations as unsupported. This would
> be particularly useful when setting compile options (including librarary
> link combinations).

You're thinking of options in terms of configure flags, is that right?
--with-mysql might be incompatible with --with-postgresql but both might
coexist with yet another feature.

I'm not sure I want to go that far in the logic of Build-Options. I
certainly would consider nice to have a sort of "flavor" mechanism
where the maintainer can propose various combinations of options.

Build-Options-Supported: flavor=mysql,postgresql,oracle,all
Build-Options-Default: flavor=all

But we could also express this with:
Build-Options: possible-flavor=mysql,postgresql,oracle,all
 default-flavor=all

(Well the set of prefix can be discussed and set in stone, exactly like
I have used the "no-" prefix to disable an option previously set)

> Also, I think it would be a good idea to explicitly make "x-foo" be
> reserved for non-standard options.

Fine.

On Fri, 11 Jul 2008, Russ Allbery wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
> 
> > Even if there's only two things, the fact is that the package maintainer
> > wants not only to decide what is supported but he might also want to
> > enable some features... if you check the case that I listed above, we
> > also want to use Build-Options to _enable_ specific hardening
> > measures. Because the maintainer knows best which hardening measures
> > should be enabled. But we also want the builder to be able to override
> > them for example to test if the package now supports a previously
> > disabled hardening measure.
> 
> This doesn't make sense to me.  The maintainer writes debian/rules; why
> would they need to change Build-Options in debian/control to enable
> anything about the build?

Because they want that anyone can easily rebuild it with that option
disabled?

> I'd rather see Build-Options in debian/control be clearly defined as
> capabilities that the package supports and not used as a substitute for
> the existing DEB_BUILD_OPTIONS method of controlling what the build does
> in practice.  (And I'd prefer it to be called Build-Options-Supported or
> something along those lines.)  I think this still fits for #489771; the
> presence of the hardening option in Build-Options-Supported indicates that
> the package can usefully be built with hardening (it doesn't cause the
> package build to break or the binaries to malfunction).  

Separating the two meanings is always possible, see above for a
discussion.

> If the package maintainer wants the package to always be built with
> those options, they should make that change directly in debian/rules,
> not via this method.

Why? (and it's not "always", it's by _default_)

I find it rather nice that we have a common way to enable this for all
packages: add a hardening-wrapper to Build-Depends, add the option
indicating which of the hardenings flags to enable, and you're done
and it works for all packages.

Of course, you can also set the right variables in debian/rules directly
but then you make it complex for anyone to disable those build options
(for example to verify if a failure can be attributed to one of these
hardening options).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #50 received at 489771@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Sun, 13 Jul 2008 11:31:45 -0700
Raphael Hertzog <hertzog@debian.org> writes:
> On Fri, 11 Jul 2008, Russ Allbery wrote:

>> This doesn't make sense to me.  The maintainer writes debian/rules; why
>> would they need to change Build-Options in debian/control to enable
>> anything about the build?

> Because they want that anyone can easily rebuild it with that option
> disabled?

That is already supported using the existing DEB_BUILD_OPTIONS mechanism.

I may be confused about your mental model here, but it seems like you're
moving rules about how the package is built from the package itself into
dpkg-buildpackage.  If that's really what's happening, I think that is a
truly dreadful idea and strongly object.  It should be possible to build
the package using whatever flags and options are the default by running
debian/rules build without involving dpkg-buildpackage at all, which
implies that the package should not be relying on dpkg-buildpackage to
provide compiler and linker flags.  Those defaults should be in
debian/rules, just as they always have been for Debian packages.

If some set of flags, such as hardening, should be possible to easily
disable, this is exactly the same case as we have right now with
optimization and with stripping.  The way to support that is to specify
another DEB_BUILD_OPTIONS flag which, if set, instructs the package to
modify its behavior accordingly.  Furthermore, that allows the package
maintainer to provide more useful defaults specific to that package, such
as exactly the hardening flags that *that* package supports, rather than
some default (and possibly changing) set from dpkg-buildpackage.

DEB_BUILD_OPTIONS then stays clearly semantically separate from the
Build-Options-Supported field; the latter specifies which interfaces the
package supports, and the former is the way to actually *use* those
interfaces, with some exceptions for interfaces that can be used other
ways (such as build-arch/build-indep).

>> If the package maintainer wants the package to always be built with
>> those options, they should make that change directly in debian/rules,
>> not via this method.

> Why? (and it's not "always", it's by _default_)

See above.  By moving the logic from debian/rules into dpkg-buildpackage,
we would be breaking a common workflow when working with packages.
Running debian/rules build in an unpacked source package to test would no
longer be a reasonable development step since you may get a completely
different compile than dpkg-buildpackage would give you.

I think the way that optimization and stripping are handled right now
works fairly well in practice, and I think we should be building on that
as a model, not replacing it with some entirely different method that
relies on additional external programs to wrap debian/rules.

The choice between always and by default can be handled using the existing
DEB_BUILD_OPTIONS mechanism just as optimization and stripping are now.

> I find it rather nice that we have a common way to enable this for all
> packages: add a hardening-wrapper to Build-Depends, add the option
> indicating which of the hardenings flags to enable, and you're done and
> it works for all packages.

Instead of doing that, you add hardening-wrapper to Build-Depends and
modify debian/rules to invoke it.  The process is just as simple.

> Of course, you can also set the right variables in debian/rules directly
> but then you make it complex for anyone to disable those build options
> (for example to verify if a failure can be attributed to one of these
> hardening options).

Not if you implement a DEB_BUILD_OPTIONS flag at the same time.  You can
then make hardening-wrapper trigger off of the DEB_BUILD_OPTIONS flag and
the package maintainer doesn't even have to handle it directly (very
similar to how debhelper packages let dh_strip handle DEB_BUILD_OPTIONS
for that flag).

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #55 received at 489771@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Mon, 14 Jul 2008 21:47:02 +0200
On Sun, 13 Jul 2008, Russ Allbery wrote:
> > Because they want that anyone can easily rebuild it with that option
> > disabled?
> 
> That is already supported using the existing DEB_BUILD_OPTIONS mechanism.
> 
> I may be confused about your mental model here, but it seems like you're
> moving rules about how the package is built from the package itself into
> dpkg-buildpackage.  If that's really what's happening, I think that is a
> truly dreadful idea and strongly object.  It should be possible to build
> the package using whatever flags and options are the default by running
> debian/rules build without involving dpkg-buildpackage at all, which
> implies that the package should not be relying on dpkg-buildpackage to
> provide compiler and linker flags.  Those defaults should be in
> debian/rules, just as they always have been for Debian packages.

I think we're already on that path for quite some time. If your package
uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting
them for you (with dpkg-architecture). The same is expected with default
values of builder/linker flags now that dpkg-buildpackage provides
reasonable defaults.

So yes, I'm somehow building on this model where dpkg-buildpackage can
simplify the work of packager by providing some distribution-wide
reasonable defaults.

People have noticed that and already requested that we can call arbitrary
targets of debian/rules with all the proper initialization done precisely
for test purpose during packaging work (see #477916).

> If some set of flags, such as hardening, should be possible to easily
> disable, this is exactly the same case as we have right now with
> optimization and with stripping.  The way to support that is to specify
> another DEB_BUILD_OPTIONS flag which, if set, instructs the package to
> modify its behavior accordingly.  Furthermore, that allows the package
> maintainer to provide more useful defaults specific to that package, such
> as exactly the hardening flags that *that* package supports, rather than
> some default (and possibly changing) set from dpkg-buildpackage.

Ok makes sense. In the case of hardening, it means that we have to modify
each and every package to enable it though. I suppose that the people
pushing this proposal would like to have the option to enable it globally
and have broken packages opt out and/or disable specific hardening
options.

Without taking into account the specific risks associated to any default
activation of build hardening, I find that having a generic system where
you can start early with an opt-in policy, have the stuff matures, and
switch to an opt-out policy later can make sense (if that plan is
announced early and that people know by advance how to opt-out
explicitely).

> See above.  By moving the logic from debian/rules into dpkg-buildpackage,
> we would be breaking a common workflow when working with packages.
> Running debian/rules build in an unpacked source package to test would no
> longer be a reasonable development step since you may get a completely
> different compile than dpkg-buildpackage would give you.

That might be so, but I'm not sure why it would be a major problem. It
can take some time to change habits but unless you see real drawbacks, I'm
not convinced that there are good reasons to revert in that direction.

> I think the way that optimization and stripping are handled right now
> works fairly well in practice, and I think we should be building on that
> as a model, not replacing it with some entirely different method that
> relies on additional external programs to wrap debian/rules.
> 
> The choice between always and by default can be handled using the existing
> DEB_BUILD_OPTIONS mechanism just as optimization and stripping are now.

Well, right now buildd do not use DEB_BUILD_OPTIONS at all AFAIK. So
there's no way to enable anything globally with this method in practice.

And I certainly wouldn't want to have to manually set DEB_BUILD_OPTIONS to
get a build similar to what the buildd would do.

The current practice only has options to disable something that
is enabled by default. I'm not sure you can usefully build on that
to provide a mechanism where something is disabled by default and that
can be enabled either by the maintainer or by the builder.

But maybe such a scheme is not desirable in general, we might not want
to offer any option for the builder that has not been validated by the
maintainer. I don't know. Maybe we won't have any other situation similar
to the hardening one and it's over-kill to try to generalize it.


the

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #60 received at 489771@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Mon, 14 Jul 2008 13:22:58 -0700
Raphael Hertzog <hertzog@debian.org> writes:

> I think we're already on that path for quite some time. If your package
> uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting
> them for you (with dpkg-architecture).

I most certainly do not rely on dpkg-buildpackage setting anything.  I
call dpkg-architecture directly, which is also what's in our best practice
documents.

DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)

I would consider packages that didn't do that and just assumed that those
variables were already set to be buggy.

> The same is expected with default values of builder/linker flags now
> that dpkg-buildpackage provides reasonable defaults.

Yeah, that bothered me too.  I made a perhaps poor tactical decision to
not fight about it since it seemed that it had a lot of momentum and I
couldn't think of specific problems other than the one that we ran into.
But this is going beyond setting some defaults that are already set in
nearly all of our packages.

> So yes, I'm somehow building on this model where dpkg-buildpackage can
> simplify the work of packager by providing some distribution-wide
> reasonable defaults.
>
> People have noticed that and already requested that we can call arbitrary
> targets of debian/rules with all the proper initialization done precisely
> for test purpose during packaging work (see #477916).

I must say, I really do not like this direction.  debhelper and cdbs and
similar sytsems are the places to provide this help where people want to
use it, in my opinion.  We have a lot of past experience with that and we
have the compatibility level to handle smoothing transitions.  (And to
provide a way for people to never transition, I admit, and I see where
that's the problem that you're solving, but I prefer that problem to the
problems introduced by the instability of having the package build
infrastructure change the input to the builds without coordination with
the package.)

Note that if you're requiring a package to participate by adding something
to Build-Options in debian/control, you have the same transition problem,
so I think that it's pretty equivalent to changing debian/rules; it's only
when you want packages to be able to change with external defaults that
you get the transition advantage.

I don't want to underestimate the transition advantage -- that is pretty
significant.  I do understand the problem that you're trying to solve, and
I understand that what I'm proposing is going to make transitions a lot
harder.

> Ok makes sense. In the case of hardening, it means that we have to
> modify each and every package to enable it though.

Well, not if you can do it via debhelper, which now with version 7 is much
more likely.  Similarly with cdbs.  But in general, yes.

For hardening, I think this is a feature; the flags aren't ones that can
just be applied to every package without breaking things.

> I suppose that the people pushing this proposal would like to have the
> option to enable it globally and have broken packages opt out and/or
> disable specific hardening options.

I think we've already found that this isn't a great approach for hardening
options in particular, since they break too many packages (and those
packages are not necessarily broken; in some cases it's the compiler
that's broken, or the assumptions behind the options).

> Without taking into account the specific risks associated to any default
> activation of build hardening, I find that having a generic system where
> you can start early with an opt-in policy, have the stuff matures, and
> switch to an opt-out policy later can make sense (if that plan is
> announced early and that people know by advance how to opt-out
> explicitely).

I agree with the benefit, but I think it's better to implement that sort
of thing in the packaging tools that already do that sort of magic and
which we already have a way of dealing with (compatibility levels in
debhelper, for example), and which continue to work with debian/rules
build.

>> See above.  By moving the logic from debian/rules into
>> dpkg-buildpackage, we would be breaking a common workflow when working
>> with packages.  Running debian/rules build in an unpacked source
>> package to test would no longer be a reasonable development step since
>> you may get a completely different compile than dpkg-buildpackage would
>> give you.

> That might be so, but I'm not sure why it would be a major problem. It
> can take some time to change habits but unless you see real drawbacks, I'm
> not convinced that there are good reasons to revert in that direction.

I'm somewhat disturbed by this.  Until this discussion, I had no idea that
you were planning on deprecating debian/rules build and expecting everyone
to use dpkg-buildpackage to get a reproducible build.  I'm not even sure
how to use dpkg-buildpackage to do the equivalent of just running
debian/rules build without the binary-* targets.

It seems like this is a significant enough change that it would warrant
Policy changes and a significant announcement in debian-devel-announce,
and I don't think we've had one about the high-level semantic change (but
maybe I missed it?).

> Well, right now buildd do not use DEB_BUILD_OPTIONS at all AFAIK.

I think the buildds should always build packages with the defaults set by
the maintainer of that package.

> The current practice only has options to disable something that
> is enabled by default.

The current practice has options that either disable something *or* enable
something; parallel=N is in the latter category.  DEB_BUILD_OPTIONS is
used to change the defaults, in whichever direction.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@outflux.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #65 received at 489771@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@outflux.net>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 489771@bugs.debian.org, hardening-discuss@lists.alioth.debian.org
Subject: Re: Bug#489771: support for centralized control over hardening-wrapper options
Date: Mon, 21 Jul 2008 11:59:11 -0700
Hi Raphael,

On Mon, Jul 07, 2008 at 11:32:16PM +0200, Raphael Hertzog wrote:
> On Mon, 07 Jul 2008, Kees Cook wrote:
> > This is a patch that add support for the "hardening-wrapper" package's
> > set of build flags, in the hopes of merging hardening-wrapper's
> > functionality into dpkg-buildpackage at some point in the future.
> 
> Thanks for the patch, but I really dislike the complexity of this whole
> setup.
> 
> Why couldn't hardening-wrapper use directly the hardening/no-hardening
> options from DEB_BUILD_OPTIONS instead of requiring a complete set of 
> specific environment variables?

Well, the original goal was to move the hardening option knowledge out
of hardening-wrapper and into dpkg-buildpackage, so this was designed to
be a migration path.

Since dpkg-buildpackage is setting the default compiler flags (-g -Wall,
etc), this seemed like a sensible place for the other distro-wide flags
to go live so we can get rid of the crazy hack that is
hardening-wrapper.  :)

> dpkg-buildpackage would be modified to use a modified Dpkg::BuildOptions
> that would do this "intelligent option forwarding" but that's all.
> 
> How does that sound to you?
> 
> Note that I'm not opposed to have dpkg-buildpackage enable hardening
> by default in the future (by auto-setting the option unless instructed
> otherwise by Build-Option: / DEB_BUILD_OPTIONS). For now, I just
> want to not bloat dpkg-buildpackage with too much specific code like this
> one and want to integrate this change in a more generic framework.

Sure, I can certainly understand that.  Will there be a framework that a
compiler flag default option system can be plugged into?

Thanks,

-Kees

-- 
Kees Cook                                            @outflux.net




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #70 received at 489771@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Kees Cook <kees@outflux.net>, 489771@bugs.debian.org
Cc: hardening-discuss@lists.alioth.debian.org
Subject: Re: Bug#489771: support for centralized control over hardening-wrapper options
Date: Tue, 22 Jul 2008 09:08:33 +0200
On Mon, 21 Jul 2008, Kees Cook wrote:
> Well, the original goal was to move the hardening option knowledge out
> of hardening-wrapper and into dpkg-buildpackage, so this was designed to
> be a migration path.

Why do we need a migration path and not a direct migration ? Since
hardening-wrapper does nothing without environment variables and since
dpkg-buildpackage already provides default values to compiler flags...
what would be the required intermediary step between: "hardening-wrapper
does the job" and "dpkg-buildpackage does the job" ?

> Since dpkg-buildpackage is setting the default compiler flags (-g -Wall,
> etc), this seemed like a sensible place for the other distro-wide flags
> to go live so we can get rid of the crazy hack that is
> hardening-wrapper.  :)

Indeed. But your patch was not changing the distro-wide flags. :)

> > Note that I'm not opposed to have dpkg-buildpackage enable hardening
> > by default in the future (by auto-setting the option unless instructed
> > otherwise by Build-Option: / DEB_BUILD_OPTIONS). For now, I just
> > want to not bloat dpkg-buildpackage with too much specific code like this
> > one and want to integrate this change in a more generic framework.
> 
> Sure, I can certainly understand that.  Will there be a framework that a
> compiler flag default option system can be plugged into?

I haven't thought about this yet. As you noticed, the framework I was
referring to was more for controlling DEB_BUILD_OPTIONS than for
controlling CFLAGS & all.

But, if someones comes up with a sensible design for such a framework,
I'm happy to give it a try. But I'm not sure if it would add any value
compared to some hardcoded rules to generate the compiler flags.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@outflux.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #75 received at 489771@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@outflux.net>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 489771@bugs.debian.org, hardening-discuss@lists.alioth.debian.org
Subject: Re: Bug#489771: support for centralized control over hardening-wrapper options
Date: Mon, 28 Jul 2008 11:39:31 -0700
On Tue, Jul 22, 2008 at 09:08:33AM +0200, Raphael Hertzog wrote:
> Why do we need a migration path and not a direct migration ? Since
> hardening-wrapper does nothing without environment variables and since
> dpkg-buildpackage already provides default values to compiler flags...
> what would be the required intermediary step between: "hardening-wrapper
> does the job" and "dpkg-buildpackage does the job" ?

Yeah, you're right -- I can't think of a good reason to do this
migration inside dpkg-buildpackage.

> I haven't thought about this yet. As you noticed, the framework I was
> referring to was more for controlling DEB_BUILD_OPTIONS than for
> controlling CFLAGS & all.
> 
> But, if someones comes up with a sensible design for such a framework,
> I'm happy to give it a try. But I'm not sure if it would add any value
> compared to some hardcoded rules to generate the compiler flags.

I will find some time to talk to doko about this, and see what we can
come up with.  The goal here is to do away with the whole
hardening-wrapper package, and have all the flag knowledge triggered via
DEB_BUILD_OPTIONS and dpkg-buildpackage.

Thanks!

-Kees

-- 
Kees Cook                                            @outflux.net




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #80 received at 489771@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Russ Allbery <rra@debian.org>
Cc: Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Wed, 10 Sep 2008 19:47:08 +0200
On Mon, Jul 14, 2008 at 01:22:58PM -0700, Russ Allbery wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
> 
> > I think we're already on that path for quite some time. If your package
> > uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting
> > them for you (with dpkg-architecture).
> 
> I most certainly do not rely on dpkg-buildpackage setting anything.  I
> call dpkg-architecture directly, which is also what's in our best practice
> documents.
> 
> DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
> DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
> 
> I would consider packages that didn't do that and just assumed that those
> variables were already set to be buggy.
> 
> > The same is expected with default values of builder/linker flags now
> > that dpkg-buildpackage provides reasonable defaults.
> 
> Yeah, that bothered me too.  I made a perhaps poor tactical decision to
> not fight about it since it seemed that it had a lot of momentum and I
> couldn't think of specific problems other than the one that we ran into.
> But this is going beyond setting some defaults that are already set in
> nearly all of our packages.
> 
> > So yes, I'm somehow building on this model where dpkg-buildpackage can
> > simplify the work of packager by providing some distribution-wide
> > reasonable defaults.
> >
> > People have noticed that and already requested that we can call arbitrary
> > targets of debian/rules with all the proper initialization done precisely
> > for test purpose during packaging work (see #477916).
> 
> I must say, I really do not like this direction.  debhelper and cdbs and
> similar sytsems are the places to provide this help where people want to
> use it, in my opinion.  We have a lot of past experience with that and we
> have the compatibility level to handle smoothing transitions.  (And to
> provide a way for people to never transition, I admit, and I see where
> that's the problem that you're solving, but I prefer that problem to the
> problems introduced by the instability of having the package build
> infrastructure change the input to the builds without coordination with
> the package.)

I like to say I concurr with Russ. There are some much difference
between packages that distributions wide default does not make sense.
Such change would rather lead me to hardcode values of
DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.

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

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #85 received at 489771@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: Russ Allbery <rra@debian.org>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 11 Sep 2008 08:46:05 +0200
On Wed, 10 Sep 2008, Bill Allombert wrote:
> > > People have noticed that and already requested that we can call arbitrary
> > > targets of debian/rules with all the proper initialization done precisely
> > > for test purpose during packaging work (see #477916).
> > 
> > I must say, I really do not like this direction.  debhelper and cdbs and
> > similar sytsems are the places to provide this help where people want to
> > use it, in my opinion.  We have a lot of past experience with that and we
> > have the compatibility level to handle smoothing transitions.  (And to
> > provide a way for people to never transition, I admit, and I see where
> > that's the problem that you're solving, but I prefer that problem to the
> > problems introduced by the instability of having the package build
> > infrastructure change the input to the builds without coordination with
> > the package.)
> 
> I like to say I concurr with Russ. There are some much difference
> between packages that distributions wide default does not make sense.
> Such change would rather lead me to hardcode values of
> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.

But more and more people want to be able to change distribution wide
default: Emdebian wants to enable "nodocs" and "nocheck" by default, other
want to be able to enable hardening options by default and I agree with
them that official support for such a facility is desirable.

See also #498355 and #498380 for such requests from Emdebian.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #90 received at 489771@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Russ Allbery <rra@debian.org>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 11 Sep 2008 10:08:58 +0100
[Message part 1 (text/plain, inline)]
On Thu, 2008-09-11 at 08:46 +0200, Raphael Hertzog wrote:
> On Wed, 10 Sep 2008, Bill Allombert wrote:
> > > > People have noticed that and already requested that we can call arbitrary
> > > > targets of debian/rules with all the proper initialization done precisely
> > > > for test purpose during packaging work (see #477916).
> > > 
> > > I must say, I really do not like this direction.  debhelper and cdbs and
> > > similar sytsems are the places to provide this help where people want to
> > > use it, in my opinion. 

The actual support will be implemented in debhelper - all that is needed
is a consistent manner to pass the same options to debhelper across a
range of packages. Packages then add extra support if necessary, e.g. if
a package installs docs manually instead of using dh_installdocs, then
those sections of debian/rules need to be either conditionally excluded:
ifeq (,$(findstring nodocs,$(DEB_BUILD_OPTIONS)))
        install foo.1 debian/foo/usr/share/man/man1/
        ...
endif

or redone for debhelper support via foo.install files, etc.

After Lenny, I will be filing bugs for this support - at least for the
packages used in Emdebian.

>  We have a lot of past experience with that and we
> > > have the compatibility level to handle smoothing transitions.  (And to
> > > provide a way for people to never transition, I admit, and I see where
> > > that's the problem that you're solving, but I prefer that problem to the
> > > problems introduced by the instability of having the package build
> > > infrastructure change the input to the builds without coordination with
> > > the package.)

There has to be coordination with the package - the package needs to
support the build option, either explicitly or via debhelper. All CDBS
or any other layer needs to do is pass down the option to make it
accessible to debhelper (usually via DEB_BUILD_OPTIONS).

> > I like to say I concurr with Russ. There are some much difference
> > between packages that distributions wide default does not make sense.

On the contrary, there are clear divisions where distribution-wide build
options do make sense. Raphael correctly identifies nodocs and nocheck
as the current Emdebian distribution-wide build options. nodocs itself
needs to be refined to allow for graded levels of documentation
exclusion and other build options may change the build process itself -
all under the control of the particular package. If the package does not
understand the option, nothing happens.

e.g. Emdebian needs nodocs (or something as broad) that drops
everything, from README and TODO to changelog.gz and manpages during the
build, rather than after downloading. Preferably, nodocs would also lead
to the mandatory compression of copyright to save more space. It is not
new for DEB_BUILD_OPTIONS to break Debian Policy - supporting a
distribution-wide superset of options allows the use of the set to
conform to Emdebian Policy etc.

Other uses of options could use graduations so that examples are dropped
but not the rest, or just manpages or just HTML docs etc. Dpkg Classes
will help with graduations, as long as the distro can afford to remove
the files *after* the package has been downloaded.

> But more and more people want to be able to change distribution wide
> default: Emdebian wants to enable "nodocs" and "nocheck" by default, other
> want to be able to enable hardening options by default and I agree with
> them that official support for such a facility is desirable.
> 
> See also #498355 and #498380 for such requests from Emdebian.

Note also that Ubuntu are interested in supporting distribution-wide
build options.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #95 received at 489771@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 11 Sep 2008 10:53:27 -0700
Raphael Hertzog <hertzog@debian.org> writes:
> On Wed, 10 Sep 2008, Bill Allombert wrote:

>> I like to say I concurr with Russ. There are some much difference
>> between packages that distributions wide default does not make sense.
>> Such change would rather lead me to hardcode values of
>> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.
>
> But more and more people want to be able to change distribution wide
> default: Emdebian wants to enable "nodocs" and "nocheck" by default,
> other want to be able to enable hardening options by default and I agree
> with them that official support for such a facility is desirable.

So they should set DEB_BUILD_OPTIONS in the environment.  That's what it's
for.  I don't have any objections to that, or even to doing it via
dpkg-buildpackage.

My objection is specifically to having dpkg-buildpackage set a variety of
environment variables *by default*, and then telling package maintainers
that they should rely on those environment variables being set in the
default case.  That breaks the debian/rules interface and requires that
all package builds go through dpkg-buildpackage.  Having dpkg-buildpackage
set environment variables in the non-default case like Emdebian is not a
problem, since for Emdebian builds (for example) Emdebian can decide that
using dpkg-buildpackage or setting the environment variables manually is
required.  There is no existing precedent, and they can make that rule
from scratch.

My concern is for the default build where there *is* an existing precedent
that debian/rules build should work sanely, not for support for special
cases like that where the existing debian/rules interface already doesn't
do the right thing without additional help.

If you are going to go down this path of having dpkg-buildpackage set up
an environment that package maintainers should rely on, you or someone
else on the dpkg team needs to make a debian-devel-announce post making it
clear that debian/rules build is no longer a supported interface for
building packages and using dpkg-buildpackage is required for consistent
behavior.

Right now, I don't think most Debian Developers have any idea what the
implications of these changes are.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #100 received at 489771@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 11 Sep 2008 19:02:33 +0100
[Message part 1 (text/plain, inline)]
On Thu, 2008-09-11 at 10:53 -0700, Russ Allbery wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
> > On Wed, 10 Sep 2008, Bill Allombert wrote:
> 
> >> I like to say I concurr with Russ. There are some much difference
> >> between packages that distributions wide default does not make sense.
> >> Such change would rather lead me to hardcode values of
> >> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.
> >
> > But more and more people want to be able to change distribution wide
> > default: Emdebian wants to enable "nodocs" and "nocheck" by default,
> > other want to be able to enable hardening options by default and I agree
> > with them that official support for such a facility is desirable.
> 
> So they should set DEB_BUILD_OPTIONS in the environment.  That's what it's
> for.  I don't have any objections to that, or even to doing it via
> dpkg-buildpackage.

That is what DEB_VENDOR seeks to achieve - set it once and it sets the
same options across all builds, in the environment.

This is getting to be a long list of CC: - isn't it worth sending to
debian-devel instead? Goswin von Brederlow and Simon Richter did a lot
of work on this at Extremadura and they aren't on the current CC:.

I'm losing track of all the bugs in the CC: and why they are listed.

> My objection is specifically to having dpkg-buildpackage set a variety of
> environment variables *by default*, and then telling package maintainers
> that they should rely on those environment variables being set in the
> default case. 

If by default you mean Debian, then NO. DEB_BUILD_OPTIONS is empty for
Debian and will continue so.

>  That breaks the debian/rules interface and requires that
> all package builds go through dpkg-buildpackage.  Having dpkg-buildpackage
> set environment variables in the non-default case like Emdebian is not a
> problem, since for Emdebian builds (for example) Emdebian can decide that
> using dpkg-buildpackage or setting the environment variables manually is
> required.  There is no existing precedent, and they can make that rule
> from scratch.

Exactly.

> My concern is for the default build where there *is* an existing precedent
> that debian/rules build should work sanely, not for support for special
> cases like that where the existing debian/rules interface already doesn't
> do the right thing without additional help.
> 
> If you are going to go down this path of having dpkg-buildpackage set up
> an environment that package maintainers should rely on, you or someone
> else on the dpkg team needs to make a debian-devel-announce post making it
> clear that debian/rules build is no longer a supported interface for
> building packages and using dpkg-buildpackage is required for consistent
> behavior.
> 
> Right now, I don't think most Debian Developers have any idea what the
> implications of these changes are.

That's fine. DEB_BUILD_OPTIONS would be empty if DEB_VENDOR is not set
or is set to Debian.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #105 received at 489771@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Russ Allbery <rra@debian.org>
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 18 Sep 2008 15:03:20 +0200
Russ Allbery <rra@debian.org> writes:

> Raphael Hertzog <hertzog@debian.org> writes:
>> On Wed, 10 Sep 2008, Bill Allombert wrote:
>
>>> I like to say I concurr with Russ. There are some much difference
>>> between packages that distributions wide default does not make sense.
>>> Such change would rather lead me to hardcode values of
>>> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.
>>
>> But more and more people want to be able to change distribution wide
>> default: Emdebian wants to enable "nodocs" and "nocheck" by default,
>> other want to be able to enable hardening options by default and I agree
>> with them that official support for such a facility is desirable.
>
> So they should set DEB_BUILD_OPTIONS in the environment.  That's what it's
> for.  I don't have any objections to that, or even to doing it via
> dpkg-buildpackage.

Setting the environment on a distribution wide level is ugly and
fragile. Too many users will reset the environment in their .bashrc.

Instead the idea was to have a vendor (set in
/etc/dpkg/origins/default) that will be exported into DEB_VENDOR if
unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults.

The bugreports relevant for this have 2 solutions:

1) make dpkg-buildpackage use (or tool with equivalent environment
   setting up capabilities) mandatory

2) have debian/rules call something to set DEB_VENDOR and possibly
   more

   E.g. 'include /usr/share/dpkg/Makefile.dpkg'
   or   'DEB_VENDOR        ?= (shell dpkg-vendor -qDEB_VENDOR)
         DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS)

The argument against 2 is that is requires every source to be modified
if they want to support vendors whereas 1 only needs some small
modification to dpkg-buildpackage to support calling arbitrary targets
in debian/rules and a change in policy making its use mandatory.

> My objection is specifically to having dpkg-buildpackage set a variety of
> environment variables *by default*, and then telling package maintainers
> that they should rely on those environment variables being set in the
> default case.  That breaks the debian/rules interface and requires that
> all package builds go through dpkg-buildpackage.  Having dpkg-buildpackage
> set environment variables in the non-default case like Emdebian is not a
> problem, since for Emdebian builds (for example) Emdebian can decide that
> using dpkg-buildpackage or setting the environment variables manually is
> required.  There is no existing precedent, and they can make that rule
> from scratch.

Then you have one interface for Debian and one interface for every
other vendor including ubuntu (or option 2 above).

> My concern is for the default build where there *is* an existing precedent
> that debian/rules build should work sanely, not for support for special
> cases like that where the existing debian/rules interface already doesn't
> do the right thing without additional help.
>
> If you are going to go down this path of having dpkg-buildpackage set up
> an environment that package maintainers should rely on, you or someone
> else on the dpkg team needs to make a debian-devel-announce post making it
> clear that debian/rules build is no longer a supported interface for
> building packages and using dpkg-buildpackage is required for consistent
> behavior.

Plus a note in policy clarifying that debian/rules is only an
interface for dpkg-buildpackage but not users.

> Right now, I don't think most Debian Developers have any idea what the
> implications of these changes are.

I have to say i verry rarely do not use debuild. And 99% of the
exceptions are calling debian/rules clean.

MfG
        Goswin

PS: with dpkg-buildpackage setting env vars like it does now you
already have a verry confusing situation.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #110 received at 489771@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Kees Cook <kees@outflux.net>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 18 Sep 2008 15:35:26 +0200
On Thu, Sep 18, 2008 at 03:03:20PM +0200, Goswin von Brederlow wrote:
> Russ Allbery <rra@debian.org> writes:
> 
> > Raphael Hertzog <hertzog@debian.org> writes:
> >> On Wed, 10 Sep 2008, Bill Allombert wrote:
> >
> >>> I like to say I concurr with Russ. There are some much difference
> >>> between packages that distributions wide default does not make sense.
> >>> Such change would rather lead me to hardcode values of
> >>> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.
> >>
> >> But more and more people want to be able to change distribution wide
> >> default: Emdebian wants to enable "nodocs" and "nocheck" by default,
> >> other want to be able to enable hardening options by default and I agree
> >> with them that official support for such a facility is desirable.
> >
> > So they should set DEB_BUILD_OPTIONS in the environment.  That's what it's
> > for.  I don't have any objections to that, or even to doing it via
> > dpkg-buildpackage.
> 
> Setting the environment on a distribution wide level is ugly and
> fragile. Too many users will reset the environment in their .bashrc.
> 
> Instead the idea was to have a vendor (set in
> /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if
> unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults.
> 
> The bugreports relevant for this have 2 solutions:
> 
> 1) make dpkg-buildpackage use (or tool with equivalent environment
>    setting up capabilities) mandatory
> 
> 2) have debian/rules call something to set DEB_VENDOR and possibly
>    more
> 
>    E.g. 'include /usr/share/dpkg/Makefile.dpkg'
>    or   'DEB_VENDOR        ?= (shell dpkg-vendor -qDEB_VENDOR)
>          DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS)
> 
> The argument against 2 is that is requires every source to be modified
> if they want to support vendors whereas 1 only needs some small
> modification to dpkg-buildpackage to support calling arbitrary targets
> in debian/rules and a change in policy making its use mandatory.

2) is the right way to proceed for _Debian_. People in a hurry can use 1,
but not us. 

2) imply that packages will not have DEB_VENDOR support unless some
check they support it.

> > Right now, I don't think most Debian Developers have any idea what the
> > implications of these changes are.
> 
> I have to say i verry rarely do not use debuild. And 99% of the
> exceptions are calling debian/rules clean.

Precisely, debuild does not use dpkg-buildpackage, but call debian/rules
directly.

Cheers,
Bill.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #115 received at 489771@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: Goswin von Brederlow <goswin-v-b@web.de>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Kees Cook <kees@outflux.net>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 18 Sep 2008 17:36:46 +0200
On Thu, 18 Sep 2008, Bill Allombert wrote:
> > I have to say i verry rarely do not use debuild. And 99% of the
> > exceptions are calling debian/rules clean.
> 
> Precisely, debuild does not use dpkg-buildpackage, but call debian/rules
> directly.

This has been fixed already. It calls dpkg-buildpackage now (except if you use
its hook features).

(And I don't see why one way would be more Debianish than the other)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #120 received at 489771@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 18 Sep 2008 12:08:21 -0700
Goswin von Brederlow <goswin-v-b@web.de> writes:

> Plus a note in policy clarifying that debian/rules is only an
> interface for dpkg-buildpackage but not users.

Right.  If you want to make this a rule, then we should discuss it, reach
a consensus, document and publicize the change, and so forth.

Right now, I feel like this change is being made as part of dpkg
development, without general recognition of what's happening and without
the corresponding changes to Policy so that DDs know what to expect.  (I
don't think this is *intentional* on your part, more a case of a set of
decisions that all seemed like a good idea at the time but which
cumulatively have a significant impact.)

> I have to say i verry rarely do not use debuild. And 99% of the
> exceptions are calling debian/rules clean.

The hard part of standards isn't the common case.  Currently, debian/rules
is defined as the package build interface, and while most people don't
normally rely on that, we don't know what might break; one of the points
of a standard is to let people rely on it without having to tell you first
what they're doing.

Personally, I use debian/rules build all the time for testing, and would
never have thought to mention it to anyone.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #125 received at 489771@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Goswin von Brederlow <goswin-v-b@web.de>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Kees Cook <kees@outflux.net>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 18 Sep 2008 21:23:22 +0200
On Thu, Sep 18, 2008 at 05:36:46PM +0200, Raphael Hertzog wrote:
> On Thu, 18 Sep 2008, Bill Allombert wrote:
> > > I have to say i verry rarely do not use debuild. And 99% of the
> > > exceptions are calling debian/rules clean.
> > 
> > Precisely, debuild does not use dpkg-buildpackage, but call debian/rules
> > directly.
> 
> This has been fixed already. It calls dpkg-buildpackage now (except if you use
> its hook features).

So it still call debian/rules directly in some case.

> (And I don't see why one way would be more Debianish than the other)

Neither I do, but then I do not attempt to kill one way in favour of the other.

I would object to a proposal policy making dpkg-buildpackage mandatory
to build packages.

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

Imagine a large red swirl here. 




Bug reassigned from package `dpkg' to `dpkg-dev'. Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Sun, 10 May 2009 20:06:10 GMT) Full text and rfc822 format available.

Tags removed: patch Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Mon, 11 May 2009 15:06:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg-dev. (Tue, 02 Aug 2011 13:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 02 Aug 2011 13:21:03 GMT) Full text and rfc822 format available.

Message #134 received at 489771@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 489771@bugs.debian.org
Cc: Kees Cook <kees@debian.org>
Subject: Enabling hardening build flags
Date: Tue, 2 Aug 2011 15:18:27 +0200
[Message part 1 (text/plain, inline)]
[ Bcc: debian-dpkg to get a wider audience ]

Hello,

during Debconf I discussed with doko and a few of the tech-ctte members
to find a good solution for the problem of enabling hardening build flags.
Following that discussion I worked on a few dpkg-buildflags enhancement
that are now in the master branch.

In this discussion it has been agreed that it's ok to enable hardening
build flags by default given that dpkg-buildflags now has everything
required to disable a specific hardening feature.

The attached patches (corresponding to my pu/build-flags branch) add
the hardening build flags by default. Each hardening feature can be
enabled/disabled via the DEB_BUILD_MAINT_OPTIONS environment variable:
DEB_BUILD_MAINT_OPTIONS="hardening=+pie,-relro"

The special value "all" enables/disables all hardening features. Thus
to disable hardening entirely you can do:
DEB_BUILD_MAINT_OPTIONS="hardening=-all"

PIE is disabled by default, any maintainer wishing to use it has to
enable it explicitly.

Before I can merge this, we still need some documentation. Kees Cook
proposed to write it so I'm waiting on him for this.

I also wonder whether we should keep -Werror=format-security given that no
archive rebuild has been made with this option so we don't really know how
many packages will be affected by this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)
[patch-1 (text/plain, attachment)]
[patch-2 (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg-dev. (Tue, 02 Aug 2011 23:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 02 Aug 2011 23:30:03 GMT) Full text and rfc822 format available.

Message #139 received at 489771@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 489771@bugs.debian.org, Kees Cook <kees@debian.org>
Subject: Re: Enabling hardening build flags
Date: Tue, 02 Aug 2011 16:27:53 -0700
Raphael Hertzog <hertzog@debian.org> writes:

> I also wonder whether we should keep -Werror=format-security given that
> no archive rebuild has been made with this option so we don't really
> know how many packages will be affected by this.

I suspect "lots" based on personal experience, but also nearly every time
I've seen this warning it's been at least a potential security
vulnerability.  (Sometimes it's not very likely since it happened in
configuration parsing code, but still.)  So making those packages fail to
compile is probably not a bad thing.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg-dev. (Wed, 03 Aug 2011 02:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kees Cook <kees@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 03 Aug 2011 02:09:03 GMT) Full text and rfc822 format available.

Message #144 received at 489771@bugs.debian.org (full text, mbox):

From: Kees Cook <kees@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: Raphael Hertzog <hertzog@debian.org>, 489771@bugs.debian.org
Subject: Re: Enabling hardening build flags
Date: Tue, 2 Aug 2011 19:06:31 -0700
On Tue, Aug 02, 2011 at 04:27:53PM -0700, Russ Allbery wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
> 
> > I also wonder whether we should keep -Werror=format-security given that
> > no archive rebuild has been made with this option so we don't really
> > know how many packages will be affected by this.
> 
> I suspect "lots" based on personal experience, but also nearly every time
> I've seen this warning it's been at least a potential security
> vulnerability.  (Sometimes it's not very likely since it happened in
> configuration parsing code, but still.)  So making those packages fail to
> compile is probably not a bad thing.

I have all of Ubuntu's "main" component's build logs local, to try to
give us a quick measure (it's about 3500 packages out of the entire
archive). I can search for the warning, but is there a good way to check
that the package was built using dpkg-buildflags?

Out of 3551 packages recently built, 166 throw the warning, so just under
5%, without paying attention to if they build with dpkg-buildflags..

I, too, would like to see it enabled by default. It will cause a certain
amount of pain, but we'll have a cleaner archive when it's done.

-Kees

-- 
Kees Cook                                            @debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#489771; Package dpkg-dev. (Thu, 04 Aug 2011 08:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 04 Aug 2011 08:15:07 GMT) Full text and rfc822 format available.

Message #149 received at 489771@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Kees Cook <kees@debian.org>, 489771@bugs.debian.org
Cc: Russ Allbery <rra@debian.org>
Subject: Re: Bug#489771: Enabling hardening build flags
Date: Thu, 4 Aug 2011 10:11:19 +0200
On Tue, 02 Aug 2011, Kees Cook wrote:
> I have all of Ubuntu's "main" component's build logs local, to try to
> give us a quick measure (it's about 3500 packages out of the entire
> archive). I can search for the warning, but is there a good way to check
> that the package was built using dpkg-buildflags?

Not that I know. That's why Matthias filed
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628516

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Added tag(s) pending. Request was from Raphaël Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Thu, 08 Sep 2011 18:33:05 GMT) Full text and rfc822 format available.

Message sent on to Kees Cook <kees@outflux.net>:
Bug#489771. (Thu, 08 Sep 2011 18:33:10 GMT) Full text and rfc822 format available.

Message #154 received at 489771-submitter@bugs.debian.org (full text, mbox):

From: Raphaël Hertzog <hertzog@debian.org>
To: 489771-submitter@bugs.debian.org
Subject: Bug#489771 marked as pending
Date: Thu, 08 Sep 2011 18:30:14 +0000
tag 489771 pending
thanks

Hello,

Bug #489771 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

    http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=f3bb7d4

---
commit f3bb7d4939ae95cf44c89e8f599e7ed5da431e57
Author: Raphaël Hertzog <hertzog@debian.org>
Date:   Wed Jul 27 22:10:49 2011 +0200

    dpkg-buildflags: emit hardening build flags by default
    
    All the hardening build flags supported by hardening-includes
    are supported except that PIE is not enabled by default (just like
    the corresponding gcc patch doesn't enable it by default).
    
    Inspired by the work of Kees Cook <kees@debian.org>.

diff --git a/debian/changelog b/debian/changelog
index 06d7dbb..977d27d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -102,6 +102,9 @@ dpkg (1.16.1) UNRELEASED; urgency=low
   * Fix dpkg's handling of a hardlink pointing to a conffile. Closes: #638291
   * Add example of extend-diff-ignore's usage in dpkg-source(1).
     Closes: #640198
+  * dpkg-buildflags now returns hardening flags by default. Closes: #489771
+    They can be individually enabled/disabled via DEB_BUILD_MAINT_OPTIONS,
+    see dpkg-buildflags(1). Thanks to Kees Cook for his help.
 
   [ Guillem Jover ]
   * Install deb-src-control(5) man pages in dpkg-dev. Closes: #620520




Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Fri, 23 Sep 2011 05:21:20 GMT) Full text and rfc822 format available.

Notification sent to Kees Cook <kees@outflux.net>:
Bug acknowledged by developer. (Fri, 23 Sep 2011 05:21:20 GMT) Full text and rfc822 format available.

Message #159 received at 489771-close@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: 489771-close@bugs.debian.org
Subject: Bug#489771: fixed in dpkg 1.16.1
Date: Fri, 23 Sep 2011 05:17:20 +0000
Source: dpkg
Source-Version: 1.16.1

We believe that the bug you reported is fixed in the latest version of
dpkg, which is due to be installed in the Debian FTP archive:

dpkg-dev_1.16.1_all.deb
  to main/d/dpkg/dpkg-dev_1.16.1_all.deb
dpkg_1.16.1.dsc
  to main/d/dpkg/dpkg_1.16.1.dsc
dpkg_1.16.1.tar.bz2
  to main/d/dpkg/dpkg_1.16.1.tar.bz2
dpkg_1.16.1_amd64.deb
  to main/d/dpkg/dpkg_1.16.1_amd64.deb
dselect_1.16.1_amd64.deb
  to main/d/dpkg/dselect_1.16.1_amd64.deb
libdpkg-dev_1.16.1_amd64.deb
  to main/d/dpkg/libdpkg-dev_1.16.1_amd64.deb
libdpkg-perl_1.16.1_all.deb
  to main/d/dpkg/libdpkg-perl_1.16.1_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 489771@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri, 23 Sep 2011 06:00:11 +0200
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source amd64 all
Version: 1.16.1
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description: 
 dpkg       - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect    - Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 147583 231089 245322 293280 308082 454694 489771 525160 526774 552123 560070 560251 603435 604241 606839 608260 610940 615899 616609 619131 620312 620490 620520 621066 622094 626684 627462 628055 628726 629582 630533 630996 631435 631439 631494 631547 631757 631808 632168 632937 633539 633627 634510 634961 635467 635683 636700 637096 637564 638291 639229 639997 640198 640298 641834
Changes: 
 dpkg (1.16.1) unstable; urgency=low
 .
   [ Raphaël Hertzog ]
   * Dpkg::Deps: Implement new "reset" method and bump module version to 1.01
     due to this.
   * Improved description of --search in dpkg-query(1). Closes: #621066
     Thanks to Lars Buitinck <larsmans@gmail.com> for the patch.
   * Let update-alternatives fsync() its administrative files before
     moving them in place to avoid empty files with some filesystems.
     LP: #344019
   * Tighten the regexp used by dpkg-source to ignore the .pc directory of
     quilt. Thanks to Mike Hommey for noticing the problem.
   * Change behaviour of dpkg-source's --extend-diff-ignore to also
     extend the current diff-ignore if it has already been set.
   * Fix dependency checking code to consider a dependency on a virtual
     package provided by a package in triggers-pending status as satisfied.
   * Do not fail when encountering a pre-dependency in triggers-awaited state,
     instead process the awaited triggers. Closes: #526774
   * "any" no longer hides "all" in the Architecture field of a .dsc.
   * Fix dpkg --remove to really remove the triggers from the various
     internal files in /var/lib/dpkg/info/triggers/. Closes: #525160
   * Avoid a perl warning in dpkg-gensymbols when no symbols file has been
     generated (because it would have been empty). Closes: #626684
   * Re-enable the Package-List field but drop the Architecture column since we
     have no clear use case yet. It can always be added later on.
     Also drop the source line since it duplicates other fields.
     Closes: #619131
   * Add the extraction part of Dpkg::Source::Package to the supported API.
     Useful to extract source packages without having to depend on dpkg-source
     (and hence dpkg-dev).
   * Add the Dpkg::Vendor module to the supported API. Useful for lintian
     when dpkg-dev is absent.
   * Check presence of required parameters in dpkg-vendor. Closes: #628726
     Thanks to Niels Thykier <niels@thykier.net> for the patch.
   * Avoid a Perl warning in dpkg-buildflags when HOME is not set.
     Closes: #635467
   * dpkg-source can now also use debian/source/local-patch-header (that is not
     included in the generated source package) instead of
     debian/source/patch-header. Closes: #629582
   * Changed dpkg-source --after-build to automatically unapply patches that it
     has applied during --before-build.
   * Fix two possible causes for the assertion failure "pigp->trigpend_head".
     LP: #798793, #424358 Closes: #560251
   * Use "special" instead of "particular" to qualify the "3.0 (custom)" format
     in dpkg-source(1). Closes: #631435
   * Add some supplementary checks to ensure debian/control has the required
     fields. Closes: #631439
   * dpkg-gensymbols(1): document syntax of comments. Closes: #630996
   * Allow empty lines in symbols files to better delimit multiple libraries.
     Thanks to Cyril Brulebois <kibi@debian.org> for the patch.
   * dpkg: if "prerm upgrade" fails when downgrading, do not try to run
     "prerm failed-upgrade" with the prerm of the oldest prerm, it can't work
     around a bug of a newer prerm anyway.
   * dpkg: support new "interest-noawait" and "activate-noawait" trigger
     directives.
   * dpkg-buildflags(1): make it clear that DEB_*_(SET|APPEND) environment
     variables are meant for users and should not be used by packages.
   * update-alternatives: do not allow to reuse a slave link in another
     slave alternative. Closes: #631547
   * Improve dpkg-source's logic to identify ignored files. Closes: #632168
   * Fix a small typo in dpkg-source(1). Closes: #632937
   * Reword the description of dpkg-source --before-build and --after-build
     to be clearer. Closes: #608260
   * dpkg-buildpackage no longer exports the compiler flags. Closes: #560070
     Packages must directly call dpkg-buildflags to retrieve them.
   * dpkg-buildflags supports a prepend command to modify the build
     flags. Particularly useful for package maintainers who don't want
     their supplementary flags to take precedence over user submitted
     flags.
   * Add new --dump action to dpkg-buildflags and make it the default action.
     Closes: #603435
   * dpkg-mergechangelogs now checks the return value of the close() call.
     Thanks to Niels Thykier <niels@thykier.net> for the patch. Closes: #633539
   * Similar changes to dpkg-shlibdeps and dpkg-gencontrol, also by Niels.
   * Fix update-alternatives to not remove a real file when dropping a
     symlink for a slave that's not provided by the new current choice.
     Closes: #633627
   * Improve dpkg-source's error message complaining about the lack
     of the upstream tarball. Closes: #634510
   * Add some common makefile snippets for use in rules files in
     /usr/share/dpkg/: default.mk, architecture.mk, buildflags.mk, pkg-info.mk,
     vendor.mk Closes: #606839
   * Fix the dpkg-divert test-suite to also skip test that would fail if run
     under root. Closes: #634961
   * Change merge conflict separators created by dpkg-mergechangelogs to match
     the usual norm of being composed of 7 characters. LP: #815700
   * With source format 2.0 and 3.0 (quilt), dpkg-source now fails by default
     when upstream changes have not been recorded in a quilt patch. The new
     --commit operation can be used to properly record the changes before-hand.
     LP: #797839
     And it fails before installing the automatic patch in debian/patches/
     Closes: #615899
   * dpkg-buildflags now supports "--export=configure" to output compilation
     flags on a single line with double quotes as delimiter of the various
     values. It also uses DEB_<flag>_MAINT_<op> to let the maintainer
     extend the build flags to use. Last but not least, it can now also strip
     options from the returned build flags.
   * Fix possible segfault of dpkg in findbreakcycle(). LP: #733414
   * dpkg-source now properly cleans up the temporary tarball generated for
     native formats in case of unexpected interruption. Closes: #631494
   * Fix simplification logic of union dependencies. Closes: #637564
   * Fix dpkg's handling of a hardlink pointing to a conffile. Closes: #638291
   * Add example of extend-diff-ignore's usage in dpkg-source(1).
     Closes: #640198
   * dpkg-buildflags now returns hardening flags by default. Closes: #489771
     They can be individually enabled/disabled via DEB_BUILD_MAINT_OPTIONS,
     see dpkg-buildflags(1). Thanks to Kees Cook for his help.
 .
   [ Guillem Jover ]
   * Install deb-src-control(5) man pages in dpkg-dev. Closes: #620520
   * Add ‘.gitmodules’ to the default dpkg-source ignore lists. Closes: #620490
   * Document in dpkg-query(1) man page that on --listfiles each list of
     files per package name is separated by a blank line. Same goes for
     --status and --print-avail.
   * Use execvp(3) unconditionally in command_exec(). Making the call always
     fallback to use the system shell in case of error, such as with empty
     maintainer scripts. Thanks to Jonathan Nieder <jrnieder@gmail.com>.
     Closes: #622094
   * Improve deb-split(5) format description by splitting debian-split
     member contents into a list.
   * Switch to debhelper compatibility level 7.
     - Use dh_prep instead of deprecated “dh_clean -k”.
   * Bump Standards-Version to 3.9.2 (no changes needed).
   * Generate filenames following current conventions on “dpkg-split --join”,
     by including the architecture in the debian-split member of a split
     package and using underscores to separate filename parts.
   * Support conffiles with spaces when diffing them. Closes: #147583
   * Allow installing packages with bogus versions with new
     --force-bad-version.
   * Do not fail when unpacking a diverted hardlink. Closes: #245322
     Based on a patch by Christopher Baines <cbaines8@gmail.com>.
   * Document in dpkg-deb(1) that --fsys-tarfile will always process the
     input archive sequentially. Closes: #616609
   * Remove long non-functional --new and --old dpkg-deb option handling
     from dpkg which were being treated as dpkg commands.
   * Remove reference to --nocheck dpkg-deb option from dpkg man page as
     the latter does not pass it to the former.
   * Clarify the current dpkg behaviour when running the dpkg-deb and
     dpkg-query back-ends, of not passing through back-end specific options
     when running them from dpkg. Closes: #610940
   * Use “unselected” as an adjective in dpkg output messages instead of
     “deselected”. Closes: #231089
   * Clarify exit status in dpkg-split and start-stop-daemon --help output.
   * Clarify “EXIT STATUS” section in man pages by using a table.
   * Add a --status command to start-stop-daemon returning LSB Init Script
     status action exit codes.
   * Add start-stop-daemon process name kernel limits for Solaris, NetBSD,
     OpenBSD, FreeBSD and Darwin.
   * On package removal, keep only directories actually containing conffiles,
     and not directories just matching the substring in the conffile or the
     directory itself. Thanks to Ondřej Surý <ondrej@debian.org>.
   * On purge correctly remove symlinks acting as directories, when they are
     not being used by any other package's files.
   * Do not lose track of parent directories on removal so that they can
     be properly cleaned up on purge if not used by any other package.
     Based on a patch by Ondřej Surý <ondrej@debian.org>. Closes: #454694
   * Add ‘.hgsigs’ to the default dpkg-source ignore lists.
     Based on a patch by Jakub Wilk <jwilk@debian.org>. Closes: #627462
   * Do not allow blank lines in field values. Closes: #308082
   * Do not warn on missing architecture on packages in config-files state,
     but then make sure the architecture field is usable. Closes: #604241
   * Run du with --apparent-size when generating the Installed-Size field in
     dpkg-gencontrol to get consistent results independent of build system.
     Thanks to Ludovic Brenta <ludovic@ludovic-brenta.org>. Closes: #630533
   * Do not fail to unpack shared directories missing on the file system
     from packages being replaced by other packages. Closes: #631808
   * Do not require programs to define thisname, provide two new functions
     to handle the program name (dpkg_set_progname and dpkg_get_progname).
     Closes: #631757
   * Man pages cleanup:
     - Rename “USAGE” dselect(1) section to “ACTIONS” and clarify they can
       be performed interactively or from command line.
     - Add missing built-in methods to dselect(1).
     - Add missing escaping to field dashes in deb-control(5).
     - Use dashes instead of underscores for variable text.
     - Clarify that several front-end fields are not dselect specific in
       dpkg-query(1).
     - Use [option...] instead of [options] and friends.
     - Use italics or bold instead of surrounding the text with <>.
     - Correctly format text with bold and italics.
     - Use minus signs and hyphens consistently in man pages.
     - Fix reference to /etc/dpkg/dselect.cfg.d instead of dpkg.cfg.d in
       dselect(1).
     - Add missing optional group|gid --chuid argument in start-stop-daemon(8).
   * Refer to Sources and Packages files as part of a repository instead of
     as being of exclusive use or owned by APT, which has never been the case.
   * Unify somewhat dpkg-maintscript-helper --help output with other commands.
   * Add build-indep and build-arch targets as aliases for build in
     debian/rules.
   * Use the perl interpreter found by configure to call dpkg-architecture.pl
     in the m4 DPKG_ARCHITECTURE macro.
   * Add new --verbose option to dpkg-deb and change --extract to honour it.
     Closes: #293280
   * Add new --raw-extract option to dpkg-deb combining --control and
     --extract. Closes: #552123
   * Defer hardlink renames so that there's never a point were the new
     file contents are accessible from the final path before they have
     been fsync()ed and cannot be executed causing ETXTBSY when trying
     to open the to be installed paths for writing.
     Thanks to Jonathan Nieder <jrnieder@gmail.com>. Closes: #635683
   * Clarify the default dpkg-deb compression-levels on the man page.
   * Clarify dpkg --update-avail usage error message. Closes: #628055
   * Change Dpkg::Compression default values depending on the compressor
     used, and as such dpkg-source inherits this functionality.
     Prompted by Timo Juhani Lindfors <timo.lindfors@iki.fi>.
   * Print an actual error or warning message instead of assert()ing on
     readlink()/stat() size discrepancies. Closes: #639229
   * Update alternative links only if they change. This allows for a
     read-only file system and a writable database. Closes: #636700
     Based on a patch by Salvatore Bonaccorso <carnil@debian.org>.
   * Fix double “error:” string in dpkg missing PATH error output.
     Closes: #639997
   * Do not warn on strange timestamps when unpacking with dpkg-deb.
     Closes: #640298
   * Reduce dpkg-trigger binary size by refactoring libdpkg modules so that
     it does not end up pulling triglib.
   * Reduce dpkg-deb binary size by refectoring libdpkg modules so that it
     does not end up pulling triglib.
   * Do not fail on --compare-version when generating parse warnings.
     Existing packages with invalid versions should not fail on their
     maintainer scripts due to that.
   * Use the user name (instead of the user id) when setting the supplementary
     groups in start-stop-daemon. Closes: #641834
   * Use --srcdir and --destdir po4a options, and bump Build-Depends version
     to 0.36.4.
 .
   [ Updated dpkg translations ]
   * German (Sven Joachim). Closes: #620312
   * Swedish (Peter Krefting).
   * French (Christian Perrier).
 .
   [ Updated man page translations ]
   * French (Christian Perrier).
   * German (Helge Kreutzmann) including improvement by "Flo".
   * Swedish (Peter Krefting).
 .
   [ Updated scripts translations ]
   * French (Christian Perrier, Sylvestre Ledru). Closes: #637096
   * German (Helge Kreutzmann).
   * Swedish (Peter Krefting).
Checksums-Sha1: 
 d8d9d5a8a9f134459987f5b187527c303498e902 1364 dpkg_1.16.1.dsc
 9e8176c88fe2b31782ddae6d0a8f599c7e540e8d 5432348 dpkg_1.16.1.tar.bz2
 a830d5633da7a96d5208a6f8a7a97e24865e7913 552790 libdpkg-dev_1.16.1_amd64.deb
 470de180ac9fa5c95abfcf30a4d9a46cab269107 2218686 dpkg_1.16.1_amd64.deb
 6e6ddbb681d1bbbb971299932f99d43a35f33750 1006884 dselect_1.16.1_amd64.deb
 b8394b2dfd4291ff206dec00e53c723fa0be902e 923836 dpkg-dev_1.16.1_all.deb
 7940dc852c11e3a386ce014cd39ab7ce30e34f30 806604 libdpkg-perl_1.16.1_all.deb
Checksums-Sha256: 
 3f1649796856228545ba610df340b47b923a31f6ebe8765c8f48e1dac7f11391 1364 dpkg_1.16.1.dsc
 f9363628a6fa1c24a1e9c41bd8977f9d5a7010bfca3ac9a6f8bf500e7e8df52b 5432348 dpkg_1.16.1.tar.bz2
 96910fa1ed1371aa2b9e3147eecdf67e4e5f61fe7d7aaa97c27254f55a92c56d 552790 libdpkg-dev_1.16.1_amd64.deb
 d0e9691aa05c1b2567b06df0856ea05a211234e40dbc955e0266fa45fb32370c 2218686 dpkg_1.16.1_amd64.deb
 4a1c44c98791f1aa1b59bfc4890a3f6aeef70319f930e1ca9b7354ede8e78125 1006884 dselect_1.16.1_amd64.deb
 885d13576b93262151b5e920dd8971072668c0bd36b103ab0e82b97fcef52fcd 923836 dpkg-dev_1.16.1_all.deb
 b6fa511f2b059a85e3d5938c73a5805893a28438785a974bf0e46a53dc5da975 806604 libdpkg-perl_1.16.1_all.deb
Files: 
 c1e7858da79770b64427a99cc628889c 1364 admin required dpkg_1.16.1.dsc
 b94c9ed2493fd9dbb53a96f2e7f674ce 5432348 admin required dpkg_1.16.1.tar.bz2
 99bbb9c901e7462d06472a27ffb6d67f 552790 libdevel optional libdpkg-dev_1.16.1_amd64.deb
 bed79ea34df74b42ebbc2ed13d3ed4cb 2218686 admin required dpkg_1.16.1_amd64.deb
 bd018624eca8f1cf04a0b588a6338622 1006884 admin optional dselect_1.16.1_amd64.deb
 78c00b38545303cf8c8fcd4dd83f30a3 923836 utils optional dpkg-dev_1.16.1_all.deb
 f604975f555da4f710167be2b0d468f7 806604 perl optional libdpkg-perl_1.16.1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk58Dr0ACgkQuW9ciZ2SjJtZVwCgkPiancaq9ojJ2L0b8uEEjSC7
87YAoKtmUCgXZS/CfakXx860t2ijO84f
=Cq2h
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 31 Oct 2011 07:40:26 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 09:50:52 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.