Debian Bug report logs - #856210
libdebian-installer: please parse SHA256 field and add it to di_* structs

Toggle useless messages

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

From: Steven Chamberlain <steven@pyro.eu.org>

To: submit@bugs.debian.org

Subject: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Sun, 26 Feb 2017 16:25:06 +0000

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

Source: libdebian-installer
Version: 0.108
Severity: serious
Tags: security
X-Debbugs-Cc: security@debian.org
User: debian-release@lists.debian.org
Usertags: bsp-2017-02-de-Berlin

Hi,

The 'etch' release (2007) added to the Release file, a field for SHA256
sums to authenticate Packages files.  But to date, libdebian-installer
does not parse it, so anna (which fetches .udeb installer component) and
cdebootstrap (which fetches .deb base system packages) can not yet
verify the SHA256 sums.

http://sources.debian.net/src/libdebian-installer/0.108/include/debian-installer/release.h/#L43
http://sources.debian.net/src/libdebian-installer/0.108/include/debian-installer/release.h/#L58
http://sources.debian.net/src/libdebian-installer/0.108/include/debian-installer/package.h/#L115

Further context and an overview of related bugs will be published at:
https://wiki.debian.org/InstallerDebacle

This bug is not itself RC, but it will be a blocking issue for RC bugs
I'm about to file.

I intend to submit a patch for this shortly.

Thanks,
Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

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

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

From: Steven Chamberlain <steven@pyro.eu.org>

To: 856210@bugs.debian.org

Cc: security@debian.org

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Sun, 26 Feb 2017 18:30:31 +0000

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

Control: tags -1 + patch

Hi,

The regression in Bug#856215 in cdebootstrap:
"since SHA1 removal from Release file, only MD5sums are used"
could only be fixed by adding support for the SHA256 fields.

An open question is whether to preserve any support for MD5.
Keeping it would:

  + reduce potential for breakage (in case MD5 is "good enough" for some
    use-case or SHA256 is still impractical)
  + allow verifiers to check both MD5 *and* SHA256, for even stronger
    authentication in case one or both algorithms are broken
  - add complexity

Otherwise, dropping MD5 entirely would:

  * break reverse-dependencies (hopefully just anna, cdebootstrap) thus
    *forcing* us to stop using MD5 there, and implement SHA256

I've attached only the most minimal patch to allow reverse-depends do
implement SHA256.  They must adapt to the new names of struct members
*and* remember that the hash length is now different.  (The hash data is
stored in variable-length fields but the length is not recorded in the
structs, and the has is denoted by a magic number not an enum;  that
could be made better, but requiring a much larger diff).

A follow-up commit should extend the testsuite to check parsing of the
SHA256 fields;  that also would result in a larger diff however.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

[libdebian-installer_bug856210_v1.patch (text/x-diff, attachment)]

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

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

From: Steven Chamberlain <steven@pyro.eu.org>

To: 856210@bugs.debian.org

Cc: security@debian.org

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Sun, 26 Feb 2017 20:42:39 +0000

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

With that patch, reverse-deps anna and cdebootstrap shall FTBFS with:

| gcc -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -g -O2 -fdebug-prefix-map=/home/steven/git/anna=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wall -W -ggdb -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE  -c -o anna.o anna.c
| anna.c: In function ‘install_modules’:
| anna.c:321:25: error: ‘di_package {aka struct di_package}’ has no member named ‘md5sum’
|      if (! md5sum(package->md5sum, dest_file)) {
|                          ^~

| gcc -DHAVE_CONFIG_H -I. -I../../src -I..  -I../../include -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -fdebug-prefix-map=/home/steven/git/cdebootstrap-0.7.6=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -std=gnu99 -c -o gpg.o ../../src/gpg.c
| ../../src/check.c: In function ‘check_deb’:
| ../../src/check.c:61:40: error: ‘di_package {aka struct di_package}’ has no member named ‘md5sum’
|    return check_sum (target, "md5sum", p->md5sum, message);
|                                         ^~
| ../../src/check.c: In function ‘check_packages’:
| ../../src/check.c:75:35: error: ‘di_release {aka struct di_release}’ has no member named ‘md5sum’
|    item = di_hash_table_lookup (rel->md5sum, &key);
|                                    ^~

so it should be quite clear that they must implement a new hashing
algorithm;  and this makes absolutely sure they are not still using MD5
unintentionally (which was the case in #856215).

If my libdebian-installer patch is okay, I will submit the patches for
anna and cdebootstrap (bugs are already filed against them).  Hopefully
no other reverse-dependencies would be affected (because they do not use
the md5sums field, and the struct size is not changing);  though if they
do use, I'd prefer they FTBFS so that we find out.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

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

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

From: Bastian Blank <waldi@debian.org>

To: Steven Chamberlain <steven@pyro.eu.org>, 856210@bugs.debian.org

Cc: security@debian.org

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Sun, 26 Feb 2017 22:06:53 +0100

Hi Steven

On Sun, Feb 26, 2017 at 06:30:31PM +0000, Steven Chamberlain wrote:
> I've attached only the most minimal patch to allow reverse-depends do
> implement SHA256.  They must adapt to the new names of struct members
> *and* remember that the hash length is now different.  (The hash data is
> stored in variable-length fields but the length is not recorded in the
> structs, and the has is denoted by a magic number not an enum;  that
> could be made better, but requiring a much larger diff).

This change breaks the existing ABI and therefor needs an ABI bump, but
it is missing from the patch.

Regards,
Bastian

-- 
It is necessary to have purpose.
		-- Alice #1, "I, Mudd", stardate 4513.3

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

From: Steven Chamberlain <steven@pyro.eu.org>

To: Bastian Blank <waldi@debian.org>, 856210@bugs.debian.org

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Sun, 26 Feb 2017 23:17:52 +0000

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

Hi,

Bastian Blank wrote:
> This change breaks the existing ABI and therefor needs an ABI bump, but
> it is missing from the patch.

I agree, that should be done.  Thanks.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

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

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

From: Cyril Brulebois <kibi@debian.org>

To: Steven Chamberlain <steven@pyro.eu.org>

Cc: debian-boot@lists.debian.org, security@debian.org

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Mon, 27 Feb 2017 10:25:34 +0100

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

Hi,

Steven Chamberlain <steven@pyro.eu.org> (2017-02-26):
> Colin Watson wrote:
> > Just FYI, since it's not clear from
> > https://wiki.debian.org/InstallerDebacle that you know this, the
> > installer in fact uses debootstrap rather than cdebootstrap to install
> > the base system.
> 
> I didn't realise that, thanks.  There was still a cdebootstrap-udeb in
> wheezy, so that installer is affected?  But not releases since.

Well, I've only been doing d-i releases for a few cycles, but base-installer's
history shows no cdebootstrap-udeb in its Depends, ever; granted, history
starts at this point:
| commit 5203c4b49f36c4372de948f6b3edc1b9c4041a7a
| Author: Tollef Fog Heen <tfheen@debian.org>
| Date:   Sat Apr 27 19:16:08 2002 +0000
| 
|     Initial checkin
|     
|     r637

> base-installer seems it would (still now) use it in preference to
> regular debootstrap, *if* it was available in the installer:
> http://sources.debian.net/src/base-installer/1.168/debian/bootstrap-base.postinst/?hl=145#L145

The only reference I see in debian-installer's history is its being added in
post-sarge goals, before being removed again, so it looks to me it would only
be put there by people who are supposed to know what they're doing?

Adding to this my initial comments about anna and net-retriever, I think it
might have made sense to be a little less clickbaity with the whole “debacle”
title. While there's clearly room for improvements in various components, I'm
not sure the installation process is as broken as you made it to be.



KiBi.

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

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

From: Steven Chamberlain <steven@pyro.eu.org>

To: Bastian Blank <waldi@debian.org>, 856210@bugs.debian.org

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Mon, 27 Feb 2017 15:40:44 +0000

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

Bastian Blank wrote:
> This change breaks the existing ABI and therefor needs an ABI bump, but
> it is missing from the patch.

The attached patch tries to bump the soname to 5.  This makes the diff
much larger, but the code changes are the same.

I think libdebian-installer-extra nowadays gets a soname bump at the
same time as libdebian-installer (whereas in the past it was possible to
set a different soname for each).

(If we really wanted, we could maybe avoid the ABI bump:  no library
functions are being added/removed, only the name and meaning of a struct
member (a pointer, which remains the same length).  The
dynamically-sized buffer it points to, would change from storing an MD5
to a SHA256 hash, and would only cause a regression where something is
still trying to validate MD5).

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

[libdebian-installer_bug856210_v2.patch (text/x-diff, attachment)]

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

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

From: Cyril Brulebois <kibi@debian.org>

To: Steven Chamberlain <steven@pyro.eu.org>, 856210@bugs.debian.org

Cc: Bastian Blank <waldi@debian.org>

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Tue, 28 Feb 2017 04:11:50 +0100

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

Steven Chamberlain <steven@pyro.eu.org> (2017-02-27):
> The attached patch tries to bump the soname to 5.  This makes the diff
> much larger, but the code changes are the same.

Thanks. Some comments below.

> I think libdebian-installer-extra nowadays gets a soname bump at the
> same time as libdebian-installer (whereas in the past it was possible
> to set a different soname for each).

Probably fine to bump both at once.

> (If we really wanted, we could maybe avoid the ABI bump:  no library
> functions are being added/removed, only the name and meaning of a struct
> member (a pointer, which remains the same length).  The
> dynamically-sized buffer it points to, would change from storing an MD5
> to a SHA256 hash, and would only cause a regression where something is
> still trying to validate MD5).

Given the number of reverse dependencies, I doubt this is worth abusing
md5 storage for sha256 things. Bumping the ABI seems reasonable to me,
even if that's effectively starting a mini-transition from a release
point of view.

FWIW, out of all d-i packages, only anna seems to be accessing the
->md5sum member.

> +  [ Steven Chamberlain ]
> +  * Parse SHA256 fields instead of MD5Sum fields in Packages files.
> +  * Parse SHA256 fields instead of (no longer existing) SHA1 fields in
> +    Release files.
> +  * In structs di_release and di_package, add new sha256 member and
> +    remove the md5sum member (a backward-incompatible change, this will
> +    force reverse-dependencies to stop using MD5 for verification)
> +    (Closes: #856212).
> +  * Bump soname as advised by Bastian Blank.
> +
>   -- Samuel Thibault <sthibault@debian.org>  Tue, 31 Jan 2017 11:09:16 +0100
>  
>  libdebian-installer (0.108) unstable; urgency=medium
> diff --git a/debian/control b/debian/control
> index 0949fd9..f53f55c 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -8,7 +8,7 @@ Standards-Version: 3.9.6
>  Vcs-Browser: https://anonscm.debian.org/cgit/d-i/libdebian-installer.git
>  Vcs-Git: https://anonscm.debian.org/git/d-i/libdebian-installer.git
>  
> -Package: libdebian-installer4
> +Package: libdebian-installer5
>  Architecture: any
>  Multi-Arch: same
>  Pre-Depends: ${misc:Pre-Depends}
> @@ -19,10 +19,10 @@ Description: Library of common debian-installer functions
>   working on debian-installer or building your own install system based
>   on debian-installer, then you probably don't need this library.
>  
> -Package: libdebian-installer4-dev
> +Package: libdebian-installer5-dev

Please don't! We're not going to support multiple libfooN-dev at the
same time. If it were to be renamed, this should become for an
unversioned libdebian-installer-dev. And now is definitely not the
time for such a thing.

And of course, this would make packages unbuildable anyway, given
libdebian-installer4-dev appears in Build-Depends for a bunch of
packages.

>  Section: libdevel
>  Architecture: any
> -Depends: ${misc:Depends}, libdebian-installer4 (= ${binary:Version}), libdebian-installer-extra4 (= ${binary:Version})
> +Depends: ${misc:Depends}, libdebian-installer5 (= ${binary:Version}), libdebian-installer-extra5 (= ${binary:Version})
>  Conflicts: libdebian-installer-dev
>  Provides: libdebian-installer-dev
>  Description: Library of common debian-installer functions
> @@ -33,7 +33,7 @@ Description: Library of common debian-installer functions
>   .
>   This package contains files needed to do libdebian-installer development.
>  
> -Package: libdebian-installer4-udeb
> +Package: libdebian-installer5-udeb
>  Package-Type: udeb
>  Section: debian-installer
>  Architecture: any
> @@ -44,22 +44,22 @@ Description: Library of common debian-installer functions
>   working on debian-installer or building your own install system based
>   on debian-installer, then you probably don't need this library.
>  
> -Package: libdebian-installer-extra4
> +Package: libdebian-installer-extra5
>  Architecture: any
>  Multi-Arch: same
> -Depends: ${shlibs:Depends}, ${misc:Depends}, libdebian-installer4 (= ${binary:Version})
> +Depends: ${shlibs:Depends}, ${misc:Depends}, libdebian-installer5 (= ${binary:Version})
>  Description: Library of some extra debian-installer functions
>   This library is used by debian-installer to perform common functions
>   such as logging messages and executing commands. If you aren't
>   working on debian-installer or building your own install system based
>   on debian-installer, then you probably don't need this library.
>  
> -Package: libdebian-installer-extra4-udeb
> +Package: libdebian-installer-extra5-udeb
>  Package-Type: udeb
>  Section: debian-installer
>  Architecture: any
> -Depends: ${shlibs:Depends}, ${misc:Depends}, libdebian-installer4-udeb (= ${binary:Version})
> -Provides: libdebian-installer-extra4
> +Depends: ${shlibs:Depends}, ${misc:Depends}, libdebian-installer5-udeb (= ${binary:Version})
> +Provides: libdebian-installer-extra5
>  Description: Library of some extra debian-installer functions
>   This library is used by debian-installer to perform common functions
>   such as logging messages and executing commands. If you aren't
> diff --git a/debian/libdebian-installer-extra4-udeb.dirs b/debian/libdebian-installer-extra4-udeb.dirs
> deleted file mode 100644
> index a65b417..0000000
> --- a/debian/libdebian-installer-extra4-udeb.dirs
> +++ /dev/null
> @@ -1 +0,0 @@
> -lib
> diff --git a/debian/libdebian-installer-extra4.install b/debian/libdebian-installer-extra4.install
> deleted file mode 100644
> index 44ad198..0000000
> --- a/debian/libdebian-installer-extra4.install
> +++ /dev/null
> @@ -1 +0,0 @@
> -usr/lib/*/libdebian-installer-extra.so.*
> diff --git a/debian/libdebian-installer-extra4.shlibs.local b/debian/libdebian-installer-extra4.shlibs.local
> deleted file mode 100644
> index 6e76754..0000000
> --- a/debian/libdebian-installer-extra4.shlibs.local
> +++ /dev/null
> @@ -1 +0,0 @@
> -libdebian-installer 4
> diff --git a/debian/libdebian-installer4-dev.install b/debian/libdebian-installer4-dev.install
> deleted file mode 100644
> index 0bea7ad..0000000
> --- a/debian/libdebian-installer4-dev.install
> +++ /dev/null
> @@ -1,5 +0,0 @@
> -usr/include
> -usr/lib/*/*.a
> -usr/lib/*/*.so
> -usr/lib/*/pkgconfig
> -usr/share/doc/libdebian-installer4-dev/*
> diff --git a/debian/libdebian-installer4-udeb.dirs b/debian/libdebian-installer4-udeb.dirs
> deleted file mode 100644
> index a65b417..0000000
> --- a/debian/libdebian-installer4-udeb.dirs
> +++ /dev/null
> @@ -1 +0,0 @@
> -lib
> diff --git a/debian/libdebian-installer4.install b/debian/libdebian-installer4.install
> deleted file mode 100644
> index 289fbef..0000000
> --- a/debian/libdebian-installer4.install
> +++ /dev/null
> @@ -1 +0,0 @@
> -usr/lib/*/libdebian-installer.so.*

Seems like some git status/git add might have went missing, since files
are deleted instead of being renamed into their '5' counterparts?

> diff --git a/debian/rules b/debian/rules
> index 11b0963..b084adc 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -26,16 +26,16 @@ override_dh_auto_build:
>  	$(MAKE) -C build/doc doc
>  
>  override_dh_install:
> -	install $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libdebian-installer.so.4 $(CURDIR)/debian/libdebian-installer4-udeb/lib
> -	install $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libdebian-installer-extra.so.4 $(CURDIR)/debian/libdebian-installer-extra4-udeb/lib
> +	install $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libdebian-installer.so.5 $(CURDIR)/debian/libdebian-installer5-udeb/lib
> +	install $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libdebian-installer-extra.so.5 $(CURDIR)/debian/libdebian-installer-extra5-udeb/lib
>  	dh_install --sourcedir=debian/tmp
>  
>  override_dh_makeshlibs:
> -	dh_makeshlibs -plibdebian-installer4 -V \
> -		--add-udeb=libdebian-installer4-udeb
> -	dh_makeshlibs -plibdebian-installer-extra4 -V \
> -		--add-udeb=libdebian-installer-extra4-udeb
> +	dh_makeshlibs -plibdebian-installer5 -V \
> +		--add-udeb=libdebian-installer5-udeb
> +	dh_makeshlibs -plibdebian-installer-extra5 -V \
> +		--add-udeb=libdebian-installer-extra5-udeb
>  
>  override_dh_shlibdeps:
> -	dh_shlibdeps -N libdebian-installer-extra4 -N libdebian-installer-extra4-udeb
> -	dh_shlibdeps -p libdebian-installer-extra4 -p libdebian-installer-extra4-udeb -- -L$(CURDIR)/debian/libdebian-installer-extra4.shlibs.local
> +	dh_shlibdeps -N libdebian-installer-extra5 -N libdebian-installer-extra5-udeb
> +	dh_shlibdeps -p libdebian-installer-extra5 -p libdebian-installer-extra5-udeb -- -L$(CURDIR)/debian/libdebian-installer-extra5.shlibs.local
> diff --git a/include/debian-installer/package.h b/include/debian-installer/package.h
> index 72d7444..e1f699d 100644
> --- a/include/debian-installer/package.h
> +++ b/include/debian-installer/package.h
> @@ -112,7 +112,7 @@ struct di_package
>    di_slist depends;                                     /**< Any different dependency types */
>    char *filename;                                       /**< Filename field */
>    size_t size;                                          /**< Size field */
> -  char *md5sum;                                         /**< MD5Sum field */
> +  char *sha256;                                         /**< SHA256 field */
>    char *short_description;                              /**< Description field, first part*/
>    char *description;                                    /**< Description field, second part */
>    unsigned int resolver;                                /**< @internal */
> diff --git a/include/debian-installer/package_internal.h b/include/debian-installer/package_internal.h
> index f6357d1..d410ce2 100644
> --- a/include/debian-installer/package_internal.h
> +++ b/include/debian-installer/package_internal.h
> @@ -52,7 +52,7 @@ const di_parser_fieldinfo
>    internal_di_package_parser_field_enhances,
>    internal_di_package_parser_field_filename,
>    internal_di_package_parser_field_size,
> -  internal_di_package_parser_field_md5sum,
> +  internal_di_package_parser_field_sha256,
>    internal_di_package_parser_field_description;
>  
>  /**
> diff --git a/include/debian-installer/release.h b/include/debian-installer/release.h
> index 223a4f8..8e3c572 100644
> --- a/include/debian-installer/release.h
> +++ b/include/debian-installer/release.h
> @@ -40,7 +40,7 @@ struct di_release
>    char *origin;                                 /**< Origin field */
>    char *suite;                                  /**< Suite field */
>    char *codename;                               /**< Codename field */
> -  di_hash_table *md5sum;                        /**< checksum fields, includes di_release_file */
> +  di_hash_table *sha256;                        /**< checksum fields, includes di_release_file */
>    di_mem_chunk *release_file_mem_chunk;         /**< @internal */
>  };

So md5sum goes away from the di_release struct…

>  
> @@ -55,7 +55,7 @@ struct di_release_file
>      di_rstring key;                             /**< @internal */
>    };
>    unsigned int size;                            /**< size */
> -  char *sum[2];                                 /**< checksums, currently md5 and sha1 */
> +  char *sum[2];                                 /**< checksums, currently md5 and sha256 */

… but is kept in the di_release_file one?

>  };
>  
>  di_release *di_release_alloc (void);
> diff --git a/src/package.c b/src/package.c
> index 653b5dd..82c7653 100644
> --- a/src/package.c
> +++ b/src/package.c
> @@ -38,7 +38,7 @@ void di_package_destroy (di_package *package)
>    di_free (package->architecture);
>    di_free (package->version);
>    di_free (package->filename);
> -  di_free (package->md5sum);
> +  di_free (package->sha256);
>    di_free (package->short_description);
>    di_free (package->description);
>  
> diff --git a/src/package_parser.c b/src/package_parser.c
> index 6d6a5e7..de80d7e 100644
> --- a/src/package_parser.c
> +++ b/src/package_parser.c
> @@ -180,13 +180,13 @@ const di_parser_fieldinfo
>        di_parser_write_int,
>        offsetof (di_package, size)
>      ),
> -  internal_di_package_parser_field_md5sum =
> +  internal_di_package_parser_field_sha256 =
>      DI_PARSER_FIELDINFO
>      (
> -      "MD5sum",
> +      "SHA256",
>        di_parser_read_string,
>        di_parser_write_string,
> -      offsetof (di_package, md5sum)
> +      offsetof (di_package, sha256)
>      ),
>    internal_di_package_parser_field_description =
>      DI_PARSER_FIELDINFO
> @@ -217,7 +217,7 @@ const di_parser_fieldinfo *di_package_parser_fieldinfo[] =
>    &internal_di_package_parser_field_enhances,
>    &internal_di_package_parser_field_filename,
>    &internal_di_package_parser_field_size,
> -  &internal_di_package_parser_field_md5sum,
> +  &internal_di_package_parser_field_sha256,
>    &internal_di_package_parser_field_description,
>    NULL
>  };
> diff --git a/src/packages_parser.c b/src/packages_parser.c
> index ac5c06b..30d66ba 100644
> --- a/src/packages_parser.c
> +++ b/src/packages_parser.c
> @@ -65,7 +65,7 @@ const di_parser_fieldinfo *di_packages_parser_fieldinfo[] =
>    &internal_di_package_parser_field_enhances,
>    &internal_di_package_parser_field_filename,
>    &internal_di_package_parser_field_size,
> -  &internal_di_package_parser_field_md5sum,
> +  &internal_di_package_parser_field_sha256,
>    &internal_di_package_parser_field_description,
>    NULL
>  };
> @@ -109,7 +109,7 @@ const di_parser_fieldinfo *di_packages_minimal_parser_fieldinfo[] =
>    &internal_di_package_parser_field_depends,
>    &internal_di_package_parser_field_pre_depends,
>    &internal_di_package_parser_field_filename,
> -  &internal_di_package_parser_field_md5sum,
> +  &internal_di_package_parser_field_sha256,
>    &internal_di_package_parser_field_size,
>    NULL
>  };
> diff --git a/src/release.c b/src/release.c
> index 7cc7cbf..7aff0d7 100644
> --- a/src/release.c
> +++ b/src/release.c
> @@ -69,10 +69,10 @@ const di_parser_fieldinfo
>        NULL,
>        0
>      )

Same as release.h here, keeping md5sum?

> -  internal_di_release_parser_field_sha1 =
> +  internal_di_release_parser_field_sha256 =
>      DI_PARSER_FIELDINFO
>      (
> -      "SHA1",
> +      "SHA256",
>        di_release_parser_read_file,
>        NULL,
>        1
> @@ -87,7 +87,7 @@ const di_parser_fieldinfo *di_release_parser_fieldinfo[] =
>    &internal_di_release_parser_field_suite,
>    &internal_di_release_parser_field_codename,
>    &internal_di_release_parser_field_md5sum,
> -  &internal_di_release_parser_field_sha1,
> +  &internal_di_release_parser_field_sha256,

Same question, keeping md5sum?

>    NULL
>  };
>  
> @@ -110,7 +110,7 @@ di_release *di_release_alloc (void)
>    di_release *ret;
>  
>    ret = di_new0 (di_release, 1);
> -  ret->md5sum = di_hash_table_new_full (di_rstring_hash, di_rstring_equal, NULL, internal_di_release_file_destroy_func);
> +  ret->sha256 = di_hash_table_new_full (di_rstring_hash, di_rstring_equal, NULL, internal_di_release_file_destroy_func);
>    ret->release_file_mem_chunk = di_mem_chunk_new (sizeof (di_release_file), 4096);
>  
>    return ret;
> @@ -124,7 +124,7 @@ void di_release_free (di_release *release)
>    di_free (release->origin);
>    di_free (release->suite);
>    di_free (release->codename);
> -  di_hash_table_destroy (release->md5sum);
> +  di_hash_table_destroy (release->sha256);
>    di_mem_chunk_destroy (release->release_file_mem_chunk);
>    di_free (release);
>  }
> @@ -169,7 +169,7 @@ void di_release_parser_read_file (data, fip, field_modifier, value, user_data)
>    int ret;
>    size_t buf_size;
>    di_release *release = *data;
> -  di_hash_table *table = release->md5sum;
> +  di_hash_table *table = release->sha256;
>  
>    while (1)
>    {


KiBi.

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

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

From: Bastian Blank <waldi@debian.org>

To: Cyril Brulebois <kibi@debian.org>

Cc: Steven Chamberlain <steven@pyro.eu.org>, 856210@bugs.debian.org

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Tue, 28 Feb 2017 07:36:39 +0100

On Tue, Feb 28, 2017 at 04:11:50AM +0100, Cyril Brulebois wrote:
> > (If we really wanted, we could maybe avoid the ABI bump:  no library
> > functions are being added/removed, only the name and meaning of a struct
> > member (a pointer, which remains the same length).  The
> > dynamically-sized buffer it points to, would change from storing an MD5
> > to a SHA256 hash, and would only cause a regression where something is
> > still trying to validate MD5).
> 
> Given the number of reverse dependencies, I doubt this is worth abusing
> md5 storage for sha256 things. Bumping the ABI seems reasonable to me,
> even if that's effectively starting a mini-transition from a release
> point of view.

On second thought, let's just do it without ABI name change.  For d-i
breaks don't work well, but if we update them en block this will not
show any breakage.  For the rest (exactl one user) breaks works fine.

Bastian

-- 
It would be illogical to assume that all conditions remain stable.
		-- Spock, "The Enterprise Incident", stardate 5027.3

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

From: Steven Chamberlain <steven@pyro.eu.org>

To: Cyril Brulebois <kibi@debian.org>

Cc: 856210@bugs.debian.org, Bastian Blank <waldi@debian.org>

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Tue, 28 Feb 2017 13:07:51 +0000

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

Thanks for your comments!

Cyril Brulebois wrote:
> Steven Chamberlain <steven@pyro.eu.org> (2017-02-27):
> > (If we really wanted, we could maybe avoid the ABI bump: [...]
> 
> Given the number of reverse dependencies, I doubt this is worth abusing
> md5 storage for sha256 things.

Maybe I should clarify that;  the current libdebian-installer/0.108 has:

di_package struct {
	...
	char *md5sum; // -> dynamically allocated md5sum field
	...
}

and we'd be changing it to:

di_package struct {
	...
	char *sha256; // -> dynamically allocated sha256 field
	...
}

("Sum" was dropped from name of that field in the Release file, so I do
the same here)

Changing the name, causes reverse-deps using that field to FTBFS.  I
think that is just anna and cdebootstrap, which we'd patch anyway.

The md5sum/sha256 field is a pointer to a dynamically-allocated field.
The struct size, and the offset of other members does not change, so
nothing else should need rebuilding with the newer package.h

"If" somehow, we missed something, which tries to dereference
package->md5sum at run-time with a new version of libdebian-installer,
it would find a sha256 hash there instead of md5.  That should fail
"safely" by complaining of a md5sum mismatch (even if it only compares
the first 32 bytes, as cdebootstrap does currently).

That's why I think an ABI bump could be safely avoided.  (And I think
Bastian agrees now?)

> Bumping the ABI seems reasonable to me,
> even if that's effectively starting a mini-transition from a release
> point of view.

[...]

> > -Package: libdebian-installer4-dev
> > +Package: libdebian-installer5-dev
> 
> Please don't!

You suggest to "bump the ABI" but not rename the packages?  or...?
Maybe the argument above is convincing enough to just not bump the ABI?

> > --- a/include/debian-installer/release.h
> > +++ b/include/debian-installer/release.h
> > @@ -40,7 +40,7 @@ struct di_release
> >    char *origin;                                 /**< Origin field */
> >    char *suite;                                  /**< Suite field */
> >    char *codename;                               /**< Codename field */
> > -  di_hash_table *md5sum;                        /**< checksum fields, includes di_release_file */
> > +  di_hash_table *sha256;                        /**< checksum fields, includes di_release_file */
> >    di_mem_chunk *release_file_mem_chunk;         /**< @internal */
> >  };
> 
> So md5sum goes away from the di_release struct…

Yes, the same as with di_package;  that preserves ABI compatibility,
and getting rid of md5sum is also our intent.

> 
> >  
> > @@ -55,7 +55,7 @@ struct di_release_file
> >      di_rstring key;                             /**< @internal */
> >    };
> >    unsigned int size;                            /**< size */
> > -  char *sum[2];                                 /**< checksums, currently md5 and sha1 */
> > +  char *sum[2];                                 /**< checksums, currently md5 and sha256 */
> 
> … but is kept in the di_release_file one?

Right, this struct currently contains:

char *sum[0] -> dynamically allocated md5sum field
char *sum[1] -> dynamically allocated sha1 field

so that is what reverse-depends expect to be in those fields,
currently.  To keep ABI comptibility, I should keep two items there.

The sha1 field is always empty, since that was removed from the Release
file.  We could either:

  1. replace sum[0] with sha256 and leave sum[1] empty;  or
  2. leave sum[0] containing md5 but replace sum[1] with sha256

My patch did 2. because it results in a smaller diff.  But I like the
idea of doing 1. instead (we would drop the MD5- and SHA1-parsing code
and make absolutely sure nobody is still using those).

If I did 1. and we didn't bump the ABI, it should be easy to test:
  * we'd patch+update only libdebian-installer, then test:
    anna should abort the install, due to mismatching md5sums;
  * then we'd patch anna, and it should all work again;  one could
    also delete the /usr/bin/md5sum symlink while testing.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

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

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

From: Steven Chamberlain <steven@pyro.eu.org>

To: Cyril Brulebois <kibi@debian.org>

Cc: 856210@bugs.debian.org, Bastian Blank <waldi@debian.org>

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Tue, 28 Feb 2017 15:36:49 +0000

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

Steven Chamberlain wrote:
> replace sum[0] with sha256 and leave sum[1] empty; 
> [...] (we would drop the MD5- and SHA1-parsing code
> and make absolutely sure nobody is still using those).

The new patch attached would do that, and it remains otherwise
ABI-compatible.

It aims to be the most minimal diff, so it does not extend the testsuite
for example, which still passes even though the Packages file testcase
has no SHA256 fields.

In src/release.c:  file->sum[1] is initialised to NULL by a calloc().
In the future, someone might want to put SHA512 hashes there.  It does
not hurt to keep the existing di_free(file->sum[1]) in place.

Within the installer, this should only break anna, until the patch from
#856211 is applied.

Outside of the installer, cdebootstrap would break, until #856212 is
patched.

If we missed any other reverse-depends, they should FTBFS if they
dereference the md5sum fields.  Already-built binaries should report a
"md5sum mismatch", if they use the patched libdebian-installer at
run-time and still try to do verification with MD5.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

[libdebian-installer_bug856210_v3.patch (text/x-diff, attachment)]

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

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

From: Cyril Brulebois <kibi@debian.org>

To: Steven Chamberlain <steven@pyro.eu.org>

Cc: 856210@bugs.debian.org, Bastian Blank <waldi@debian.org>

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Tue, 28 Feb 2017 20:31:46 +0100

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

Hi,

Steven Chamberlain <steven@pyro.eu.org> (2017-02-28):
> Changing the name, causes reverse-deps using that field to FTBFS.  I
> think that is just anna and cdebootstrap, which we'd patch anyway.

Sure.

> The md5sum/sha256 field is a pointer to a dynamically-allocated field.
> The struct size, and the offset of other members does not change, so
> nothing else should need rebuilding with the newer package.h
> 
> "If" somehow, we missed something, which tries to dereference
> package->md5sum at run-time with a new version of libdebian-installer,
> it would find a sha256 hash there instead of md5.  That should fail
> "safely" by complaining of a md5sum mismatch (even if it only compares
> the first 32 bytes, as cdebootstrap does currently).
> 
> That's why I think an ABI bump could be safely avoided.  (And I think
> Bastian agrees now?)

I only glanced quickly over the “minimal patch” you sent as a follow-up,
and I think that should do just fine at this point of the release cycle,
yes.

Maybe Bastian will comment before I do (not sure I'll be able to look
into it before a few days).

> > Bumping the ABI seems reasonable to me, even if that's effectively
> > starting a mini-transition from a release point of view.
> 
> [...]
> 
> > > -Package: libdebian-installer4-dev
> > > +Package: libdebian-installer5-dev
> > 
> > Please don't!
> 
> You suggest to "bump the ABI" but not rename the packages?  or...?

But not rename *this* particular binary.

There's no reason to have a versioned -dev package, unless you're
maintaining various src:fooX, src:fooY packages at the same time, and so
that one can choose between libfooX-dev and libfooY-dev (hello openssl).
That's not what's happening here.

> Maybe the argument above is convincing enough to just not bump the ABI?
> 
> > > --- a/include/debian-installer/release.h
> > > +++ b/include/debian-installer/release.h
> > > @@ -40,7 +40,7 @@ struct di_release
> > >    char *origin;                                 /**< Origin field */
> > >    char *suite;                                  /**< Suite field */
> > >    char *codename;                               /**< Codename field */
> > > -  di_hash_table *md5sum;                        /**< checksum fields, includes di_release_file */
> > > +  di_hash_table *sha256;                        /**< checksum fields, includes di_release_file */
> > >    di_mem_chunk *release_file_mem_chunk;         /**< @internal */
> > >  };
> > 
> > So md5sum goes away from the di_release struct…
> 
> Yes, the same as with di_package;  that preserves ABI compatibility,
> and getting rid of md5sum is also our intent.

FWIW I'm not sure I'm convinced changing semantics for a given field can
be advertised as keeping “ABI compatibility” (even if one can decide to
ignore this issue).

> > > @@ -55,7 +55,7 @@ struct di_release_file
> > >      di_rstring key;                             /**< @internal */
> > >    };
> > >    unsigned int size;                            /**< size */
> > > -  char *sum[2];                                 /**< checksums, currently md5 and sha1 */
> > > +  char *sum[2];                                 /**< checksums, currently md5 and sha256 */
> > 
> > … but is kept in the di_release_file one?
> 
> Right, this struct currently contains:
> 
> char *sum[0] -> dynamically allocated md5sum field
> char *sum[1] -> dynamically allocated sha1 field
> 
> so that is what reverse-depends expect to be in those fields,
> currently.  To keep ABI comptibility, I should keep two items there.

Well, your initial patch was bumping the ABI, so it looked to me like it
could have been cleaned up at the same time, and that's why I asked. But
nevermind, going a different route now. Someone can rethink this with a
dynamic checksum mapping in a later release (see people/waldi branch).


KiBi.

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

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

From: Bastian Blank <waldi@debian.org>

To: Steven Chamberlain <steven@pyro.eu.org>, 856210@bugs.debian.org

Cc: security@debian.org

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Tue, 28 Feb 2017 22:35:27 +0100

On Sun, Feb 26, 2017 at 06:30:31PM +0000, Steven Chamberlain wrote:
> I've attached only the most minimal patch to allow reverse-depends do
> implement SHA256.  They must adapt to the new names of struct members
> *and* remember that the hash length is now different.  (The hash data is
> stored in variable-length fields but the length is not recorded in the
> structs, and the has is denoted by a magic number not an enum;  that
> could be made better, but requiring a much larger diff).

Adopted and commited to
https://anonscm.debian.org/git/d-i/libdebian-installer.git, branch
sha256

Bastian

-- 
Totally illogical, there was no chance.
		-- Spock, "The Galileo Seven", stardate 2822.3

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

From: Steven Chamberlain <steven@pyro.eu.org>

To: Bastian Blank <waldi@debian.org>, 856210@bugs.debian.org, security@debian.org

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Tue, 28 Feb 2017 22:00:01 +0000

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

Bastian Blank wrote:
> Adopted and commited to
> https://anonscm.debian.org/git/d-i/libdebian-installer.git, branch
> sha256

That differs from the latest version of my patch, and from what I sent
earlier today to the release team when asking about a potential unblock:
https://lists.debian.org/debian-release/2017/02/msg01033.html

I think we should wait for them to answer before doing anything else.

Based on KiBi's feedback I thought it better to swap sum[0] and sum[1],
and remove the SHA1 parsing also.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

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

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

From: Bastian Blank <waldi@debian.org>

To: Steven Chamberlain <steven@pyro.eu.org>, 856210@bugs.debian.org

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Tue, 28 Feb 2017 23:41:10 +0100

On Tue, Feb 28, 2017 at 10:00:01PM +0000, Steven Chamberlain wrote:
> That differs from the latest version of my patch, and from what I sent
> earlier today to the release team when asking about a potential unblock:
> https://lists.debian.org/debian-release/2017/02/msg01033.html

This happens if you send incomplete patches and do uncoordinated unblock
requests.

Bastian

-- 
Bones: "The man's DEAD, Jim!"

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

From: Steven Chamberlain <steven@pyro.eu.org>

To: Bastian Blank <waldi@debian.org>, 856210@bugs.debian.org

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Tue, 28 Feb 2017 22:56:27 +0000

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

Bastian Blank wrote:
> On Tue, Feb 28, 2017 at 10:00:01PM +0000, Steven Chamberlain wrote:
> > That differs from the latest version of my patch, and from what I sent
> > earlier today to the release team when asking about a potential unblock:
> > https://lists.debian.org/debian-release/2017/02/msg01033.html
> 
> This happens if you send incomplete patches and do uncoordinated unblock
> requests.

Maybe you just volunteered to do that, then.

You even said before you "don't have time" to write the cdebootstrap
patch, so I offered one, and the anna patch, the libdebian-installer
patch, all this after the initial discovery, triage and write-up.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

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

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

From: Julien Cristau <jcristau@debian.org>

To: Steven Chamberlain <steven@pyro.eu.org>, 856210@bugs.debian.org, Bastian Blank <waldi@debian.org>

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Wed, 1 Mar 2017 14:25:12 +0100

On 02/27/2017 04:40 PM, Steven Chamberlain wrote:
> Bastian Blank wrote:
>> This change breaks the existing ABI and therefor needs an ABI bump, but
>> it is missing from the patch.
> 
> The attached patch tries to bump the soname to 5.  This makes the diff
> much larger, but the code changes are the same.
> 
> I think libdebian-installer-extra nowadays gets a soname bump at the
> same time as libdebian-installer (whereas in the past it was possible to
> set a different soname for each).
> 
> (If we really wanted, we could maybe avoid the ABI bump:  no library
> functions are being added/removed, only the name and meaning of a struct
> member (a pointer, which remains the same length).  The
> dynamically-sized buffer it points to, would change from storing an MD5
> to a SHA256 hash, and would only cause a regression where something is
> still trying to validate MD5).
> 
Changing semantics of an existing struct member is classic ABI breakage.
 This does very much need a SONAME bump.

Cheers,
Julien

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

From: Steven Chamberlain <steven@pyro.eu.org>

To: 856210@bugs.debian.org

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Wed, 1 Mar 2017 13:52:07 +0000

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

Control: tags -1 - patch

I've no more desire to work on this bug, sorry.

Thanks for the feedback that was given, but it has already been more
effort than I have time or patience to contribute.

For what should be essentially, s/md5/sha256/ in a few places, the
required procedures and personal interactions beyond that, is just too
much.  That is the real "debacle";  it is not surprising to me now, that
this did not happen yet in 10 years, or that no enthusiastic new
contributor had already done this.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

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

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

From: Bastian Blank <waldi@debian.org>

To: Julien Cristau <jcristau@debian.org>

Cc: Steven Chamberlain <steven@pyro.eu.org>, 856210@bugs.debian.org

Subject: Re: Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

Date: Wed, 1 Mar 2017 15:54:45 +0100

On Wed, Mar 01, 2017 at 02:25:12PM +0100, Julien Cristau wrote:
> Changing semantics of an existing struct member is classic ABI breakage.
>  This does very much need a SONAME bump.

Technically yes.  But this one is noe used uncontrolled outside.  So it
works without.

Bastian

-- 
Warp 7 -- It's a law we can live with.

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

From: Bastian Blank <waldi@debian.org>

To: 856210-close@bugs.debian.org

Subject: Bug#856210: fixed in libdebian-installer 0.109

Date: Sun, 05 Mar 2017 11:33:53 +0000

Source: libdebian-installer
Source-Version: 0.109

We believe that the bug you reported is fixed in the latest version of
libdebian-installer, 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 856210@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bastian Blank <waldi@debian.org> (supplier of updated libdebian-installer 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: Sun, 05 Mar 2017 11:02:27 +0000
Source: libdebian-installer
Binary: libdebian-installer4 libdebian-installer4-dev libdebian-installer4-udeb libdebian-installer-extra4 libdebian-installer-extra4-udeb
Architecture: source
Version: 0.109
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Changed-By: Bastian Blank <waldi@debian.org>
Description:
 libdebian-installer-extra4 - Library of some extra debian-installer functions
 libdebian-installer-extra4-udeb - Library of some extra debian-installer functions (udeb)
 libdebian-installer4 - Library of common debian-installer functions
 libdebian-installer4-dev - Library of common debian-installer functions
 libdebian-installer4-udeb - Library of common debian-installer functions (udeb)
Closes: 853489 856210
Changes:
 libdebian-installer (0.109) unstable; urgency=medium
 .
   [ Samuel Thibault ]
   * Fix build with gcc-7. Closes: #853489
 .
   [ Steven Chamberlain ]
   * Parse SHA256 fields in Packages files.  (closes: #856210)
   * Parse SHA256 fields in Release files.
 .
   [ Bastian Blank ]
   * Update versions for changed symbols.
     - Add Breaks on cdebootrap.
Checksums-Sha1:
 651339f4a8613b3bb186f153077bd30e18111acc 1877 libdebian-installer_0.109.dsc
 ed1faa09fbd711c1c2e31aa415b733981b22daff 78960 libdebian-installer_0.109.tar.xz
 097747ca7cfe2deb3f49a0675bb3be24c648ffd4 4570 libdebian-installer_0.109_source.buildinfo
Checksums-Sha256:
 50255aa8202f1a4fb2d42f43211cc68f4600fe7b0ba909187f8055066f77ef60 1877 libdebian-installer_0.109.dsc
 ac3025dadda656716045b7901c551abfa0b339ae47429471df1f5c75976c4b73 78960 libdebian-installer_0.109.tar.xz
 3e0f4deda32b4cc6c0d8e41ac5d3b1103882efa2b4180aee09633806acc97f07 4570 libdebian-installer_0.109_source.buildinfo
Files:
 a8de0535b202a6f24c61e82938b8429d 1877 libs optional libdebian-installer_0.109.dsc
 abbe45edaf66741e8c8019869d7e9d2a 78960 libs optional libdebian-installer_0.109.tar.xz
 c403b6d945d8d4b3e7319f86e88d46ee 4570 libs optional libdebian-installer_0.109_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEER3HMN63jdS1rqjxLbZOIhYpp/lEFAli79LUACgkQbZOIhYpp
/lEV1wgAiKoXA9ZsOY6gBZmDBzj39K7Udps74XeivkdzjAUUMRWRP8dIkQVFBw6B
DGUK+drhQ6lXNAgTyMupQcKIp38VRR4c1jywewFSAHnNNvz8DN8//sSrCdDM+1jJ
pLCZN9lSjvCKtPH934MtT9jZVZh4/L0xrRa+ZkgN3ncG5ajA2Jmf6/ZOrkyNETDa
miu4FFr103z9JdFG82NG6ZJGdMRlkCGj5SDZkxEb58PfmEwU6CoOMRDB9hXE1hT4
z0SMsDPJJxBpmX4dSjOqMNlfoSCZhnIJixLeeUloQ71JEXLiv/tKg01YdJtQ4p9+
/R6ESqSa+97pXl/2eNdSkF+3WbICnQ==
=zzKV
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.