FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-21-2011, 07:18 PM
"Adam D. Barratt"
 
Default Release file changes

On Mon, 2011-02-21 at 20:58 +0100, Joerg Jaspert wrote:
> >>> until today our Release files included 3 Hashes for all their entries:
> >>> MD5SUM, SHA1, SHA256. I just modified the code to no longer include
> >>> MD5SUM in *all* newly generated Release files.
> >> When will that affect Release files for stable? Next point release?
> >> Because that unfortunatly completly breaks debmirror..
> > It did suddenly change for squeeze-updates without consultation with the
> > suite admins. I expect that this is reverted.
>
> Good laugh that is.

In any case, it would seem logical for squeeze and squeeze-updates to
use the same set of hashes, imho; similarly the -proposed-updates
suites. Each of the "sister" suites would generally be expected to be
consumed (for want of a better word) by the tools in the corresponding
(old)stable suite.

Regards,

Adam


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1298319528.14573.225.camel@hathi.jungle.funky-badger.org">http://lists.debian.org/1298319528.14573.225.camel@hathi.jungle.funky-badger.org
 
Old 02-21-2011, 07:30 PM
Florian Weimer
 
Default Release file changes

* Joerg Jaspert:

>>> I additionally opened a bug with apt to add support for SHA512SUM, so
>>> we can start using them. As soon as that is possible I intend to drop
>>> SHA256 and end up with SHA1/SHA512 only.
>> Please don't. I have more faith in SHA-256 than SHA-512.
>
> Uhh, fine - why?

I think this question is a bit rude if faith is involved, but here we
go: the number of rounds in SHA-512 is rather small, considering its
block size and internal state space, in particular in comparison with
SHA-256.

More practically speaking, SHA-512 would add about 450 kB of
incompressible junk to the Packages file, so we probably want to stick
to SHA-256 there. But using different hashes in Release and Packages
files is just bloat.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pqql9lla.fsf@mid.deneb.enyo.de">http://lists.debian.org/87pqql9lla.fsf@mid.deneb.enyo.de
 
Old 02-21-2011, 07:52 PM
The Fungi
 
Default Release file changes

On Mon, Feb 21, 2011 at 09:13:51PM +0100, Joerg Jaspert wrote:
> Care to make a point for the gpg stuff around it within bug
> #612657?

Gladly! Restating and Cc'ing...

While I agree that moving away from SHA-1 is necessary, SHA-512 is
not part of the compatibility set according to the gpg(1) manpage
and so may be hard for users of other OpenPGP implementations to
validate:

[...]
> > INTEROPERABILITY
> >
> > GnuPG tries to be a very flexible implementation of the OpenPGP
> > standard. In particular, GnuPG implements many of the optional
> > parts of the standard, such as the SHA-512 hash, and the ZLIB
> > and BZIP2 compression algorithms. It is important to be aware
> > that not all OpenPGP programs implement these optional
> > algorithms and that by forcing their use via the --cipher-algo,
> > --digest-algo, --cert-digest-algo, or --compress-algo options in
> > GnuPG, it is possible to create a perfectly valid OpenPGP
> > message, but one that cannot be read by the intended recipient.
> >
> > There are dozens of variations of OpenPGP programs available,
> > and each supports a slightly different subset of these optional
> > algorithms. For example, until recently, no (unhacked) version
> > of PGP supported the BLOWFISH cipher algorithm. A message using
> > BLOWFISH simply could not be read by a PGP user. By default,
> > GnuPG uses the standard OpenPGP preferences system that will
> > always do the right thing and create messages that are usable by
> > all recipients, regardless of which OpenPGP program they use.
> > Only override this safe default if you really know what you are
> > doing.
> >
> > If you absolutely must override the safe default, or if the
> > preferences on a given key are invalid for some reason, you are
> > far better off using the --pgp6, --pgp7, or --pgp8 options.
> > These options are safe as they do not force any particular
> > algorithms in violation of OpenPGP, but rather reduce the
> > available algorithms to a "PGP-safe" list.
[...]

While it seems apparent that PGP 8 or older (and some other
compatible clients) will support SHA-256 but not SHA-512, I couldn't
find anything to back up the implication that one of them is
required by "the OpenPGP standard" while the other is optional. Both
are unmentioned in RFC 2440, and both are mentioned equally in RFC
4880. I'm guessing there were some intermediate standards in the 9
years between them where this would have been the case, but that
situation doesn't appear to have made it into an IETF RFC at least.

If it's only intended that modern implementations backending our
tools are going to need to validate the signatures and we don't
expect end users to do this themselves on other platforms, then I
don't suppose it's much of a concern but thought it worth mentioning
nonetheless.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fungi@yuggoth.org); FINGER(fungi@yuggoth.org);
MUD(kinrui@katarsis.mudpy.org:6669); IRC(fungi@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110221205247.GL1293@yuggoth.org">http://lists.debian.org/20110221205247.GL1293@yuggoth.org
 
Old 02-21-2011, 08:26 PM
Joerg Jaspert
 
Default Release file changes

>> >>> until today our Release files included 3 Hashes for all their entries:
>> >>> MD5SUM, SHA1, SHA256. I just modified the code to no longer include
>> >>> MD5SUM in *all* newly generated Release files.
>> >> When will that affect Release files for stable? Next point release?
>> >> Because that unfortunatly completly breaks debmirror..
>> > It did suddenly change for squeeze-updates without consultation with the
>> > suite admins. I expect that this is reverted.
>> Good laugh that is.
> In any case, it would seem logical for squeeze and squeeze-updates to
> use the same set of hashes, imho; similarly the -proposed-updates
> suites. Each of the "sister" suites would generally be expected to be
> consumed (for want of a better word) by the tools in the corresponding
> (old)stable suite.

Sure, and thats a reason I happily follow. Instead of that useless we
had before.
Done.

--
bye, Joerg
<aj> vorlon: would it be less subtle if we replaced red, green and
yellow with black, white and a shade of grey?
<vorlon> aj: "and this is what a necrotic port looks like"?
<aj> vorlon: the arch qualification table, halloween edition?
<aj> vorlon: "i heard a faint pinging, and went to the firewall and what
greeted my eyes? AN m68k RISED FROM THE GRAVE!!!"


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 877hctt6z6.fsf@gkar.ganneff.de">http://lists.debian.org/877hctt6z6.fsf@gkar.ganneff.de
 
Old 02-21-2011, 08:31 PM
Joerg Jaspert
 
Default Release file changes

>>>> I additionally opened a bug with apt to add support for SHA512SUM, so
>>>> we can start using them. As soon as that is possible I intend to drop
>>>> SHA256 and end up with SHA1/SHA512 only.
>>> Please don't. I have more faith in SHA-256 than SHA-512.
>> Uhh, fine - why?
> I think this question is a bit rude if faith is involved, but here we
> go:

Not intended rude, but you asked to not do something. So I want to know
why, as I'm not of the faith...

> the number of rounds in SHA-512 is rather small, considering its block
> size and internal state space, in particular in comparison with
> SHA-256.

Thanks.

> More practically speaking, SHA-512 would add about 450 kB of
> incompressible junk to the Packages file, so we probably want to stick
> to SHA-256 there. But using different hashes in Release and Packages
> files is just bloat.

We are not (yet?) speaking about the other files, *right* now this is
about the Release file. Yes, in the future the rest has to come up too.
Though, 450k in a Packages file of nearly 7mb, bz2 compressed...

--
bye, Joerg
If God didn’t want us to eat in church, he would’ve made gluttony a sin.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87zkpprs52.fsf@gkar.ganneff.de">http://lists.debian.org/87zkpprs52.fsf@gkar.ganneff.de
 
Old 02-21-2011, 08:32 PM
Joey Hess
 
Default Release file changes

Joerg Jaspert wrote:
> Yep. debmirror, reprepro, debootstrap and cdebootstrap seem to be the
> tools that can't deal with this. The latter two are serious enough to
> keep the change away from oldstable forever, and stable at least until
> after next point release, should they get updated there.

It's also desirable that stable's debootstrap be able to bootstrap
unstable chroots.

> > Also, I'll see about getting d-i generating some stronger checksum files
> > now that it's been pointed out. Although I wonder if it would make more
> > sense to generate those checksums on the server side.
>
> Well, the files currently come from the d-i builds. Makes sense, it
> shows what the build host expects them to be, not what a *possible*
> corruption during transport to us and unpack made them. How likely such
> a corruption is is a different topic, but the theoretical possibility is
> there. And we ARE using the MD5SUMS file when we accept the d-i tarballs
> to check if it actually matches, so I think we should keep that.

The debian-installer .changes file should list the byhand tarball
with sha1 and sha256 just like any other file in a changes file.
Those would be the right checksums to verify, not the md5sums inside the
tarball.

Also, it seems like the Releases file is already including sha1 and
sha256 for all the d-i files.

--
see shy jo
 
Old 02-21-2011, 09:08 PM
Sune Vuorela
 
Default Release file changes

On 2011-02-21, Joey Hess <joeyh@debian.org> wrote:
>
> --qMm9M+Fa2AknHoGS
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> Joerg Jaspert wrote:
>> Yep. debmirror, reprepro, debootstrap and cdebootstrap seem to be the
>> tools that can't deal with this. The latter two are serious enough to
>> keep the change away from oldstable forever, and stable at least until
>> after next point release, should they get updated there.
>
> It's also desirable that stable's debootstrap be able to bootstrap
> unstable chroots.

and desireable that you can run your mirroring software (reprepro or
demirror or others) on a stable machine, even mirroring unstable or
testing.

/Sune


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrnim5oi4.rvp.nospam@sshway.ssh.pusling.com">http ://lists.debian.org/slrnim5oi4.rvp.nospam@sshway.ssh.pusling.com
 
Old 02-21-2011, 09:12 PM
Eduard Bloch
 
Default Release file changes

#include <hallo.h>
* Joey Hess [Mon, Feb 21 2011, 05:32:00PM]:
> Joerg Jaspert wrote:
> > Yep. debmirror, reprepro, debootstrap and cdebootstrap seem to be the
> > tools that can't deal with this. The latter two are serious enough to
> > keep the change away from oldstable forever, and stable at least until
> > after next point release, should they get updated there.
>
> It's also desirable that stable's debootstrap be able to bootstrap
> unstable chroots.

I don't like this change either because users of my apt-cacher-ng daemon
might use the stable version for unstable archives. Without installing a
backport version that will be fun.

Do we really need to drop the MD5 version? It's less than 20KiB which we
are talking about.

> Also, it seems like the Releases file is already including sha1 and
> sha256 for all the d-i files.

Nope. Those Release files in debian-installer subdir are just stubs and
don't contain checksum information. And there was nothing for
installer-$ARCH subdirs and the image files therein. Instead, there are
MD5SUMS files there which were not covered by signatures in the main
Release file.

Regards,
Eduard.

--
<Alfie> Du kannst mit mir machen, was du willst. Ihr hab mich schlielich
gekauft.
 
Old 02-21-2011, 10:07 PM
Bernd Zeimetz
 
Default Release file changes

On 02/21/2011 09:05 PM, Joerg Jaspert wrote:
> On 12398 March 1977, Joey Hess wrote:
>
>>> until today our Release files included 3 Hashes for all their entries:
>>> MD5SUM, SHA1, SHA256. I just modified the code to no longer include
>>> MD5SUM in *all* newly generated Release files.
>> When will that affect Release files for stable? Next point release?
>> Because that unfortunatly completly breaks debmirror..
>
> Yep. debmirror, reprepro, debootstrap and cdebootstrap seem to be the
> tools that can't deal with this. The latter two are serious enough to
> keep the change away from oldstable forever, and stable at least until
> after next point release, should they get updated there.

Please keep them away even longer - not everybody has the spare time to update
the machines which run the mirror scripts to Squeeze - or at least make sure
that debmirror and friends are updated in an oldstable pointrelease.

--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D62F03C.1080007@bzed.de">http://lists.debian.org/4D62F03C.1080007@bzed.de
 
Old 02-21-2011, 10:29 PM
Joerg Jaspert
 
Default Release file changes

>> Also, it seems like the Releases file is already including sha1 and
>> sha256 for all the d-i files.
> Nope. Those Release files in debian-installer subdir are just stubs and
> don't contain checksum information. And there was nothing for
> installer-$ARCH subdirs and the image files therein. Instead, there are
> MD5SUMS files there which were not covered by signatures in the main
> Release file.

They are since yesterday.

--
bye, Joerg
<wiggy> "Memory is like gasoline. You use it up when you are running. Of
<wiggy> course you get it all back when you reboot..."; Actual explanation
<wiggy> obtained from the Micro$oft help desk.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87tyfxotku.fsf@gkar.ganneff.de">http://lists.debian.org/87tyfxotku.fsf@gkar.ganneff.de
 

Thread Tools




All times are GMT. The time now is 05:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org