Hi Stefan, On Thu, 2009-09-03 at 16:54 +0200, Stefan Bodewig wrote: > > Another benefit is that the download client can also verify the > > download afterwards, > > This depends on my level of paranoia. Do I want to trust md5 or sha1 > hashes at all? Does the client speak OpenPGP for a stronger checksum > algorithm (unless the signer is in my web of trust, the signature isn't > more than that)? That is true, the security of the download depends on the strength of the published verification method (e.g. SHA-512 would be better then SHA-1), the security of each of the mirrors you have approved, and the method/response time to break-ins on those mirrors. And then there is the security of the transmission. I don't think we would disagree on any of those :).
> > > without the user having to run any extra commands after the download > > finished. > > Do I tust the download client? ;-; I trust my download client, just as much as I trust my md5sums binary ;). If the users' software can't be trusted, then nothing about the download can be, simply because any kind of trojan could even mod it after the download and verification. It's all very complicated and depends on how paranoid you are I guess, I've actually never looked at most of the core-utils source, so all my `ls` results may just be lies. Anyway, I trust my download client (aria2c). > > > About the digest information coming from a reliable central source, you > > are already doing that with your download page by pointing only to the > > central MD4/SHA1/signature files. I've rewritten the page to keep other > > people from getting confused about that :) > > Thanks. > > I think in the ASF's case dynmirror doesn't really help. The list of > mirrors is dynamic and mirrors come and go (e.g. they may get removed if > they don't sync fast enough) and we like to keep it that way. The > specific ASF projects (like Ant) aren't even aware of the process. Which I can understand is big no-no for large projects, but hopefully a step up for small projects that want to do their own mirroring in collaboration with their users. I'll see what smaller projects have to say about it. But we can safely say that dynmirrors is not for you. > If I understand dynmirror correctly it would accept any download URL as > a mirror if it can provide matching filenames and MD5 checksums, is that > correct? This would allow mirrors to add themselves that are not > "approved" (they may want to show ads we don't like for example). It is not possible for them to show ads, as the links are only mentioned in the metalink and the download client won't open them in a browser. If they host an add there, the download client will simply check the server, see that the content-length doesn't match up and drop it. If everything goes well, the user won't even notice dynmirror.net is involved. However, as we already said, dynmirror is not for you :) > If my understanding is correct it would also allow me to create a trojan > distribution of some software if I manage to create MD5 checksums that > match the original distribution - given that creating hash collisions in > MD5 isn't that difficult for a well-funded bad-guy, this is something > I'd be concerned about. Given its adoption Apache httpd looks like a > very attractive target for inserting a backdoor, so the well-funded > bad-guy isn't that far-fetched IMHO. > > Let's say I hope my understanding is wrong. You are correct, a well funded bad-guy would be able to do so creating a hash collision on MD5 or any other kind of verification method you can muster. A really well-funded bad-guy would be better off becoming a dictator, and taking control of most of the countries DNS servers. But yes, you are completely right if you assume that the download security is completely dictated by the security of the verification method (which is what dynmirror.net does). Again, don't use dynmirror.net if you feel uncomfortable with this. That said, you could host your own metalink with only one or two mirrors, anybody using aria2c for example, would no-longer require to hand-check the digest after download. Consider this example metalink: <?xml version="1.0" encoding="utf-8"?> <metalink version="3.0" xmlns="http://www.metalinker.org/";> <files> <file name="apache-ivy-2.1.0-rc2-bin.zip"> <verification> <hash type="sha-1">f3e10f28d15c59276d6808742018af2f2e1f13e6</hash> </verification> <resources> <url type="http">http://mirror.hostfuss.com/apache/ant/ivy/2.1.0-rc2/apache-ivy-2.1.0-rc2-bin.zip</url> </resources> </file> <file name="apache-ivy-2.1.0-rc2-bin.zip.asc"> <resources> <url type="http">http://www.apache.org/dist/ant/ivy/2.1.0-rc2/apache-ivy-2.1.0-rc2-bin.zip.asc</url> </resources> </file> </files> </metalink> This would allow people to download both the file and the detatched signature, while their download client will check the SHA-1 (I suggest aria2c -M http://link_to_the_above_metalink). I think that would actually help increase security, as people are more likely to check the detached signature if it's automatically downloaded with next to the file. Greets, Bram --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
