Author edulix
Recipients Arfrever, Daniel.Garcia, benjamin.peterson, christian.heimes, edulix, georg.brandl, jwilk, larry, lars.gustaebel, martin.panter, ned.deily, r.david.murray, serhiy.storchaka, vstinner
Date 2014-04-26.11:34:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1398512046.55.0.0193339886815.issue21109@psf.upfronthosting.co.za>
In-reply-to
Content
Do we have any final decision on what's the best approach to solve this? I see some possibilities:

a) leave the issue to the library user. I think that's a not good solution security-wise as many will be unaware of the problem and this promotes code duplication for the fix. On the other hand, this does not change default behavior.

b) fix the problem as proposed in the patch sent by Daniel. This makes the tarfile secure against this kind of attacks. It does change the behavior and doesn't allow to extract in arbitrary paths, though.

c) fix the problem so that by default extracting in arbitrary paths is not allowed, but allow somehow to do that optionally. This way we change the default behavior but provide an easy fix for those that depend on that functionality.

d) do not change the default, but provide a well documented and easy  way to activate the safety checks that fix this kind of attacks. The advantage is that it doesn't change the default behavior, the disadvantage is that many people will have to modify their code to be secure, and that the default is not very secure.

For what is worth, I believe either b or c should be chosen to fix this issue.
History
Date User Action Args
2014-04-26 11:34:06edulixsetrecipients: + edulix, georg.brandl, lars.gustaebel, vstinner, larry, christian.heimes, benjamin.peterson, jwilk, ned.deily, Arfrever, r.david.murray, martin.panter, serhiy.storchaka, Daniel.Garcia
2014-04-26 11:34:06edulixsetmessageid: <1398512046.55.0.0193339886815.issue21109@psf.upfronthosting.co.za>
2014-04-26 11:34:06edulixlinkissue21109 messages
2014-04-26 11:34:05edulixcreate