[bittorrent] How should .torrent files with unsorted info dictionary keys be handled

Harold Feit dwknight at depthstrike.com
Wed Jan 20 13:02:31 EST 2010

I'll put my two cents in quick.
Take option three. The specification is clearly defined, if your
dictionary's keys aren't sorted properly, you're in violation and should
NOT be encouraged to continue to be in violation.

Alan McGovern wrote:
> I'm going to keep this short and link to a longer post [0] if you want
> more background. Basically I'm hoping that all of us will be able to
> agree on one method of handling these invalid torrents and implement
> that for the next release of our software. We should also update the
> unofficial spec (http://wiki.theory.org/BitTorrentSpecification) and
> also try to get the official spec ammended with the results of this
> discussion.
> Essentially the problem is that if a .torrent file exists which has
> unsorted dictionary keys [1] in its info dictionary then there are three
> ways in which it can be parsed and two possible infohashes which can be
> generated:
> 1) You can decode the info dictionary, order the keys (as per spec) then
> generate the infohash using the sorted keys.
> 2) You can take a substring from the .torrent file which spans the info
> dictionary and just run those raw bytes through a SHA1 hash and generate
> the info hash. This generates a *different* infohash as to method 1.
> 3) Discard the torrent as invalid and refuse to process.
> So pros and cons:
> Approach 1:
> Pro: This approach implies that if an invalid bencoded dictionary is
> found it should be converted into a valid representation and used.
> Pro: This should be relatively trivial for most clients to implement.
> Con: The letter of the spec [2] says that we should always use a
> substring of the .torrent metadata. Strictly speaking this approach goes
> against the spec. However, we have to assume that when the spec refers
> to ".torrent metadata' it refers to *specification compliant* .torrent
> metadata. i.e. the keys in the metadata must be sorted for it to be
> considered valid .torrent metadata. Conversely, if the keys are *not*
> sorted then the data should not be considered valid .torrent metadata.
> If that's the case, then why are you generating a valid infohash from
> invalid metadata?
> Con: You need a non-spec compliant way of decoding bencoded data.
> Approach 2:
> Pro: You follow the letter of the bittorrent specification but still
> break the BEncoding specification.
> Con: I'd argue that this is slightly more complex to implement as you
> may now need to double parse the .torrent file in order to generate the
> infohash. The first time you pass it through your bencoded data decoder
> to generate your in-memory representation. Then you have to parse the
> file manually a second time to find the start and end of the info
> dictionary and extract that substring.
> Con: I'd argue that you're breaking the spirit of the specification
> again as you're now running under the assumption that invalid bencoded
> data is valid .torrent metadata and the spec doesn't explicitly allow
> this ;)
> Approach 3:
> Pro: Simplest to implement as you just have to make your bencoded data
> decoder spec compliant. Once this happens, the .torrent won't be
> loadable so that question of how to generate the infohash never has to
> be answered.
> Con: It will render some torrents unloadable but those should be a very
> small percentage.
> [0] http://forum.utorrent.com/viewtopic.php?pid=431793#p431793
> [1] http://wiki.theory.org/BitTorrentSpecification#dictionaries
> [2] "The 20 byte sha1 hash of the bencoded form of the info value from
> the metainfo file. Note that this is a substring of the metainfo file."
> ------------------------------------------------------------------------
> _______________________________________________
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/bittorrent

More information about the BitTorrent mailing list