ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram Neijt <bne...@gmail.com>
Subject Re: Publishing metalinks on the download page
Date Thu, 03 Sep 2009 17:19:29 GMT
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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message