Files get has no way to specify the name of the file once it is retrieved

[whereswaldon]

In the IPFS CLI, you can use ipfs get -o <hash> to get a file and save it with a given name, but the ipfsApi.Client().get() function does not have this capability right now.

[lordcirth]

I intend to fix this issue.

[ntninja]

@lordcirth: Any help is appreciated! Please make sure that you develop against the py-ipfs-http-client branch however as that is the code that will become the new master soonish. Thanks for the heads up and your help!

[lordcirth]

Good to know, thanks!

…

On Tue., Jan. 29, 2019, 7:34 p.m. Alexander Schlarb < ***@***.*** wrote: @lordcirth <https://github.com/lordcirth>: Any help is appreciated! Please make sure that you develop against the py-ipfs-http-client <https://github.com/ipfs/py-ipfs-api/tree/py-ipfs-http-client> branch however as that is the code that will become the new master soonish. Thanks for the heads up and your help! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#48 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACaBNqqA6dOQi8WmbOS7SayYXG8p_ipxks5vIOingaJpZM4JblWa> .

[lordcirth]

From the docs for tarfile.extractall [1]

Never extract archives from untrusted sources without prior inspection. It is possible that files are created outside of path, e.g. members that have absolute filenames starting with "/" or filenames with two dots "..".

Is this something we ought to be concerned about? Would this attack allow a malicious IPFS object to overwrite files, or only a malicious IPFS daemon? Is tar formatting applied by the IPFS daemon? In that case it's not a big deal.

EDIT: API docs imply that the tar format is created by the IPFS daemon. [2]

[1] https://docs.python.org/2/library/tarfile.html#tarfile.TarFile.extractall
[2] https://ipfs.docs.apiary.io/#reference/get/get/get

[ntninja]

@lordcirth: Didn't see your message yet. The tarfile is indeed assembled by the IPFS daemon, not part of some IPFS file.

It'd be still be good to guard against this since there is no guarantee that this library will be used with a trusted daemon. Maybe this can be done as part of #158? 😉