| [reply] |
I am no IT security guru. In trying to read all the information in the docs you've pointed out (and a few others), I see that it's a bit much for me to digest. What I need is a sort of security-related-smoking-gun to present to the overlords as a stong motivator to upgrade ( I need the upgrade for a module install). Any help? Thanks in advance. | [reply] |
I don't think you're going to manage to get this, the Perl 5 series has been pretty secure overall. There's also the downside that many 'overlords' may look at your smoking gun and go 'Okay, we can't trust Perl.. let's get some Java going in there, I hear that's secure'.
| [reply] |
| [reply] |
contrive
To invent or fabricate
To plan with evil intent
surreptitious
Obtained, done, or made by clandestine or stealthy means.
Acting with or marked by stealth
The upgrade is based on the need of the functionality offered in later version. This is already clear to everyone involved. There has been no dishonesty. I don't remember posting "I need a way to fool these idiots into thinking theres a problem when there really isn't". Nor do I remember posting "Can someone help me MAKE UP a FAKE security issue?". The oposition is security based, that's why I asked. Thanks, anyway, for the morality lesson. I'll bring it up next time I'm in church.
| [reply]
[d/l] |
then I appologize for my misunderstanding...I was basing my comments on your later statement (assuming it was the same Anonymous Monk) "What I need is a sort of security-related-smoking-gun to present to the overlords as a stong motivator to upgrade ( I need the upgrade for a module install)."
I appologize if my intrepretation of your statement that you wanted to point out a security issue as a reason for you to get your upgrade so you can use a module was incorrect.
Still, I stand by the intent of my previous post...if you need the upgrade to get a module you want to use, why not just say so instead of trying to play the security card?
| [reply] |
You would be better off asking us how to address the security concern that you are being opposed with than you are asking us to find a security problem with the old version of Perl. It may be that the issue is a non-issue. It may be a real issue but someone is saying "security" when they really mean something closer to "control". It may be that you would be violating a security policy which exists for a good reason, and that point is a blow against you no matter how you cut things.
I would be more specific on that, but I have no idea what security objections you are being confronted with.
Instead I will be specific with what you said here. You asked about security problems with a specific version of Perl, and then said that you wanted to know this to try to get them to upgrade. That is clearly a case of a conclusion begging a line of reasoning. My experience is that people who rightly or wrongly give that impression quickly find any reasoning that they present promptly dismissed by everyone who knows them because of the obvious bias.
Indeed I would tell you that in the long run (and the run need not be very long), being seen as willing to lose a battle because the immediate facts don't support your side will win you more battles fairly shortly thereafter. Sometimes you even wind up winning the original battle that you gave up. If there is a security objection, and the objection is fair, a willingness to acknowledge that and work with the objectors to address rather than dismiss their objection may be the best way to get results.
| [reply] |