Re: dpkg-sig support wanted?
Scripsit Florian Weimer [EMAIL PROTECTED] This means that it's dangerous to commit yourself to the contents of a document, using a digital signature, unless you fully understand the meaning of each byte in the document. So how do the MD5 sums of .debs end up in a Packages file signed with the archive key? Do the ftpmasters go over each file with a disassembler, fully understanding the meaning of each byte in the .deb? (Note the rub.de part of the URL. A clear warning sign.) The nice thing about ad hominem arguments is that you can make them without ever having to argue the merits of your case. *shrug* The computer security folks at that university started spreading FUD about various security systems, mainly rehashing the work of others. They seem to be in it mostly for the publicity. More ad hominem arguing. -- Henning Makholm Jeg mener, at der eksisterer et hemmeligt selskab med forgreninger i hele verden, som arbejder i det skjulte for at udsprede det rygte at der eksisterer en verdensomspændende sammensværgelse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: dpkg-sig support wanted?
A cryptographer friend of mine recently attended the NIST Hallowe'en Hash Bash (http://www.csrc.nist.gov/pki/HashWorkshop/index.html), and made a few notes in his blog: http://www.livejournal.com/users/sevenstring/7326.html His suggestion there was stick to SHA2 (or maybe Whirlpool) for now. Did anyone else here attend this workshop? I attended, and the message I got was: use SHA-256 (or SHA-512 if you want to be cautious) for new applications, but consider it to be an interim solution for the 5-10 year timeframe until something better is devised, and have the agility to switch to that something better when it comes; most importantly, stop using MD5 ASAP. Regarding your friend's suggestion to stick with SHA2 (or maybe Whirlpool) for now, what I wrote in my notes was: * Asked about which two functions would be best to use in parallel, suggestions were SHA-256+(Whirlpool/Tiger). One of the panelists explained, though, that using two different hash functions and concatenating the output yields a result which is not significantly more secure than either of the functions by itself. And the SHA family of functions were the predominant topic of the workshop; others, such as Whirlpool, were mentioned only occasionally. Some choice quotes from Niels Ferguson: SHA-1 is a wounded fish in shark-infested waters. Switch away from SHA-1 as soon as you can, but switch away from MD5 first. It's true that MD5 and SHA-1 are still acceptable for certain uses where the current attacks aren't a threat, but Ferguson argued that it's much easier and safer to replace them entirely than to try to analyze which uses are still OK. Also from my notes: SHA-1 is OK for ephemeral uses, but not for non-repudiation and certification -- essentially, if it matters that the signature be verified by a third party, not just the recipient, avoid SHA-1. Some people wanted NIST to specify an approximate target year for a hash standard to be issued, like they did for AES. Bruce Schneier said we don't know hashing well enough, like we knew about block ciphers for AES, and recommended that we wait ten years. Several people requested that NIST publish the design criteria with which SHA-1 was designed, but I don't remember hearing a definitive answer to that. (Note that I'm not a cryptographer; I attended simply as an interested individual.) -- Mike Paul [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: dpkg-sig support wanted?
* Henning Makholm: Scripsit Florian Weimer [EMAIL PROTECTED] * Jochen Voss: I found the example at http://www.cits.rub.de/MD5Collisions/ quite impressive. They have two different valid PostScript files with identical MD5 sums. I don't know how much computing time they used, though. They claim a few hours: | Based on [WY05] and the analysis described in [Da], we implemented | an attack to find random collisions for the MD5 compression | function. It took just a few hours on a customary PC. I can no longer recall if this paragraph was present in the original version of the page; I didn't notice it when I read it for the first time. None, many of these examples were created before the collision generation tools were generally available. They did create or use a collision, as anyone can verify simply by downloading the files. One collision was published by Wang et al. as a zero-knowledge proof of their discovery. I thought they had reused this one, like many others did. The exploit uses some properties of Postscript files which make them not very desirable for storing electronic documents which cannot be altered. There is absolutely no reason to put the word exploit in scare quotes here. Strictly speaking, you cannot exploit MD5 itself, you can only exploit security systems that rely on some property of the MD5 function. Let's look what happens in the attack published by the RUB researchers: 1. The attacker creates two Postscript files with the same MD5 hash. 2. The attacker submits one of the file to the victim. 3. The victim views the file in his Postscript viewer, doesn't notice anything strange, and signs it. 4. The attacker obtains the signature, and uses it together with the second file he has created. A successful attack is possible if the following conditions are met: (a) the attacker can create a suitable collision, (b) the victim uses the document supplied by the attacker, (c) the victim only checks one presentation form of the document, and (d) the document is used in a way which does not lead to the victim disputing the signature, and into investigation (which would immediately reveal the attack). It turns out that we can actually do without (a). Have a look at the attached Postscript with your favorite Postscript viewer, and sign it if you agree with its message. 8-) In my opinion, this modified attack strongly suggest that the process described above is already substantially broken. MD5 is just a weak part among others. As a result, the attack doesn't show what people claim. Just be clear: I don't claim everything is alright with MD5. For most applications, you should definitely migrate to something else (what is a different question). But most organization's resources are limited, you can't afford to migrate too often, and you deal with many issues at once. Correctly analyzing the relevance of security issues is very important. Misleading claims about the impact of new attacks are not helpful, may lead to wrong allocation of resources, and prevent more important vulnerabilities from being addressed. You might want to notice that the properties you apparently think invalidate the example are also shared by many common formats for software. An ELF binary can easily be crafted to contain a blob of initialized data whose contents are only used for checking whether to enable some malicious machine code that is always present - and this would not be easily detectable at all. In general, any form of malicious code is not easy to detect. But the malicious code must be present in the first place. You can use a MD5 collision to make it dormant, but it has to be there. This means that it's dangerous to commit yourself to the contents of a document, using a digital signature, unless you fully understand the meaning of each byte in the document. (Note the rub.de part of the URL. A clear warning sign.) The nice thing about ad hominem arguments is that you can make them without ever having to argue the merits of your case. *shrug* The computer security folks at that university started spreading FUD about various security systems, mainly rehashing the work of others. They seem to be in it mostly for the publicity. psTcrNiJNRKU.ps Description: PostScript document
Re: dpkg-sig support wanted?
On Mon, Nov 28, 2005 at 07:07:22PM +1000, Anthony Towns wrote: (Note that dsum would probably need to become Priority:required, and possibly Essential:yes, with the complications that entails) Stick it in dpkg.deb. There's plenty of precedent for that (some not-so-good, but I think mostly good). -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Tue, Nov 29, 2005 at 02:20:55PM +0100, Florian Weimer wrote: * Anthony Towns: On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote: In terms of security, there are some better hash functions. My understanding was that there aren't other hash functions that've had remotely similar levels of cryptographic analysis to md5 and sha. Neither MD5 nor SHA1 have received much public scrutiny. Dobertin's work on MD5 has never been fully published. I've already joked that the difference between Wang et al. and European or U.S. cryptographers is that the Chinese government doesn't tell their researchers not to publish their results. 8-P IIRC, the elliptic curve cryptography stuff was supposed to be similarly neat, until people started analysing it seriously, at which point it broke. The NSA has recently licensed ECC patents from Certicom. There are weak elliptic curves as far as cryptography is concerned, but there are also others: inefficient ones and those which have been patented by Certicom. A cryptographer friend of mine recently attended the NIST Hallowe'en Hash Bash (http://www.csrc.nist.gov/pki/HashWorkshop/index.html), and made a few notes in his blog: http://www.livejournal.com/users/sevenstring/7326.html His suggestion there was stick to SHA2 (or maybe Whirlpool) for now. Did anyone else here attend this workshop? That said, I suspect that any my favourite algorithm argument is going to get horribly bogged down in bikeshedding. As long as we don't fall into the multicollisions trap of spending more and more CPU time generating and checking more and more iterative hash functions that don't actually add significant collision-resistance when you check them all together, a generalised checksumming tool as proposed seems an obviously sensible and desirable thing to have. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Tue, Nov 29, 2005 at 02:20:55PM +0100, Florian Weimer wrote: not even be out of the question to find someone who'll sponsor an upload without rebuilding the .deb. I think it's safe to imagine that there are developers right now who've done some shady things in the past; is it that far fetched to imagine it's worth protecting against developers who try to abuse their priveleges? No, but they can directly upload a bad package. No need to create an MD5 collision and sneak the evil twin package into some mirror archive. Sure; someday, maybe some of the test suite stuff will allow us to avoid that, but at the moment we can't. What we can do now is limit the chances that people will get away with that. Have we already done that? Have we expelled people becaue they put vulnerable code into Debian? We've expelled people for violating the DMUP in other ways; and we've stopped distributing micq because it included upstream code that could reasonably be called an exploit. You can embed code that checks for characteristics of the victim system and activate the attack only if there's a match. Sure, these things aren't perfect; but they're a help. Anyway, I'm not going to waste my time further arguing why we shouldn't continue using a hash that's had a practical exploit published on slashdot. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: The archive signing key gives absolutely no integrity ensurance on the deb package. The only thing it insures is that the file was not altered _after_ leaving ftp.de.debian.org for the mirrors and/or user. In no way does it prevent altering the deb on ftp-master. Isn't that a useful assurance? Perhaps I trust the maintenance of ftp-master, but not the maintenance of Joe Random Mirror. It sure is usefull as it removes a lot of untrusted steps from being a vulnerability. But that doesn't help if the attack happens at ftp-master. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Steinar H. Gunderson [EMAIL PROTECTED] writes: On Sat, Nov 26, 2005 at 09:13:02AM +1000, Anthony Towns wrote: Moving away from MD5 is certainly not a bad idea, but it's not clear whether the alternatives are any better. Sure, everyone recommends SHA-256 at this stage, but nobody can give a rationale. MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or higher) are significantly harder to break in practice, and there's nothing better yet. Just a comment here for those who are not used to hash functions: Broken here means that you can generate collisions faster than using the birthday attack (2^64 for MD5, 2^80 for SHA-1). It does not have to mean that you can do _really_ evil stuff, like generate a second file with the same MD5 hash as a given file (so-called second preimage, IIRC) and to the best of my knowledge, nobody has done so yet). According to slashdot articles you can generate human readable files (like the Packages file) with md5sum collision in ~45minutes on a modern cpu now. I think that counts as broken. Luckily for us we also have the size of the file. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Anthony Towns aj@azure.humbug.org.au writes: On Fri, Nov 25, 2005 at 12:49:11PM -0800, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: .deb signatures are aimed at giving users some sort of assurance the package is valid; but when you actually look into it -- at least in Debian's circumstances -- those signatures can't actually give any meaningful assurance for any specific validity. Don't they give the user the assurance that a Debian developer was responsible for building and providing the package? Not really, they give the assurance that it was built by someone who at some point possessed a key that at some point was considered sufficient to identify a Debian developer or a buildd. What assurance would you take from a package signed by Chip's old key? (And why do you think it's actually helpful? Debian developers build *lots* of crap, especially if you can't differentiate stuff uploaded to Debian and not) Cheers, aj They also upload *lots* of crap. Should we stop using Release.gpg now? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
* Anthony Towns: On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote: For the exploits we have seen so far to work, the malicious party needs upload access to the archive and has to plant a specially crafted package there, for which they have created an evil twin package. (Same for attacking one of the text files listing hashes.) Looks a bit far-fatched to me. Not really. Joining Debian isn't particularly difficult, and it might not even be out of the question to find someone who'll sponsor an upload without rebuilding the .deb. I think it's safe to imagine that there are developers right now who've done some shady things in the past; is it that far fetched to imagine it's worth protecting against developers who try to abuse their priveleges? No, but they can directly upload a bad package. No need to create an MD5 collision and sneak the evil twin package into some mirror archive. The way we do that has to be mostly after the fact, of course: someone uploads a bad package, people find out it's bad, we trace it back to whoever uploaded it, then we kick them out of the project. Have we already done that? Have we expelled people becaue they put vulnerable code into Debian? But that only works if the bad package is actually discovered. If the .deb's distributed across hundreds of mirrors and to thousands of users, it's reasonably likely that it will be discovered; but if it's possible to target the attack against an individual user, and leave the rest of the Debian universe untouched, you've got a much better chance of not getting caught. Hence: distribute an iced .deb in the archive, that does no harm ever and thus needn't arouse any suspicion; and sneak a fire .deb that has the exploit activated onto the mirror of your target. You can embed code that checks for characteristics of the victim system and activate the attack only if there's a match. The advantage is that you need only to compromise a DD account (or become a DD yourself), and not both a DD account and part of the mirror cascade which is used by the victim. Looks a bit far-fetched comes under the famous last words heading for security analysis. One part of security analysis is figuring out which potential attacks are relevant. Keep in mind that most attacks never happen. There's no point in wasting resources on irrelevant attacks. It's embarrassing to be wrong on such matters, in both directions. Money thrown at a problem that turns out to be a non-issue is money lost. But you hardly ever read about those failures. There is one attack on MD5 which is a significant threat to many companies: the PR attack. There are many, many security experts who are all too willing to label your system as broken just because it uses MD5 internally. With the right media spin, such claims of insecurity can become a PR nightmare and very costly. Worse, the existance of a practical md5(A+B+C)=md5(A+D+C) attack means that it's not out of the question that there're md5(A+B)=md5(C+D) attacks in the hands of particularly well resourced groups (which is worse, since the version uploaded to the archive could then be entirely innocent looking). Personally, I don't have any interest in making the NSA's job any easier, or that of other signals intelligence groups. Oh, many Debian packages happily leak so much data over the network that I often wonder if it is feasible to create user profiles using this information. 8-) SHA256 is better than SHA1 in the same way 2048 bit RSA keys are better than 512 bit RSA keys. No, the algorithms are somewhat different. It's easy to build a 256 bit hash which is less secure than a 160 bit hash, so it's not really comparable to the RSA situation. MD5 is broken, and isn't extensible. SHA1 is fragile, but not broken, and is extensible. What do you mean with extensible? Both MD5 and SHA1 are based on MD4, and SHA256 is based on SHA1, but AFAIK, no rationale for the changes from MD4 - SHA1 and SHA1 - SHA256 has been published. (Ron Rivest explained his changes from MD4 to MD5.) In terms of security, there are some better hash functions. My understanding was that there aren't other hash functions that've had remotely similar levels of cryptographic analysis to md5 and sha. Neither MD5 nor SHA1 have received much public scrutiny. Dobertin's work on MD5 has never been fully published. I've already joked that the difference between Wang et al. and European or U.S. cryptographers is that the Chinese government doesn't tell their researchers not to publish their results. 8-P IIRC, the elliptic curve cryptography stuff was supposed to be similarly neat, until people started analysing it seriously, at which point it broke. The NSA has recently licensed ECC patents from Certicom. There are weak elliptic curves as far as cryptography is concerned, but there are also others: inefficient ones and those which have been patented by Certicom. -- To UNSUBSCRIBE, email
Re: dpkg-sig support wanted?
Steve Langasek [EMAIL PROTECTED] writes: On Fri, Nov 25, 2005 at 02:57:36PM +0100, Goswin von Brederlow wrote: Steve Langasek [EMAIL PROTECTED] writes: On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote: That's easy: you trust the Packages file to be correct when using apt, and it's not verified at all by per-package signatures. In what way trust and how does that change anything? At best you can prevent a newer version of a package to appear in the Packages file by compromising it. You can't subvert a package itself. But you can already ship yesterdays Release.gpg, Release and Packages file to a user and thereby prevent any updates. On the other hand, without package signatures ftp-master adds a vulnerability. You can hack into it, replace debs, recreate the Packages, Release and Release.gpg file and thereby infect users. With signed debs that could still be detected by every user in apt-get. Only if every user is in a position to verify signatures from each Debian developer individually, which is completely unrealistic. Up to a point you can trust the keyring. As much as you can trust any DD signature. You try to argue that signatures are not absolutely trustworthy but that is nothing new. I'm arguing that a 5-hop-long signature chain to establish the validity of a Debian package is as good as useless, and worse if the user doesn't understand this. And a 5-hop-long signature chain does *not* mean that anyone in that chain trusts the person holding the key on the end to upload packages to Debian. They aren't ment to. The in-deb signature by the DD is only ment to say I did build this. The only thing we have that establishes *that* is the presence of the user's key in the Debian keyring, so then you have the logistical problem of how arbitrary users are supposed to verify whether a given key is in the They aren't supposed to. They just should have the possibility. keyring. The debian-keyring package doesn't get updated every time there's a key added or removed, and the web interface to keyring.debian.org doesn't provide any cryptographic assurances. Oh, and BTW, check the IPs of ftp-master.debian.org and keyring.debian.org... The amount of package that fall through the cracks due to the keyring not being fully updates is marginal. You can also ask keyservers for keys and verify them through your trust path. That is enough to establish who build the deb (not to be confused with for whom did he build it). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Steinar H. Gunderson [EMAIL PROTECTED] writes: On Sat, Nov 26, 2005 at 10:47:57AM +1100, Brian May wrote: Well, even if I know naught about it, it looks to me that having something signed is better than having the same something not signed. Sorry, but that's a snake oil rationale. A: Why do you lock your car up[1]? Because it makes it harder to steal the car. I think the point was that signing a .deb did not automatically make it harder to do whatever the scenario asked for. /* Steinar */ Why do you put a serial number on the car? So you can trace it back to the true owner when you find a car that was repainted. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Anthony Towns aj@azure.humbug.org.au writes: On Fri, Nov 25, 2005 at 03:13:58PM +0100, Goswin von Brederlow wrote: You're correct. And he is also wrong. That would result in debs with the same name and version but different md5sums. Something that easily confuses apt-get and people. And yet, somehow people manage partial cross-grades between Debian and Ubuntu... Regards, aj I said confuse. Doesn't mean it won't work at all. But apart from stuff not getting cross-graded (as you put it) you can also end up in loops that will re-cross-grade a package every time you apt-get upgrade and the like. Having apt-get say there is a new version of foo available every day is damn anoying. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Hi! On Tue, Nov 29, 2005 at 02:08:45PM +0100, Goswin von Brederlow wrote: According to slashdot articles you can generate human readable files (like the Packages file) with md5sum collision in ~45minutes on a modern cpu now. I found the example at http://www.cits.rub.de/MD5Collisions/ quite impressive. They have two different valid PostScript files with identical MD5 sums. I don't know how much computing time they used, though. All the best, Jochen -- http://seehuhn.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
* Jochen Voss: On Tue, Nov 29, 2005 at 02:08:45PM +0100, Goswin von Brederlow wrote: According to slashdot articles you can generate human readable files (like the Packages file) with md5sum collision in ~45minutes on a modern cpu now. I found the example at http://www.cits.rub.de/MD5Collisions/ quite impressive. They have two different valid PostScript files with identical MD5 sums. I don't know how much computing time they used, though. None, many of these examples were created before the collision generation tools were generally available. The exploit uses some properties of Postscript files which make them not very desirable for storing electronic documents which cannot be altered. For example, it is possible to create a Postscript file whose output, when printed, varies from printer to printer. (Note the rub.de part of the URL. A clear warning sign.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Scripsit Anthony Towns aj@azure.humbug.org.au On Mon, Nov 28, 2005 at 10:15:34PM +0100, Henning Makholm wrote: I would expect something like $ dsum -a sha1 COPYING; sha1sum COPYING s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING sha1sum already exists; and isn't that long. Do you mean sha256? Feh. Yes, I meant SHA-256. Sorry for the confusion. -- Henning Makholm What has it got in its pocketses? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Scripsit Florian Weimer [EMAIL PROTECTED] * Jochen Voss: I found the example at http://www.cits.rub.de/MD5Collisions/ quite impressive. They have two different valid PostScript files with identical MD5 sums. I don't know how much computing time they used, though. They claim a few hours: | Based on [WY05] and the analysis described in [Da], we implemented | an attack to find random collisions for the MD5 compression | function. It took just a few hours on a customary PC. None, many of these examples were created before the collision generation tools were generally available. They did create or use a collision, as anyone can verify simply by downloading the files. Whether or not they used a generally available tool is not important to the fact that a collision was actually generated. The exploit uses some properties of Postscript files which make them not very desirable for storing electronic documents which cannot be altered. There is absolutely no reason to put the word exploit in scare quotes here. You might want to notice that the properties you apparently think invalidate the example are also shared by many common formats for software. An ELF binary can easily be crafted to contain a blob of initialized data whose contents are only used for checking whether to enable some malicious machine code that is always present - and this would not be easily detectable at all. The only thing that would seem to make it less than straightforward to craft a similar attack consisting of two different .deb files with the same MD5 sum of which one behaves maliciously, is the need to trick the CRC-32 in the gzip trailer for data.tar.gz simultaneously with tricking MD5. But a CRC-32 is, to put it mildly, not much of a defense against a determined attacker! All it takes to beat *that* is finding at most 33 different MD5 single-block collisions in sequence; it is then a matter of extremely simple linear algebra find a nontrivial combination of them that cancel out each other's effect on the CRC. Note that the gzip compression format allows blocks of compressed data to specify use of the no compression algorithm, so injecting your collisions in a gzipped data stream is trivial, too. (Note the rub.de part of the URL. A clear warning sign.) The nice thing about ad hominem arguments is that you can make them without ever having to argue the merits of your case. -- Henning Makholm I always thought being *real* sad would be *cooler* than acting *fake* sad, but it's not. It's not cool at *all*. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Hi Florian, On Tue, Nov 29, 2005 at 03:24:54PM +0100, Florian Weimer wrote: None, many of these examples were created before the collision generation tools were generally available. The exploit uses some properties of Postscript files which make them not very desirable for storing electronic documents which cannot be altered. Do you mean the ability to embed comments into the file? Several other formats allow this, too. For example, it is possible to create a Postscript file whose output, when printed, varies from printer to printer. How is this related to their examples? (Note the rub.de part of the URL. A clear warning sign.) This is the university of Bochum, Germany, isn't it? Should I be afraid of them? All the best, Jochen -- http://seehuhn.de/ signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Sat, Nov 26, 2005 at 11:10:27PM -0600, Peter Samuelson wrote:
sha256sum () {
(Implementation of -c left as an exercise, etc.)
Hrm, if we're writing our own thing, maybe we should do it properly:
have a single program that can do multiple hash algorithms, have the
default hash be secure, and update it in future, and so on.
gnupg comes close to being this, except for two things: it's got too
many dependencies, and it's command line arguments are overly complex. A
gpgh variant (like gpgv but for hashing) might work, though. It
doesn't support --check, and gpg --print-md md5 /etc/motd has a
different format to md5sum /etc/motd though.
Of course, if we're doing it right, we probably want to have some way
of telling what hash was used, so we don't have to wonder whether a
given 160bit hash is sha1 or ripemd160 or something else that gets
cooked up in future. OpenBSD's cksum apparently does this, by having its
output be:
MD5 (filename) = hash
That strikes me as pretty inconvenient, but cksum does do most of what we
want.
OTOH, it would be far more convenient for *us* if it supported the
.changes style we use, ie:
MD5Sum:
hash size filename
Then there are the encoding questions; both the one above (do we switch
from hexadeximal to something more compact for longer hashes?) and also
the question of what happens if there's a ) or a \n in the filename
-- is it worth doing some sort of http-style % encoding that apt uses
in that case?
Something like this might work well:
$ dsum -a sha1 foo; sha1sum foo
f572d396fae9206628714fb2ce00f72e94f2258f foo
f572d396fae9206628714fb2ce00f72e94f2258f foo
$ dsum -d foo
SHA1Sum:
f572d396fae9206628714fb2ce00f72e94f2258f 6 foo
$ dsum -b foo
SHA1 (foo) = f572d396fae9206628714fb2ce00f72e94f2258f
$ dsum -d foo | dsum --check; echo $?
0
$ dsum -b foo | dsum --check; echo $?
0
Though what dsum foo should do is a trickier question (particularly
whether it's better to be compatible with current md5sum/sha1sum
output, or if dsumA foo foo.sum and dsumB --check foo.sum will
work if dsumA's default cypher is sha1 and dsumB's is ripemd160).
(Note that dsum would probably need to become Priority:required,
and possibly Essential:yes, with the complications that entails)
Cheers,
aj
signature.asc
Description: Digital signature
Re: dpkg-sig support wanted?
[Anthony Towns] gnupg comes close to being this, except for two things: it's got too many dependencies, and it's command line arguments are overly complex. A gpgh variant (like gpgv but for hashing) might work, though. It doesn't support --check, and gpg --print-md md5 /etc/motd has a different format to md5sum /etc/motd though. I think it's important to support md5sum/sha1sum format, in cases where md5 or sha1 are used, so people can conveniently use --check with their existing binaries. That might be just me, though. Of course, if we're doing it right, we probably want to have some way of telling what hash was used, so we don't have to wonder whether a given 160bit hash is sha1 or ripemd160 or something else that gets cooked up in future. For large files, getting a cryptographic checksum is more about reading blocks off the disk than about CPU time. So it wouldn't be completely ridiculous to allow sha-1 to remain ambiguous with competing 160-bit hashes, and have --check check for all of them (reading the file only once). I still think two-byte prefixes for non-md5-non-sha1 hashes makes some sense, like s- for sha-256. Avoids the filename encoding issue you mentioned later (unless we want to encode newlines). OTOH, it would be far more convenient for *us* if it supported the .changes style we use, ie: MD5Sum: hash size filename This might be generally reasonable, but we do want our dsum tool to work with arbitrary MD5SUMS style files. And if such files require a hash-type header, dsum will have to produce one, at least optionally. I really like the default behavior of our existing md5sum outputting just a single line per file, and nothing more. $ dsum -a sha1 foo; sha1sum foo f572d396fae9206628714fb2ce00f72e94f2258f foo f572d396fae9206628714fb2ce00f72e94f2258f foo $ dsum -d foo SHA1Sum: f572d396fae9206628714fb2ce00f72e94f2258f 6 foo $ dsum -b foo SHA1 (foo) = f572d396fae9206628714fb2ce00f72e94f2258f What's the 6 above? Surely not a hollerith-like string. Other than that, I like your proposed command line quite a lot. (Note that dsum would probably need to become Priority:required, and possibly Essential:yes, with the complications that entails) Hmmm, promoting libgcrypt11 + libgpg-error0 to Required adds 516 kB on i386, plus a trivial amount for dsum itself. I wonder if it'd be better to just copy / paste the algorithm code into dsum. signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
Scripsit Peter Samuelson [EMAIL PROTECTED] For large files, getting a cryptographic checksum is more about reading blocks off the disk than about CPU time. So it wouldn't be completely ridiculous to allow sha-1 to remain ambiguous with competing 160-bit hashes, and have --check check for all of them (reading the file only once). That sounds cryptographically unsafe. It would mean that a practical preimage attack against _any_ of the supported hashes would break the entire system. That's not the kind of algorithm agility we need. I still think two-byte prefixes for non-md5-non-sha1 hashes makes some sense, like s- for sha-256. That is much better. But let's use s. as a prefix and do a [/+] - [_-] substitution on the following base64 data. The dot in the prefix will prevent the prefix from being mistaken as part of a slightly larger non-tagged hash value. $ dsum -a sha1 foo; sha1sum foo f572d396fae9206628714fb2ce00f72e94f2258f foo f572d396fae9206628714fb2ce00f72e94f2258f foo There appears to be to few characters of hash there, at least unless it is a cosmically weird coincidence that it base64 encodes to all hex digits. :-) I would expect something like $ dsum -a sha1 COPYING; sha1sum COPYING s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING $ dsum -a sha1 -a md5 COPYING s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING 4325afd396febcb659c36b49533135d4 COPYING $ echo m | sha1sum - s.-tUTs04N4IxBOtWpdoIXt1b0qgHIgNm9IC_OgYjm-mU - -- Henning MakholmBut I am a Sunni Muslim, the bemused Arab said. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Mon, Nov 28, 2005 at 10:15:34PM +0100, Henning Makholm wrote: I would expect something like $ dsum -a sha1 COPYING; sha1sum COPYING s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING sha1sum already exists; and isn't that long. Do you mean sha256? Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Mon, Nov 28, 2005 at 12:09:33PM -0600, Peter Samuelson wrote: I still think two-byte prefixes for non-md5-non-sha1 hashes makes some sense, like s- for sha-256. Avoids the filename encoding issue you mentioned later (unless we want to encode newlines). The encoding issues are only for doing base64 (or similar compression) or filename encoding, so you can't avoid them :) OTOH, it would be far more convenient for *us* if it supported the .changes style we use, ie: MD5Sum: hash size filename This might be generally reasonable, Doesn't matter if it's generally reasonable, it's needed by *us*. That's the format we use in .changes, in .dscs and Sources, and in Release. It's silly to have a useful format, then not have tools that conveniently check it, particularly if we're writing our own. $ dsum -a sha1 foo; sha1sum foo f572d396fae9206628714fb2ce00f72e94f2258f foo f572d396fae9206628714fb2ce00f72e94f2258f foo $ dsum -d foo SHA1Sum: f572d396fae9206628714fb2ce00f72e94f2258f 6 foo $ dsum -b foo SHA1 (foo) = f572d396fae9206628714fb2ce00f72e94f2258f What's the 6 above? wc -c foo. foo was hello\n for reference. (And it probably should've been SHA1: not SHA1Sum: too) (Note that dsum would probably need to become Priority:required, and possibly Essential:yes, with the complications that entails) Hmmm, promoting libgcrypt11 + libgpg-error0 to Required adds 516 kB on i386, plus a trivial amount for dsum itself. I wonder if it'd be better to just copy / paste the algorithm code into dsum. libssl0.9.8 is 860kB of .deb, 2MB installed. It's possible that libssl would be too much of a nuisance wrt transitions to use, at least dynamically. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Sat, 26 Nov 2005 14:14:38 +0100, Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Florian Weimer [EMAIL PROTECTED] I wouldn't use real base64, though, because it would mean that you can use its hashed output as a file name. Good point. One might replace / with _ and omit the final =. Having a + in the hash should be safe in most contexts. Isn't base62, which for example exim uses to create its message-ids, a standard? I have never seen it outside exim. Greetins Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: dpkg-sig support wanted?
On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote: My understanding was that there aren't other hash functions that've had remotely similar levels of cryptographic analysis to md5 and sha. IIRC, the elliptic curve cryptography stuff was supposed to be similarly neat, until people started analysing it seriously, at which point it broke. To the best of my knowledge, elliptic curve cryptography isn't any more broken than RSA or ElGamal is. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
In linux.debian.devel, you wrote: Worse, the existance of a practical md5(A+B+C)=3Dmd5(A+D+C) attack means that it's not out of the question that there're md5(A+B)=3Dmd5(C+D) attacks in the hands of particularly well resourced groups (which is worse, since the version uploaded to the archive could then be entirely innocent looking). Personally, I don't have any interest in making the NSA's job any easier, or that of other signals intelligence groups. While this is arguably true (the NSA claims to have developed asymmetric cryptography ten years ahead of Diffie/Hellman), it seems that nowadays the end of the cold war and improved corporate interest have shifted things, so I'm personally not _too_ worried about that. Moving away from MD5 is certainly not a bad idea, but it's not clear whether the alternatives are any better. Sure, everyone recommends SHA-256 at this stage, but nobody can give a rationale. MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or higher) are significantly harder to break in practice, So? If SHA256 is so much better, why is that nobody can prove it, or at least can provide some evidence which supports that claim? The numbers are bigger is the main argument at this point, which is awfully similar to the usual snake-oil arguments (although there is a slight difference, of course). SHA256 is better than SHA1 in the same way 2048 bit RSA keys are better than 512 bit RSA keys. MD5 is broken, and isn't extensible. SHA1 is fragile, but not broken, and is extensible. Do you have other suggestions? I'd suggest the combination of several hash systems, e.g. RIPEMD-160, a SHA-based algorithm and possibly Tiger. and there's nothing better yet. In terms of security, there are some better hash functions. =20 My understanding was that there aren't other hash functions that've had remotely similar levels of cryptographic analysis to md5 and sha. IIRC, the elliptic curve cryptography stuff was supposed to be similarly neat, until people started analysing it seriously, at which point it broke. I'm not aware of any attacks beyond birthday attacks, which are still infeasible for the recommended key sizes of = 160 bits. ECC has several patent problems, though. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Sun, Nov 27, 2005 at 12:42:42PM +0100, Steinar H. Gunderson wrote: On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote: My understanding was that there aren't other hash functions that've had remotely similar levels of cryptographic analysis to md5 and sha. IIRC, the elliptic curve cryptography stuff was supposed to be similarly neat, until people started analysing it seriously, at which point it broke. To the best of my knowledge, elliptic curve cryptography isn't any more broken than RSA or ElGamal is. Oh god, how embarassing. I'm confusing elliptic curves and knapsacks, my bad. Knapsack cryptograph's provably secure (in that a general solution is NP), and practically insecure (in that it's hard to find instances that are reliably hard enough, at least without obscene key sizes). But hey, SHA-something, Tiger, or whatever; it's well past time to choose one, get a /usr/bin/... binary we can use, and replace md5 with it. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Sun, Nov 27, 2005 at 12:42:42PM +0100, Steinar H. Gunderson wrote: On Sun, Nov 27, 2005 at 02:18:00PM +1000, Anthony Towns wrote: My understanding was that there aren't other hash functions that've had remotely similar levels of cryptographic analysis to md5 and sha. IIRC, the elliptic curve cryptography stuff was supposed to be similarly neat, until people started analysing it seriously, at which point it broke. To the best of my knowledge, elliptic curve cryptography isn't any more broken than RSA or ElGamal is. It isn't really broken, but the recommended key sizes have grown significantly. I mean, the factor to divide RSA/DH/ElGamal key sizes by to get equivalent security in ECC has shrunk. At least, I've heard so, I don't remember what keys sizes were advertised in the beginnings of ECC. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Mon, Nov 28, 2005 at 03:32:21PM +1000, Anthony Towns wrote: Knapsack cryptograph's provably secure (in that a general solution is NP), You mean NP-_complete_. (Sorting is also NP, but not NP-complete. NP is can be done in polynomial time by a non-deterministic Turing machine, so anything polynomial by a normal machine is also NP. Foo is NP-complete is any NP problem can be polynomially reduced to foo, or in other words, if there is a normal machine that does foo in polynomial time, all NP problems can be done in polynomial time.) -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote: * Anthony Towns: On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote: * Anthony Towns: Moving away from MD5 is certainly not a bad idea, but it's not clear whether the alternatives are any better. Sure, everyone recommends SHA-256 at this stage, but nobody can give a rationale. MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or higher) are significantly harder to break in practice, So? If SHA256 is so much better, why is that nobody can prove it, or at least can provide some evidence which supports that claim? The idea behind using SHA256 (or SHA512) is that we have more _margin_. If we are targeting MD5's design security (2^64 against collisions), even if SHA512 is broken significantly - say an attack four times better than birthday - we still have our expected strength. It is also the best we can get to *right* *now*, unless we escape to humongous hash sizes (arithmetic-based designs). and there's nothing better yet. In terms of security, there are some better hash functions. But those are academic designs, most of them based on big integer arithmetic instead of bit fiddling. Currently, nobody seems to be willing to pay the price that comes with them. What this means is that your hashes will be as big as your asymmetric keys, and hashing as slow as asymmetric cryptography. That's significant. They also seem to have deeply different security properties as far as the user is concerned: the one I know, at least (http://diswww.mit.edu/bloom-picayune/crypto/13190) relies (as asymmetric crypto) on n a hard to factor product of two primes p and q. The security proof under assumption that factoring is hard is that if you generate a collision, you have factored n (roughly). Now, what I don't get is who generates n and thus knows p and q and thus _can_ generate collisions? Does everyone use his own n (and thus everyone can generate collisions for the hash _he_ uses, but not for the hash others use), do we use a trusted third party (that's a _significantly_ different security model!) that publishes n? (When I write n above, I obviously mean the pair (n,g), g element of maximal order in Z/nZ.) -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Saturday 26 November 2005 01:13, Anthony Towns wrote: On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote: * Anthony Towns: (I'm amazed the security crisis we're having is about deb sigs *again*, when we're still relying on md5sum which has a public exploit available now...) These exploits are irrelevant as far as the Debian archive is concerned. (And that's not because hardly any sarge user verifies the MD5 hashes, by the way. 8-) Uh. You're seriously putting your reputation on that claim? And md5 hashes have been verified since either slink or potato depending on when you started using apt; possibly earlier if dselect methods used them like they should have. debootstrap certainly verified them for woody. And heck, they've been used in .changes since day 0. Moving away from MD5 is certainly not a bad idea, but it's not clear whether the alternatives are any better. Sure, everyone recommends SHA-256 at this stage, but nobody can give a rationale. MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or higher) are significantly harder to break in practice, and there's nothing better yet. Even using weak hash sum algorythms you can easily make the hash collider life tremendously difficult by simply having more than one (ok two should be enough) hash sums generated with _different_ (weak?) algorythms on the same entity. Searching for parallel meaningful collisions is despairing job. For example the Release file stores two hash sums for the same entities. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
* Anthony Towns: On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote: * Anthony Towns: (I'm amazed the security crisis we're having is about deb sigs *again*, when we're still relying on md5sum which has a public exploit available now...) These exploits are irrelevant as far as the Debian archive is concerned. (And that's not because hardly any sarge user verifies the MD5 hashes, by the way. 8-) (I meant that the signature on a hash of those hashes is not verified.) Uh. You're seriously putting your reputation on that claim? Yes. To attack the Debian archive, you need to carry out a preimage attack. Nothing in that direction has been published so far. For the exploits we have seen so far to work, the malicious party needs upload access to the archive and has to plant a specially crafted package there, for which they have created an evil twin package. (Same for attacking one of the text files listing hashes.) Looks a bit far-fatched to me. Moving away from MD5 is certainly not a bad idea, but it's not clear whether the alternatives are any better. Sure, everyone recommends SHA-256 at this stage, but nobody can give a rationale. MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or higher) are significantly harder to break in practice, So? If SHA256 is so much better, why is that nobody can prove it, or at least can provide some evidence which supports that claim? The numbers are bigger is the main argument at this point, which is awfully similar to the usual snake-oil arguments (although there is a slight difference, of course). On the other hand, the cost of adding another hash function is not that high for Debian, compared to other deployments. Adding SHA256 and RSHA a few months (hopefully, years) later doesn't really hurt that much, I guess. and there's nothing better yet. In terms of security, there are some better hash functions. But those are academic designs, most of them based on big integer arithmetic instead of bit fiddling. Currently, nobody seems to be willing to pay the price that comes with them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
* Thiemo Seufer: A: Why do you lock your car up[1]? B: Because it looks like having it locked is better then not having it locked. A: Sorry, but that's a snake oil rationale. Anybody can pick the lock and break in. Anybody can smash a window and break in. etc. Wrong, it makes break-ins harder. OTOH we don't put stickers with this car is locked on our cars. Uhm, we do. There are those blinking LEDs which serve exactly that purpose. And yes, those electronic locks have been broken; the only thing that protects them is that it's a crime to tell anyone how they work. At this stage, car locks (especially those of the electronic kind) serve only to show intent. You can't claim that you erroneously drove away in someone else's car. Besides that, they don't really help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Fri, 25 Nov 2005 12:50:41 -0800, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Goswin von Brederlow [EMAIL PROTECTED] writes: The archive signing key gives absolutely no integrity ensurance on the deb package. The only thing it insures is that the file was not altered _after_ leaving ftp.de.debian.org for the mirrors and/or user. In no way does it prevent altering the deb on ftp-master. Isn't that a useful assurance? Perhaps I trust the maintenance of ftp-master, but not the maintenance of Joe Random Mirror. So the natural reaction would be having _both_ signatures so that the individual user can choose whom to trust. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: dpkg-sig support wanted?
Scripsit Peter Samuelson [EMAIL PROTECTED] You may laugh if you wish, but I think it's annoying to have to move to a hash function whose hexadecimal representation takes 64 bytes, which doesn't leave much room on an 80-column line to describe what the hash is hashing. Maybe by the time coreutils ships a sha256sum program, the world will have settled upon BASE64, which requires only 43 bytes. Why wait for the world to settle? Would there be anything wrong with writing a sha256sum program that outputs base64 right now? -- Henning Makholm Lad min høne være. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
* Henning Makholm: Scripsit Peter Samuelson [EMAIL PROTECTED] You may laugh if you wish, but I think it's annoying to have to move to a hash function whose hexadecimal representation takes 64 bytes, which doesn't leave much room on an 80-column line to describe what the hash is hashing. Maybe by the time coreutils ships a sha256sum program, the world will have settled upon BASE64, which requires only 43 bytes. Why wait for the world to settle? Would there be anything wrong with writing a sha256sum program that outputs base64 right now? I wouldn't use real base64, though, because it would mean that you can use its hashed output as a file name. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote: So? If SHA256 is so much better, why is that nobody can prove it, or at least can provide some evidence which supports that claim? The numbers are bigger is the main argument at this point, which is awfully similar to the usual snake-oil arguments (although there is a slight difference, of course). In the world of cryptography, _proving_ security is rather difficult. All you can say is well, nobody have made any real progress towards this yet, and then estimate approximately how much work has actually been done with regard to breaking it. In terms of security, there are some better hash functions. But those are academic designs, most of them based on big integer arithmetic instead of bit fiddling. Currently, nobody seems to be willing to pay the price that comes with them. Well, the number theory-based hashes are interesting, but they haven't been around for a very long time (and aren't widely used yet), so nobody really knows how well they will fare in the long run. The other part of the price is of course speed. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
* Steinar H. Gunderson: On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote: So? If SHA256 is so much better, why is that nobody can prove it, or at least can provide some evidence which supports that claim? The numbers are bigger is the main argument at this point, which is awfully similar to the usual snake-oil arguments (although there is a slight difference, of course). In the world of cryptography, _proving_ security is rather difficult. That's why I wrote some evidence. Things like nobody managed so far to extend attacks A, B, C beyond k rounds are pretty weak. All you can say is well, nobody have made any real progress towards this yet, and then estimate approximately how much work has actually been done with regard to breaking it. There are cryptosystems where attacks (in some well-defined sense, of course) are provably equivalent to some other problem which is believed to be hard (factoring, RSA). However, there are also cryptosystems which were shown to have such properties, but where the proof was wrong. General OAEP was such a case, IIRC. In terms of security, there are some better hash functions. But those are academic designs, most of them based on big integer arithmetic instead of bit fiddling. Currently, nobody seems to be willing to pay the price that comes with them. Well, the number theory-based hashes are interesting, but they haven't been around for a very long time (and aren't widely used yet), so nobody really knows how well they will fare in the long run. Some of these systems have provable security properties, which might increase confidence despite their lack of age. The other part of the price is of course speed. Yes, this is the primary problem, it seems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Scripsit Florian Weimer [EMAIL PROTECTED] * Henning Makholm: Why wait for the world to settle? Would there be anything wrong with writing a sha256sum program that outputs base64 right now? I wouldn't use real base64, though, because it would mean that you can use its hashed output as a file name. Good point. One might replace / with _ and omit the final =. Having a + in the hash should be safe in most contexts. -- Henning Makholm We will discuss your youth another time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
* Henning Makholm: I wouldn't use real base64, though, because it would mean that you can use its hashed output as a file name. Good point. One might replace / with _ and omit the final =. Having a + in the hash should be safe in most contexts. It should be replaced with -. Beyond alphanumerics, only ., _, - are in the POSIX portable filename character set[1], and some systems do not allow the character + in file names. [1] http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
* Adeodato Simó: * Florian Weimer [Thu, 24 Nov 2005 18:28:04 +0100]: Hi, AFAIK, binary NMus aren't announced on debian-devel-changes. Binary-only uploads are announced in the appropriate debian-devel-$ARCH-changes list. According to http://murphy.debian.org/lists/debian-devel-i386-changes/details.html these lists are dead. Or am I missing something?
Re: dpkg-sig support wanted?
Scripsit Florian Weimer [EMAIL PROTECTED] * Henning Makholm: I wouldn't use real base64, though, because it would mean that you can use its hashed output as a file name. Good point. One might replace / with _ and omit the final =. Having a + in the hash should be safe in most contexts. It should be replaced with -. Beyond alphanumerics, only ., _, - are in the POSIX portable filename character set[1], and some systems do not allow the character + in file names. However there are already plenty of files with + in their names involved in Debian (e.g. /usr/lib/libstdc++.so.6). Having every 64th hash-based filename start with - or . would lead to failure modes for shell scripts (mistaking the filename for a command line option, resp. missing it in globs) that are just infrequent enough that they might not be observed before a quick-and-dirty script is deployed. I think the conclusion is that no simple substitution is at the same time Posix friendly and friendly towards quick-and-dirty scripting. (Yes: substitute /+ with _-, and then move the last character of the base64 encoding to the front. Due to zero padding it must come from the set [AEIMQUYcgkosw048].) -- Henning Makholm You want to know where my brain is, spetsnaz girl? Do you? Look behind you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
[George Danchev] Even using weak hash sum algorythms you can easily make the hash collider life tremendously difficult by simply having more than one (ok two should be enough) hash sums generated with _different_ (weak?) algorythms on the same entity. What you have just defined is a new hash algorithm of M+N bits. Why not instead use an existing hash algorithm with M+N bits? If nothing else, the attack is likely to be less parallelizable. signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 11:08:32PM -0600, Peter Samuelson wrote: You may laugh if you wish, but I think it's annoying to have to move to a hash function whose hexadecimal representation takes 64 bytes, which doesn't leave much room on an 80-column line to describe what the hash is hashing. Maybe by the time coreutils ships a sha256sum program, the world will have settled upon BASE64, which requires only 43 bytes. Why should we wait for the rest of the world to settle on a standard? Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote: For the exploits we have seen so far to work, the malicious party needs upload access to the archive and has to plant a specially crafted package there, for which they have created an evil twin package. (Same for attacking one of the text files listing hashes.) Looks a bit far-fatched to me. Not really. Joining Debian isn't particularly difficult, and it might not even be out of the question to find someone who'll sponsor an upload without rebuilding the .deb. I think it's safe to imagine that there are developers right now who've done some shady things in the past; is it that far fetched to imagine it's worth protecting against developers who try to abuse their priveleges? The way we do that has to be mostly after the fact, of course: someone uploads a bad package, people find out it's bad, we trace it back to whoever uploaded it, then we kick them out of the project. But that only works if the bad package is actually discovered. If the .deb's distributed across hundreds of mirrors and to thousands of users, it's reasonably likely that it will be discovered; but if it's possible to target the attack against an individual user, and leave the rest of the Debian universe untouched, you've got a much better chance of not getting caught. Hence: distribute an iced .deb in the archive, that does no harm ever and thus needn't arouse any suspicion; and sneak a fire .deb that has the exploit activated onto the mirror of your target. Looks a bit far-fetched comes under the famous last words heading for security analysis. Worse, the existance of a practical md5(A+B+C)=md5(A+D+C) attack means that it's not out of the question that there're md5(A+B)=md5(C+D) attacks in the hands of particularly well resourced groups (which is worse, since the version uploaded to the archive could then be entirely innocent looking). Personally, I don't have any interest in making the NSA's job any easier, or that of other signals intelligence groups. Moving away from MD5 is certainly not a bad idea, but it's not clear whether the alternatives are any better. Sure, everyone recommends SHA-256 at this stage, but nobody can give a rationale. MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or higher) are significantly harder to break in practice, So? If SHA256 is so much better, why is that nobody can prove it, or at least can provide some evidence which supports that claim? The numbers are bigger is the main argument at this point, which is awfully similar to the usual snake-oil arguments (although there is a slight difference, of course). SHA256 is better than SHA1 in the same way 2048 bit RSA keys are better than 512 bit RSA keys. MD5 is broken, and isn't extensible. SHA1 is fragile, but not broken, and is extensible. Do you have other suggestions? and there's nothing better yet. In terms of security, there are some better hash functions. My understanding was that there aren't other hash functions that've had remotely similar levels of cryptographic analysis to md5 and sha. IIRC, the elliptic curve cryptography stuff was supposed to be similarly neat, until people started analysing it seriously, at which point it broke. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
[Florian Weimer]
It should be replaced with -. Beyond alphanumerics, only .,
_, - are in the POSIX portable filename character set[1], and
some systems do not allow the character + in file names.
[Henning Makholm]
However there are already plenty of files with + in their names
involved in Debian (e.g. /usr/lib/libstdc++.so.6).
Well, if we're trying to drive a standard representation, there will be
people outside Debian who will care about POSIX filename characters.
Having every 64th hash-based filename start with - or . would
lead to failure modes for shell scripts
True.
(Yes: substitute /+ with _-, and then move the last character of the
base64 encoding to the front. Due to zero padding it must come from
the set [AEIMQUYcgkosw048].)
Or: substitute /+ with _- and then add a short prefix like s- to
denote the hash type, in case other 256-bit hashes become popular. I
guess we didn't really have that problem with 128-bit and 160-bit
checksums, but we could've.
sha256sum () {
local f;
if [ $# = 0 ]; then
openssl dgst -sha256 -binary | base64-encode |
sed 'y|/+|_-|; s|^|s-|; s|=|\t-|'
else for f; do
echo s-$(openssl dgst -sha256 -binary $f | base64-encode |
sed 'y|/+|_-|; s|=|\t|')$f
done; fi
}
(Implementation of -c left as an exercise, etc.)
signature.asc
Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote: That's easy: you trust the Packages file to be correct when using apt, and it's not verified at all by per-package signatures. In what way trust and how does that change anything? At best you can prevent a newer version of a package to appear in the Packages file by compromising it. You can't subvert a package itself. But you can already ship yesterdays Release.gpg, Release and Packages file to a user and thereby prevent any updates. On the other hand, without package signatures ftp-master adds a vulnerability. You can hack into it, replace debs, recreate the Packages, Release and Release.gpg file and thereby infect users. With signed debs that could still be detected by every user in apt-get. Only if every user is in a position to verify signatures from each Debian developer individually, which is completely unrealistic. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Wed, Nov 23, 2005 at 05:34:41PM +0100, Jeroen van Wolffelaar wrote: In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There are 8 distinct keys used for those 525 .deb's, seven of which correspond to DD's[1]. Slightly off the topic, but does this mean the archive contains .debs not build by Debian developers? Shouldn't sponsors be recompiling packages from non-DDs before upload? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
* Hamish Moffatt [Fri, 25 Nov 2005 20:34:02 +1100]: On Wed, Nov 23, 2005 at 05:34:41PM +0100, Jeroen van Wolffelaar wrote: In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There are 8 distinct keys used for those 525 .deb's, seven of which correspond to DD's[1]. Slightly off the topic, but does this mean the archive contains .debs not build by Debian developers? Shouldn't sponsors be recompiling packages from non-DDs before upload? I was suspicious too, but it was later checked on irc that all keys actually belonged to a DD. (One of them was not in public keyservers, AIUI, and Jeroen assumed it was not a DD, or something similar.) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A lie can go round the world before the truth has got its boots on. -- Terry Pratchett -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Hi, Anthony Towns wrote: The problem is that using gzip and ar is complicated, which adds possibilities for errors. You might find yourself not putting the deb together again and getting false signature mismatches, or worse, you might find yourself only verifying part of the .deb, and having dpkg actually use parts of the .deb that haven't been authenticated under the false conviction that you're actually safe. With md5sum foo.deb you know you've authenticated everything. Which is also a disadvantage in some cases. I could see a case for extending .deb files (say, with additional translations for the description and templates, thus removing the need for the maintainer to reupload new packages when new translations are ready). I think that it should be fairly easy to implement something that can verify parts of .deb files and check whether the authenticated parts together form a complete and consistent package on their own. This thread, however, is not about a technical problem, so I would propose a sauna meeting. IF this means we can switch the effort to a detached signature that is more powerful than a .changes file (or we are allowed to have multiple signatures in a .changes file), That is already possible with gnupg, just not well-documented; I'm not entirely sure what interesting breakage would occur if one were to upload a changes file with multiple signatures. and also that the .changes file will be stored in the archives along with the .debs, As it turns out, that's probably not feasible per se -- it likely implies too much inode usage, and slack space. And is probably pointless. If you don't trust the Debian infrastructure, you are free to get the source (which is signed by the maintainer) and build the package yourself. where dpkg would simply refuse per user-set policy any non-signed deb or any deb without a specific signature... I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting a signature by a random Debian developer to mean something is not reasonable. That's why there can be multiple signatures. There would be one from the maintainer/buildd, a few from the Debian archive (for example, you could add one sig for officially in Debian unstable, one for migrated to testing and one for in a stable release) and if the idea of adding description/template translations later on catches on, also some from the translators/translation system. Simon signature.asc Description: OpenPGP digital signature
Re: dpkg-sig support wanted?
Anthony Towns aj@azure.humbug.org.au writes: On Thu, Nov 24, 2005 at 06:28:04PM +0100, Florian Weimer wrote: If you just want to check hashes, you should just use changes files. If you _actually_ want to check hashes, and this isn't just a thought experiment, working out a usable way to deliver .changes for whatever purpose you've got in mind would be a good idea. (Again though, I don't see a point to them, beyond reverification of the archive in the event of an exploit. Of course, maybe that's what you want to do...) We have a perfectly useable and trivial way to deliver the hashes, which is the intresting part of the changes file for security. It is the signature in the deb. For comparison: Why do we have a signature in dsc files? From your arguments that signature is completly useless since changes files already provide all that is needed. We still sign dsc files because it is just that much easier to apt-get source foo and verify it. And that is a good thing. Why are you so set in stone against allowing the same for debs? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Steve Langasek [EMAIL PROTECTED] writes: On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote: That's easy: you trust the Packages file to be correct when using apt, and it's not verified at all by per-package signatures. In what way trust and how does that change anything? At best you can prevent a newer version of a package to appear in the Packages file by compromising it. You can't subvert a package itself. But you can already ship yesterdays Release.gpg, Release and Packages file to a user and thereby prevent any updates. On the other hand, without package signatures ftp-master adds a vulnerability. You can hack into it, replace debs, recreate the Packages, Release and Release.gpg file and thereby infect users. With signed debs that could still be detected by every user in apt-get. Only if every user is in a position to verify signatures from each Debian developer individually, which is completely unrealistic. Up to a point you can trust the keyring. As much as you can trust any DD signature. You try to argue that signatures are not absolutely trustworthy but that is nothing new. Nothing you can do will change that. What you fail to see (or say) is that all the security Debian already has is weak in exactly the same way. The difference to signed debs is the transparency and triviality to check. Even if that check has to use a 5 hop trust path to some DD you never met. Also for !i386 !ppc basicaly all packages are autobuild and will be signed by a handfull of people. You can go and meet them easily enough. Further, with signed debs, you could only allow installation of debs from people you trust and recompile all the rest after a source audit. If you are that paranoid. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Anthony Towns aj@azure.humbug.org.au writes: On Thu, Nov 24, 2005 at 07:47:58PM +0100, Goswin von Brederlow wrote: Anthony Towns aj@azure.humbug.org.au writes: On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote: Use 1: I have this deb in my apt-move mirror and I want to know if it was compromised on yesterdays breakin Boot a clean system with debian keyring and check all deb signatures. Find some don't pass because they were signed with keys that have been removed from the keyring. Those I remove and refetch from a clean source again. False negatives are no big deal. 99% of the debs will verify leaving only a managable amount of wokr behind. The clean source that's signed by the same key that you can't verify? If I can't find any verifiable source then the package can't be trusted and can be removed till that is changed. Still much better than having 100% untrustworthy packages. Ah, I see the light. Signatures are useless because packages have no signatures. That's a transitional problem, yes. In this case it's a severe one; since there are up to 150GBs worth of .debs. It's a problem that could be solved if it were worthwhile, but it's not worthwhile since .changes already do everything deb sigs could do without any transition issues, and it's not something that can be simply ignored. Cheers, aj By the way, this is trivial to work around: 1) archive the Release.gpg, Release and Packages file from today 2) only allow signed debs from now on From then on all debs can be verified. I say the transition can be simply ignored (for now). The problem will fix itself in due time when signed debs become more popular and debsign automatically adds them. At some point in the future the majority of debs will be signed and then a transition can be force by scheduling a binNMU for any remaining deb. But first there must be an official debs may be signed before anyone can think about a debs MUST be signed. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: On Thu, 24 Nov 2005, Anthony Towns wrote: On Thu, Nov 24, 2005 at 07:39:57AM +0100, Marc Haber wrote: Uh, packages not uploaded to the official Debian archive can do whatever they want. It would, however, be convenient to be able to upload a package to Debian and to be able to use the same package for different things. As far as dpkg-sign's concerned, can't you already do that by building the package, uploading it to debian, then running dpkg-sign? At worst you'd have to run dpkg-genchanges again before uploading to your other suite, afaics. You're correct. And he is also wrong. That would result in debs with the same name and version but different md5sums. Something that easily confuses apt-get and people. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Simon Richter [EMAIL PROTECTED] writes: IF this means we can switch the effort to a detached signature that is more powerful than a .changes file (or we are allowed to have multiple signatures in a .changes file), That is already possible with gnupg, just not well-documented; I'm not entirely sure what interesting breakage would occur if one were to upload a changes file with multiple signatures. It gives a parse error and the DAK rejects the file. where dpkg would simply refuse per user-set policy any non-signed deb or any deb without a specific signature... I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting a signature by a random Debian developer to mean something is not reasonable. A signature in the deb by a random developer is as trustworthy as the changes file and you already trust that. So we are going from snakeoil to snakoil. No harm done. That's why there can be multiple signatures. There would be one from the maintainer/buildd, a few from the Debian archive (for example, you could add one sig for officially in Debian unstable, one for migrated to testing and one for in a stable release) and if the idea of adding description/template translations later on catches on, also some from the translators/translation system. Although that would alter the packages md5sum and even alter a package while still being in a distribution (the unstable deb would suddenly gain a signature). It would be a big change to allow this. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 03:22:37PM +0100, Goswin von Brederlow wrote: A signature in the deb by a random developer is as trustworthy as the changes file and you already trust that. So we are going from snakeoil to snakoil. No harm done. It's not the same, actually. A signature in a .deb needs to be made by a key which is still trustworthy at the time of verification, which could be quite some time in the future. The key which makes a .changes signature, in contrast, only *needs* to be valid at the time the upload is made -- if it is later compromised, it's not important, because by that time the archive signing key hsa taken over the role of integrity verification. Of course, using the signature on the .changes to verify the .debs independent from the archive at some later date is a nice side-benefit, but one which suffers from the same key-lifetime issues as in-deb signatures, and since the .changes from autobuilt uploads aren't publically available (apparently d-d-$arch-changes isn't archived, from info previously posted in this thread) that method of package authentication isn't going to be 100% reliable anyway. - Matt signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On 11/25/05, Matthew Palmer [EMAIL PROTECTED] wrote: Of course, using the signature on the .changes to verify the .debs independent from the archive at some later date is a nice side-benefit, but one which suffers from the same key-lifetime issues as in-deb signatures, What exactly is this key lifetime issue? Is it a cryptographic issue? and since the .changes from autobuilt uploads aren't publically available (apparently d-d-$arch-changes isn't archived, from info previously posted in this thread) that method of package authentication isn't going to be 100% reliable anyway.
Re: dpkg-sig support wanted?
Matthew Palmer [EMAIL PROTECTED] writes: On Fri, Nov 25, 2005 at 03:22:37PM +0100, Goswin von Brederlow wrote: A signature in the deb by a random developer is as trustworthy as the changes file and you already trust that. So we are going from snakeoil to snakoil. No harm done. It's not the same, actually. A signature in a .deb needs to be made by a key which is still trustworthy at the time of verification, which could be quite some time in the future. The key which makes a .changes signature, in contrast, only *needs* to be valid at the time the upload is made -- if it is later compromised, it's not important, because by that time the archive signing key hsa taken over the role of integrity verification. And there you have the big misconception. The archive signing key gives absolutely no integrity ensurance on the deb package. The only thing it insures is that the file was not altered _after_ leaving ftp.de.debian.org for the mirrors and/or user. In no way does it prevent altering the deb on ftp-master. The chain of trust from the DD to the enduser is broken at that point when the chnages file disapears into a non public place and the Release.gpg takes over. Even worse the Release.gpg is signed with an automatic key which I trust way less than a DDs key. Of course, using the signature on the .changes to verify the .debs independent from the archive at some later date is a nice side-benefit, but one which suffers from the same key-lifetime issues as in-deb signatures, and since the .changes from autobuilt uploads aren't publically available (apparently d-d-$arch-changes isn't archived, from info previously posted in this thread) that method of package authentication isn't going to be 100% reliable anyway. - Matt The key-lifetime issue, as you say, is already there for the changes files. It also already there for the dsc files. The deb signatures don't change a thing there. What they change is the availability of the signature. And that they change to 100% for every signed deb (and we hope all debs gets igned at some point). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Olaf van der Spek [EMAIL PROTECTED] writes: On 11/25/05, Matthew Palmer [EMAIL PROTECTED] wrote: Of course, using the signature on the .changes to verify the .debs independent from the archive at some later date is a nice side-benefit, but one which suffers from the same key-lifetime issues as in-deb signatures, What exactly is this key lifetime issue? Is it a cryptographic issue? A key can expire, get stolen / lost or get compromised and revoced. Once that happens you can't trust any signature made by that key. Although one can probably argue that an expired key still has enough trust to verify old debs. Many people don't set an expiry date anyway. While this sounds like a big problem lets have some numbers: Shortly before the sarge release we imported all source packages into the debian-amd64 DAK and actualy did have the problem with dsc file signatures. But that was a problem of maybe 20 packages (out of over 8000). Overall a miniscule problem. If I can verify all but 20 packages that realy is a great bonus. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Fri, 25 Nov 2005, Anthony Towns wrote: (I'm amazed the security crisis we're having is about deb sigs *again*, when we're still relying on md5sum which has a public exploit available now...) Do you really want a thread about how we should switch everything to SHA-512 or something like that? Huh? Why do you want multiple signatures of a .changes file? If I am to do with a .changes file everything I can do with the in-deb signatures, it needs to support at least nested signatures. and also that the .changes file will be stored in the archives along with the .debs, As it turns out, that's probably not feasible per se -- it likely implies too much inode usage, and slack space. That speaks for in-deb signatures in the usability department. and that .debs with wrong/incomplete/missing Source: fields will be rejected (such as all automated bin-NMUed .debs made until about a week ago, or any made by a maintainer right now), Huh? I don't think #62529 is fixed yet. If you think you'll have better luck at doing so, be my guest. That's not a prerequisite for verifying packages from changes files though. Well, the email about the new bin-NMU structure implied that it was fixed for *NMUs done through that structure*. I very much doubt we can produce bin NMUs in our systems with the proper Source header without taking very special steps. My objection is that it's *useless* for *Debian*. Debian has too many sources for packages for key management to be plausible, and keeps This applies to .changes files too, with the aggravating addition that those are a bitch to find right now. Uh, no, .changes files are not remotely useless for Debian right now. Where would you get that idea? I was refering to Debian has too many sources for packages for key management to be plausible. Duh, obviously .change files are useful for Debian, DAK needs them. The tools are the least concern; what's a few dozen lines of code here and there matter? If you insist every package only be uploaded once, and do the maximum packages per day, and stop all other development just to get deb sigs done, it's roughly half a year before that's finished. New packages, bug fixes, new upstream versions will make it take longer. Who said anything about adding in-deb sigs to the entire archive? where dpkg would simply refuse per user-set policy any non-signed deb or any deb without a specific signature... I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting I see I have to spell it out completely all the time, for you will always assume you are talking to clueless people who either doesn't know anything about the issue at hand, or who will be impressed by your over-use of snake-oil. If I want dpkg to always check a signature, it is because it is a signature I know must be there. Like an hypothetical signature added by DAK/dinstall/whatever, or a signature I add to all debs in a specific repository under my control (and in this case, with a timestamp under my own control too, which means I can use it). Doing so with signed release files is possible, but not always in the same way and under the same conditions, and it requires a lot of fragile infrastructure which would be less fragile using in-deb signatures. a signature by a random Debian developer to mean something is not reasonable. YOU are the one who is bringing in signatures from j.random developer. Which, I should add, is all we have in .changes files. Release files are something else, though. I'm tempted to do something like that anyway to see if the md5sum exploit can be used to create fire and ice .debs. Without signed debs, Make that an exploit that says kaboom, you're it but still runs dpkg, and I will help you with it. you'll have no reason to trust it, which is exactly right; with signed debs, you'll have reason to know I built it, but you won't have reason to know I was never going to upload it to Debian because I was just experimenting with some possible security vectors. The question is, will you make the unwarranted assumption that because it's been built by me, that it's usable my you? I won't, that's for sure. I might trust such a deb because it was in a archive where you place debs for general use or something else like that, but not because you signed it. The explanation you need is ...which is useful because _. Again, I can't see any need for multiple signatures for Debian; for non-Debian, if deb sigs are convenient, use them. deb sigs get a lot less convenient if Debian doesn't allow them in debs uploaded to the archive. I don't really care if Debian will ever use the in-deb signatures somehow or not, but I'd like to see them allowed into the archive. -- 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
Re: dpkg-sig support wanted?
* Anthony Towns: (I'm amazed the security crisis we're having is about deb sigs *again*, when we're still relying on md5sum which has a public exploit available now...) These exploits are irrelevant as far as the Debian archive is concerned. (And that's not because hardly any sarge user verifies the MD5 hashes, by the way. 8-) Moving away from MD5 is certainly not a bad idea, but it's not clear whether the alternatives are any better. Sure, everyone recommends SHA-256 at this stage, but nobody can give a rationale. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Anthony Towns aj@azure.humbug.org.au writes: .deb signatures are aimed at giving users some sort of assurance the package is valid; but when you actually look into it -- at least in Debian's circumstances -- those signatures can't actually give any meaningful assurance for any specific validity. Don't they give the user the assurance that a Debian developer was responsible for building and providing the package? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Goswin von Brederlow [EMAIL PROTECTED] writes: The archive signing key gives absolutely no integrity ensurance on the deb package. The only thing it insures is that the file was not altered _after_ leaving ftp.de.debian.org for the mirrors and/or user. In no way does it prevent altering the deb on ftp-master. Isn't that a useful assurance? Perhaps I trust the maintenance of ftp-master, but not the maintenance of Joe Random Mirror. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 03:13:58PM +0100, Goswin von Brederlow wrote: You're correct. And he is also wrong. That would result in debs with the same name and version but different md5sums. Something that easily confuses apt-get and people. And yet, somehow people manage partial cross-grades between Debian and Ubuntu... Regards, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 12:49:11PM -0800, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: .deb signatures are aimed at giving users some sort of assurance the package is valid; but when you actually look into it -- at least in Debian's circumstances -- those signatures can't actually give any meaningful assurance for any specific validity. Don't they give the user the assurance that a Debian developer was responsible for building and providing the package? Not really, they give the assurance that it was built by someone who at some point possessed a key that at some point was considered sufficient to identify a Debian developer or a buildd. What assurance would you take from a package signed by Chip's old key? (And why do you think it's actually helpful? Debian developers build *lots* of crap, especially if you can't differentiate stuff uploaded to Debian and not) Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 02:27:23PM -0200, Henrique de Moraes Holschuh wrote: Well, the email about the new bin-NMU structure implied that it was fixed for *NMUs done through that structure*. Then the email was wrong. *shrug* My objection is that it's *useless* for *Debian*. Debian has too many sources for packages for key management to be plausible, and keeps This applies to .changes files too, with the aggravating addition that those are a bitch to find right now. Uh, no, .changes files are not remotely useless for Debian right now. Where would you get that idea? I was refering to Debian has too many sources for packages for key management to be plausible. Duh, obviously .change files are useful for Debian, DAK needs them. Then my comment doesn't appl[y] to .changes files too. The tools are the least concern; what's a few dozen lines of code here and there matter? If you insist every package only be uploaded once, and do the maximum packages per day, and stop all other development just to get deb sigs done, it's roughly half a year before that's finished. New packages, bug fixes, new upstream versions will make it take longer. Who said anything about adding in-deb sigs to the entire archive? If they provide a useful service, then of course they should be everywhere. If they don't provide a useful service, why should they be anywhere? The dak check, for reference, is the one that authenticates an ar's in the correct form, it's not an explicit we had dpkg-sig check. If I want dpkg to always check a signature, it is because it is a signature I know must be there. Like an hypothetical signature added by DAK/dinstall/whatever, or a signature I add to all debs in a specific repository under my control (and in this case, with a timestamp under my own control too, which means I can use it). Again, what you do in your own repositories is _fine_. .deb signatures are a completely useful thing to do in some circumstances; which I'm inclined to classify as private development / public release. Debian just happens not to be in that problem space. a signature by a random Debian developer to mean something is not reasonable. YOU are the one who is bringing in signatures from j.random developer. Uh, no, it's what this thread's about. You know, random developers uploading signed packages to the archive...? I'm tempted to do something like that anyway to see if the md5sum exploit can be used to create fire and ice .debs. Without signed debs, Make that an exploit that says kaboom, you're it but still runs dpkg, and I will help you with it. ATM I've got better things to do. But xmas is coming up, with the corresponding need for a pointless xmas project... The explanation you need is ...which is useful because _. Again, I can't see any need for multiple signatures for Debian; for non-Debian, if deb sigs are convenient, use them. deb sigs get a lot less convenient if Debian doesn't allow them in debs uploaded to the archive. How so? Seriously -- add the signature after uploading to Debian. At worst, if you have a deb that's in both Debian and some other source, you might end up installing the unsigned .deb from Debian instead of the signed version -- but you've still verified it just like every other Debian package, so... big deal? If you set up apt's pinning correctly, that won't even happen. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote: * Anthony Towns: (I'm amazed the security crisis we're having is about deb sigs *again*, when we're still relying on md5sum which has a public exploit available now...) These exploits are irrelevant as far as the Debian archive is concerned. (And that's not because hardly any sarge user verifies the MD5 hashes, by the way. 8-) Uh. You're seriously putting your reputation on that claim? And md5 hashes have been verified since either slink or potato depending on when you started using apt; possibly earlier if dselect methods used them like they should have. debootstrap certainly verified them for woody. And heck, they've been used in .changes since day 0. Moving away from MD5 is certainly not a bad idea, but it's not clear whether the alternatives are any better. Sure, everyone recommends SHA-256 at this stage, but nobody can give a rationale. MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or higher) are significantly harder to break in practice, and there's nothing better yet. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Sat, Nov 26, 2005 at 08:48:45AM +1000, Anthony Towns wrote: On Fri, Nov 25, 2005 at 03:13:58PM +0100, Goswin von Brederlow wrote: You're correct. And he is also wrong. That would result in debs with the same name and version but different md5sums. Something that easily confuses apt-get and people. And yet, somehow people manage partial cross-grades between Debian and Ubuntu... People manage to do it, but it really isn't a good idea at all to mix repositories which contain different builds of the same source packages. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Sat, Nov 26, 2005 at 09:13:02AM +1000, Anthony Towns wrote: Moving away from MD5 is certainly not a bad idea, but it's not clear whether the alternatives are any better. Sure, everyone recommends SHA-256 at this stage, but nobody can give a rationale. MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or higher) are significantly harder to break in practice, and there's nothing better yet. Just a comment here for those who are not used to hash functions: Broken here means that you can generate collisions faster than using the birthday attack (2^64 for MD5, 2^80 for SHA-1). It does not have to mean that you can do _really_ evil stuff, like generate a second file with the same MD5 hash as a given file (so-called second preimage, IIRC) and to the best of my knowledge, nobody has done so yet). However, there's a long way from you can't generate a valid .deb with a given md5sum easily to SHA-256 is no better than MD5. You can generate an MD5 collision in four hours on a standard desktop computer today; you're nowhere near that for SHA-1, and SHA-256 is still AFAIK not broken (although it relies on the same basic structure as MD5 and SHA-1). All three might eventually be truly broken, but you can bet that MD5 will be the first to go. If you use SHA-256 today instead of MD5, you probably buy yourself a few extra years, which you can use to smooth out the transition to the next hash function when the world advances. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Thiemo == Thiemo Seufer [EMAIL PROTECTED] writes: Well, even if I know naught about it, it looks to me that having something signed is better than having the same something not signed. Thiemo Sorry, but that's a snake oil rationale. A: Why do you lock your car up[1]? B: Because it looks like having it locked is better then not having it locked. A: Sorry, but that's a snake oil rationale. Anybody can pick the lock and break in. Anybody can smash a window and break in. etc. However, we still lock our cars regardless. We still lock our houses. We still use signatures and ID cards (all of which can be forged) as protection to keep our money safe. The reason why? Because we have just made it more difficult (or so we hope!) for somebody to break in. We still consider this a worth while compared with the added inconvenience of having to maintain the additional security (e.g. keep the key safe and not lost). Despite the fact we all know it is not absolute security. It is also feasible. Yes, you could hire a security guard to watch your car 24 hours a day, but that is likely to cost more then the car is worth. Most people don't consider their cars to be this important. I think the same thing applies here - sure somebody could interfere with the system and either steal the private key or get a package signed that shouldn't be signed, but if you really want to argue along these lines, I think we remove all signatures everywhere, because the possibility exists any one of these could be forged (especially as Debian cannot guarantee that every maintainer keeps their private key secure, and that their build systems are secure, etc). So just saying its snake oil isn't really saying anything IMHO, because taken to an extreme all security we have in this world *is* snake oil. Sometimes it works. Sometimes it doesn't work. That doesn't mean we shouldn't try to improve it as much as possible. The only exception I would make is when improvements mean extra security for political/red tape reasons which do nothing to stop the weaknesses they are meant to stop, but instead serve to make our politicians looks good as well as giving them more income. However, I think the ability to trace a Debian binary package to its source, even if the original .changes file is no longer available, is a definite advantage, and is not any less reliable or secure then using the original .changes file for the same purpose. In fact, you could argue it is more secure then the Received headers everyone relies on to trace SPAM (which have no cryptographic signature). I also believe that the threat of somebody being tricked into installing a Trojan package is a very real possibility, and we should do everything we can do to aid our users prevent this from happening. Notes: [1] Assuming you have a car, if not replace the words car and lock with something more appropriate. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Sat, Nov 26, 2005 at 10:47:57AM +1100, Brian May wrote: Well, even if I know naught about it, it looks to me that having something signed is better than having the same something not signed. Sorry, but that's a snake oil rationale. A: Why do you lock your car up[1]? Because it makes it harder to steal the car. I think the point was that signing a .deb did not automatically make it harder to do whatever the scenario asked for. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 02:57:36PM +0100, Goswin von Brederlow wrote: Steve Langasek [EMAIL PROTECTED] writes: On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote: That's easy: you trust the Packages file to be correct when using apt, and it's not verified at all by per-package signatures. In what way trust and how does that change anything? At best you can prevent a newer version of a package to appear in the Packages file by compromising it. You can't subvert a package itself. But you can already ship yesterdays Release.gpg, Release and Packages file to a user and thereby prevent any updates. On the other hand, without package signatures ftp-master adds a vulnerability. You can hack into it, replace debs, recreate the Packages, Release and Release.gpg file and thereby infect users. With signed debs that could still be detected by every user in apt-get. Only if every user is in a position to verify signatures from each Debian developer individually, which is completely unrealistic. Up to a point you can trust the keyring. As much as you can trust any DD signature. You try to argue that signatures are not absolutely trustworthy but that is nothing new. I'm arguing that a 5-hop-long signature chain to establish the validity of a Debian package is as good as useless, and worse if the user doesn't understand this. And a 5-hop-long signature chain does *not* mean that anyone in that chain trusts the person holding the key on the end to upload packages to Debian. The only thing we have that establishes *that* is the presence of the user's key in the Debian keyring, so then you have the logistical problem of how arbitrary users are supposed to verify whether a given key is in the keyring. The debian-keyring package doesn't get updated every time there's a key added or removed, and the web interface to keyring.debian.org doesn't provide any cryptographic assurances. Oh, and BTW, check the IPs of ftp-master.debian.org and keyring.debian.org... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
up-to-date debian keyring with rsync (Re: dpkg-sig support wanted?)
* Steve Langasek [Fri, 25 Nov 2005 17:19:01 -0800]: how arbitrary users are supposed to verify whether a given key is in the keyring. The debian-keyring package doesn't get updated every time there's a key added or removed, and the web interface to keyring.debian.org doesn't provide any cryptographic assurances. Just as a side note other developers may be interested in knowing, the debian keyring can be synced via rsync. I personally like having a mostly-up-to-date copy of it in my computer. % cat /etc/cron.weekly/LOCAL-update-keyring #! /bin/sh -e cd /var/local/keyring rsync -rlptDq rsync://keyring.debian.org/keyrings/ . -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Elton John - Too many tears -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Brian May wrote: Thiemo == Thiemo Seufer [EMAIL PROTECTED] writes: Well, even if I know naught about it, it looks to me that having something signed is better than having the same something not signed. Thiemo Sorry, but that's a snake oil rationale. A: Why do you lock your car up[1]? B: Because it looks like having it locked is better then not having it locked. A: Sorry, but that's a snake oil rationale. Anybody can pick the lock and break in. Anybody can smash a window and break in. etc. Wrong, it makes break-ins harder. OTOH we don't put stickers with this car is locked on our cars. The quote above suggested a signed package is somehow better than an unsigned one, even when no improvements can be shown. But the only thing it reliably achieves in that case is to increase the exposure of the signing key. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 05:19:01PM -0800, Steve Langasek wrote: Oh, and BTW, check the IPs of ftp-master.debian.org and keyring.debian.org... Well, at this moment those are distinct, because ftp-master is temporarily hosted on spohr.debian.org, and not on raff.debian.org, where keyring.d.o still is. But yes, they used to be the same and will again become the same. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
[Steinar H. Gunderson] All three might eventually be truly broken, but you can bet that MD5 will be the first to go. If you use SHA-256 today instead of MD5, you probably buy yourself a few extra years, which you can use to smooth out the transition to the next hash function when the world advances. You may laugh if you wish, but I think it's annoying to have to move to a hash function whose hexadecimal representation takes 64 bytes, which doesn't leave much room on an 80-column line to describe what the hash is hashing. Maybe by the time coreutils ships a sha256sum program, the world will have settled upon BASE64, which requires only 43 bytes. signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 12:56:15AM +0100, Marc 'HE' Brockschmidt wrote: I will fill a whishlist bugreport against debuild to support dpkg-sig side by side with debuild. There is already #247825. #247824 is the wishlist bug for dpkg-buildpackage support. Indeed, I spotted them just after the post. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Hasler [EMAIL PROTECTED] writes: Marc Haber writes: So, most of the DD's do not care about security at all. I think that DD's do not use dpkg-sig and debsigs because they believe them to be hard to use and not supported by the infrastructure or by policy. ACK. I certainly care about security, and I'll sign my packages just as soon as debsign supports it. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDhZtKVcFcaSW/uEgRAp4CAJ93sOae+cyRL9KsTgrIYkme1vHjOwCfXZ4N zmom+bKRm2tMU16IklDxSNk= =seoz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Thu, 24 Nov 2005 10:51:55 +, Roger Leigh [EMAIL PROTECTED] wrote: John Hasler [EMAIL PROTECTED] writes: Marc Haber writes: So, most of the DD's do not care about security at all. I think that DD's do not use dpkg-sig and debsigs because they believe them to be hard to use and not supported by the infrastructure or by policy. ACK. I certainly care about security, and I'll sign my packages just as soon as debsign supports it. So you wouldn't use dpkg-sig even if it were still supported by the archive? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: dpkg-sig support wanted?
Marc Haber [EMAIL PROTECTED] wrote: On Thu, 24 Nov 2005 10:51:55 +, Roger Leigh [EMAIL PROTECTED] wrote: John Hasler [EMAIL PROTECTED] writes: Marc Haber writes: So, most of the DD's do not care about security at all. I think that DD's do not use dpkg-sig and debsigs because they believe them to be hard to use and not supported by the infrastructure or by policy. ACK. I certainly care about security, and I'll sign my packages just as soon as debsign supports it. So you wouldn't use dpkg-sig even if it were still supported by the archive? I think these are bogus questions. I am a complete non-expert in these security things. I am sure that if the project comes to the conclusion that signing debs is a good thing, more people will do it irrespective of how convenient the procedure is in the beginning. If it finds its way into the Developer's Reference, even more will use it (and start integrating it into debsign or whatever). To me, it's not a question of whether it's easy to use, but rather whether I can be convinced that it is worth it. So far, I could not draw any conclusion from this discussion - both the counter and the pro arguments contain some truth, and uneducated as I am I cannot judge at the moment. However, if there was no technical reason to reject signed binary packages, it seems to me as if making that change to DAK is an abuse of ftpmaster's powers: This is a design decision, and it should be made after thorough public discussion, either by finding a consensus or by using our constitutional means of making a decision. Changes should not be made in advance, except if there is an unrelated technical reason (I don't know whether this is the case). Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 02:11:45PM +1100, Matthew Palmer wrote: On Thu, Nov 24, 2005 at 11:54:33AM +1000, Anthony Towns wrote: On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote: On Thu, 24 Nov 2005, Anthony Towns wrote: Personally, I think it's cryptographic snake oil, at least in so far A signed deb has a seal of procedence and allows one to track the path it made through the system, and who changed it. That's what the .changes file is for. Only possible if the .changes file is still accessable, and going through the d-d-c archives isn't exactly convenient. On that score, the description for d-d-c says that it includes buildd logs, Then that description is wrong. It never did include buildd logs, and AFAIK, there are no plans to that effect, either. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Thursday, November 24, 2005 11:17 AM, Wouter Verhelst [EMAIL PROTECTED] wrote: On Thu, Nov 24, 2005 at 02:11:45PM +1100, Matthew Palmer wrote: [...] On that score, the description for d-d-c says that it includes buildd logs, Then that description is wrong. It never did include buildd logs, and AFAIK, there are no plans to that effect, either. It doesn't say that. It says: Notices about uploaded packages for the unstable distribution, from developers, buildds and katie, the archive sentinel. i.e. the only e-mails from buildds involved are notices about uploaded packages, not logs. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 11:38:45AM -, Adam D. Barratt wrote: On Thursday, November 24, 2005 11:17 AM, Wouter Verhelst [EMAIL PROTECTED] wrote: On Thu, Nov 24, 2005 at 02:11:45PM +1100, Matthew Palmer wrote: [...] On that score, the description for d-d-c says that it includes buildd logs, Then that description is wrong. It never did include buildd logs, and AFAIK, there are no plans to that effect, either. It doesn't say that. It says: Notices about uploaded packages for the unstable distribution, from developers, buildds and katie, the archive sentinel. i.e. the only e-mails from buildds involved are notices about uploaded packages, not logs. Sorry, that was a massive typo on my part. I thought buildd output, and wrote buildd logs when I meant buildd .changes files. My question, as amended, though, still holds -- are the .changes associated with the upload of autobuilt packages supposed to go to d-d-c, and if so, are they there and I'm just not seeing them in the list archive? - Matt signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
* Matthew Palmer [Thu, 24 Nov 2005 22:54:58 +1100]: Sorry, that was a massive typo on my part. I thought buildd output, and wrote buildd logs when I meant buildd .changes files. My question, as amended, though, still holds -- are the .changes associated with the upload of autobuilt packages supposed to go to d-d-c, and if so, are they there and I'm just not seeing them in the list archive? They go to the respective debian-devel-$ARCH-changes list, none of which is archived AIUI. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org You cannot achieve the impossible without attempting the absurd. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Thu, 24 Nov 2005, Anthony Towns wrote: On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote: On Thu, 24 Nov 2005, Anthony Towns wrote: Personally, I think it's cryptographic snake oil, at least in so far A signed deb has a seal of procedence and allows one to track the path it made through the system, and who changed it. That's what the .changes file is for. Well, assuming .changes is not snake-oil, then why should in-deb sigs be called snake-oil? After all, according to you they essentially do the same job. Still, .changes file do not carry all the information in-deb sigs do (although they could, if we sign the .changes files more than once -- but changes are DAK will croak on that too). They're not stored along with the .debs anywhere (we could change that too, I suppose... but I doubt one extra file per source in the archive will be welcome). They are *far* from being as simple to handle as in-deb signatures. Not to mention that doing the inverse path (from .deb to .changes) is far more complicated than using in-deb sigs, and is only possible in fact if you either always respect some sort of naming convention to go from source package to .changes (and this *IS* a kludge), or if you read all .change files hunting for the file you want in the MD5s. Uh, packages not uploaded to the official Debian archive can do whatever they want. Sure. But I for one won't be building all debs twice, and many others won't either. And proper support for in-deb signatures means added functionality in a lot of other utilities that won't happen if Debian doesn't use in-deb signatures, etc. So, it makes a damn big difference if the Debian archive accepts signed debs or not. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Thu, 24 Nov 2005, Anthony Towns wrote: You can already use release signatures for this. Further, changing the deb after upload would make it much more difficult to check the deb was what was uploaded -- you can no longer just use md5sum, you've instead got to use special tools. While the point about you can no longer just use md5sum is useless (you need gpg, other special tools won't make it any more difficult, especially since they are gzip and ar), the point about not changing the .deb after upload is a very good one. In fact, the only good point against in-deb signatures I've seen so far. Sure; but why do that inside the .deb? You can verify a detached signature just as easily as an inline one (gpgv sig file // gpgv file), and you IF this means we can switch the effort to a detached signature that is more powerful than a .changes file (or we are allowed to have multiple signatures in a .changes file), and also that the .changes file will be stored in the archives along with the .debs, and that .debs with wrong/incomplete/missing Source: fields will be rejected (such as all automated bin-NMUed .debs made until about a week ago, or any made by a maintainer right now), and that the path to go from the Source:-field to the .origin/.changes file name is set in stone... then yes, detached signatures would do it. My objection is that it's *useless* for *Debian*. Debian has too many sources for packages for key management to be plausible, and keeps This applies to .changes files too, with the aggravating addition that those are a bitch to find right now. authenticated both via Packages.gz files and .changes files, which already exist and are usable. ONLY if we change the way .changes files are stored. It would be best to have them stored in the archive itself along the .debs, really, if we're going to use them for anything other than initial acceptance through DAK. However, integrating this on the tools will be far more difficult than an in-deb signature (still doable, of course), where dpkg would simply refuse per user-set policy any non-signed deb or any deb without a specific signature... This is what .changes files are for, and it's useful both for recovering from compromises and in a cvs blame sort of sense. Note that they also give more information than a simple signature on the .deb. Only if we can sign it multiple times, which is one of the capabilities of the simple signature on the .deb we are talking about. Hrm, I see queue/done (which contains .changes files going back to the dark ages) isn't even being mirrored to merkel properly at the moment. That's not so constructive. Agreed. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Hi, Henrique de Moraes Holschuh wrote: Well, assuming .changes is not snake-oil, then why should in-deb sigs be called snake-oil? After all, according to you they essentially do the same job. Not exactly. .changes files say that the archive should be changed. If the archive were to accept any signed .deb just because a developer signed it, that would be bad(tm). Simon signature.asc Description: OpenPGP digital signature
Re: dpkg-sig support wanted?
* Anthony Towns: Personally, I think it's cryptographic snake oil, at least in so far as it relates to Debian. I remain interested in seeing any realistic demonstration of how a Debian user could reasonably rely on them for any practical assurance. The assurance doesn't come from the signature, but from the procedures that create it and leave a cryptographically secured audit trail on the binary package. The approach chosen by dpkg-sig makes it possible to add further signatures while the package is propagated through Debian's infrastructure (unless there are some instances of compare-by-hash hard-wired into it, but there aren't AFAIK). Of course, with current state of technology, there can't be a digital signature that directly says that installation of this package will not cause any harm. But this doesn't mean that we should give up completely. since May 31. The diff at http://cvs.debian.org/dak/jennifer?root=dakr1=1.56r2=1.57 shows that the additional check was *removed*, not *added* more than a week ago. Yes; CVS was corrupted in May and hadn't been updated 'til the other week. http://azure.humbug.org.au/~aj/blog/2005/11/16#2005-11-16-dak So, just to be clear, revision 1.58 (which has been committed in the meantime) is equivalent (if not identical) to the production version, and adding metadata in the way dpkg-sig does is no longer possible? Since there is no way for Debian Developers to review the way Debian packages are created (and it's totally out of question for end users), buildd.debian.org gives full logs, to developers or users. But what do you do if there is a discrepancy between the hash in those logs and the package which is actually in the archive? I don't know how common this would be; the hashes on buildd.debian.org are not in a readily extractable format, it seems. Oh, and I looked again at the buildd stats after some time. Good to see that m68k is not lagging behind as dramatically as it used to. Debian is not doomed after all. 8-) something that provides DD-to-user package signatures at least in some cases is very desirable indeed. debian-devel-changes provides this. AFAIK, binary NMus aren't announced on debian-devel-changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Anthony Towns aj@azure.humbug.org.au writes: On Thu, Nov 24, 2005 at 09:09:21AM +1100, Matthew Palmer wrote: 2) A signature from dinstall saying this package was installed in the Debian archive would provide a means of automatic assurance of the source of a binary package, when I'm putting together custom CDs or package repos. You can already use release signatures for this. Further, changing the Only if you have a release signature corresponding to every deb and the Packages files where that deb was in. If you collect debs over any amount of time that would become a huge archive. deb after upload would make it much more difficult to check the deb was what was uploaded -- you can no longer just use md5sum, you've instead got to use special tools. So? Is that so bad? Also so far nothing is changing debs after upload. The deb signatures so far are all done prior to uploading and even changes file generation. Only a dinstall signature would change that, making the changes file less easy to verify while keeping everything else the same. 3) I can verify the provenance of a particular package in my own custom repos at any time (did that come from Debian? Did someone build it internally? What's going on?) I can kinda-sorta do that if I manually sign each binary package I download verify against the Packages-Release chain with a special came from Debian key, and I can verify the source of the source (heh) package via the dsc signature, but having a complete chain of custody on a binary package seems like a nice thing to have. Sure; but why do that inside the .deb? You can verify a detached signature just as easily as an inline one (gpgv sig file // gpgv file), and you can verify a signature of a hash just as easily as a signature of a file. If you're worried you might lose the detached, signed information, either keep it with the data it's authenticating (pool/main/f/foo/foo.origin, eg), or keep good backups, or both. I've requested that the changes files be kept along with the debs in pool several times. It aparently isn't going to happen. Also a detached signature needs more space since it uses another inode and a full block on the filesystem instead of just the few bytes inside the deb. And yes, I am worried about loosing the detached signatures. Why risk it if we have a perfect mechanism without it? At the very least, though, I can't find a hole which makes binary package signatures, done properly, any less secure than per-archive signing. That's easy: you trust the Packages file to be correct when using apt, and it's not verified at all by per-package signatures. In what way trust and how does that change anything? At best you can prevent a newer version of a package to appear in the Packages file by compromising it. You can't subvert a package itself. But you can already ship yesterdays Release.gpg, Release and Packages file to a user and thereby prevent any updates. On the other hand, without package signatures ftp-master adds a vulnerability. You can hack into it, replace debs, recreate the Packages, Release and Release.gpg file and thereby infect users. With signed debs that could still be detected by every user in apt-get. It is not that I don't trust ftp-master but that I don't even have to trust it. Is your objection to binary-package signing that it is no better than archive signing, or that it is actively *worse* than per-archive signing (again, if both are done properly, whatever we may define that to mean). My objection is that it's *useless* for *Debian*. Debian has too many sources for packages for key management to be plausible, and keeps packages unchanged over too long a period for the keys to be guaranteed secure for the lifetime of a package. Additionally, packages can be authenticated both via Packages.gz files and .changes files, which already exist and are usable. Changes files are not publicly accessible on demand so they are not practical for any authentication. And even if you have a changes file at hand by chance its signature has exactly the same security as debsig has. It is as secure as the DDs key. The major difference is the accessibility. And Packages.gz has a 24h lifetime at worst. It is only a temporary means to validate a deb. So both methods are, to put it in your words, *useless* for *users*. Please have a bit of an open mind and don't just think about what the archive needs. One scenario, which initially seems compelling, but which I've since rejected, is that of offline signing of binary packages -- the idea that the archive can be authenticated via signatures applied to packages before they hit the archive. This is what .changes files are for, and it's useful both for recovering from compromises and in a cvs blame sort of sense. Note that they also give more information than a simple signature on the .deb. Hrm, I see queue/done (which contains .changes files going back to the dark ages) isn't even
Re: dpkg-sig support wanted?
Anthony Towns aj@azure.humbug.org.au writes: On Thu, Nov 24, 2005 at 02:31:22PM +1100, Matthew Palmer wrote: Then there's the opposite argument about why not do that inside the .deb?. Simple answers: unnecessary bloat, unwarranted feeling of security leading to bad decisions. Where do you have an unwarranted feeling of security? You keep hinting at debsig being insecure but nothing you have said makes it any different (security wise) from changes files. Whenever anyone asks how do you manage the keys, the answer is usually automatically sign by dinstall which means the deb is modified after it leaves the builders system (invalidating existing authentication methods) and usually means changing the deb after its entered the archive (for signatures identifying packages released as part of sarge / etch, or in the case where an old key expires). That is just plain wrong. The only existing debsig signatures are all done by the builder and/or DD prior to creating the changes file. And that is all what the initial post in this thread was about. Having dinstall _also_ sign debs is an option that can be implemented or not. And it would only invalidate one authentication method: using a plain md5sum and the changes files. The Packages files md5sum would naturaly be the md5sum after signing and still work. Let me repeat this for you: An automatic dinstall signature is just an option. ... That's a good point. However, what damage can be done with a bodgy Packages file, if only well-signed .debs are actually accepted for installation on the system? Add a Depends: some-random-package that you know has a security hole to dpkg's entry in the Packages and it'll be automatically installed by apt. Add a Conflicts: dpkg to some package's entry and it'll never be installed by apt or aptitude. You can possibly be trickier by pointing apt at a completely different file too, so that the user thinks they're installing foo, but end up with bar instead only noticing if they see dpkg say Unpacking bar (from .../foo_*.deb). IIRC, it's tricky to make that actually work. All you do there is install a trusted package or sabotage installing a package. An attacker still can't change any package. And all of that you can do with or without package signatures. If the original package is buggy too bad. That is what we have security.debian.org for. Signed debs are not ment to protect the Packages file, we have the Release file for that. Signed debs are ment to protect the deb itself. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Goswin von Brederlow [EMAIL PROTECTED] wrote: Anthony Towns aj@azure.humbug.org.au writes: deb after upload would make it much more difficult to check the deb was what was uploaded -- you can no longer just use md5sum, you've instead got to use special tools. So? Is that so bad? Also so far nothing is changing debs after upload. The deb signatures so far are all done prior to uploading and even changes file generation. Only a dinstall signature would change that, making the changes file less easy to verify while keeping everything else the same. If such a signature mechanism is implemented, dinstall could also append a copy of the filelist, with updated md5sums. I'm not familiar with the ar format, but can one restore the old md5sum when you unpack the deb, remove the additional signature, and re-ar it? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: dpkg-sig support wanted?
Simon Richter [EMAIL PROTECTED] writes: Hi, Henrique de Moraes Holschuh wrote: Well, assuming .changes is not snake-oil, then why should in-deb sigs be called snake-oil? After all, according to you they essentially do the same job. Not exactly. .changes files say that the archive should be changed. If the archive were to accept any signed .deb just because a developer signed it, that would be bad(tm). Simon The only differences between accepting signed debs and signed changes files are that changes file have some additional infos (like who gets the ACK mails) and what set of debs go together. Both features are still needed with signed debs and nobody has any intention of changing them. The only request so far is to not reject debs that are also signed themself. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Anthony Towns aj@azure.humbug.org.au writes: On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote: Use 1: I have this deb in my apt-move mirror and I want to know if it was compromised on yesterdays breakin Boot a clean system with debian keyring and check all deb signatures. Find some don't pass because they were signed with keys that have been removed from the keyring. Those I remove and refetch from a clean source again. False negatives are no big deal. 99% of the debs will verify leaving only a managable amount of wokr behind. Use 2: I have this Ubuntu CD and want to know which debs are from debian and which got recompiled Look for all debs that have a deb signature of the debian archive (to be added to dinstall at some point). Never to be added, because it would change the .deb from that which was originally uploaded, for no benefit. Fair enough. Use 3: The debian servers were compromised and the security team takes too long to check the archive for my taste Being a normal user I obviously have no mail archive of all the old changes files laying around so that road is closed. But everyone has a Debian stable CD with keyring. See Use 1. And see why it doesn't work. Not to mention keys added since stable released, and packages uploaded by those maintainers. More than just keys removed from the keyring, there's the issue of keys being compromised -- it's not even unknown for developers to post secret keys to mailing lists -- the issue that a package that's once been in the Compromised keys are compromised keys. No matter what you use for authentification they don't change. One has to look for revocation certificates and remove bad keys from the keyring prio to checking signatures. archive may well by now have known security holes (which is why we have As for known security holes in packages. They are known. The signature of a deb only tells me that no new holes were added. And yes, that is what we have security.debian.org for. security.debian.org after all), and that this is entirely moot anyway since the vast majority of packages can't be verified by dpkg-sig. Ah, I see the light. Signatures are useless because packages have no signatures. Lightbulbs do not work because without lightbulbs it is dark. You can't breath air because there is no oxygen in a vacuum. buildd.debian.org gives full logs, to developers or users. While the log contains the md5sum of each build deb it does not contain any signature against tampering. No, that's what the signed .changes file is for. Which aren't readily available to the public. Tampered debs can be uploaded by sending a fake mail to the admin and filtering out his responce. A deb signature of the buildd and a subsequent dak check would prevent this. So would having the buildd sign the mails to the buildd admin, which would have the benefit of not giving a couple of dozen completely untrustworthy keys special access to the archive. (AIUI, signed mails to the admin are on the TODO list; at present buildds don't have keys of their own at all) Nothing in signed debs gives any keys additional access to the archive. Checking for a buildd signature would only restrict the access further from what we have already, not weaken it. something that provides DD-to-user package signatures at least in some cases is very desirable indeed. debian-devel-changes provides this. That covers only the sourcefull uploads and the arch specific -changes lists are not archived and therefore useless for non constant monitoring. Far easier to fix that, than retrofit 150G of debs to a flawed and redundant scheme like this. Cheers, aj Where is there any flaw? You still haven't shown any that changes files don't also have. As to redundant. Yes they are redundant to changes files, IF ONLY one could get a changes file when needed and have multiple signatures in it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Frank Küster [EMAIL PROTECTED] writes: If such a signature mechanism is implemented, dinstall could also append a copy of the filelist, with updated md5sums. I'm not familiar with the ar format, but can one restore the old md5sum when you unpack the deb, remove the additional signature, and re-ar it? You can simply strip off the parts that change the md5sum, without the unpack/pack cycle. The problem is to know which parts need to be removed. Marc -- BOFH #335: the AA battery in the wallclock sends magnetic interference pgprsAWzGrlFl.pgp Description: PGP signature
Re: dpkg-sig support wanted?
* Florian Weimer [Thu, 24 Nov 2005 18:28:04 +0100]: Hi, AFAIK, binary NMus aren't announced on debian-devel-changes. Binary-only uploads are announced in the appropriate debian-devel-$ARCH-changes list. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org As scarce as truth is, the supply has always been in excess of the demand. -- Josh Billings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 07:39:57AM +0100, Marc Haber wrote: Uh, packages not uploaded to the official Debian archive can do whatever they want. It would, however, be convenient to be able to upload a package to Debian and to be able to use the same package for different things. As far as dpkg-sign's concerned, can't you already do that by building the package, uploading it to debian, then running dpkg-sign? At worst you'd have to run dpkg-genchanges again before uploading to your other suite, afaics. Allowing things like these is what makes it possible for some people to work for Debian during their paid time. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, 24 Nov 2005, Anthony Towns wrote: On Thu, Nov 24, 2005 at 07:39:57AM +0100, Marc Haber wrote: Uh, packages not uploaded to the official Debian archive can do whatever they want. It would, however, be convenient to be able to upload a package to Debian and to be able to use the same package for different things. As far as dpkg-sign's concerned, can't you already do that by building the package, uploading it to debian, then running dpkg-sign? At worst you'd have to run dpkg-genchanges again before uploading to your other suite, afaics. You're correct. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 06:44:37PM +1100, Matthew Palmer wrote: On Thu, Nov 24, 2005 at 03:48:15PM +1000, Anthony Towns wrote: On Thu, Nov 24, 2005 at 02:31:22PM +1100, Matthew Palmer wrote: I think the final judgment in this issue is going to come down to personal taste and needs more than anything else. That's fine for personal repositories, it's not sufficient for Debian's archive. Well, I think that personal taste is sufficient for Debian's archive, and it seems obvious that Those In The Know have decided that they prefer one taste over another. grin *sigh* Do you really think that comment was helpful? Add a Depends: some-random-package that you know has a security hole to dpkg's entry in the Packages and it'll be automatically installed by apt. You're a lot more devious than I am, AJ, as I'd never considered these possibilities. I've had this same conversation a dozen times before... No, there isn't anything, apparently the mirroring to merkel got disabled due to the inode usage / rsync time. There's some 700k odd changes files. Ouch. rsync must be *loving* those. Well, it's loving them being excluded, yeah... Developers who'd like to play with making a workable format for .changes files can play around with changes files separated by month up 'til 2005/04 by poking around in /org/ftp.debian.org/queue/done on merkel; changes up 'til August are also available unseparated, but you're better off just ignoring those for experimenting. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 10:43:38AM -0200, Henrique de Moraes Holschuh wrote: On Thu, 24 Nov 2005, Anthony Towns wrote: On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote: On Thu, 24 Nov 2005, Anthony Towns wrote: Personally, I think it's cryptographic snake oil, at least in so far A signed deb has a seal of procedence and allows one to track the path it made through the system, and who changed it. That's what the .changes file is for. Well, assuming .changes is not snake-oil, then why should in-deb sigs be called snake-oil? After all, according to you they essentially do the same job. Sure, and sugar water is okay for quenching your thirst, but it's still snake oil as far as, say, curing cancer is concerned. .deb signatures are aimed at giving users some sort of assurance the package is valid; but when you actually look into it -- at least in Debian's circumstances -- those signatures can't actually give any meaningful assurance for any specific validity. .changes files aren't aimed at users, they're aimed at the archive -- the fact that they become more complicated to validate over time isn't a problem, because they're not expected to be validated in the future on a regular basis. Still, .changes file do not carry all the information in-deb sigs do (although they could, if we sign the .changes files more than once -- but changes are DAK will croak on that too). You can have multiple signatures on a .changes file easily -- you strip the old signature, add a new one, and tar the two (or more) files up together. Or you use detached signatures of an origianl signed or unsigned changes file. That has nothing to do with dak or Debian though. Not to mention that doing the inverse path (from .deb to .changes) is far more complicated than using in-deb sigs, *shrug* Grepping through files isn't that difficult. You can use indices to make it quicker if it matters, but it doesn't. Uh, packages not uploaded to the official Debian archive can do whatever they want. Sure. But I for one won't be building all debs twice, Uh, you add a signature to a .deb after building it. Upload the .deb to Debian before signing it if you want it both in Debian and in some local repository that requires signed debs. So, it makes a damn big difference if the Debian archive accepts signed debs or not. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 07:47:58PM +0100, Goswin von Brederlow wrote: Anthony Towns aj@azure.humbug.org.au writes: On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote: Use 1: I have this deb in my apt-move mirror and I want to know if it was compromised on yesterdays breakin Boot a clean system with debian keyring and check all deb signatures. Find some don't pass because they were signed with keys that have been removed from the keyring. Those I remove and refetch from a clean source again. False negatives are no big deal. 99% of the debs will verify leaving only a managable amount of wokr behind. The clean source that's signed by the same key that you can't verify? Use 3: The debian servers were compromised and the security team takes too long to check the archive for my taste Being a normal user I obviously have no mail archive of all the old changes files laying around so that road is closed. But everyone has a Debian stable CD with keyring. See Use 1. And see why it doesn't work. Not to mention keys added since stable released, and packages uploaded by those maintainers. More than just keys removed from the keyring, there's the issue of keys being compromised -- it's not even unknown for developers to post secret keys to mailing lists -- the issue that a package that's once been in the Compromised keys are compromised keys. Compromised keys are not, however, compromised debs. Ah, I see the light. Signatures are useless because packages have no signatures. That's a transitional problem, yes. In this case it's a severe one; since there are up to 150GBs worth of .debs. It's a problem that could be solved if it were worthwhile, but it's not worthwhile since .changes already do everything deb sigs could do without any transition issues, and it's not something that can be simply ignored. Cheers, aj signature.asc Description: Digital signature
