Re: Release file changes
On 21 February 2011 15:39, Joey Hess jo...@debian.org wrote: 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. cowbuilder --create fails with: W: Failed to fetch http://mi.mirror.garr.it/mirrors/debian/dists/sid/main/binary-armel/PackagesIndex MD5Sum mismatch E: Some index files failed to download. They have been ignored, or old ones used instead. I: unmounting /var/cache/pbuilder/ccache filesystem I: unmounting dev/pts filesystem I: unmounting proc filesystem pbuilder create failed forking: rm -rf /var/cache/pbuilder/base.cow Did Packages.diff/Index use to contain an MD5sum? (it doesn't as of now) Or is this some unrelated breakage? Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinocn0xdosjglz-oeeacgreqtsvvbjju68mm...@mail.gmail.com
Re: Release file changes
On 24 February 2011 11:29, Luca Niccoli lultimou...@gmail.com wrote: Did Packages.diff/Index use to contain an MD5sum? (it doesn't as of now) Or is this some unrelated breakage? Mmm, if worked using ftp.debian.org, so it was a mirror problem I guess. Aptitude and apt didn't have any problems with it though. Sorry for the noise, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=y9s+g3rxc4asgr_qmyfjwp+arnhgmyz3_c...@mail.gmail.com
Re: Release file changes
On 02/22/2011 07:37 PM, 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. Right. For now I undo this (with next dinstall run), until either one of the following happens: # wget -q -O - ftp://security.debian.org/debian-security/dists/lenny/updates/Release | grep -i md5 # Please fix this on security.debian.org ASAP. Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d64d4f3.9010...@bzed.de
Re: Release file changes
Hi, On Dienstag, 22. Februar 2011, Joerg Jaspert wrote: - lenny is gone and the tools are fixed in squeeze with a point update (provided the SRMs approve such updates, but I *hope* so). Do I understand correctly that you again plan to break squeeze, this time for those who then havent upgraded to that pointrelease? Until today we discovered: * debootstrap (has a patch IIRC) * cdebootstrap * debmirror (fix uploaded) * reprepro * anna * apt-cacher(-ng) * fai-mirror (needs confirmation) * lots of custom code - wheezy is released. (This is the option I dont really favor, takes ages :) ) I actually prefer this very much over more random breakage in which is supposed to be stable. 2 years aint that long. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Release file changes
On 2011-02-23, Holger Levsen hol...@layer-acht.org wrote: - wheezy is released. (This is the option I dont really favor, takes ages :) ) I actually prefer this very much over more random breakage in which is supposed to be stable. 2 years aint that long. Seconded. If it would've been urgent it should've gone into squeeze. Furthermore it's about Release files which aren't that large anyway. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnim9okb.e38.tr...@kelgar.0x539.de
Re: Release file changes
Hi, On Montag, 21. Februar 2011, Joerg Jaspert wrote: Yep. debmirror, reprepro, debootstrap and cdebootstrap seem to be the tools that can't deal with this. fai-mirror came to my mind. And probably older dak setups as well? 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. There are also people who use the packages as backports on stable+oldstable... and those backports dont neccessarily come from debian.backports.org but are homemade. I'm actually of the opinion that such a change _must not_ be introduced in a stable point release. cheers, Holger, refraining from changing the subject to hey, let's break stable, it's already 2 weeks old.. sigh. signature.asc Description: This is a digitally signed message part.
Re: 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. Right. For now I undo this (with next dinstall run), until either one of the following happens: - lenny is gone and the tools are fixed in squeeze with a point update (provided the SRMs approve such updates, but I *hope* so). Until today we discovered: * debootstrap (has a patch IIRC) * cdebootstrap * debmirror (fix uploaded) * reprepro * anna * apt-cacher(-ng) - wheezy is released. (This is the option I dont really favor, takes ages :) ) Also note that in the process we found some inconsistencies in the Sources file output by apt-ftparchive we currently use - it doesn't provide a Checksum other than MD5 for the .dsc files of a package. Thats fixed in Squeeze and so will be fixed on ftp-master when we upgrade the machine to Squeeze, currently scheduled the day before our meeting. Additionally let me mention that *right* *now* we are not removing MD5 anywhere else (got asked about Packages/Sources files), but that those are certainly on the list to be done. Ideally we end up with just two (at least halfway trustable :) ) hashes everywhere in the archive. -- bye, Joerg elmo [..] trying to avoid extra dependencies on gnumeric is like trying to plug one hole in the titantic with a bit of tissue paper -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vx7oqzi@gkar.ganneff.de
Re: Release file changes
Joerg Jaspert jo...@debian.org writes: Right. For now I undo this (with next dinstall run), until either one of the following happens: - lenny is gone and the tools are fixed in squeeze with a point update (provided the SRMs approve such updates, but I *hope* so). Until today we discovered: * debootstrap (has a patch IIRC) * cdebootstrap * debmirror (fix uploaded) I can confirm that the unstable debmirror runs great on oldstable and can mirror the new-format repository, although I had to use --diff=none because otherwise a bunch of Packages diff files would fail the SHA-1 checksum and block the mirror. (That's not a new problem; I had --pdiff=none previously due to the same problem.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871v2z3m7u@windlord.stanford.edu
Re: Release file changes
Russ Allbery wrote: Joerg Jaspert jo...@debian.org writes: Right. For now I undo this (with next dinstall run), until either one of the following happens: - lenny is gone and the tools are fixed in squeeze with a point update (provided the SRMs approve such updates, but I *hope* so). Until today we discovered: * debootstrap (has a patch IIRC) * cdebootstrap * debmirror (fix uploaded) I can confirm that the unstable debmirror runs great on oldstable and can mirror the new-format repository, although I had to use --diff=none because otherwise a bunch of Packages diff files would fail the SHA-1 checksum and block the mirror. (That's not a new problem; I had --pdiff=none previously due to the same problem.) It does have a minor big with -v on oldstable. More problimatic is the diff size to use generic checksum types, since it entailed many broad changes: git diff 2.5..2.6|wc -l 565 This would be difficult to justify for proposed-updates. -- see shy jo signature.asc Description: Digital signature
Re: Release file changes
On Tue, 22 Feb 2011, Joey Hess wrote: Russ Allbery wrote: Joerg Jaspert jo...@debian.org writes: Right. For now I undo this (with next dinstall run), until either one of the following happens: - lenny is gone and the tools are fixed in squeeze with a point update (provided the SRMs approve such updates, but I *hope* so). Until today we discovered: * debootstrap (has a patch IIRC) * cdebootstrap * debmirror (fix uploaded) I can confirm that the unstable debmirror runs great on oldstable and can mirror the new-format repository, although I had to use --diff=none because otherwise a bunch of Packages diff files would fail the SHA-1 checksum and block the mirror. (That's not a new problem; I had --pdiff=none previously due to the same problem.) It does have a minor big with -v on oldstable. More problimatic is the diff size to use generic checksum types, since it entailed many broad changes: git diff 2.5..2.6|wc -l 565 This would be difficult to justify for proposed-updates. If it has been extensively regression-tested, and there are no ABI changes that could break local scripts, it should still be considered a valid candidate, IMO. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011030656.ga15...@khazad-dum.debian.net
Re: Release file changes
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.. 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. -- see shy jo signature.asc Description: Digital signature
Re: Release file changes
On Sun, Feb 20, 2011 at 07:03:11PM +0100, Joerg Jaspert wrote: 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. Unfortunately, the algorithm used for the GnuPG signatures (both in InRelease and Release.gpg) is SHA-1. Removing SHA-256 in favor of SHA-512 does not increase security because the signatures are the weakest point. See #612657 for more details. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Release file changes
On 2011-02-21, Joey Hess jo...@debian.org wrote: 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. The SRMs will not allow this change to affect oldstable's or stable's Release files at point release time. (Lucky enough they cannot be changed without invalidating the signatures.) Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnim55tg.9gd.tr...@kelgar.0x539.de
Re: 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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762sdff26@mid.deneb.enyo.de
Re: Release file changes
On Mon, 21 Feb 2011 18:55:13 +0100, Florian Weimer wrote: * 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. What indications are there that SHA-512 is weak? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110221130502.dfb4c885.michael.s.gilb...@gmail.com
Re: Release file changes
On Mon, Feb 21, 2011 at 01:05:02PM -0500, Michael Gilbert wrote:
What indications are there that SHA-512 is weak?
It might be worth approaching from a pragmatic perspective... why
generate SHA-512 checksums when you're only going to be signing a
SHA-256 digest of that list (that is unless you want to alienate
users of OpenPGP-compliant tools which don't implement optional
algorithms). Is it because you feel SHA-512 is more
tamper-resistant, or because you're worried that you might wind up
with two entries accidentally colliding over the same SHA-256 hash
(which is pretty unlikely statistically speaking, and even then may
not be particularly relevant depending on the use case for the
hashes).
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110221192243.gk1...@yuggoth.org
Re: 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. -- bye, Joerg Lisa, you’re a Buddhist, so you believe in reincarnation. Eventually, Snowball will be reborn as a higher life form… like a snowman. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y659tb18@gkar.ganneff.de
Re: Release file changes
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. 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. Please ping me when you start providing additional checksum files (if possible before the debian-installer-images upload, so I can have the byhand and release file generation script adjusted). -- bye, Joerg I'm having the best day of my life, and I owe it all to not going to Church! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyfxtap3@gkar.ganneff.de
Re: 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. Unfortunately, the algorithm used for the GnuPG signatures (both in InRelease and Release.gpg) is SHA-1. Removing SHA-256 in favor of SHA-512 does not increase security because the signatures are the weakest point. See #612657 for more details. Well, a slightly different point then reducing yourself to just 2 hashes, but yes, we should look to change that part too. -- bye, Joerg Son, when you participate in sporting events, it's not whether you win or lose: it's how drunk you get. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqqltaid@gkar.ganneff.de
Re: 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? -- bye, Joerg Well, it's 1 a.m. Better go home and spend some quality time with the kids. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwrhtadq@gkar.ganneff.de
Re: Release file changes
It might be worth approaching from a pragmatic perspective... why generate SHA-512 checksums when you're only going to be signing a SHA-256 digest of that list (that is unless you want to alienate users of OpenPGP-compliant tools which don't implement optional algorithms). Is it because you feel SHA-512 is more tamper-resistant, or because you're worried that you might wind up with two entries accidentally colliding over the same SHA-256 hash (which is pretty unlikely statistically speaking, and even then may not be particularly relevant depending on the use case for the hashes). Care to make a point for the gpg stuff around it within bug #612657? -- bye, Joerg snooze02 sind jabber und icq 2 unterschiedliche netzwerke ? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp25tabk@gkar.ganneff.de
Re: Release file changes
On 2011-02-21, Joerg Jaspert jo...@debian.org 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. Seriously? Child's play with productive stable suites, breaking tools in the process and then not fixing it up? And no, just telling people to update their tools in stable is not the way to go here. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnim5hrp.9ov.tr...@kelgar.0x539.de
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1298319528.14573.225.ca...@hathi.jungle.funky-badger.org
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqql9lla@mid.deneb.enyo.de
Re: 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(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110221205247.gl1...@yuggoth.org
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hctt6z6@gkar.ganneff.de
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkpprs52@gkar.ganneff.de
Re: 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 signature.asc Description: Digital signature
Re: Release file changes
On 2011-02-21, Joey Hess jo...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnim5oi4.rvp.nos...@sshway.ssh.pusling.com
Re: 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 schließlich gekauft. :) signature.asc Description: Digital signature
Re: 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 ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d62f03c.1080...@bzed.de
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyfxotku@gkar.ganneff.de
Re: Release file changes
On Mon, Feb 21, 2011 at 3: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. Can we get this reverted at least until the major tools can actually cope with the change (i.e. for the next point release)? The fact that this causes a regression in stable's debootstrap is rather unfortunate. Stable is called stable because its functionality isn't supposed to suddenly change. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinkmmpqjigr3tmgzurozl5izbjx0rwue+35f...@mail.gmail.com
