Hi, long time no see. I didn't die, just off checking out other planets. :-) My meditation came about as I tried to think of ways to make Perl economically useful. I thought the most useful tool one could have now, is some sort of end-to-end encrypted communications system, written in Perl, yet really can't be tampered with without proper keys, etc. Much like Microsoft's new voting system. :-)
Anyways, how secure is a properly compiled and sha-checked source install of Perl and its core sockets modules. Are they prone to breaking, are there obvious security flaws that would preclude it from being used for encrypted end-2-end messaging scheme. Are there problems in Perl's buffers that make it vulnerable to text-mining core dumps etc. Would you buy a working end-2end port-specific encryption system written is Perl? Would you trust it in encrypted communications? This idea is probably my last attempt to make use of Perl, but would Perl stand up in court as being a viable software choice? Could I be shown to be negligent by using Perl? :-)
I expect this meditation to go on for awhile. :-)

I'm not really a human, but I play one on earth. ..... an animated JAPH

Replies are listed 'Best First'.
Re: security and Perl
by atcroft (Abbot) on May 09, 2019 at 07:29 UTC

    An interesting meditation, to be sure.

    How secure is a properly compiled and sha-checked source install of Perl and its core sockets modules? I would start with search of the Common Weakness Enumeration, National Vulnerability Database, or similar trusted site. Also, a look at rt.perl.org (searching for "CVE-", or similar) might be assistive.

    Are they prone to breaking, are there obvious security flaws? Recently at $job I heard a discussion about issues reported in a security scan because the version of perl being used supposedly had vulnerabilities. (From what I read on the specific vulnerabilities, however, it appeared they involved setting environment variables, but it would be something to find out more about.)

    Would you trust it in encrypted communications? I think that would depend on a number of things. The first in my consideration, which also goes toward your later question of, would Perl stand up in court as being a viable software choice? would be on whether the whole thing were home-grown, or if modules (CPAN or otherwise) were used, if the modules used are available for examination, if the module developer has sufficient expertise and experiencing in cryptographic matters, and if there are sufficient tests to reasonably assure a user that due diligence was taken (among others).

    Personally, I would not specifically rule in or out a product on the basis of the language used, as "crap code can be written in any language" (I think there is an actual quote like that, although something different being written). If the author(s) are diligent, use care in the code they develop and in the process of selecting what outside code they may use, and are transparent and responsive, I do not see a reason why it could not be plausible.

    My $0.02, at least. Hope that helps.

Re: security and Perl
by FreeBeerReekingMonk (Deacon) on May 11, 2019 at 11:09 UTC
    Reverse that thought: As long as there is someone to blame (read: payed support for the software), then it's OK to use it. So if Core Perl comes with AIX, backed by IBM or Core Perl comes with RedHat, backed by RedHat, or Core Perl comes with Windows, backed by ActiveState. then it's OK to use it.

    Mitel (they do IP phones for businesses), for example, has their core management software written in Perl (robust), all tools around it are written in more modern languages (Java) and interface to it.

    I've seen one case in the wild, where they had this specific, certified Perl version, in a separate directory to run a program that connected to a database. It broke when the new OS C libraries were not supported anymore (Perl binds to C for low-level things). Instead of rolling back the OS (because the security team pushed those changes, these are not reversible) the software was abandoned (due to too little time/knowledge to fix it and a management decision to replace it) (yes, probably an update in the hashbangs and a re-download of the relevant CPAN would have fixed it - but we did not get authorization to download from CPAN)

    As for trusting your encryption code. No. You will need to seek 3rd party certification for that, unless you are a big company with a name already. The certification, of course, is on top of your fuzzing, Robustness testing and your weekly/monthly? report of your TestDrivenDesign test-suit against a freshly patched OS (and maybe even the customer's flavour of Patches). It's lots of work, unless automated, to certify that a CVE patch will not break your software... and that means testing each individually, or as a group.

    If I put on my Managers hat, then I would trust a leaky Java, DotNet, $flashyLanguage E2E-encryption software more than a Perl E2E-encryption software. Don't tout that it's Perl on the first page. Perl is not sexy at the moment. Old and Stable is not a selling point. But having Ansible checks the CRC's and certify that your software is still "original and unchanged" is... and it's auditable.

    Also note that because there are less eyeballs on a language, the amount of bugs found is less. While weird experimental stuff is still added to it...

    As for hacking your system. Depending on how important it gets, maybe nobody will care to hack it. However, read up on SoftICE (sorry my age is showing) and strace and man-in-the-middle.

    This year I played with a certain tsocks/toxsocks encryption. I bound to their compiled libraries and got their password encryptor/decryptor working, because it was modular, and small.

    So instead of embeddable E2E and selling only the software I would go for total solution, and also sell the hardware. Don't use R-Pi's (not even for a show-case) but only use expensive and certified hardware (a good NUC, for example)! And if you go for software only, maybe go opensouce, like PGP and sell certified solutions with it.

    Anyway, good luck with your journey deciding for Perl!

        Nice to see you back, this site needs more like you.