Please implement --allow-insecure-filename

[grinapo]

There is an ongoing problem with some official torrent providers, where they inlcude paths (slash) in the filename. For years. Despite the huge amounts of negative feedback from users.

Right now the only way to download those is to patch bt regex in Meta/Info.py to allow paths, but it's really ugly. There is --security 0 but it seems not to be checked for this particular check. Too bad. I briefly checked the code but I don't see the options available in Info.py, so instead of a pull request I request this: please implement a switch to be able to download filenames with slashes or possibly other junk, under the risk of the user. It is not much worse than having security=0. :-)

[effigies]

Hi, I have zero time to work on this project for the foreseeable future. Feel free to submit a PR and I'll try to review it.

[grinapo]

If you help a bit to offer the shortcut how to retrieve a command line switch value in the given module I will. :-) Otherwise it'd take plenty of tiem to track through unfamiliar code. No problem though, you can keep this ticket open if you feel you'll have time later. I have patched mine directly.

[effigies]

I don't understand the question. Which command line interface are you using?

[grinapo]

Since btdownloadcurses.py seems to be the only way to accept command line args, I do use that. (Possibly same true for headless.)

You possibly don't understand the question since you're failiar with python but I'm not, I know syntax but not all the libs and takes me time to follow the scope of a variable for example.

I guess my question is how can I access the variable config[] in the said module according to python best practices, since probably the arg parser would put something there to show whether user used a switch on the cmdline or not.

Technically it's not a brainy patch, since Meta/Info.py needs

if config['unsafe_name']:
 valid_name = re.compile(r'^[^/\\.~][^\\]*$')
else:
 valid_name = re.compile(r'^[^/\\.~][^/\\]*$')

and the arg parser have to parse "--allow_unsafe_names" switch into the config entry above, and that's all.

(Sidenote: I can't see what VALID_NAME variable does there, it seems very unused.)

[effigies]

VALID_NAME is used here:

https://github.com/effigies/BitTornado/blob/ed327c4e1ebbe1fe949be81723527cfda87aeb8d/BitTornado/Meta/Info.py#L175-L197

I see what you're asking. I'm not sure if the fix you're proposing will be sufficient, given the refactoring I've done. Can you confirm the version of BitTornado you're running, and paste the error you see?

In any event, I think you would need to add your option to the list in download_bt1.py:

https://github.com/effigies/BitTornado/blob/ed327c4e1ebbe1fe949be81723527cfda87aeb8d/BitTornado/Client/download_bt1.py#L31-L167

Then you would need to either pipe config['allow_unsafe_names'] through to Meta/Info.py (whenever called), or you could change global state like so:

if config['allow_unsafe_names']:
    BitTornado.Meta.Info.VALID_NAME = re.compile(r'^[^/\\.~][^\\]*$')

This should probably be done shortly after the config variable is instantiated, in btdownload*.py and btlaunchmany*.py.

Finally, I think you'd want to replace valid_name with VALID_NAME in MetaInfo.check_info, so that its behavior is affected by this change.

[grinapo]

Indeed debian package seems to be rather behind, so I'll check the current and ponder your solution. If I feel like it's working I'll PR it. Thanks for now.