On 9/6/21 2:42 AM, Andrew Gregory wrote:
Put notes here to avoid including them in the commit message.
Understood, thanks!
After thinking about this some more, I think this is far too simple. Just running download_internal in an unprivileged fork will break anything that relies on side effects. download_internal sets pm_errno, tracks server errors, and calls a number of front-end callbacks. Losing server error tracking across multiple downloads isn't a big deal, but losing pm_errno is significant and we have no way of knowing what kind of state changes the front-end callbacks might be making. I suspect this would massively break GUI front-ends.
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?
Remi
OpenPGP_signature
Description: OpenPGP digital signature
