Bo Peng wrote:
> Richard Heck wrote:
> In any event, the "nail in the coffin" for Bo's approach ended up being
> security issues that were first raised by Andre. These can be hard to
> foresee. It wasn't that these issues couldn't be addressed within Bo's
> approach. It was, rather, that once you'd addressed them, you couldn't
> have true "reversibility" any longer, and then the motivation for his
> approach kind of evaporated, because that was the guiding idea.
While I will not continue our debate here, I would like to point out that,
The reason why I chose to revert my feature was because no other
developer agreed with the basic design of my implementation (i.e.
in-place reversible bundle/unbundle), and I refused to change to a
design that I dislike (i.e. force a directory structure,
non-reversible bundle/unbundle). It was not because my implementation
has any sort of fundamental flaw, as Richard indicated above. I have
addressed Andre's security concern sufficiently, and I have proposed a
method to achieve 'true reversibility' using my approach.
What I wrote had nothing to do with why Bo chose to revert the embedding
code. It had to do with why, as I saw it, most developers ended up
disagreeing with the basic design. It is a fundamental flaw if the mere
possibility of unbundling files to arbitrary locations *even within the
document directory* leads to the possibility of executing arbitrary code
on the user's machine. I can easily construct a file such that (on
Linux), if you put the file in your home directory, unbundle it, and
then open the unbundled file, I can have you execute any Python program
I like. It'd take me a little more work to figure out exactly what to do
on Windows or Mac, as I don't use them, but something similar would be
possible there, too---with of course much worse results on Windows than
on Linux.
I don't recall seeing any solution to this problem proposed. And I'm
confident there is none. The only thing the exploit uses is, as I said,
the possibility of unbundling to arbitrary locations within the document
directory.
Richard
