Front page | perl.perl5.porters |
Postings from July 2012
On Tue, Jul 24, 2012 at 06:12:44PM +0200, Abigail wrote: > On Tue, Jul 24, 2012 at 03:49:25PM +0100, Nicholas Clark wrote: > > It's potentially going to cause alarm if the report says "security report", > > because it could be anything from "no, it's not" to "OMG, pwnies", and some > > people will (understandably) suspect the worst. Whereas my impression is that > > what is needed for dealing successfully with a messy issue is no publicity, > > until the co-ordinated response is ready to roll. > > > Can't you just say something like "Dealing with 'require ::foo'" (or whatever > it will be the next time you're dealing with a potential security issue)? > That isn't hiding or bending any truth, nor should it cause any unjust alarms. The trouble is that anything descriptive enough ends up revealing where the problem is to any black hats. 'require ::foo' strikes me as a perfect example of this - it tells you exactly where to look to exploit the problem. So if it gets used as the description of something that took hours but didn't get commented on, it starts to highlight itself as "interesting". In this case, the red flag as to the problem is in the error message: $ perl -e 'require ::foo' Can't locate /foo.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.9/BSDPAN /usr/local/lib/perl5/site_perl/5.8.9/mach /usr/local/lib/perl5/site_perl/5.8.9 /usr/local/lib/perl5/5.8.9/mach /usr/local/lib/perl5/5.8.9 .) at -e line 1. I really don't think that it's a good idea using accurate descriptions of live issues to describe live but private issues, even if they're not highlighted as being "security", as the description alone may be enough to let others figure it out. Nicholas ClarkThread Previous | Thread Next