I think having clients ignore the "verification" section in the Metalink is a bad idea. The file at the bittorrent URL could be changed to deliver malicious content instead of the intended file. If the Metalink verification is checked this can be prevented. Basically you use the Metalink file as a trust anchor to ensure that the bittorrent file is indeed what you really want. We assume that a user trusts the source of the Metalink file, but not necessarily the source of the .torrent file (the user doesn't open the metalink file and review the bittorrent URL). If using GPG the metalink source can even be validated, something bittorrent doesn't do.
Neil Hampus Wessman wrote: > I hadn't thought about this before. It sure deserves a satisfactory > solution. Good that the issue was brought up! > > I have no good ideas right now about how to best solve it. > > When it comes to <verification> I think the intention is that you MAY > ignore it when a torrent is available, but a client can use it too. A > client without support for bittorrent would always use those hashes, > for example. Clients with support for bittorrent probably doesn't need > them when a torrent is available, but IMO it's up to the client > programmer to decide what to use in this case. A very pedantic and > somewhat paranoid client would of course check them all =) > > Hampus > > > On Mon, 11 May 2009 07:45:59 -0500 > Matt Domsch <[email protected]> wrote: > >> I'm trying to understand common practice for including bittorrent URLs >> in a metalink, either with version 3.0 or the IETF draft. >> >> <file name="example.file"> >> <size>XXXX</size> >> <verification> >> <hash .../> >> </verification> >> <resources> >> <url type="bittorrent">http://www.example.com/example.torrent</url> >> </resources> >> </file> >> >> >> This makes sense, if each file has its own torrent. However, Fedora >> and other torrent generator persons don't always do this. Instead, >> they will have multiple files inside the torrent: >> >> {'path': ['Fedora-10-x86_64-DVD.iso'], 'length': 4172283904L} >> {'path': ['SHA1SUM'], 'length': 788} >> >> In this instance, the metalink for the Fedora-10-x86_64-DVD.iso that >> MirrorManager publishes has direct FTP/HTTP URLs to that ISO, and the >> <verification> section has info on this single file. >> >> But this single file isn't published in its own torrent, it's in a >> torrent with those multiple pieces. The whole <verification> section >> then is either meaningless, or would provide incorrect information, as >> compared to the torrent URL. >> >> Likewise, the CD downloads for the multi-CD set includes direct >> HTTP/FTP URLs to each of the CDs, but the torrent includes all of them >> in a single torrent. >> >> >> Is the <verification> section completely ignored when torrents are >> used, and instead the torrent metadata used? If so, can that be >> documented in the specification? >> >> Thanks, >> Matt >> > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Metalink Discussion" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/metalink-discussion?hl=en -~----------~----~----~----~------~----~------~--~---
