On 9/6/21 09:34, Remi Gacogne wrote:
Right, that was my main worry when I started working on this, but since the 'XferCommand' option existed I was hopeful the download code was not too tightly coupled with the rest of the code. Do you think it would still make sense to keep working on this? It looks like we could pass the value of pm_errno back to the main process, using a pipe if needed. As for the front-end callbacks I guess we could detect that these are set and disable the sandboxing in that case, while documenting that this option does not play well with GUI front-ends. I'm guessing that's already the case with 'XferCommand?', since the same issues likely apply?
I looked a bit more into this. Passing pm_errno back is easy, and can even be done using the exit status without setting up a pipe. Unfortunately I realize now that I under-estimated the criticality of the front-ends callbacks. Reading that code more in depth quickly uncovered issues I did not notice earlier, like 'on_progress' being set during the downloads and leading to cb_log adding messages to a list that is never flushed when we fork. I'm not sure how to deal with that. Serializing the content of the dlcb events to pass them over a pipe could be done, but that would be a rather big patch, and would be cumbersome to maintain. I'll think about it a bit more, and in the meantime any ideas are welcome :) Remi