Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #5173 > unrolled thread

Some Debian package upgrades are corrupting rsync "quick check" backups

Back to article view | Back to linux.debian.security

Contents

  Some Debian package upgrades are corrupting rsync "quick check"  backups Adam Warner <lists@consulting.net.nz> - 2017-01-28 14:20 +0100
    Re: Some Debian package upgrades are corrupting rsync "quick check"  backups Christoph Biedl <debian.axhn@manchmal.in-ulm.de> - 2017-01-28 15:00 +0100
    Re: Some Debian package upgrades are corrupting rsync "quick check"  backups Daniel Reichelt <debian@nachtgeist.net> - 2017-01-28 15:50 +0100
      Re: Some Debian package upgrades are corrupting rsync "quick check"  backups Holger Levsen <holger@layer-acht.org> - 2017-01-28 16:00 +0100
        Re: Some Debian package upgrades are corrupting rsync "quick check"  backups Daniel Reichelt <debian@nachtgeist.net> - 2017-01-28 16:40 +0100
        Re: Some Debian package upgrades are corrupting rsync "quick check"  backups Lupe Christoph <lupe@lupe-christoph.de> - 2017-01-28 23:10 +0100
          Re: Some Debian package upgrades are corrupting rsync "quick       check" backups "Jonathan Hutchins" <hutchins@tarcanfel.org> - 2017-01-29 00:10 +0100
          Re: Some Debian package upgrades are corrupting rsync "quick check"  backups Santiago Vila <sanvila@unex.es> - 2017-01-29 20:30 +0100
            Re: Some Debian package upgrades are corrupting rsync "quick check" backups Russell Coker <russell@coker.com.au> - 2017-01-30 10:40 +0100
          Re: Some Debian package upgrades are corrupting rsync "quick check"  backups Jonathan Wiltshire <jmw@debian.org> - 2017-01-29 21:20 +0100
          Re: Some Debian package upgrades are corrupting rsync "quick check"  backups Henrik Ahlgren <pablo@seestieto.com> - 2017-01-30 13:10 +0100
            Re: Some Debian package upgrades are corrupting rsync "quick check"  backups Mattia Rizzolo <mattia@debian.org> - 2017-01-30 13:20 +0100
              Re: Some Debian package upgrades are corrupting rsync "quick check"  backups Holger Levsen <holger@layer-acht.org> - 2017-01-30 14:30 +0100
                Re: Some Debian package upgrades are corrupting rsync "quick check" backups Johannes Schauer <josch@debian.org> - 2017-01-30 15:00 +0100
                  Re: Some Debian package upgrades are corrupting rsync "quick check"  backups Holger Levsen <holger@layer-acht.org> - 2017-01-30 15:00 +0100
                    Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync  "quick check" backups Johannes Schauer <josch@debian.org> - 2017-01-30 16:30 +0100
                      Re: [buildd-tools-devel] Some Debian package upgrades are corrupting  rsync "quick check" backups Chris Lamb <lamby@debian.org> - 2017-05-13 16:50 +0200
                        Re: [buildd-tools-devel] Some Debian package upgrades are corrupting  rsync "quick check" backups Holger Levsen <holger@layer-acht.org> - 2017-05-13 18:00 +0200
                        Re: [buildd-tools-devel] Some Debian package upgrades are corrupting  rsync "quick check" backups Mattia Rizzolo <mattia@debian.org> - 2017-05-13 18:00 +0200
                          Re: [buildd-tools-devel] Some Debian package upgrades are corrupting  rsync "quick check" backups Aurelien Jarno <aurelien@aurel32.net> - 2017-05-13 21:40 +0200
                            Re: [buildd-tools-devel] Some Debian package upgrades are corrupting  rsync "quick check" backups Aurelien Jarno <aurelien@aurel32.net> - 2017-05-13 22:50 +0200
                              Re: [buildd-tools-devel] Some Debian package upgrades are corrupting  rsync "quick check" backups Holger Levsen <holger@layer-acht.org> - 2017-05-13 23:00 +0200
                              Re: [buildd-tools-devel] Some Debian package upgrades are  corrupting rsync "quick check" backups Adam Warner <lists@consulting.net.nz> - 2017-08-28 08:20 +0200
                                Re: [buildd-tools-devel] Some Debian package upgrades are corrupting  rsync "quick check" backups Aurelien Jarno <aurelien@aurel32.net> - 2017-08-28 12:40 +0200
                                  Re: [buildd-tools-devel] Some Debian package upgrades are corrupting  rsync "quick check" backups Aurelien Jarno <aurelien@aurel32.net> - 2017-08-28 12:50 +0200
                                    Re: [buildd-tools-devel] Some Debian package upgrades are corrupting  rsync "quick check" backups Aurelien Jarno <aurelien@aurel32.net> - 2017-08-28 13:00 +0200
                                      Re: [buildd-tools-devel] Some Debian package upgrades are  corrupting rsync "quick check" backups Adam Warner <lists@consulting.net.nz> - 2017-08-28 14:20 +0200
    Re: Some Debian package upgrades are corrupting rsync "quick check"  backups Bob Weber <bobrweber@gmail.com> - 2017-01-28 17:20 +0100

Page 1 of 2  [1] 2  Next page →

#5173 — Some Debian package upgrades are corrupting rsync "quick check" backups

Hi all,

rsync typically detects file modifications by comparing exact
modification time and size of each identically named file in the source
and destination locations.

An rsync backup can be surreptitiously corrupted by modifying a source
file's content while keeping its size and modification time the same.

If some program is doing this then one way for rsync to detect the
modification is by appending the --checksum option. This requires every
file in the source and destination to be fully read. This can be many
orders of magnitude slower than a "quick check".

If you have been using rsync without --checksum to back up your Debian
partitions then your backups are likely corrupted.

Some packages are being generated with files containing exactly the
same size and timestamps even though the contents of those files are
different. This is how the data corruption arises:

1. You use rsync to back up your OS partition.
2. You perform package upgrades. Some files are replaced with different
content but have the same size and modification time.
3. You use rsync to back up your OS partition to the same destination.
The modified files with the same size and modification time are
skipped. Your backup is now corrupt (you have old files mixed with new
files).

Here's a recent example of a package upgrade causing this:

<https://packages.debian.org/testing/amd64/libqt5concurrent5/download>
<https://packages.debian.org/sid/amd64/libqt5concurrent5/download>

If you're tracking unstable you may have recently upgraded from
libqt5concurrent5_5.7.1+dfsg-3_amd64.deb to
libqt5concurrent5_5.7.1+dfsg-3+b1_amd64.deb (a subsequent binary non-
maintainer upload).

Here are the contents of both packages:
$ dpkg -c libqt5concurrent5_5.7.1+dfsg-3_amd64.deb 
drwxr-xr-x root/root         0 2017-01-12 04:14 ./
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/lib/
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/lib/x86_64-linux-gnu/
-rw-r--r-- root/root     27352 2017-01-12 04:14 ./usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5.7.1
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/share/
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/share/doc/
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/share/doc/libqt5concurrent5/
-rw-r--r-- root/root      1196 2016-12-01 21:17 ./usr/share/doc/libqt5concurrent5/LGPL_EXCEPTION.txt
-rw-r--r-- root/root     18232 2017-01-12 04:14 ./usr/share/doc/libqt5concurrent5/changelog.Debian.gz
-rw-r--r-- root/root      3792 2016-12-01 21:17 ./usr/share/doc/libqt5concurrent5/changelog.gz
-rw-r--r-- root/root    103466 2017-01-12 04:14 ./usr/share/doc/libqt5concurrent5/copyright
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/share/lintian/
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/share/lintian/overrides/
-rw-r--r-- root/root       230 2017-01-12 04:14 ./usr/share/lintian/overrides/libqt5concurrent5
lrwxrwxrwx root/root         0 2017-01-12 04:14 ./usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5 -> libQt5Concurrent.so.5.7.1
lrwxrwxrwx root/root         0 2017-01-12 04:14 ./usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5.7 -> libQt5Concurrent.so.5.7.1

$ dpkg -c libqt5concurrent5_5.7.1+dfsg-3+b1_amd64.deb 
drwxr-xr-x root/root         0 2017-01-12 04:14 ./
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/lib/
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/lib/x86_64-linux-gnu/
-rw-r--r-- root/root     27352 2017-01-12 04:14 ./usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5.7.1
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/share/
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/share/doc/
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/share/doc/libqt5concurrent5/
-rw-r--r-- root/root      1196 2016-12-01 21:17 ./usr/share/doc/libqt5concurrent5/LGPL_EXCEPTION.txt
-rw-r--r-- root/root       252 2017-01-12 04:14 ./usr/share/doc/libqt5concurrent5/changelog.Debian.amd64.gz
-rw-r--r-- root/root     18232 2017-01-12 04:14 ./usr/share/doc/libqt5concurrent5/changelog.Debian.gz
-rw-r--r-- root/root      3792 2016-12-01 21:17 ./usr/share/doc/libqt5concurrent5/changelog.gz
-rw-r--r-- root/root    103466 2017-01-12 04:14 ./usr/share/doc/libqt5concurrent5/copyright
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/share/lintian/
drwxr-xr-x root/root         0 2017-01-12 04:14 ./usr/share/lintian/overrides/
-rw-r--r-- root/root       230 2017-01-12 04:14 ./usr/share/lintian/overrides/libqt5concurrent5
lrwxrwxrwx root/root         0 2017-01-12 04:14 ./usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5 -> libQt5Concurrent.so.5.7.1
lrwxrwxrwx root/root         0 2017-01-12 04:14 ./usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5.7 -> libQt5Concurrent.so.5.7.1

In particular notice the shared library
/usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5.7.1 has an identical
size and timestamp.

However:
(testing) $ sha256sum ./usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5.7.1
aef7b3d108ba5c686279fa2dbd63bb7916b1bb79ec69faeab55ea8f3b85725df  ./usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5.7.1
(sid) $ sha256sum ./usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5.7.1
052a748ebc2ab3e65e8b25cab3515a73762450b7c84308dad157c1f677e21b0a  ./usr/lib/x86_64-linux-gnu/libQt5Concurrent.so.5.7.1

Why is a 27 January recompilation of the source package purporting to
have the same modification time as the original binary package
distributed 16 days earlier?

It is now also clear I have previously encountered this with some X
shared libraries.

I suggest an rsync --checksum test on your backups (using
--itemize-changes and --dry-run to check for modifications without
making changes to the destination).

Regards,
Adam Warner

[toc] | [next] | [standalone]

#5174

[Multipart message — attachments visible in raw view] — view raw

Adam Warner wrote...

> Why is a 27 January recompilation of the source package purporting to
> have the same modification time as the original binary package
> distributed 16 days earlier?

Lemme guess: For the sake of reproducible builds, the timestamp of all
created files is set to the time of the latest changelog entry.

> I suggest an rsync --checksum test on your backups (using
> --itemize-changes and --dry-run to check for modifications without
> making changes to the destination).

This is an ugly situation. Always using --checksum brings a huge penalty
indeed. The rsync program could take the source file's ctime into
account but I doubt there's support for that.

To me it seems saner to change Debian's workflow. Adding a new changelog
entry for a binNMU would break a lot of things, though. The least
intrusive but quite hacky way I can think of was to modify the timestamp
by adding one second for the first binNMU and so on. Nothing that gets
implemented over night, though.

    Christoph

[toc] | [prev] | [next] | [standalone]

#5175

[Multipart message — attachments visible in raw view] — view raw

Hi,

I highly suspect this stems from packages' rules files supporting
reproducible builds.

The only way I see to solve this would be for the "reproducible builds"
infrastructure to hard-wire new timestamps at release-time of a new
package version.

Also: this is not limited to rsync. Basically any tool relying on
(mtime/file size) as a changed indicator is affected by this. Even if
the tool in question relied on (mtime/file size/inode number), "changed
checks" could be subverted in situations where changes are made to the
file directly instead of writing a new file and moving it into place
(thus retaining the inode number).


Cheers
Daniel

[toc] | [prev] | [next] | [standalone]

#5176

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jan 28, 2017 at 03:04:56PM +0100, Daniel Reichelt wrote:
> I highly suspect this stems from packages' rules files supporting
> reproducible builds.

I rather think this is due to binNMUs not modifying debian/changelog…
(in the source package while it's modified in the binary packages…)


-- 
cheers,
	Holger

[toc] | [prev] | [next] | [standalone]

#5177

[Multipart message — attachments visible in raw view] — view raw

On 01/28/2017 03:51 PM, Holger Levsen wrote:
> On Sat, Jan 28, 2017 at 03:04:56PM +0100, Daniel Reichelt wrote:
>> I highly suspect this stems from packages' rules files supporting
>> reproducible builds.
> 
> I rather think this is due to binNMUs not modifying debian/changelog…
> (in the source package while it's modified in the binary packages…)
> 

Makes sense. Thanks for the clarification, Holger.

[toc] | [prev] | [next] | [standalone]

#5179

On Saturday, 2017-01-28 at 14:51:19 +0000, Holger Levsen wrote:
> On Sat, Jan 28, 2017 at 03:04:56PM +0100, Daniel Reichelt wrote:
> > I highly suspect this stems from packages' rules files supporting
> > reproducible builds.

> I rather think this is due to binNMUs not modifying debian/changelog…
> (in the source package while it's modified in the binary packages…)

This is completely counter intuitive. I'm using rsnapshot to backup a
few private machines. I will have to set up separate rsnapshots for
those parts of the backup that suffer from this <expletive>, to avoid
bogging down the data parts by unnecessary checksum calculations.

This problem may affect many other backups too. Did anybody research
backup programs before this <expletive> was introduced to Debian?

The servers are all Debian, except for my home router which is running
OpenWRT. But for curiosity, does anybody know if Ubuntu is using the
same <expletive>, or are they doing the usual, i.e. not follow Debian?

Thanks,
Lupe Christoph
-- 
| As everyone knows, it was predicted that the world would end last       |
| Wednesday at 10:00 PST.  Since there appears to be a world in existence |
| now, the entire universe must therefore have been recreated, complete   |
| with an apparent "history", last *Thursday*.  QED.                      |
| Seanna Watson, <1992Nov2.165142.11847@bcrka451.bnr.ca>                  |

[toc] | [prev] | [next] | [standalone]

#5180 — Re: Some Debian package upgrades are corrupting rsync "quick check" backups

Does it occur to you that the reason for having a "testing" release is
precisely so that problems like this can be found and fixed, and that this
is why it's not smart to run testing on essential production machines?

[toc] | [prev] | [next] | [standalone]

#5181

On Sat, Jan 28, 2017 at 11:00:32PM +0100, Lupe Christoph wrote:

> This problem may affect many other backups too. Did anybody research
> backup programs before this <expletive> was introduced to Debian?

This <expletive> is really the combination of two different things:

* The way we currently do binNMUs.
* Reproducible builds.

IMO, if we want reproducible builds and we don't want this to happen,
we should probably change the way we do binNMUs (where "change" could
well be not doing binNMUs at all and always include full and exact
source with every upload).

Thanks.

[toc] | [prev] | [next] | [standalone]

#5183 — Re: Some Debian package upgrades are corrupting rsync "quick check" backups

On Sunday, 29 January 2017 8:07:09 PM AEDT Santiago Vila wrote:
> IMO, if we want reproducible builds and we don't want this to happen,
> we should probably change the way we do binNMUs (where "change" could
> well be not doing binNMUs at all and always include full and exact
> source with every upload).

Why is it desirable to have bunNMUs anyway?  For small packages there's little 
overhead in just rebuilding it on all architectures.  For complex packages I 
think that it's best to avoid the potential problems of binNMUs in terms of 
tracking changes etc.  Things like LibreOffice and the kernel are complex 
enough without having binary changes that lack a changelog entry.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

[toc] | [prev] | [next] | [standalone]

#5182

Hi,

On 2017-01-28 22:00, Lupe Christoph wrote:
> This problem may affect many other backups too. Did anybody research
> backup programs before this <expletive> was introduced to Debian?

I do not consider this an acceptable attitude on Debian lists.

Thanks,

-- 
Jonathan Wiltshire                                      jmw@debian.org
Debian Developer                         http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

<directhex> i have six years of solaris sysadmin experience, from
             8->10. i am well qualified to say it is made from bonghits
			layered on top of bonghits

[toc] | [prev] | [next] | [standalone]

#5184

On Sat, 2017-01-28 at 23:00 +0100, Lupe Christoph wrote:
> On Saturday, 2017-01-28 at 14:51:19 +0000, Holger Levsen wrote:
> > On Sat, Jan 28, 2017 at 03:04:56PM +0100, Daniel Reichelt wrote:
> > > I highly suspect this stems from packages' rules files supporting
> > > reproducible builds.
> 
> > I rather think this is due to binNMUs not modifying debian/changelog…
> > (in the source package while it's modified in the binary packages…)
> 
> This is completely counter intuitive. I'm using rsnapshot to backup a
> few private machines. I will have to set up separate rsnapshots for
> those parts of the backup that suffer from this <expletive>, to avoid
> bogging down the data parts by unnecessary checksum calculations.
> 
> This problem may affect many other backups too. Did anybody research
> backup programs before this <expletive> was introduced to Debian?

Would reproducible-builds@lists.alioth.debian.org be the correct mailing
list to discuss this?

[toc] | [prev] | [next] | [standalone]

#5185

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jan 30, 2017 at 02:01:10PM +0200, Henrik Ahlgren wrote:
> On Sat, 2017-01-28 at 23:00 +0100, Lupe Christoph wrote:
> > On Saturday, 2017-01-28 at 14:51:19 +0000, Holger Levsen wrote:
> > > On Sat, Jan 28, 2017 at 03:04:56PM +0100, Daniel Reichelt wrote:
> > > > I highly suspect this stems from packages' rules files supporting
> > > > reproducible builds.
> > 
> > > I rather think this is due to binNMUs not modifying debian/changelog…
> > > (in the source package while it's modified in the binary packages…)
> > 
> > This is completely counter intuitive. I'm using rsnapshot to backup a
> > few private machines. I will have to set up separate rsnapshots for
> > those parts of the backup that suffer from this <expletive>, to avoid
> > bogging down the data parts by unnecessary checksum calculations.
> > 
> > This problem may affect many other backups too. Did anybody research
> > backup programs before this <expletive> was introduced to Debian?
> 
> Would reproducible-builds@lists.alioth.debian.org be the correct mailing
> list to discuss this?

Not really, because that has been done in sbuild since long before the
reproducible builds project became active: 0.62.2-1, Tue, 05 Apr 2011:
    - Improve binNMU handling to permit binNMUs for multiarch packages
      (Closes: #620112).  Currently, binary NMUs use the current date
      in the new changelog entry, but co-installable packages require
      an identical changelog.  To avoid this, take the date from the
      previous changelog entry to ensure the same date for all binNMUs.
      Thanks to Anders Kaseorg for this patch.

And, incidentally, this has been kind of reverted in 0.73.0-1 (Sat, 24
Dec 2016) after a fairly long and annoying discussion in debian-devel:
  * For binNMUs, instead of copying the timestamp of the last changelog entry,
    generate a new one (closes: #843773)


-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

[toc] | [prev] | [next] | [standalone]

#5186

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jan 30, 2017 at 01:10:12PM +0100, Mattia Rizzolo wrote:
> > Would reproducible-builds@lists.alioth.debian.org be the correct mailing
> > list to discuss this?
 
the debian-buildd list or a bug against sbuild might be more
appropriate…

(the sbuild maintainer reads the above list which has been cc:ed so he
should be able to comment…)

> Not really, because that has been done in sbuild since long before the
> reproducible builds project became active: 0.62.2-1, Tue, 05 Apr 2011:
>     - Improve binNMU handling to permit binNMUs for multiarch packages
>       (Closes: #620112).  Currently, binary NMUs use the current date
>       in the new changelog entry, but co-installable packages require
>       an identical changelog.  To avoid this, take the date from the
>       previous changelog entry to ensure the same date for all binNMUs.
>       Thanks to Anders Kaseorg for this patch.
> 
> And, incidentally, this has been kind of reverted in 0.73.0-1 (Sat, 24
> Dec 2016) after a fairly long and annoying discussion in debian-devel:
>   * For binNMUs, instead of copying the timestamp of the last changelog entry,
>     generate a new one (closes: #843773)

so, two questions: 

a.) has been fixed, so that no new occurrances of this problem will occur?
b.) if thats the case, shall we scan all packages in sid for files which
have the same timestamp+filename but different checksums and ask for
binNMUs of those packages?

thinking about b.) debian-release@l.d.o might be the right list for
this…


-- 
cheers,
	Holger

[toc] | [prev] | [next] | [standalone]

#5187 — Re: Some Debian package upgrades are corrupting rsync "quick check" backups

[Multipart message — attachments visible in raw view] — view raw

Hi Henrik & Holger,

sbuild maintainer here.

Quoting Holger Levsen (2017-01-30 14:25:51)
> On Mon, Jan 30, 2017 at 01:10:12PM +0100, Mattia Rizzolo wrote:
> > > Would reproducible-builds@lists.alioth.debian.org be the correct mailing
> > > list to discuss this?
>  
> the debian-buildd list or a bug against sbuild might be more
> appropriate…

Yes.

> (the sbuild maintainer reads the above list which has been cc:ed so he
> should be able to comment…)

You were talking about buildd-tools-devel@lists.alioth.debian.org

You forgot to CC that one (I understood that was your intention) but I'm also
still subscribed to reproducible-builds@l.a.d.o. :)

> > Not really, because that has been done in sbuild since long before the
> > reproducible builds project became active: 0.62.2-1, Tue, 05 Apr 2011:
> >     - Improve binNMU handling to permit binNMUs for multiarch packages
> >       (Closes: #620112).  Currently, binary NMUs use the current date
> >       in the new changelog entry, but co-installable packages require
> >       an identical changelog.  To avoid this, take the date from the
> >       previous changelog entry to ensure the same date for all binNMUs.
> >       Thanks to Anders Kaseorg for this patch.

The reason for this commit became void now that changelogs are stored in
architecture specific paths. Thus, as far as coinstallability of the changelog
is concerned, versions from different architectures having different timestamps
in their binNMU changelog entry is not a problem anymore. The remaining
coinstallability problem can come from packages that share files with content
that depends on the SOURCE_DATE_EPOCh timestamp which is calculated from the
generated binNMU changelog entry. But the following commit allows to tell
sbuild the exact timestamp for the new changelog entry and thus it is possible
to synchronize it across binNMUs on different architectures:

> > And, incidentally, this has been kind of reverted in 0.73.0-1 (Sat, 24
> > Dec 2016) after a fairly long and annoying discussion in debian-devel:
> >   * For binNMUs, instead of copying the timestamp of the last changelog entry,
> >     generate a new one (closes: #843773)

The discussion that prompted this change was this one:

https://lists.debian.org/22562.21637.415611.768269@chiark.greenend.org.uk

> so, two questions:
> 
> a.) has been fixed, so that no new occurrances of this problem will occur?

Hopefully. I welcome reports that show the contrary.

> b.) if thats the case, shall we scan all packages in sid for files which
> have the same timestamp+filename but different checksums and ask for
> binNMUs of those packages?
> 
> thinking about b.) debian-release@l.d.o might be the right list for
> this…

The version of sbuild used on the buildds probably doesn't bump the timestamp
yet. At least the binNMU-ed packages on my system share the binNMU changelog
timestamp with the timestamp of the last source upload. :)

Thanks!

cheers, josch

[toc] | [prev] | [next] | [standalone]

#5188

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jan 30, 2017 at 02:47:45PM +0100, Johannes Schauer wrote:
> > (the sbuild maintainer reads the above list which has been cc:ed so he
> > should be able to comment…)
> 
> You were talking about buildd-tools-devel@lists.alioth.debian.org

yes

> You forgot to CC that one (I understood that was your intention) but I'm also
> still subscribed to reproducible-builds@l.a.d.o. :)

no, I didnt forget to cc: the list as I didnt know it's exact name and I
was too lazy to look for it as I knew you read the reproduible list ;)

[nice explaination deleted, nothing to add here, except thanks for
explaining.]

> > so, two questions:
> > 
> > a.) has been fixed, so that no new occurrances of this problem will occur?
> Hopefully. I welcome reports that show the contrary.

you are refering to "fixed in sbuild" here, while I ment (but didnt excplitly
say…) "fixed in the buildd network"…

> > b.) if thats the case, shall we scan all packages in sid for files which
> > have the same timestamp+filename but different checksums and ask for
> > binNMUs of those packages?
> The version of sbuild used on the buildds probably doesn't bump the timestamp
> yet. At least the binNMU-ed packages on my system share the binNMU changelog
> timestamp with the timestamp of the last source upload. :)

so it seems we should 

a.) get this fix deployed on all the buildds. (how?)
b.) do the b.) above… (because AIUI this issue atm is only be noticed
    by those running unstable or stretch, while once stretch is released many
    more people will notice it…)


-- 
cheers,
	Holger

[toc] | [prev] | [next] | [standalone]

#5189 — Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups

[Multipart message — attachments visible in raw view] — view raw

Hi,

Quoting Holger Levsen (2017-01-30 14:58:33)
> On Mon, Jan 30, 2017 at 02:47:45PM +0100, Johannes Schauer wrote:
> > > b.) if thats the case, shall we scan all packages in sid for files which
> > > have the same timestamp+filename but different checksums and ask for
> > > binNMUs of those packages?
> > The version of sbuild used on the buildds probably doesn't bump the timestamp
> > yet. At least the binNMU-ed packages on my system share the binNMU changelog
> > timestamp with the timestamp of the last source upload. :)
> 
> so it seems we should 
> 
> a.) get this fix deployed on all the buildds. (how?)
> b.) do the b.) above… (because AIUI this issue atm is only be noticed
>     by those running unstable or stretch, while once stretch is released many
>     more people will notice it…)

I'm not involved in buildd development. I think Aurélien Jarno (CC) is involved
as there are many commits from him in the respective sbuild git branch.
Possibly the right mailing is debian-dak@l.d.o but I'm not active there.

The buildds are running a custom version of sbuild with their own patches on
top. So I'd expect that once Stretch is released, they will rebase their
patches on top of sbuild from Stretch.

So as far as I understand Henrik's original message, their problem should be
fixed once packages start being built with sbuild from Stretch which happens
after the Stretch release.

Thanks!

cheers, josch

[toc] | [prev] | [next] | [standalone]

#5229 — Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups

Hi all,

Just following up on this thread. As it's been a while, here's the
thread index:

 https://lists.debian.org/debian-security/2017/01/threads.html#00014

... but AIUI, the issue is as follows. Naturally, let me know if this
a poor or inaccurate summary:

 * binNMUs do not bump debian/changelog.

 * This causes mtimes to to not be bumped in the (actually modified!)
   package.

 * Backup programs (eg. rsync) will therefore not believe a binary has
   changed and thus will be skipped over.

 * A binary restored from such a backup may not execute correctly.

 * Asking users to change anything at all is always problematic, but
   to ask them to switch to using (for example) --checksum with its
   non-trivial performance penalty is a very difficult ask indeed.
   Some backup programs may not even support such a mode anyway…

My questions are as follows:

 a) Has anything changed in the meantime?

 b) Will this affect stretch? If so, what do we need to do now?


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

[toc] | [prev] | [next] | [standalone]

#5230 — Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups

[Multipart message — attachments visible in raw view] — view raw

On Sat, May 13, 2017 at 05:52:04PM +0200, Mattia Rizzolo wrote:
> On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote:
> >  a) Has anything changed in the meantime?
> 
> Yes: sbuild stopped repeating the changelog time taking it from the last
> entry, and will instead generate a new timestamp based on the current
> time:
> 
>   * For binNMUs, instead of copying the timestamp of the last changelog entry,
>     generate a new one (closes: #843773)
> 
> In version 0.73.0-1.

this is correct, but AFAIK this hasnt been deployed on the buildd yet.
I'd be glad to be corrected about this…
 
> >  b) Will this affect stretch? If so, what do we need to do now?
> IMHO, nothing.

we might need to reschedule some packages…


-- 
cheers,
	Holger

[toc] | [prev] | [next] | [standalone]

#5231 — Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups

[Multipart message — attachments visible in raw view] — view raw

On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote:
>  a) Has anything changed in the meantime?

Yes: sbuild stopped repeating the changelog time taking it from the last
entry, and will instead generate a new timestamp based on the current
time:

  * For binNMUs, instead of copying the timestamp of the last changelog entry,
    generate a new one (closes: #843773)

In version 0.73.0-1.

>  b) Will this affect stretch? If so, what do we need to do now?

Yes.
IMHO, nothing.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

[toc] | [prev] | [next] | [standalone]

#5232 — Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups

[Multipart message — attachments visible in raw view] — view raw

On 2017-05-13 17:52, Mattia Rizzolo wrote:
> On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote:
> >  a) Has anything changed in the meantime?
> 
> Yes: sbuild stopped repeating the changelog time taking it from the last
> entry, and will instead generate a new timestamp based on the current
> time:
> 
>   * For binNMUs, instead of copying the timestamp of the last changelog entry,
>     generate a new one (closes: #843773)
> 
> In version 0.73.0-1.

And I am glad that after all that months with people talking about the
issue, I finally got a detailed description of the issue and a pointer
to the commit to backport. I'll work on that.

> >  b) Will this affect stretch? If so, what do we need to do now?

It depends by wat you mean by "affect stretch". According to the version
above, the buildds running stretch are not affected by the bug. So it
mostly depends where the packages are built, not for which distribution.

Cheers,
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.security

csiph-web