> -----Original Message----- > From: Robert Landrum [mailto:[EMAIL PROTECTED] > Sent: 28 March 2007 16:30 > To: Shah, Sagar: IT (LDN) > Cc: [EMAIL PROTECTED]; modperl@perl.apache.org > Subject: Re: "Insecure dependency in eval while running setgid" error > > [EMAIL PROTECTED] wrote: > > Unfortunately turning taint mode off isn't an option for me. My > > application is client facing and so we want to continue to > make use of > > the security mechanism that taint mode gives us. > > > > Keep taint mode on in dev, so you can identify your issues in > development, then turn in off in prod.
Is that actually the generally recommended approach? I know there are some people that argue that warnings should also be turned off in prod, but I've always thought that having -wT in prod was the best way to ensure you don't get any security holes. I know it could be argued that the test rig in dev should pick up any issues, but when you're working on a public web based system you can't forsee every crazy and not-so-crazy permutation of input you end up getting. I wouldn't mind disabling taint as a temporary solution, if we found that the issue I'm having was a bug in mod_perl/some_module and it was just a case of accepting a fix, but I feel very nervous about giving up on taint mode in prod forever as this is something that I sell as an advantage of Perl to our security department when I argue why our application doesn't need to fit the standard company architectures that are designed with Java and .NET apps in mind. ------------------------------------------------------------------------ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ------------------------------------------------------------------------
