Debian Bug report logs - #760741
dpkg: Please add new port hardened-amd64 enabling ASAN and UBSAN by default

Toggle useless messages

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

From: Balint Reczey <balint@balintreczey.hu>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: dpkg: Please add new port hardened-amd64 enabling ASAN and UBSAN by default

Date: Sun, 07 Sep 2014 15:01:35 +0200

[Message part 1 (text/plain, inline)]

Package: dpkg
Version: 1.17.13
Severity: wishlist
Tags: patch


Hi,

I'm working on a new port, hardened-amd64 [1]. The attached patches adds
the new port and enables ASAN and UBSAN through the hardening flags.
The flags are disabled on other architectures by default even when using
hardening=all, since ASAN causes significant slowdown and UBSAN will
probably reveal a lot of issues in many packages.

Dpkg for example builds fine with ASAN (with fixed #760690), but UBSAN
makes it FTBFS due to the following issue:
.../dpkg.git$ DEB_BUILD_MAINT_OPTIONS=hardening=all,+asan,+ubsan
dpkg-buildpackage
...

PATH="../src:../scripts:../utils:/usr/lib/ccache:/home/rbalint/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
\
  LC_ALL=C \
   \
  srcdir=../../src builddir=. \
  PERL_DL_NONLAZY=1 \
  PERL5OPT= \
  /usr/bin/perl -MTAP::Harness -e ' my $harness = TAP::Harness->new({
lib => [ "../../scripts" ], color => 1, verbosity => 0, failures => 1,
}); my $aggregate = $harness->runtests(@ARGV); die "FAIL: test suite has
errors\n" if $aggregate->has_errors;' \
     ../../src/t/dpkg_divert.t
../../src/t/dpkg_divert.t .. 1/257
not ok 62 - --list stderr

#   Failed test '--list stderr'
#   at ../../src/t/dpkg_divert.t line 106.
#          got: '../../src/filesdb.c:581:21: runtime error: signed
integer overflow: 313137907 * 1787 cannot be represented in type 'int'
# '
#     expected: ''
not ok 65 - --list * stderr

The third patch fixes the issue.

Please consired accepting the patches despite the fact that
hardened-amd64 is not an official port yet. It would help the
bootstrapping efforts and patch 2 would make it easier to experiment
with ASAN and UBSAN for others.

Cheers,
Balint

[1]
http://balintreczey.hu/blog/proposing-amd64-hardened-architecture-for-debian/

[0001-Add-hardened-amd64-architecture.patch (text/x-patch, attachment)]

[0002-Set-ASAN-and-UBSAN-for-hardened-amd64-builds-by-defa.patch (text/x-patch, attachment)]

[0003-Fix-signed-overflow-in-hash.patch (text/x-patch, attachment)]

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

From: Guillem Jover <guillem@debian.org>

To: balint@balintreczey.hu, 760741@bugs.debian.org

Subject: Re: Bug#760741: dpkg: Please add new port hardened-amd64 enabling ASAN and UBSAN by default

Date: Sun, 7 Sep 2014 17:26:40 +0200

Hi!

On Sun, 2014-09-07 at 15:01:35 +0200, Balint Reczey wrote:
> Package: dpkg
> Version: 1.17.13
> Severity: wishlist
> Tags: patch

> I'm working on a new port, hardened-amd64 [1].

This does not what dpkg ports are meant to denote, as I think was
mentioned in that thread. If the ports are ABI compatible then they
are the same port. The lpia port was such a thing, which I disagreed
with at the time but accepted anyway, and that was a mistake I'm not
going to repeat. I'm planning on removing lpia support soonish to
avoid anyone else take that as a precedent to follow.

This is the equivalent of bumping the instruction set baseline or
enabling a different set of build flags by default, etc. Please see
the recent Boostrap Sprint notes on the multiple ISAs section, which
is relevant for your scenario.

In any case I'm not planning on adding support for a hardened-amd64
architecture, sorry.

> The attached patches adds
> the new port and enables ASAN and UBSAN through the hardening flags.
> The flags are disabled on other architectures by default even when using
> hardening=all, since ASAN causes significant slowdown and UBSAN will
> probably reveal a lot of issues in many packages.

I'd be fine with adding ASAN and UBSAN or any other hardening stuff,
disabled by default on a feature area, but if they do not make sense
to be enabled by “all” then they do not belong in the hardening feature
area, probably in another one. OOC how many packages do enable all
hardening features?

> Dpkg for example builds fine with ASAN (with fixed #760690), but UBSAN
> makes it FTBFS due to the following issue:
> .../dpkg.git$ DEB_BUILD_MAINT_OPTIONS=hardening=all,+asan,+ubsan
> dpkg-buildpackage
> ...
> 
> PATH="../src:../scripts:../utils:/usr/lib/ccache:/home/rbalint/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
> \
>   LC_ALL=C \
>    \
>   srcdir=../../src builddir=. \
>   PERL_DL_NONLAZY=1 \
>   PERL5OPT= \
>   /usr/bin/perl -MTAP::Harness -e ' my $harness = TAP::Harness->new({
> lib => [ "../../scripts" ], color => 1, verbosity => 0, failures => 1,
> }); my $aggregate = $harness->runtests(@ARGV); die "FAIL: test suite has
> errors\n" if $aggregate->has_errors;' \
>      ../../src/t/dpkg_divert.t
> ../../src/t/dpkg_divert.t .. 1/257
> not ok 62 - --list stderr
> 
> #   Failed test '--list stderr'
> #   at ../../src/t/dpkg_divert.t line 106.
> #          got: '../../src/filesdb.c:581:21: runtime error: signed
> integer overflow: 313137907 * 1787 cannot be represented in type 'int'
> # '
> #     expected: ''
> not ok 65 - --list * stderr
> 
> The third patch fixes the issue.

Thanks! I've merged this one locally, will be included in 1.17.14.

> Please consired accepting the patches despite the fact that
> hardened-amd64 is not an official port yet. It would help the
> bootstrapping efforts and patch 2 would make it easier to experiment
> with ASAN and UBSAN for others.

It's not a matter of it being or not an official port, the main
requirement is that the GNU triplet is officially recognized and that
the naming and the thing makes sense. Which does not in this case.

Thanks,
Guillem

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

From: Bálint Réczey <balint@balintreczey.hu>

To: Guillem Jover <guillem@debian.org>

Cc: 760741@bugs.debian.org

Subject: Re: Bug#760741: dpkg: Please add new port hardened-amd64 enabling ASAN and UBSAN by default

Date: Sun, 7 Sep 2014 20:31:58 +0200

Hi Gulliem,

2014-09-07 17:26 GMT+02:00 Guillem Jover <guillem@debian.org>:
> Hi!
>
> On Sun, 2014-09-07 at 15:01:35 +0200, Balint Reczey wrote:
>> Package: dpkg
>> Version: 1.17.13
>> Severity: wishlist
>> Tags: patch
>
>> I'm working on a new port, hardened-amd64 [1].
>
> This does not what dpkg ports are meant to denote, as I think was
> mentioned in that thread. If the ports are ABI compatible then they
> are the same port. The lpia port was such a thing, which I disagreed
> with at the time but accepted anyway, and that was a mistake I'm not
> going to repeat. I'm planning on removing lpia support soonish to
> avoid anyone else take that as a precedent to follow.
>
> This is the equivalent of bumping the instruction set baseline or
> enabling a different set of build flags by default, etc. Please see
> the recent Boostrap Sprint notes on the multiple ISAs section, which
> is relevant for your scenario.
>
> In any case I'm not planning on adding support for a hardened-amd64
> architecture, sorry.
Sorry for not mentioning it earlier, but I don't intend to keep ABI
compatibility.
Libraries compiled with ASAN can't be loaded binaries without ASAN
support, thus the ABI can be considered to be different.
I also plan removing some functions which are deprecated for security
reasons but path of the ABI such as getwd(), thus ABI compatibility is
broken again, in a different way.
Third, I would like to enable breaking the ABI for enabling efficient
tracking of pointers through library calls. SoftBound + CETS [2]
projects are researching this way and if they come up with something
usable I would like to adopt it.
Based on the three reasons above please don't consider amd64 and
hardened-amd64 ABI compatible and please don't reject it due to having
compatible ABI.

>
>> The attached patches adds
>> the new port and enables ASAN and UBSAN through the hardening flags.
>> The flags are disabled on other architectures by default even when using
>> hardening=all, since ASAN causes significant slowdown and UBSAN will
>> probably reveal a lot of issues in many packages.
>
> I'd be fine with adding ASAN and UBSAN or any other hardening stuff,
> disabled by default on a feature area, but if they do not make sense
> to be enabled by “all” then they do not belong in the hardening feature
> area, probably in another one. OOC how many packages do enable all
> hardening features?
I think distinguishing between 'all' and 'extra' has its history, gcc
-Wall and -Wextra are similar to our case. I think ASAN should not be
part of 'all' because it should be enebled for packages shipping
binaries first, then in packages shipping the libraries used by the
binaries, thus it is not a per-package decision to enable ASAN.
UBSAN is different, I think it could be added to 'all', but I'm not
sure how many packages use 'all' and I did not want to break them.
Maybe after a full archive rebuild revealing the breakages.

>
>> Dpkg for example builds fine with ASAN (with fixed #760690), but UBSAN
>> makes it FTBFS due to the following issue:
>> .../dpkg.git$ DEB_BUILD_MAINT_OPTIONS=hardening=all,+asan,+ubsan
>> dpkg-buildpackage
>> ...
>>
>> PATH="../src:../scripts:../utils:/usr/lib/ccache:/home/rbalint/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
>> \
>>   LC_ALL=C \
>>    \
>>   srcdir=../../src builddir=. \
>>   PERL_DL_NONLAZY=1 \
>>   PERL5OPT= \
>>   /usr/bin/perl -MTAP::Harness -e ' my $harness = TAP::Harness->new({
>> lib => [ "../../scripts" ], color => 1, verbosity => 0, failures => 1,
>> }); my $aggregate = $harness->runtests(@ARGV); die "FAIL: test suite has
>> errors\n" if $aggregate->has_errors;' \
>>      ../../src/t/dpkg_divert.t
>> ../../src/t/dpkg_divert.t .. 1/257
>> not ok 62 - --list stderr
>>
>> #   Failed test '--list stderr'
>> #   at ../../src/t/dpkg_divert.t line 106.
>> #          got: '../../src/filesdb.c:581:21: runtime error: signed
>> integer overflow: 313137907 * 1787 cannot be represented in type 'int'
>> # '
>> #     expected: ''
>> not ok 65 - --list * stderr
>>
>> The third patch fixes the issue.
>
> Thanks! I've merged this one locally, will be included in 1.17.14.
>
>> Please consired accepting the patches despite the fact that
>> hardened-amd64 is not an official port yet. It would help the
>> bootstrapping efforts and patch 2 would make it easier to experiment
>> with ASAN and UBSAN for others.
>
> It's not a matter of it being or not an official port, the main
> requirement is that the GNU triplet is officially recognized and that
> the naming and the thing makes sense. Which does not in this case.
I'm not sure which part of the proposal you are questioning here so I
try to answer all of them.
I think there was precedent for adopting an GNU triplet first in
Debian then later getting it adopted upstream.
I'm not tied to a name. I think it is reasonable and reflects that
this is not a port with a different kernel (hardened-amd64 vs.
kfreebsd-i386), but I'm open for better proposals.
I tried to explain the goals of having this new port (improved
security, discovering more bugs using the Debian buildds
automatically) and I think they make sense.
IMO the multiple ISAs proposal which would work for mips does not work
here due to binaries and libraries are not being interchangeable
separately.

I think if this port gets accepted it will be the third most popular
port after it stabilizes and it will also let us discover and fix a
lot of bugs early in the archive.

Cheers,
Balint

[2] https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/

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

From: Bálint Réczey <balint@balintreczey.hu>

To: Guillem Jover <guillem@debian.org>

Cc: 760741@bugs.debian.org

Subject: Re: Bug#760741: dpkg: Please add new port hardened-amd64 enabling ASAN and UBSAN by default

Date: Sun, 7 Sep 2014 20:49:11 +0200

2014-09-07 20:31 GMT+02:00 Bálint Réczey <balint@balintreczey.hu>:
> Hi Gulliem,
>
> 2014-09-07 17:26 GMT+02:00 Guillem Jover <guillem@debian.org>:
>> Hi!
>>
>> On Sun, 2014-09-07 at 15:01:35 +0200, Balint Reczey wrote:
>>> Package: dpkg
>>> Version: 1.17.13
>>> Severity: wishlist
>>> Tags: patch
...
>> I'd be fine with adding ASAN and UBSAN or any other hardening stuff,
>> disabled by default on a feature area, but if they do not make sense
>> to be enabled by “all” then they do not belong in the hardening feature
>> area, probably in another one. OOC how many packages do enable all
>> hardening features?
> I think distinguishing between 'all' and 'extra' has its history, gcc
> -Wall and -Wextra are similar to our case. I think ASAN should not be
> part of 'all' because it should be enebled for packages shipping
> binaries first, then in packages shipping the libraries used by the
> binaries, thus it is not a per-package decision to enable ASAN.
> UBSAN is different, I think it could be added to 'all', but I'm not
> sure how many packages use 'all' and I did not want to break them.
> Maybe after a full archive rebuild revealing the breakages.
Looks like 7-9% of packages use 'all'.
http://outflux.net/debian/hardening/

Cheers,
Balint

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

From: Guillem Jover <guillem@debian.org>

To: balint@balintreczey.hu, 760741@bugs.debian.org

Subject: Re: Bug#760741: dpkg: Please add new port hardened-amd64 enabling ASAN and UBSAN by default

Date: Mon, 15 Sep 2014 16:44:04 +0200

Hi!

On Sun, 2014-09-07 at 20:31:58 +0200, Bálint Réczey wrote:
> 2014-09-07 17:26 GMT+02:00 Guillem Jover <guillem@debian.org>:
> > On Sun, 2014-09-07 at 15:01:35 +0200, Balint Reczey wrote:
> >> Package: dpkg
> >> Version: 1.17.13
> >> Severity: wishlist
> >> Tags: patch

> >> I'm working on a new port, hardened-amd64 [1].
> >
> > This does not what dpkg ports are meant to denote, as I think was
> > mentioned in that thread. If the ports are ABI compatible then they
> > are the same port. The lpia port was such a thing, which I disagreed
> > with at the time but accepted anyway, and that was a mistake I'm not
> > going to repeat. I'm planning on removing lpia support soonish to
> > avoid anyone else take that as a precedent to follow.
> >
> > This is the equivalent of bumping the instruction set baseline or
> > enabling a different set of build flags by default, etc. Please see
> > the recent Boostrap Sprint notes on the multiple ISAs section, which
> > is relevant for your scenario.
> >
> > In any case I'm not planning on adding support for a hardened-amd64
> > architecture, sorry.

> Sorry for not mentioning it earlier, but I don't intend to keep ABI
> compatibility.

In what ways? You mention some above, but I'd like to understand to
what extend.

> Libraries compiled with ASAN can't be loaded binaries without ASAN
> support, thus the ABI can be considered to be different.

Do you have more information on this, I didn't see anything obvious
by reading the (almost non-existent) information in gcc, and the
canonical one in
<http://dev.chromium.org/developers/testing/addresssanitizer>.

> I also plan removing some functions which are deprecated for security
> reasons but path of the ABI such as getwd(), thus ABI compatibility is
> broken again, in a different way.

Well, these kind of functions can be deactivated w/o breaking ABI. For
example getwd() could return NULL and set errno to ENAMETOOLONG. Or
even abort at run-time. Or it could be marked to emit an error at
build-time.

> Third, I would like to enable breaking the ABI for enabling efficient
> tracking of pointers through library calls. SoftBound + CETS [2]
> projects are researching this way and if they come up with something
> usable I would like to adopt it.

Well, once the architecture is accepted it's “supposed” to have a
stable os-kernel-cpu ABI defined, it seems to me you want to have the
freedom to experiment with new developments that might break ABI? In
which case I think this really should be a private playground until
something stable has been defined.

> >> The attached patches adds
> >> the new port and enables ASAN and UBSAN through the hardening flags.
> >> The flags are disabled on other architectures by default even when using
> >> hardening=all, since ASAN causes significant slowdown and UBSAN will
> >> probably reveal a lot of issues in many packages.
> >
> > I'd be fine with adding ASAN and UBSAN or any other hardening stuff,
> > disabled by default on a feature area, but if they do not make sense
> > to be enabled by “all” then they do not belong in the hardening feature
> > area, probably in another one. OOC how many packages do enable all
> > hardening features?

> I think distinguishing between 'all' and 'extra' has its history, gcc
> -Wall and -Wextra are similar to our case. I think ASAN should not be
> part of 'all' because it should be enebled for packages shipping
> binaries first, then in packages shipping the libraries used by the
> binaries, thus it is not a per-package decision to enable ASAN.
> UBSAN is different, I think it could be added to 'all', but I'm not
> sure how many packages use 'all' and I did not want to break them.
> Maybe after a full archive rebuild revealing the breakages.

What I meant is that I'm going to add a new feature area named “qa”,
alongside “hardening”, so it seems it might make sense to have a new
“sanitizer” (or similar name) feature area, with all new interesting
sanitizer options, such as asan, ubsan, tsan, lsan, etc. Does that
make more sense now?

> >> Please consired accepting the patches despite the fact that
> >> hardened-amd64 is not an official port yet. It would help the
> >> bootstrapping efforts and patch 2 would make it easier to experiment
> >> with ASAN and UBSAN for others.
> >
> > It's not a matter of it being or not an official port, the main
> > requirement is that the GNU triplet is officially recognized and that
> > the naming and the thing makes sense. Which does not in this case.

> I'm not sure which part of the proposal you are questioning here so I
> try to answer all of them.

I added a FAQ entry about all the requirements (I could remember) a
new port needs to fulfill at the end of
<https://wiki.debian.org/Teams/Dpkg/FAQ>. As it stands this
architecture seems to fail several of them.

> I think there was precedent for adopting an GNU triplet first in
> Debian then later getting it adopted upstream.

That might have been the case in the distant past, I'd rather have it
the other way around, in general.

> I'm not tied to a name. I think it is reasonable and reflects that
> this is not a port with a different kernel (hardened-amd64 vs.
> kfreebsd-i386), but I'm open for better proposals.

Any Linux port needs to use a single word name.

> I tried to explain the goals of having this new port (improved
> security, discovering more bugs using the Debian buildds
> automatically) and I think they make sense.

Oh! I think those goals do make sense, I'm not sure if they make sense
as part of an entire new port.

Thanks,
Guillem

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

From: Guillem Jover <guillem@debian.org>

To: balint@balintreczey.hu, 760741@bugs.debian.org

Cc: Sylvestre Ledru <sylvestre@debian.org>

Subject: Re: Bug#760741: dpkg: Please add new port hardened-amd64 enabling ASAN and UBSAN by default

Date: Tue, 24 Feb 2015 02:11:50 +0100

[Message part 1 (text/plain, inline)]

[ CCing Sylvestre given the involvement in the GSoC proposal. ]

Hi!

On Mon, 2014-09-15 at 16:44:04 +0200, Guillem Jover wrote:
> On Sun, 2014-09-07 at 20:31:58 +0200, Bálint Réczey wrote:
> > 2014-09-07 17:26 GMT+02:00 Guillem Jover <guillem@debian.org>:
> > > On Sun, 2014-09-07 at 15:01:35 +0200, Balint Reczey wrote:

> > >> The attached patches adds
> > >> the new port and enables ASAN and UBSAN through the hardening flags.
> > >> The flags are disabled on other architectures by default even when using
> > >> hardening=all, since ASAN causes significant slowdown and UBSAN will
> > >> probably reveal a lot of issues in many packages.
> > >
> > > I'd be fine with adding ASAN and UBSAN or any other hardening stuff,
> > > disabled by default on a feature area, but if they do not make sense
> > > to be enabled by “all” then they do not belong in the hardening feature
> > > area, probably in another one. OOC how many packages do enable all
> > > hardening features?
> 
> > I think distinguishing between 'all' and 'extra' has its history, gcc
> > -Wall and -Wextra are similar to our case. I think ASAN should not be
> > part of 'all' because it should be enebled for packages shipping
> > binaries first, then in packages shipping the libraries used by the
> > binaries, thus it is not a per-package decision to enable ASAN.
> > UBSAN is different, I think it could be added to 'all', but I'm not
> > sure how many packages use 'all' and I did not want to break them.
> > Maybe after a full archive rebuild revealing the breakages.
> 
> What I meant is that I'm going to add a new feature area named “qa”,
> alongside “hardening”, so it seems it might make sense to have a new
> “sanitizer” (or similar name) feature area, with all new interesting
> sanitizer options, such as asan, ubsan, tsan, lsan, etc. Does that
> make more sense now?

Here's the patch I'm considering to commit, and given that there's been
no replies to the other questions and issues rised previously in the bug
report, I'm thinking about closing it with this patch.

Thanks,
Guillem

[0001-Dpkg-Vendor-Debian-Add-sanitize-area-feature.patch (text/x-diff, attachment)]

Message #33 received at 760741-submitter@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: 760741-submitter@bugs.debian.org

Subject: Bug#760741 marked as pending

Date: Wed, 01 Apr 2015 05:27:29 +0000

Control: tag 760741 pending

Hi!

Bug #760741 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:

    https://anonscm.debian.org/cgit/dpkg/dpkg.git/diff/?id=c005f4e

---
commit c005f4e35a4f91a250cb0108ab5644ce7e1d064c
Author: Guillem Jover <guillem@debian.org>
Date:   Tue Oct 21 22:43:55 2014 +0200

    Dpkg::Vendor::Debian: Add sanitize feature area
    
    This feature area includes the features “address”, “thread”, “leak” and
    “undefined”, all disabled by default.
    
    Cloess: #760741

diff --git a/debian/changelog b/debian/changelog
index cc3bdc2..c566c9c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -98,6 +98,9 @@ dpkg (1.18.0) UNRELEASED; urgency=low
     Thanks to Mathias Behrle <mathiasb@m9s.biz>.
   * Add support for $DEFAULT_TEXT_DOMAIN to Dpkg::Gettext, so that the Dpkg
     perl modules can always produce localized messages.
+  * Add a new dpkg-buildflags sanitize feature area:
+    - Add new “address”, “thread”, “leak” and “undefined” features, all
+      disabled by default. Closes: #760741
 
   [ Raphaël Hertzog ]
   * Drop myself from Uploaders.

Message #40 received at 760741-close@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: 760741-close@bugs.debian.org

Subject: Bug#760741: fixed in dpkg 1.18.0

Date: Mon, 18 May 2015 18:22:01 +0000

Source: dpkg
Source-Version: 1.18.0

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.

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 760741@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@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Mon, 18 May 2015 15:08:31 +0200
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source all
Version: 1.18.0
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: 588505 616614 630342 650077 690361 693951 760741 767003 768842 769515 771752 772184 773398 773718 775124 775258 775379 776072 776551 777044 779467 780866 781074 781887 782019 782326 783014 784966 785096
Changes:
 dpkg (1.18.0) unstable; urgency=low
 .
   [ Guillem Jover ]
   * Only trim trailing “/” and “/.” from «dpkg-query --search» arguments if
     they are a pathname, and not a pattern or a substring match.
   * Switch C/C++ code to use a new set of C locale character type functions
     independent of the current locale.
   * Add support for arch-bits and arch-endian dpkg-gensymbols tags.
     Closes: #630342
   * Switch perl code from legacy File::Path functions to new ones.
   * Fix perl uninitialized value usage in dpkg-scansources when the Binary
     field is missing.
   * Use dpkg-query instead of dpkg for --search in dpkg-shlibdeps so that
     the subprocesses get the correct admindir. Closes: #775258
   * Rework the Installed-Size field default value computation to make it
     reproducible regardless of the build system filesystem, and document
     how the value is computed and that it is just an approximation.
     Closes: #650077
   * Use strftime() instead of «date -R» in dpkg-genchanges, as the latter
     is not specified by POSIX and is not widely portable.
   * Warn on obsolete '<' and '>' operators in dpkg --compare-versions.
   * Trim end of line whitespace from dpkg and dselect config file parsers.
     Reported by Christoph Biedl <debian.axhn@manchmal.in-ulm.de>.
   * Do not silently eat a standalone ‘-’ in the libdpkg command-line parser.
   * Fix short-lived memory leaks in dpkg-deb and libdpkg. Closes: #769515
   * Fix «dpkg-deb -b» filename generation when the package does not contain
     an Architecture field. Regression introduced in dpkg 1.16.2.
   * Fix «dpkg --audit» to report missing and empty architecture fields.
     Regression introduced in dpkg 1.16.2.
   * Add support to dpkg-deb for reading the archive from standard input,
     except for --raw-extract which does not yet support it. Closes: #616614
     Based on a patch by Johannes Schauer <j.schauer@email.de>.
   * Add ‘.mailmap’ to the default dpkg-source ignore lists.
   * Set the SE Linux context on «dpkg-statoverride --update». Closes: #690361
   * Do not fail on dpkg-query -W and -l when multiple arguments match the
     same package. Closes: #588505
   * Change dpkg-maintscript-helper to handle symlinks and pathnames ending in
     slash. For the former error out, for the latter strip it. Closes: #771752
   * Support moving a conffile not being shipped anymore. Closes: #767003
     Thanks to Mathias Behrle <mathiasb@m9s.biz>.
   * Add a new dpkg-buildflags sanitize feature area:
     - Add new “address”, “thread”, “leak” and “undefined” features, all
       disabled by default. Closes: #760741
   * Do not accept unknown user or group names on «dpkg-statoverride --add».
     Regression introduced in dpkg 1.17.11. Closes: #775124
   * Normalize dpkg-parsechangelog command-line parsing, so that «-ovalue»,
     «-o value», «--option=value» and «--option value» will all be accepted.
     Closes: #693951
   * Add dpkg --ctrl-tarfile forwarding command for dpkg-deb.
   * Disable dependency checks on dpkg-buildpackage -S -nc.
   * Make dependency checks fatal for dpkg-buildpackage -S.
   * Update amd64 GNU cpu regex in cputable to match amd64 too, in addition
     to x86_64. This is required for FreeBSD.
   * Use badusage() instead of ohshit() for command-line errors.
   * Use the original template symbols file when diffing in dpkg-gensymbols.
     We should not create a new template symbols file, because the output
     might change (different sorting order for example) relative to the
     original. Closes: #773718
   * Do not leak kvm descriptors in start-stop-daemon on GNU/kFreeBSD systems.
     Based on a patch by Jeff Epler <jepler@unpythonic.net>. Closes: #779467
   * Switch start-stop-daemon to use a monotonic clock if available. This
     makes the timeout checks resilient to abrupt system clock changes.
     Suggested by Jose M Calhariz <jose.calhariz@hds.com>. Closes: #783014
   * Fix perl warning in dpkg-genchanges when parsing BY-HAND file entries.
     Regression introduced in dpkg 1.17.7. Closes: #781074
   * Use the checksums files list order when building the Files field to match
     the other Checksum fields in dpkg-genchanges.
   * Skip files based on the architecture from the filename in dpkg-genchanges.
   * Allow binary packages not found in debian/control in dpkg-genchanges,
     which could allow injecting debug .debs for example.
   * Annotate any non-deb binary descriptions (not just udebs) with their
     package type in dpkg-genchanges.
   * Remove outdated local copy of the Debian README.mirrors.txt file from
     dselect ftp access method, and print a message pointing to the current
     URL instead. Closes: #784966
   * Cleanup default dpkg-shlibdeps shared library directory search list:
     - Do not add cross-root directories (/<triplet>/ and /usr/<triplet>/).
     - Remove ancient multilib /emul/ia32-linux/ paths.
     - Reorder directory precedence to:
       «dpkg-shlibdeps -l» > ENV{LD_LIBRARY_PATHS} > cross-multiarch >
       DEFAULT_LIBRARY_PATH > ld.so.conf > DEFAULT_MULTILIB_PATH
   * When upgrading, copy over the cached arch-qualified package name. This
     fixes wrong output when cross-grading.
   * Consider foreign packages ambiguous in need of an arch-qualifier.
   * Perl modules:
     - Rename and deprecate Dpkg::Gettext _g function with new g_.
     - Assume in Dpkg::Arch that the abitable is always present, and bump
       libdpkg-perl Depends on dpkg to 1.16.3, the version introducing the file.
     - Remove support for GCC_TARGET environment variable from Dpkg::Shlibs.
       This was a temporary workaround for very old gcc toolchains. See #453267.
     - Prefer multiarch paths to multilib ones in Dpkg::Shlibs.
       Thanks to Helmut Grohne <helmut@subdivi.de>. Closes: #772184
     - Enable sub-second timestamps in Dpkg::Source::Patch by using Time::HiRes.
     - Use TMPDIR instead of manually setting DIR on tempfile() call in
       Dpkg::Source::Package::V2.
     - Switch Dpkg::Checksums from using checksum programs to the more portable
       Digest modules. Obsolete the 'program' property, and add a 'name' one.
     - Add support for $DEFAULT_TEXT_DOMAIN to Dpkg::Gettext, so that the Dpkg
       perl modules can always produce localized messages.
     - Fix OpenPGP Armor Header Line parsing in Dpkg::Control::Hash. We should
       only accept [\r\t ] as trailing whitespace, although RFC4880 does not
       clarify what whitespace really maps to, we should really match the GnuPG
       implementation anyway, as that's what we use to verify the signatures.
       Reported by Jann Horn <jann@thejh.net>. Fixes CVE-2015-0840.
     - Pass PATCH_GET environment varialbe instead of -g0 to the patch command
       in Dpkg::Source::Patch. This allows using non-GNU patch programs, like
       FreeBSD's patch.
     - Accept an %opts argument for the Dpkg::Control::Info constructor, and
       accept either passing a filename option as undef, or a scalar undef.
       Closes: #782019
     - Do not print on undef filehandle in Dpkg::Control::Info output().
       Thanks to Roderich Schupp <roderich.schupp@gmail.com>. Closes: #781887
     - Always sort the Dpkg::Dist::Files files list on output, instead of
       preserving the insertion order, which is not reproducible with parallel
       builds. Reported by Jérémy Bobbio <lunar@debian.org>.
     - Add new filter() method to Dpkg::Substvars.
     - Kill the process when reaching timeout in Dpkg::IPC::wait_child().
   * Test suite:
     - Check perl code compilation, warnings and strictness.
     - Fix dpkg-divert unit test to work on BSD «rm -rf» that cannot traverse
       directories with mode 000.
     - Fix dpkg-divert unit test to work when there is no /dev/full.
     - Skip test cases when there is no c++filt available.
     - Add test cases for Dpkg::Conf and Dpkg::Checksums.
     - Handle libtool executables in progname unit test.
     - Do not use a timeout when testing cat I/O, speeds up test suite by 5s.
     - Reduce timeout test from 5 seconds to 1, to speed up test suite by 4s.
   * Build system:
     - Bump gettext version to 0.19:
       + Use --add-location=file in msgmerge and xgettext commands.
       + Use --porefs=noline for po4a command.
     - Wrap file references in man page PO files with po4a --porefs=wrap.
     - Fix support for cross-building dpkg:
       + Assume a working C99 snprintf on SUS >= v3.
       + Do not try to run the va_copy configure check, just check that the
         symbol is available.
     - Check that HAVE_DECL_SYS_SIGLIST is 0 instead of undefined, to fix a
       build failure on uclibc based systems. Closes: #777044
       Based on a patch by Alex Potapenko <opotapenko@gmail.com>.
     - Use single suffix rules instead of non-portable %-pattern rules.
     - Pass CC to the test suite, so that we can use a non-gcc compiler.
     - Call AM_PROG_AR to detect the correct system archiver to use.
     - Pass -Wall to automake in AM_INIT_AUTOMAKE, not implied by foreign.
   * Packaging:
     - Remove old trigger related Breaks and Conflicts from dpkg.
     - Only use stackprotectorstrong when building dpkg with gcc >= 4.9.
     - Switch to debhelper compatibility level 9.
     - Name each public-domain license with a different name.
     - Add missing public modules to dpkg-dev package description.
     - Get rid of backward compatibility pseudo-tags from bug reports.
     - Install doc/README.feature-removal-schedule only on affected packages
       and debian/usertags everywhere.
   * Documentation:
     - Document arch-qualifiers for dependency fields in deb-control(5) and
       deb-src-control(5). Reported by Johannes Schauer <j.schauer@email.de>.
       Closes: #768842
     - Document versioned Provides in deb-control(5).
     - Document the version when dpkg-deb --raw-extract got introduced.
     - Document dpkg --log format, add missing actions and describe the startup
       messages. Closes: #773398
     - Document when and how the dpkg-maintscript-helper package name argument
       is or should be arch-qualified. Closes: #776072
     - Fix and update Arch substvar description in deb-substvars(5).
     - Document that current build flag feature areas only work on Debian and
       derivatives in dpkg-buildflags(1).
     - Use “wildcard characters” instead of “wildchars” in dpkg-query(1).
     - Document dpkg-query --search behavior in man page. Closes: #775379
     - Document postinst “triggered” argument in debian/dpkg.postinst comment
       header.
     - Document Dpkg::IPC function signatures.
     - Document the obsolete --compare-versions '<' and '>' operators in the
       dpkg(1) man page. Thanks to Tomas Pospisek <tpo_hp@sourcepole.ch>.
       Closes: #776551
     - Move dpkg-divert, dpkg-statoverride and update-alternatives man pages
       from section 8 to 1, to match their installation path.
     - Capitalize dpkg-parsechangelog(1) option descriptions.
     - Mark dpkg-parsechangelog(1) --format values in bold.
     - Place short options before long ones in dpkg-mergechangelogs(1) and
       dselect(1) man pages.
     - Properly terminate a bold marking in dpkg(1).
     - Document in man pages the dpkg version when new features were introduced.
     - Document that timestamps are reset for files patched with source format
       “3.0 (quilt)” too.
     - Document in dpkg-buildpackage(1) that using dpkg-source is sometimes
       better than -S. Suggested by Johannes Schauer <j.schauer@email.de>.
     - Document dselect -? option.
     - Document in dpkg-buildflags(1) that DEB_VENDOR influences the execution.
     - Document that dpkg performs sanity checks on PATH.
     - Mark some words and commands as non-hyphenable in man pages.
     - Separate multi-line hanging tag paragraphs with .TQ in man pages.
     - Mark field names in bold in man pages.
     - Use various groff escape sequences for quoting characters.
     - Lowercase warning and note admonitions in start-stop-daemon(8).
     - Mark dselect(1) color attributes in bold.
     - Say output instead of display for dpkg-deb tar-file option in dpkg(1).
     - Say archive instead of filename for dpkg-deb option in dpkg(1).
     - Say control-field-name instead of control-file-field in dpkg-deb(1).
     - Fix option values and pathname markup in dpkg-deb(1).
     - Use .TQ to separate different but related options in dpkg(1).
     - Clarify that dpkg-buildpackage -jN forces parallel builds, regardless of
       the packaging or upstream build systems supporting them. Closes: #780866
     - Remove unneeded update-alternatives references from options descriptions.
     - Document that apt might expect Packages.xz too in dpkg-scanpackages(1).
     - Say METHODS instead of FUNCTIONS or OBJECT FOO in POD section titles.
     - Document dpkg version when perl module versions got bumped.
   * Output message fixes and improvements:
     - Remove trailing newline from string literal in warning calls.
     - Say “execute” instead of “exec” in Dpkg::Changelog::Parse error message.
     - Say “package” instead of “it” in dpkg-name warning message.
     - Uppercase field names in error messages.
     - Expand EOF and eof into “end of file” in error messages.
     - Use “<enter>” instead of “return” or “enter” in input prompts.
     - Say directory instead of dir in output messages.
     - Merge the same dpkg-scanpackages warning messages into a single line.
     - Clarify dpkg-genchanges changes description open error.
     - Add missing preposition in Dpkg::Source::Patch error message.
     - Improve available state sorting order strings in dselect panel.
     - Say “changelog-file” instead of “changelogfile” in --help output.
     - Say “command“ instead of “action“ for dselect.
     - Improve commands listing in «dselect --help» output, by printing them
       before options and listing them one on each line with a description.
     - Improve dselect color-spec --help output.
     - Move "(default)" annotations in scripts --help output after option
       description.
     - Consistently use proper quotation marks ("" or '', and not the
       unbalanced `' pair) all over the place.
     - Use syserr() instead of an ad-hoc error message in dpkg-scansources.
     - Say substvars instead of varlist in dpkg-shlibdeps error messages.
     - Fix error messages on invalid uid/git/mode command-line syntax errors
       in dpkg-statoverride, to not say they are from the statoverride file.
     - Fix error message on empty dsc file in dpkg-genchanges.
     - Mention “(^Z)” instead of “char” for the MSDOS end of file character.
 .
   [ Raphaël Hertzog ]
   * Drop myself from Uploaders.
 .
   [ Updated programs translations ]
   * Simplified Chinese (Zhou Mo). Closes: #782326
   * Turkish (Mert Dirik). Closes: #785096
   * Vietnamese (Trần Ngọc Quân).
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
 .
   [ Updated manpages translations ]
   * German (Helge Kreutzmann).
Checksums-Sha1:
 158ab1c81d80eea7127bb8e0eb0d30f4d9df2c06 2014 dpkg_1.18.0.dsc
 ec82818dc1a3990a87f6c8257adaab0445058a9f 4330304 dpkg_1.18.0.tar.xz
 ffe4d125594e847b3bb6f5951eb115a55f6fdd2d 1408828 dpkg-dev_1.18.0_all.deb
 9051fad27d2b01180d5415b29517328724ede516 1102386 libdpkg-perl_1.18.0_all.deb
Checksums-Sha256:
 c8b9009b644236c86abcd87d47c932735641983b4a54f616b87655db7a8f12a5 2014 dpkg_1.18.0.dsc
 7b156fbeed5bbfb8aa546a18badb46e471b65fa00777ccd8d7e3bbce002f225a 4330304 dpkg_1.18.0.tar.xz
 9d33b1adefce8c65721e77bd92ac8a7ba645a3d268dfb324e62b951df4b94ddd 1408828 dpkg-dev_1.18.0_all.deb
 39798e363bdfd7620fedfab787042580a3550e6e696fe703f190182b45f47f8d 1102386 libdpkg-perl_1.18.0_all.deb
Files:
 22762915c7530b472077d5708228b962 2014 admin required dpkg_1.18.0.dsc
 22d1a0cc18910fc1275a4fbc22aa4982 4330304 admin required dpkg_1.18.0.tar.xz
 2d6f6b6381a343c0262acc4233accd0f 1408828 utils optional dpkg-dev_1.18.0_all.deb
 ef39f89dae3f3006e4711d84c3b64b95 1102386 perl optional libdpkg-perl_1.18.0_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVWfCZAAoJELlyvz6krlej7u8P+wflvoopOuHfc5xBsoz2EWSj
sLe3v0qtQv3ffZfZ+M8dVUBC32Bf/11NNbyarf35g702nAay1DL5T2YDypXLCid7
3KoMRWbaiSsvABuF+SOHmGVccagL9f5bd3xgMNA1JgvqEJ6ujFuG7plRP9ieCpOK
nhmKKhp1uhQtF7NDu4UFOtVrJJpZqmJ5JwVr5thYukB46fRNeWSEgY6n20+VmjFL
ThCHIbhxtXxyQaR+PURNfNXlmBO/zK1sA/9aUTcX9pafXg83rrBuMVhr+SOwScQ/
YWFjoao0nmi+3Z+lL4fg3hxNz4QirHk0t2H97ivLd1A39J7YOooTIz+SgmPuuQZH
UV+DDS8xBE+fiH3Vn529yXa84puRndYA7iD1UW0nJzVEkyJbb6HcA+Qi1hjDRaD/
QOxA5gFcMXFi4tMu8KESMztL0SZOHvyWEl17p4Ofu+oHCvmh4jsw+MEjOWcSFzaC
YW8t7DC9pP1cMOhMYFJBxjO0YjIu3nOQ6n2/HzlAYnF5FPCoQC8JKcWgIyurzJI1
+YcL5aSeB9xyVJlKPl7gJk+LgKU4S4QKT1rs4z4uVML7WRIbXfzmoPZCOntqBvF/
Yr8Pf77ZFdIwzmiyQBHKmUaxGP/+z3gupl9UfF+/5u+ty08+rfRgoASEr5m0ej8Q
CU8WUmb6vEHwytaqwMmy
=J4L8
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.