Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
15 views
Skip to first unread message
Peter Samuelson
Oct 11, 2012, 12:40:02 PM10/11/12
to
[Christoph Anton Mitterer]
> Wouldn't it make sense to start discussions about moving to the
> "strongest" possible?
No. What makes sense is to use a hash that has the properties that are
needed for a particular application.
To use your example of dpkg file checksums, their purpose has _nothing_
to do with security. They cannot protect against a malicious attacker,
because an attacker who can corrupt /usr/bin/lsof can also corrupt
/var/lib/dpkg/info/lsof.md5sums. (And /var cannot be read-only as /usr
sometimes is.) If you need protection against a malicious attacker,
you need to generate and store your checksums in some other way.[1]
[1] Check out 'apt-cache search tripwire' for various ways to
reinvent that wheel. tripwire was an early implementation of this
idea, so it is mentioned in other package descriptions.
Rather, the checksums are for integrity checking in the face of disk
corruption or administrative snafu. Basically to answer the question
"Would it help to reinstall this package?" MD5 is perfectly well
suited for that. The presence of the md5sums file in control.tar.gz is
just a convenience so that end systems don't have to calculate it at
install time, much like providing .pyc or .elc files in a .deb (which
we don't do, but we could).
My point is not to pick on your specific example, but to suggest
actually _thinking_ about what a hash is used for, as opposed to the
common knee-jerk reaction "oooh, MD5 is weak, it must be replaced!"
every time someone sees MD5. (Or SHA-1.)
Peter
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012101116...@p12n.org
Martin Bagge / brother
Oct 11, 2012, 2:20:02 PM10/11/12
to
On 2012-10-11 19:38, Christoph Anton Mitterer wrote:
> critical, e.g. when you're on embedded devices or so,... but the places
> I've mentioned should have probably no disadvantages by using a "strong"
> algo,... not to mention that newer algos like Keccack are quite fast.
Debian on a low power embedded system fits in the "normal" category I
assume?
What is "embedded device" then?
--
brother
http://sis.bthstudent.se
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/50770C0E...@bsnet.se
> On Thu, 2012-10-11 at 11:35 -0500, Peter Samuelson wrote:
>> > What makes sense is to use a hash that has the properties that are
>> > needed for a particular application.
> Well... I think that's only really required if performance is very
>> > What makes sense is to use a hash that has the properties that are
>> > needed for a particular application.
> critical, e.g. when you're on embedded devices or so,... but the places
> I've mentioned should have probably no disadvantages by using a "strong"
> algo,... not to mention that newer algos like Keccack are quite fast.
Debian on a low power embedded system fits in the "normal" category I
assume?
What is "embedded device" then?
--
brother
http://sis.bthstudent.se
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Kurt Roeckx
Oct 11, 2012, 2:20:02 PM10/11/12
to
On Thu, Oct 11, 2012 at 01:19:58AM +0200, Christoph Anton Mitterer wrote:
> Hi folks.
>
> AFAICS, secure APT and similar things (e.g. dpkg's file hash sums) still
> use even MD5.
dpkg-genchanges and dak both generate md5, sha1 and sha256. So
.deb files themself are hashed by all 3 of them. A as far as I
know all tools that verify those files also check all 3 of those
hashes.
As far as I understand, there is no need to move away from sha256
to SHA-3 when it becomes available at this time.
So basicly the question is if we want to keep the md5 and sha1 in
those files or not.
MD5 is covered by policy, and it's the only mentioned in policy,
maybe that should change.
There are also the md5sums files that are stored in the .deb file.
I'm not really sure what the real use case for them is and
wouldn't have a problem with them going away.
Then there dpkg status file keeps track of config files with md5
to see if they changed on upgrade. I can see no good reason to
change this.
> Wouldn't it make sense to start discussions about moving to the
> "strongest" possible?
I see no reason why we can't also add SHA-3 to the files when the
tools become available.
> Or, like in the case of package files (dsc and friends) make a policy of
> verifying all hashes, and fail if any single doesn't match?
As far that's already the case?
Kurt
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012101118...@roeckx.be
> Hi folks.
>
> AFAICS, secure APT and similar things (e.g. dpkg's file hash sums) still
> use even MD5.
dpkg-genchanges and dak both generate md5, sha1 and sha256. So
.deb files themself are hashed by all 3 of them. A as far as I
know all tools that verify those files also check all 3 of those
hashes.
As far as I understand, there is no need to move away from sha256
to SHA-3 when it becomes available at this time.
So basicly the question is if we want to keep the md5 and sha1 in
those files or not.
MD5 is covered by policy, and it's the only mentioned in policy,
maybe that should change.
There are also the md5sums files that are stored in the .deb file.
I'm not really sure what the real use case for them is and
wouldn't have a problem with them going away.
Then there dpkg status file keeps track of config files with md5
to see if they changed on upgrade. I can see no good reason to
change this.
> Wouldn't it make sense to start discussions about moving to the
> "strongest" possible?
tools become available.
> Or, like in the case of package files (dsc and friends) make a policy of
> verifying all hashes, and fail if any single doesn't match?
As far that's already the case?
Kurt
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrey Rahmatullin
Oct 11, 2012, 2:50:02 PM10/11/12
to
On Thu, Oct 11, 2012 at 08:18:55PM +0200, Kurt Roeckx wrote:
> There are also the md5sums files that are stored in the .deb file.
> I'm not really sure what the real use case for them is and
> wouldn't have a problem with them going away.
debsums(1) aka "what packages on my system are corrupt by a recent FS
> There are also the md5sums files that are stored in the .deb file.
> I'm not really sure what the real use case for them is and
> wouldn't have a problem with them going away.
failure"
--
WBR, wRAR
Kurt Roeckx
Oct 11, 2012, 6:40:01 PM10/11/12
to
For the case of corruption I would either use backups or
reinstall the whole thing. If there is corruption it
ussually screws up more than the files covered by the md5sums.
Kurt
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Charles Plessy
Oct 11, 2012, 6:50:02 PM10/11/12
to
Le Thu, Oct 11, 2012 at 08:18:55PM +0200, Kurt Roeckx a �crit :
For control files, Checksums-Sha1 and Checksums-Sha256 are covered in chapter
5, where they are marked as recommended.
-----------------------------------------------------------------------------
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Checksums
These multiline fields contain a list of files with a checksum and size for
each one. Both Checksums-Sha1 and Checksums-Sha256 have the same syntax and
differ only in the checksum algorithm used: SHA-1 for Checksums-Sha1 and
SHA-256 for Checksums-Sha256.
Checksums-Sha1 and Checksums-Sha256 are multiline fields. The first line of
the field value (the part on the same line as Checksums-Sha1: or
Checksums-Sha256:) is always empty. The content of the field is expressed as
continuation lines, one line per file. Each line consists of the checksum, a
space, the file size, a space, and the file name. For example (from a .changes
file):
Checksums-Sha1:
1f418afaa01464e63cc1ee8a66a05f0848bd155c 1276 example_1.0-1.dsc
a0ed1456fad61116f868b1855530dbe948e20f06 171602 example_1.0.orig.tar.gz
5e86ecf0671e113b63388dac81dd8d00e00ef298 6137 example_1.0-1.debian.tar.gz
71a0ff7da0faaf608481195f9cf30974b142c183 548402 example_1.0-1_i386.deb
Checksums-Sha256:
ac9d57254f7e835bed299926fd51bf6f534597cc3fcc52db01c4bffedae81272 1276 example_1.0-1.dsc
0d123be7f51e61c4bf15e5c492b484054be7e90f3081608a5517007bfb1fd128 171602 example_1.0.orig.tar.gz
f54ae966a5f580571ae7d9ef5e1df0bd42d63e27cb505b27957351a495bc6288 6137 example_1.0-1.debian.tar.gz
3bec05c03974fdecd11d020fc2e8250de8404867a8a2ce865160c250eb723664 548402 example_1.0-1_i386.deb
In the .dsc file, these fields should list all files that make up the source
package. In the .changes file, these fields should list all files being
uploaded. The list of files in these fields must match the list of files in the
Files field.
-----------------------------------------------------------------------------
For MD5, it is only mentionned in the description of the Files field (same
chapter), in appendix D about other control fields (MD5sum), and in appendix E
about configuration file handling.
Please let us know if there is something else missing about SHA-1 or SHA-256
checksums.
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20121011224...@falafel.plessy.net
>
> MD5 is covered by policy, and it's the only mentioned in policy,
> maybe that should change.
Hi Kurt and everybody,
> MD5 is covered by policy, and it's the only mentioned in policy,
> maybe that should change.
For control files, Checksums-Sha1 and Checksums-Sha256 are covered in chapter
5, where they are marked as recommended.
-----------------------------------------------------------------------------
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Checksums
These multiline fields contain a list of files with a checksum and size for
each one. Both Checksums-Sha1 and Checksums-Sha256 have the same syntax and
differ only in the checksum algorithm used: SHA-1 for Checksums-Sha1 and
SHA-256 for Checksums-Sha256.
Checksums-Sha1 and Checksums-Sha256 are multiline fields. The first line of
the field value (the part on the same line as Checksums-Sha1: or
Checksums-Sha256:) is always empty. The content of the field is expressed as
continuation lines, one line per file. Each line consists of the checksum, a
space, the file size, a space, and the file name. For example (from a .changes
file):
Checksums-Sha1:
1f418afaa01464e63cc1ee8a66a05f0848bd155c 1276 example_1.0-1.dsc
a0ed1456fad61116f868b1855530dbe948e20f06 171602 example_1.0.orig.tar.gz
5e86ecf0671e113b63388dac81dd8d00e00ef298 6137 example_1.0-1.debian.tar.gz
71a0ff7da0faaf608481195f9cf30974b142c183 548402 example_1.0-1_i386.deb
Checksums-Sha256:
ac9d57254f7e835bed299926fd51bf6f534597cc3fcc52db01c4bffedae81272 1276 example_1.0-1.dsc
0d123be7f51e61c4bf15e5c492b484054be7e90f3081608a5517007bfb1fd128 171602 example_1.0.orig.tar.gz
f54ae966a5f580571ae7d9ef5e1df0bd42d63e27cb505b27957351a495bc6288 6137 example_1.0-1.debian.tar.gz
3bec05c03974fdecd11d020fc2e8250de8404867a8a2ce865160c250eb723664 548402 example_1.0-1_i386.deb
In the .dsc file, these fields should list all files that make up the source
package. In the .changes file, these fields should list all files being
uploaded. The list of files in these fields must match the list of files in the
Files field.
-----------------------------------------------------------------------------
For MD5, it is only mentionned in the description of the Files field (same
chapter), in appendix D about other control fields (MD5sum), and in appendix E
about configuration file handling.
Please let us know if there is something else missing about SHA-1 or SHA-256
checksums.
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bob Proulx
Oct 11, 2012, 10:10:01 PM10/11/12
to
Kurt Roeckx wrote:
neither is it a security mechanism. But it is a useful integrity
check mechanism.
Bob
> Andrey Rahmatullin wrote:
> > Kurt Roeckx wrote:
> > > There are also the md5sums files that are stored in the .deb file.
> > > I'm not really sure what the real use case for them is and
> > > wouldn't have a problem with them going away.
> > debsums(1) aka "what packages on my system are corrupt by a recent FS
> > failure"
>
> I know about debsums, I just don't find it useful.
>
> For the case of corruption I would either use backups or
> reinstall the whole thing. If there is corruption it
> ussually screws up more than the files covered by the md5sums.
The use case for debsums is for *detection* of corruption. And
> > Kurt Roeckx wrote:
> > > There are also the md5sums files that are stored in the .deb file.
> > > I'm not really sure what the real use case for them is and
> > > wouldn't have a problem with them going away.
> > debsums(1) aka "what packages on my system are corrupt by a recent FS
> > failure"
>
> I know about debsums, I just don't find it useful.
>
> For the case of corruption I would either use backups or
> reinstall the whole thing. If there is corruption it
> ussually screws up more than the files covered by the md5sums.
neither is it a security mechanism. But it is a useful integrity
check mechanism.
Bob
Paul Wise
Oct 11, 2012, 10:10:01 PM10/11/12
to
On Fri, Oct 12, 2012 at 8:30 AM, Christoph Anton Mitterer wrote:
> I further looked around:
> e.g. the Release file seems to only use MD5.... not so good :(
Wrong, the Release file has had all 3 since sarge. woody had MD5 & SHA-1.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAKTje6F-37FUhWCGFNXMU-mD...@mail.gmail.com
> I further looked around:
> e.g. the Release file seems to only use MD5.... not so good :(
Wrong, the Release file has had all 3 since sarge. woody had MD5 & SHA-1.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Wise
Oct 11, 2012, 10:20:01 PM10/11/12
to
On Fri, Oct 12, 2012 at 8:30 AM, Christoph Anton Mitterer wrote:
> Sources files seems to use MD5, SHA1 and SHA256... though MD5 seems to
> have a "special status" (Files vs. Checksums-<algo>).
> That might be just historic, though.
>
> Similarly the Packages files... MD5/SHA1/SHA256...
Only since wheezy has that been true for all files listed in
Packages/Sources though. squeeze Packages is missing SHA-1 and SHA-256
for 1905 binary packages.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAKTje6EHRFK2Qj7H7A4=UF3SqnroEMeAd4xA=Pfzum8=A7s...@mail.gmail.com
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bernhard R. Link
Oct 12, 2012, 3:20:01 AM10/12/12
to
* Christoph Anton Mitterer <cale...@scientia.net> [121011 19:39]:
for people to compare. The only reason that for those md5 is optimal and
not crc32 is that there is only one md5 and there is a nice always
available tool to compute it, so people can compare it more easy.
> > To use your example of dpkg file checksums, their purpose has _nothing_
> > to do with security.
> Well their _intended_ purpose,.. that's right.
> But nothing keeps people from using it a security manner (e.g. by
> replication it to a "secure" remote node or so).... and in fact... e.g.
> rkhunter already has a mode where it uses DPKG directly.
Everything doing something like that can also create those sha2 sums on
their own and use them. Using the debsums system (which has no security
part at all) will only weaken security. So I think what you say is an
argument for keeping md5sum, so that noone think they can use that
information for security.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012101207...@client.brlink.eu
> On Thu, 2012-10-11 at 11:35 -0500, Peter Samuelson wrote:
> > What makes sense is to use a hash that has the properties that are
> > needed for a particular application.
> > needed for a particular application.
> Well... I think that's only really required if performance is very
> critical, e.g. when you're on embedded devices or so,... but the places
> I've mentioned should have probably no disadvantages by using a "strong"
> algo,... not to mention that newer algos like Keccack are quite fast.
There is a disadvantage of having longer hashsums, thus making it harder
> critical, e.g. when you're on embedded devices or so,... but the places
> I've mentioned should have probably no disadvantages by using a "strong"
> algo,... not to mention that newer algos like Keccack are quite fast.
for people to compare. The only reason that for those md5 is optimal and
not crc32 is that there is only one md5 and there is a nice always
available tool to compute it, so people can compare it more easy.
> > To use your example of dpkg file checksums, their purpose has _nothing_
> > to do with security.
> But nothing keeps people from using it a security manner (e.g. by
> replication it to a "secure" remote node or so).... and in fact... e.g.
> rkhunter already has a mode where it uses DPKG directly.
Everything doing something like that can also create those sha2 sums on
their own and use them. Using the debsums system (which has no security
part at all) will only weaken security. So I think what you say is an
argument for keeping md5sum, so that noone think they can use that
information for security.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Adam D. Barratt
Oct 12, 2012, 3:30:01 AM10/12/12
to
On 12.10.2012 01:30, Christoph Anton Mitterer wrote:
> I further looked around:
> e.g. the Release file seems to only use MD5.... not so good :(
You didn't look very far / well.
> I further looked around:
> e.g. the Release file seems to only use MD5.... not so good :(
$ wget -O- -q http://ftp.debian.org/debian/dists/squeeze/Release | grep
-v "^ "
Origin: Debian
Label: Debian
Suite: stable
Version: 6.0.6
Codename: squeeze
Date: Sat, 29 Sep 2012 11:31:27 UTC
Architectures: amd64 armel i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
mipsel powerpc s390 sparc
Components: main contrib non-free
Description: Debian 6.0.6 Released 29 September 2012
MD5Sum:
SHA1:
SHA256:
Please check more carefully before making such assertions.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ansgar Burchardt
Oct 12, 2012, 3:40:01 AM10/12/12
to
Package: debian-policy
Severity: minor
Charles Plessy <ple...@debian.org> writes:
> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Checksums
documented in Policy[1], but by now dak requires Checksums-{SHA1,SHA256}
to be present and listing all files in both .dsc and .changes files.
[1] <http://bugs.debian.org/478295#73>
I suggest replacing both 'should's with 'must' in the paragraph quoted
above.
Ansgar
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
Severity: minor
Charles Plessy <ple...@debian.org> writes:
> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Checksums
>
> In the .dsc file, these fields should list all files that make up the source
> package. In the .changes file, these fields should list all files being
> uploaded. The list of files in these fields must match the list of files in the
> Files field.
The Checksums-{SHA1,SHA256} fields were optional when they were
> In the .dsc file, these fields should list all files that make up the source
> package. In the .changes file, these fields should list all files being
> uploaded. The list of files in these fields must match the list of files in the
> Files field.
documented in Policy[1], but by now dak requires Checksums-{SHA1,SHA256}
to be present and listing all files in both .dsc and .changes files.
[1] <http://bugs.debian.org/478295#73>
I suggest replacing both 'should's with 'must' in the paragraph quoted
above.
Ansgar
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
David Kalnischkies
Oct 12, 2012, 7:30:02 AM10/12/12
to
On Thu, Oct 11, 2012 at 7:38 PM, Christoph Anton Mitterer
<cale...@scientia.net> wrote:
> algo,... not to mention that newer algos like Keccack are quite fast.
I wonder if it is really a good idea to search for a security checksum
<cale...@scientia.net> wrote:
> algo,... not to mention that newer algos like Keccack are quite fast.
based on the metric that it can be quickly calculated … but off-topic.
>> To use your example of dpkg file checksums, their purpose has _nothing_
>> to do with security.
> Well their _intended_ purpose,.. that's right.
> But nothing keeps people from using it a security manner (e.g. by
> replication it to a "secure" remote node or so).... and in fact... e.g.
> rkhunter already has a mode where it uses DPKG directly.
I think adding "better" checksums here would just encourage people to
> But nothing keeps people from using it a security manner (e.g. by
> replication it to a "secure" remote node or so).... and in fact... e.g.
> rkhunter already has a mode where it uses DPKG directly.
think that they could be used in a security relevant way.
And carrying bigger/more checksums around just means that we waste
everyones diskspace to keep up the illusion of security for some people.
> Anyway... I guess it was clear, that I rather meant secure APT... dsc
> files, Release.gpg, etc. pp.
APT will usually negotiate the checksum to use based on what it supports
and what is included in the Release file.
Supported is currently in squeeze (in wheezy):
MD5, SHA1, SHA256(, SHA512)
Usually found in a Release file is currently:
MD5, SHA1, SHA256
so it will take SHA256 and be done with it. apt-ftparchive/wheezy will
generate SHA512 by default as well, I am not sure about dak or others,
but that isn't really a problem just yet.
This falls apart of course as soon as RSA (or whatever ftpmasters will use
in this dystopia) is broken, but I guess we have a problem then anyway.
So dropping MD5 and/or SHA1 would be okay I guess, note through that
apt-get --print-uris outputs md5sum by default as some scripts can't cope
with other checksums. See #576420 as an example why, so you would need
to find and fix these scripts first I guess (or just break them of course).
There is one exception: pdiffs work entirely with SHA1, were is some work
pending on the dak side, I guess while incorporating them into APT we could
work on that. In case of an emergency you could just disable that optional
feature of course (user as well as server side). And in the end of all days,
really interesting is only a pre-image attack, collision is kinda boring …
Oh, and there is "Description-md5". I can't imagine a scenario in which it
would be useful to change the English description of a package for an attack
(which you want to hide by displaying the translations of the not modified
version), but feel free to be the first to launch a successful pre-image
attack on long descriptions (with the "side" problem of not changing size
and checksum of the [compressed] Packages file including the description).
Beside, for Debian this "attack" becomes easier now as the translation is
split out and the md5sum therefore pre-calculated, so you can write whatever
you want in the Translation-* files as a description without caring for
Description-md5 ("side" problem still applies though).
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Simon McVittie
Oct 12, 2012, 7:50:02 AM10/12/12
to
On 12/10/12 12:10, David Kalnischkies wrote:
> I wonder if it is really a good idea to search for a security checksum
> based on the metric that it can be quickly calculated … but off-topic.
It depends what you're using it for: security is not magic pixie dust. A
> I wonder if it is really a good idea to search for a security checksum
> based on the metric that it can be quickly calculated … but off-topic.
hashing algorithm that is faster and equally collision-resistant is
better for integrity-checking (faster and no less secure), but worse for
password hashing (an attacker can try potential passwords faster).
>> Anyway... I guess it was clear, that I rather meant secure APT... dsc
>> files, Release.gpg, etc. pp.
>
> APT will usually negotiate the checksum to use based on what it supports
> and what is included in the Release file.
ftpmasters) uses to generate the signature for InRelease and
Release.gpg. For wheezy-as-testing, InRelease appears to be signed with
(RSA +) SHA1, which is the GnuPG default. In principle the ftpmasters
could configure gpg to sign with SHA256 (or even SHA512) in future,
assuming stable's gnupg (and preferably also oldstable's gnupg) can
verify such signatures.
squeeze's gnupg does seem to support the SHA-2 set of hashes (SHA224 up
to SHA512).
> Oh, and there is "Description-md5". I can't imagine a scenario in which it
> would be useful to change the English description of a package for an attack
security-sensitive. The signed file (In)Release(.gpg) contains MD5,
SHA1, SHA256 hashes of both Packages and Translation-*, so you can be
sure that nobody has modified Packages or Translation-* since they left
dak; and anyone who could cause dak to incorporate maliciously-colliding
descriptions (a DD or DM with upload privileges) could do more damage by
uploading a malicious .deb instead.
S
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Adam D. Barratt
Oct 12, 2012, 8:10:01 AM10/12/12
to
On 12.10.2012 12:49, Christoph Anton Mitterer wrote:
> ftp://ftp.de.debian.org/debian/dists/sid/Release
It's a file containing MD5, SHA1 and SHA256 sums, as has already been
explained to you.
/===================================================================
| $ wget -q ftp://ftp.de.debian.org/debian/dists/sid/Release
|
| $ sha256sum Release
| ca8a6b8809246a885e74600d2a61a0b73ead28dd0f324a682d8d3d359d82aa35
Release
|
| $ grep -v "^ " Release
| Origin: Debian
| Label: Debian
| Suite: unstable
| Codename: sid
| Date: Fri, 12 Oct 2012 08:17:30 UTC
| Valid-Until: Fri, 19 Oct 2012 08:17:30 UTC
| Architectures: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64
kfreebsd-i386 mips mipsel powerpc s390 s390x sparc
| Components: main contrib non-free
| Description: Debian x.y Unstable - Not Released
| MD5Sum:
| SHA1:
| SHA256:
\===================================================================
I'm struggling to see what point you believe you're making here.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/c881b1115792d5f0...@mail.adsl.funky-badger.org
> On Fri, 2012-10-12 at 10:09 +0800, Paul Wise wrote:
>> > I further looked around:
>> > e.g. the Release file seems to only use MD5.... not so good :(
>> Wrong, the Release file has had all 3 since sarge. woody had MD5 &
>> SHA-1.
>
> Then what's this:
>> > I further looked around:
>> > e.g. the Release file seems to only use MD5.... not so good :(
>> Wrong, the Release file has had all 3 since sarge. woody had MD5 &
>> SHA-1.
>
> ftp://ftp.de.debian.org/debian/dists/sid/Release
It's a file containing MD5, SHA1 and SHA256 sums, as has already been
explained to you.
/===================================================================
| $ wget -q ftp://ftp.de.debian.org/debian/dists/sid/Release
|
| $ sha256sum Release
| ca8a6b8809246a885e74600d2a61a0b73ead28dd0f324a682d8d3d359d82aa35
Release
|
| $ grep -v "^ " Release
| Origin: Debian
| Label: Debian
| Suite: unstable
| Codename: sid
| Date: Fri, 12 Oct 2012 08:17:30 UTC
| Valid-Until: Fri, 19 Oct 2012 08:17:30 UTC
| Architectures: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64
kfreebsd-i386 mips mipsel powerpc s390 s390x sparc
| Components: main contrib non-free
| Description: Debian x.y Unstable - Not Released
| MD5Sum:
| SHA1:
| SHA256:
\===================================================================
I'm struggling to see what point you believe you're making here.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dmitrijs Ledkovs
Oct 12, 2012, 8:40:02 AM10/12/12
to
On 12 October 2012 13:03, Adam D. Barratt <ad...@adam-barratt.org.uk> wrote:
> I'm struggling to see what point you believe you're making here.
>
The point he was trying to make that he either caught a mirror during
> I'm struggling to see what point you believe you're making here.
>
update, or his connection was flaky, as he didn't fetch the complete
file, nor verify it's gpg signature.
Regards,
Dmitrijs.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Wise
Oct 12, 2012, 8:50:02 AM10/12/12
to
On Fri, Oct 12, 2012 at 7:49 PM, Christoph Anton Mitterer
<cale...@scientia.net> wrote:
> Then what's this:
> ftp://ftp.de.debian.org/debian/dists/sid/Release
Sounds like you have a person in the middle hacking your network (or a
<cale...@scientia.net> wrote:
> Then what's this:
> ftp://ftp.de.debian.org/debian/dists/sid/Release
browser bug), it works for me:
pabs@chianamo ~ $ GET ftp://ftp.de.debian.org/debian/dists/sid/Release
| grep ^SHA
SHA1:
SHA256:
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Wesley J. Landaker
Oct 12, 2012, 11:10:02 AM10/12/12
to
On Friday, October 12, 2012 05:10:12 David Kalnischkies wrote:
> On Thu, Oct 11, 2012 at 7:38 PM, Christoph Anton Mitterer
>
> <cale...@scientia.net> wrote:
> > algo,... not to mention that newer algos like Keccack are quite fast.
>
> I wonder if it is really a good idea to search for a security checksum
> based on the metric that it can be quickly calculated … but off-topic.
FWIW, NIST disagrees. Keccack is SHA-3:
> On Thu, Oct 11, 2012 at 7:38 PM, Christoph Anton Mitterer
>
> <cale...@scientia.net> wrote:
> > algo,... not to mention that newer algos like Keccack are quite fast.
>
> I wonder if it is really a good idea to search for a security checksum
> based on the metric that it can be quickly calculated … but off-topic.
<http://csrc.nist.gov/groups/ST/hash/sha-3/winner_sha-3.html>
Michael Gilbert
Oct 12, 2012, 4:40:02 PM10/12/12
to
On Fri, Oct 12, 2012 at 4:31 PM, Christoph Anton Mitterer wrote:
> But it's a general security paradigm, that one shouldn't just focus on
> the attack vectors one can think of... but rather trying to secure
> "everything" ;)
Which is impossible, or at least man-powerwise insurmountable. There
are something like 500 million lines of code in a Debian release.
Obviously not all code bits have security implications, but the right
flaw in any one link in that chain could lead to security problems.
If we were rigorous, that would 500,000 lines of code to review per
DD. An impossible and error-prone task.
It's more about identifying mistakes, learning from them, attempting
to track *everything*, and correcting known problems quickly.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CANTw=MP9wqmuuey4-erR4JNNRZn...@mail.gmail.com
> But it's a general security paradigm, that one shouldn't just focus on
> the attack vectors one can think of... but rather trying to secure
> "everything" ;)
Which is impossible, or at least man-powerwise insurmountable. There
are something like 500 million lines of code in a Debian release.
Obviously not all code bits have security implications, but the right
flaw in any one link in that chain could lead to security problems.
If we were rigorous, that would 500,000 lines of code to review per
DD. An impossible and error-prone task.
It's more about identifying mistakes, learning from them, attempting
to track *everything*, and correcting known problems quickly.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Michael Gilbert
Oct 12, 2012, 5:00:02 PM10/12/12
to
On Fri, Oct 12, 2012 at 4:45 PM, Christoph Anton Mitterer wrote:
> nothing against relatively easy things,... like securing all of our
> package repository infrastructure by strong algos (as we already did)...
> and trying to prevent higher level attacks, like downgrade attacks.
Do you have evidence of any of those things? If so, please submit
bugs, and we will look at fixing them. Otherwise, speculation gets us
nowhere and actually wastes time.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CANTw=MNPfrP=N+92tHmy7tSqp8WQrKp...@mail.gmail.com
> On Fri, 2012-10-12 at 16:37 -0400, Michael Gilbert wrote:
>> Which is impossible, or at least man-powerwise insurmountable. There
>> are something like 500 million lines of code in a Debian release.
> I wasn't talking about such an impossible task,... but there speaks
>> Which is impossible, or at least man-powerwise insurmountable. There
>> are something like 500 million lines of code in a Debian release.
> nothing against relatively easy things,... like securing all of our
> package repository infrastructure by strong algos (as we already did)...
> and trying to prevent higher level attacks, like downgrade attacks.
Do you have evidence of any of those things? If so, please submit
bugs, and we will look at fixing them. Otherwise, speculation gets us
nowhere and actually wastes time.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Wouter Verhelst
Oct 13, 2012, 5:00:01 AM10/13/12
to
On Fri, Oct 12, 2012 at 09:17:32AM +0200, Bernhard R. Link wrote:
> part at all) will only weaken security. So I think what you say is an
> argument for keeping md5sum, so that noone think they can use that
> information for security.
This argument is based on the incorrect assumption that everyone in the
> part at all) will only weaken security. So I think what you say is an
> argument for keeping md5sum, so that noone think they can use that
> information for security.
world knows md5 is broken.
(Heck, I'm sure I can find people who don't know that parity checks are
not a security measure, yet who think they know about security, if I
search good enough)
--
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bernhard R. Link
Oct 14, 2012, 7:20:01 AM10/14/12
to
* Wouter Verhelst <wou...@debian.org> [121013 10:56]:
about security at all but have little enough knowledge of security
to mix up protection against faulty hardware with protection against
attackers there is at least one user having heared the meme
"md5 considered broken" and might combine those half-knowledges to
the correct result that debsums is not about security against attackers.
Causing at least one user to not think they could use debsums as protection
against wilfull file modification by sticking with md5 is (given there are
no benefits from switching hashes at all) a very strong argument that
switching hashes for debsums to stick to the hashes it uses.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20121014111...@client.brlink.eu
> On Fri, Oct 12, 2012 at 09:17:32AM +0200, Bernhard R. Link wrote:
> > part at all) will only weaken security. So I think what you say is an
> > argument for keeping md5sum, so that noone think they can use that
> > information for security.
>
> This argument is based on the incorrect assumption that everyone in the
> world knows md5 is broken.
No it is based on the assumption that in that set of people that care
> > part at all) will only weaken security. So I think what you say is an
> > argument for keeping md5sum, so that noone think they can use that
> > information for security.
>
> This argument is based on the incorrect assumption that everyone in the
> world knows md5 is broken.
about security at all but have little enough knowledge of security
to mix up protection against faulty hardware with protection against
attackers there is at least one user having heared the meme
"md5 considered broken" and might combine those half-knowledges to
the correct result that debsums is not about security against attackers.
Causing at least one user to not think they could use debsums as protection
against wilfull file modification by sticking with md5 is (given there are
no benefits from switching hashes at all) a very strong argument that
switching hashes for debsums to stick to the hashes it uses.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrey Rahmatullin
Oct 14, 2012, 7:30:02 AM10/14/12
to
On Sun, Oct 14, 2012 at 01:14:19PM +0200, Bernhard R. Link wrote:
> > > part at all) will only weaken security. So I think what you say is an
> > > argument for keeping md5sum, so that noone think they can use that
> > > information for security.
> >
> > This argument is based on the incorrect assumption that everyone in the
> > world knows md5 is broken.
>
> No it is based on the assumption that in that set of people that care
> about security at all but have little enough knowledge of security
> to mix up protection against faulty hardware with protection against
> attackers there is at least one user having heared the meme
> "md5 considered broken" and might combine those half-knowledges to
> the correct result that debsums is not about security against attackers.
>
> Causing at least one user to not think they could use debsums as protection
> against wilfull file modification by sticking with md5 is (given there are
> no benefits from switching hashes at all) a very strong argument that
> switching hashes for debsums to stick to the hashes it uses.
For the reference: the manpage says:
> > > part at all) will only weaken security. So I think what you say is an
> > > argument for keeping md5sum, so that noone think they can use that
> > > information for security.
> >
> > This argument is based on the incorrect assumption that everyone in the
> > world knows md5 is broken.
>
> No it is based on the assumption that in that set of people that care
> about security at all but have little enough knowledge of security
> to mix up protection against faulty hardware with protection against
> attackers there is at least one user having heared the meme
> "md5 considered broken" and might combine those half-knowledges to
> the correct result that debsums is not about security against attackers.
>
> Causing at least one user to not think they could use debsums as protection
> against wilfull file modification by sticking with md5 is (given there are
> no benefits from switching hashes at all) a very strong argument that
> switching hashes for debsums to stick to the hashes it uses.
"""
debsums is intended primarily as a way of determining what installed files
have been locally modified by the administrator or damaged by media errors
and is of limited use as a security tool.
If you are looking for an integrity checker that can run from safe media,
do integrity checks on checksum databases and can be easily configured to
run periodically to warn the admin of changes see other tools such as:
aide, integrit, samhain, or tripwire.
"""
--
WBR, wRAR
Andrey Rahmatullin
Oct 15, 2012, 3:20:01 AM10/15/12
to
On Mon, Oct 15, 2012 at 02:58:15AM +0200, Christoph Anton Mitterer wrote:
> > """
> > debsums is intended primarily as a way of determining what installed files
> > have been locally modified by the administrator or damaged by media errors
> > and is of limited use as a security tool.
> >
> > If you are looking for an integrity checker that can run from safe media,
> > do integrity checks on checksum databases and can be easily configured to
> > run periodically to warn the admin of changes see other tools such as:
> > aide, integrit, samhain, or tripwire.
> > """
> I never claimed (and already explicitly said that before) that it was
> > """
> > debsums is intended primarily as a way of determining what installed files
> > have been locally modified by the administrator or damaged by media errors
> > and is of limited use as a security tool.
> >
> > If you are looking for an integrity checker that can run from safe media,
> > do integrity checks on checksum databases and can be easily configured to
> > run periodically to warn the admin of changes see other tools such as:
> > aide, integrit, samhain, or tripwire.
> > """
> intended to be used for that,... or that I would do or recommend so...
I never said you did.
--
WBR, wRAR
Michael Gilbert
Oct 15, 2012, 1:50:02 PM10/15/12
to
On Sun, Oct 14, 2012 at 9:08 PM, Christoph Anton Mitterer wrote:
>> If so, please submit
>> bugs, and we will look at fixing them. Otherwise, speculation gets us
>> nowhere and actually wastes time.
> Well I had once a discussion (around March this year) here about
>> If so, please submit
>> bugs, and we will look at fixing them. Otherwise, speculation gets us
>> nowhere and actually wastes time.
> blockin/downgrade attacks... which, AFAICS, both are possible in secure
> APT right now.... but there was no real outcome.
> Unforunately it seems that people do not take these higher-level attacks
> really serious.... even though the danger they impose is quite high.
Are there bug reports with a clear description of the problem,
preferably with a proposed fix? Discussion doesn't really get us
anywhere. Useful info and actual efforts at fixing problems do.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dmitrijs Ledkovs
Oct 15, 2012, 7:30:02 PM10/15/12
to
On 15 October 2012 18:46, Michael Gilbert <mgil...@debian.org> wrote:
> On Sun, Oct 14, 2012 at 9:08 PM, Christoph Anton Mitterer wrote:
>>> If so, please submit
>>> bugs, and we will look at fixing them. Otherwise, speculation gets us
>>> nowhere and actually wastes time.
>> Well I had once a discussion (around March this year) here about
>> blockin/downgrade attacks... which, AFAICS, both are possible in secure
>> APT right now.... but there was no real outcome.
>> Unforunately it seems that people do not take these higher-level attacks
>> really serious.... even though the danger they impose is quite high.
>
> Are there bug reports with a clear description of the problem,
> preferably with a proposed fix? Discussion doesn't really get us
> anywhere. Useful info and actual efforts at fixing problems do.
>
So far no bugs or problems were uncovered. So nothing to file or fix ;-)
> On Sun, Oct 14, 2012 at 9:08 PM, Christoph Anton Mitterer wrote:
>>> If so, please submit
>>> bugs, and we will look at fixing them. Otherwise, speculation gets us
>>> nowhere and actually wastes time.
>> Well I had once a discussion (around March this year) here about
>> blockin/downgrade attacks... which, AFAICS, both are possible in secure
>> APT right now.... but there was no real outcome.
>> Unforunately it seems that people do not take these higher-level attacks
>> really serious.... even though the danger they impose is quite high.
>
> Are there bug reports with a clear description of the problem,
> preferably with a proposed fix? Discussion doesn't really get us
> anywhere. Useful info and actual efforts at fixing problems do.
>
I can think of adding SHA-3 hashes... but none of the tools support it
yet, so it's future wishlist bug, which I am sure will be acted upon
at an appropriate time and doesn't need a bug filed at present time.
Regards,
Dmitrijs.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Daniel Hartwig
Oct 19, 2012, 12:50:01 AM10/19/12
to
On 19 October 2012 09:19, Christoph Anton Mitterer
<cale...@scientia.net> wrote:
> 1) Programs (I usually mean apt or aptitude here don't give exit
> statuses != 0 in all cases when something critical has happened.
The apt-utils are mostly ok at aborting with non-zero for critical
errors. Aptitude is not.
> e.g. apt-get update returns 0 even if the update failed.
This is only for transient errors (such as connection problems)
printed with a “W:” label. If a Release file is expired or otherwise
invalid the exit status is reliably non-zero.
After Wheezy it may be useful to look at using $? = 1 (or 2) to
indicate these transient errors (or just consider them the same as the
other errors). Calling programs could then retry the update, or
switch to a different mirror, which may resolve the issue. If the
calling program doesn't care it can test for $? != 0 to catch *all*
errors, or $? = 100 for only serious errors.
>
> E.g. a cluster operator may have done the following:
> Added a cron job that calls apt-get update daily and reports an error if
> $? != 0.
>
> Run check_apt via Nagios/Icinga to be notified on updates.
>
>
> An attacker simply blocking the update as described above may now easily
> prevent updates from being installed.
For a short time. Eventually “update” will (or should!) complain
about the expired Release files, $? != 0.
> 2) downgrade attacks
> These have the same idea as blocking attacks (prevent the user to get
> updates) but are a bit smarter.
> You don't simply block any update requests, but rather you sent the user
> old repository data. These are correctly signed by Debian... just...
> they are old and do not yet know about the updates.
>
> The only way of preventing this was, if apt/aptitude would utterly bail
> out/print error messages/give non-zero exit statuses if the repo-data
> they are working on are older than <some well thought time interval>
> (typically that would be something around the mirror update interval).
>
> Of course the time of a Release file would have to be signed ;)
> And of course it would be the duty of a user to make sure he has a
> correct time source.
> But at least now he'd have a chance to have a fully secured chain.
Security and -updates Release files use Valid-Until which partially
addresses this. I think this will only trigger an error on “apt-get
update”, not “install” or “upgrade”. Presumably update scripts use
“update” before “upgrade” and check the status of the former.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAN3veRfa9tewymwfMszTpz8H...@mail.gmail.com
<cale...@scientia.net> wrote:
> 1) Programs (I usually mean apt or aptitude here don't give exit
> statuses != 0 in all cases when something critical has happened.
The apt-utils are mostly ok at aborting with non-zero for critical
errors. Aptitude is not.
> e.g. apt-get update returns 0 even if the update failed.
This is only for transient errors (such as connection problems)
printed with a “W:” label. If a Release file is expired or otherwise
invalid the exit status is reliably non-zero.
After Wheezy it may be useful to look at using $? = 1 (or 2) to
indicate these transient errors (or just consider them the same as the
other errors). Calling programs could then retry the update, or
switch to a different mirror, which may resolve the issue. If the
calling program doesn't care it can test for $? != 0 to catch *all*
errors, or $? = 100 for only serious errors.
>
> E.g. a cluster operator may have done the following:
> Added a cron job that calls apt-get update daily and reports an error if
> $? != 0.
>
> Run check_apt via Nagios/Icinga to be notified on updates.
>
>
> An attacker simply blocking the update as described above may now easily
> prevent updates from being installed.
For a short time. Eventually “update” will (or should!) complain
about the expired Release files, $? != 0.
> 2) downgrade attacks
> These have the same idea as blocking attacks (prevent the user to get
> updates) but are a bit smarter.
> You don't simply block any update requests, but rather you sent the user
> old repository data. These are correctly signed by Debian... just...
> they are old and do not yet know about the updates.
>
> The only way of preventing this was, if apt/aptitude would utterly bail
> out/print error messages/give non-zero exit statuses if the repo-data
> they are working on are older than <some well thought time interval>
> (typically that would be something around the mirror update interval).
>
> Of course the time of a Release file would have to be signed ;)
> And of course it would be the duty of a user to make sure he has a
> correct time source.
> But at least now he'd have a chance to have a fully secured chain.
Security and -updates Release files use Valid-Until which partially
addresses this. I think this will only trigger an error on “apt-get
update”, not “install” or “upgrade”. Presumably update scripts use
“update” before “upgrade” and check the status of the former.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Michael Gilbert
Oct 19, 2012, 1:10:02 AM10/19/12
to
On Thu, Oct 18, 2012 at 9:19 PM, Christoph Anton Mitterer wrote:
> 2) downgrade attacks
> These have the same idea as blocking attacks (prevent the user to get
> updates) but are a bit smarter.
> You don't simply block any update requests, but rather you sent the user
> old repository data. These are correctly signed by Debian... just...
> they are old and do not yet know about the updates.
>
> The only way of preventing this was, if apt/aptitude would utterly bail
> out/print error messages/give non-zero exit statuses if the repo-data
> they are working on are older than <some well thought time interval>
> (typically that would be something around the mirror update interval).
>
> Of course the time of a Release file would have to be signed ;)
The release files *are* signed. Try using snapshot.debian.org (older
> 2) downgrade attacks
> These have the same idea as blocking attacks (prevent the user to get
> updates) but are a bit smarter.
> You don't simply block any update requests, but rather you sent the user
> old repository data. These are correctly signed by Debian... just...
> they are old and do not yet know about the updates.
>
> The only way of preventing this was, if apt/aptitude would utterly bail
> out/print error messages/give non-zero exit statuses if the repo-data
> they are working on are older than <some well thought time interval>
> (typically that would be something around the mirror update interval).
>
> Of course the time of a Release file would have to be signed ;)
than 2 weeks I think) as an apt source. It will fail loudly that the
release file is expired.
This is a whole lot of speculation about things that are already
handled. Please think about how you could demonstrate to yourself
before pressing it on the rest of the world.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages