Thank you so much for responding - and for taking on the responsibility to maintain this module.

IMHO the most important thing near term is to update the documentation so that it clearly describes the security issues along with recommendations for safe use. It needs to be explained more clearly that

• SAFEMODE is not the least bit comprehensive. This can be nicely spun as "future implementation". All the same, I think one needs to make it very clear that some really obvious kinds of security are not being performed. For example, while reading through the code, I also noticed that rmpath calls _rmtree which disables taint protection on parameters to unlink by blindly passing them through /.*/. It also allows the entire tree under "/" to be deleted. There are probably others as well.
• UNTAINT mode is optional - as CountZero points out the documentation implies the exact opposite. The only way to know that UNTAINT is optional is to scan the source code.
• Using the UNTAINT option, effectively nukes Taint mode for the *entire* application, not just the portions controlled by Inline. This could have serious implications, especially in web applications that may be counting on Taint mode to break system calls using Environment variables.
• I'd also add a note on the bug list about the security issues in the work-around for bug 13084 (Inline doesn't work in taint mode). The work-around suggested there nixes the only safety feature that SAFEMODE currently implements (it recommends setting CLEAN_AFTER_BUILD => 0).

Also I would think twice about rushing to fix that UNTAINT bug. I see the long standing nature of that bug as good news. It means that security conscious developers are unlikely to be using this module in security sensitive production applications to any great degree simply because they can't. This has two benefits:

• We have probably avoided some significant bad publicity about security issues in Perl's cross language support.
• If you really do want to make this module work in taint mode, it buys you time until you or a volunteer is available to rethink the strategy for making this module work when TAINT mode is turned on. The current approach effectively boils down to "go away taint mode - I don't like you - you are in my way!". A developer (or corporation) that turns on taint mode is making a statement about their desired level of security. For those users, making a better sledge hammer to nuke taint mode is not going to be acceptable.

Best, beth