Mavericks and 2.8.3 bug:

[plumsmooth]

OSX 10.9.2 Transmission 2.8.2

Getting this error message on otherwise good torrents.
I DL'd another torrent program and they worked fine...

[plumsmooth]

I checked the topic however it didn't seem to offer a fix; and my mention seems very specific in regards to the "invalid data" issue.
Maybe worth keeping this thread if even just for this.
Can someone please tell me how to revert back to 2.8.2

I tried DL'ing from the long back-versions list and all I got was a bunch of files with no App!

[plumsmooth]

2.8.2 works no problem, both torrents that weren't working!

Thanks for the 2.8.2, I'll keep it for now...

Having a real hard time PM'ing.
Getting "user doesn't exist" or "Message does not contain enough characters."

This is making me feel like a newbie...

[cfpp2p]

Maybe worth keeping this thread if even just for this.

plumsmooth,

if it's easier just send the whole torrent file(s) and in that way I'll analyze the whole torrent so it can be posted on this thread why v2.83 fails.

I'll pm you how to get the data to me.

Thanks

[cfpp2p]

Thanks so much plumsmooth

I exactly see what the problem is and I will post a full analysis tomorrow.

2.8.2 works no problem, both torrents that weren't working!

I see why for both torrents you sent and a specific changeset to 2.83 affected both.

[cfpp2p]

Note in the two images and pointed out with <--- empty path





changeset 14264 https://trac.transmissionbt.com/changeset/14264 incorporated

- return (path == NULL)
- || (!strncmp (path, "../", 3))
- || (strstr (path, "/../") != NULL);
+ return (component == NULL)
+ || (*component == '\0')
+ || (strpbrk (component, PATH_DELIMITER_CHARS) != NULL)
+ || (strcmp (component, ".") == 0)
+ || (strcmp (component, "..") == 0);

and with this as the path is formulated each component is checked for
being NULL. In other words if ANY of the path formulation results in NULL.
This is why the tested torrents result in an invalid or corrupt error and
Invalid metadata entry "path" in the message log.

The creator of the torrents is shown as: "ruTorrent (PHP Class - Adrien Gibrat)"
and this I think is a front end for rtorrent and not some "suspicious".
Transmission now flags these torrents with path_component_is_suspicious but I didn't
see anything suspicious with the metadata path or anywhere else.
The case of where entire path is NULL should definitely not be allowed
but disallowed only because an individual component being null is incorrect.

The changeset that falsely flags these torrents stems from
trac ticket #5517. I still think the best way to resolve
these type of false positives _is_suspicious being:

https://trac.transmissionbt.com/ticket/5517#comment:22
https://trac.transmissionbt.com/ticket/5517#comment:26

and patch comment:22 + comment:26 into metainfo.c functions correctly
for this as well as all the other cases, and handles the case of entire path
is NULL which definitely should not be allowed.

[cfpp2p]

How do you create a torrent with a NULL path component?

I didn't. The two torrents appear to be properly created from rTorrent, a legitimate client. That's the point, we are getting false positives with the current implementation of _is_suspicious. They don't appear faked such as using a custom bencode editing tool. These type of false positives can be eliminated with proper coding since the are not hidden faults. My analysis is from real torrents from a well respected client. I can think of ways that this can happen. Transmission should allow such as it's not suspicious or harmful, other widely used clients allow for it, and it causes confusion for users to disallow such.

[cfpp2p]

It would be helpful if your image examples were in plaintext.

you must have the mind of a Martian to like your code this way


d8:announce89:http://tracker.xxxxxx.org/announce.php? ... 10:created by37:ruTorrent (PHP Class - Adrien Gibrat)13:creation datei1385220415e4:infod5:filesld6:lengthi60e4:pathl0:12:r2r-1459.sfveed6:lengthi4339370e4:pathl0:12:r2r-1459.rareed6:lengthi18612e4:pathl0:7:R2R.nfoeee4:name32:xxxxxxxx12:piece lengthi65536e6:pieces1340:

private data replaced, - length of replacement characters not accurate

[mike.dld]

As far as I can tell, it's probably not Adrien (his Torrent.php looks quite different and may not have this issue) but ruTorrent guys (novik65?) who should make the fix.

[cfpp2p]

part of my post to trac ticket #5517 which seems stuck/froze moderated . hope my posts shows up in any sequence to make any sense.

partial trac #5517 post
....
Other clients, not inclusive to rTorrent, ruTorrent, allow this structure, there will be these types of metadata in the wild now, and it doesn't look ''_is_suspicious''. I believe transmission should not flag this type metadata corrupt or invalid and exclude itself from processing these types of torrents.

At any rate, we are now getting false positives with v2.83.