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

I've no problem with providing documentation that warns of the potential danger - in fact, mainly as a result of your suggestions, I'm now also thinking of having the use of both UNTAINT and SAFEMODE options generate a warning about the inadvisability of using them.

I left things as they are (wrt tainting) in the last Inline::C update, partly to give me more time to think about what to do with it ... and I'm still finding most options unpalatable.

I don't like the idea of just leaving it as is - that seems silly to me (despite the pragmatic wisdom). Surely it should be either fixed or removed.
I certainly have no intention of personally trying to add improvements (that would be disastrous), and yet I consider that I would be acting in bad faith if I just went ahead and removed all of that code that Ingy (I presume it was he) had gone to so much trouble to put in place in the beginning.

So, I still find myself leaning towards applying Patrick's patches - but, yes, with stern warnings about the dangers of using this particular piece of rope. (Thanks for the cautionary advice.)

Ingy was recently making noises about once again contributing to Inline - I might yet try and contact him and find out just what his vision for untainting actually was, and how he thinks it should be dealt with in the present and future.

Cheers,
Rob