If you've arrived to this page, it is likely that you've read in the
README file in one of the distributions I've published at
CPAN
, about the security measures I've taken to insure that
the code you've obtained hasn't been modified by anyone besides me.
The decision of taking explicit measures to protect the source code integrity that I distribute is based on the possibility that in any point of the path that the code you downloaded followed since the moment I published it until it got in your hands, something or someone may have altered it. Those alterations may be a simple data corruption, which can be detected easily, without causing greater problems. But there is also the possibility that a malicious entity manipulated the code, introducing unknown functions in it.
With the amount of users that my code has accumulated, that I can only estimated based on the communications I get, the least I can do as the responsible developer that I am, is deploy measures that are proportional to the level of trust that some of my users deposit every day in my code.
This page offers a series of simple explanations about this topic, based in the questions that I've recently received.
Security measures to protect the code
The mechanism that coording to my judgement, better integrates with the work of Perl developers, is the application of digital signatures the the distributions, which can then be published using the same channels that the distributions they protect. This insures easy access for any user wishing to do the verification.
I generate the digital signatures using public domain software
known as GPG. GPG is available in binary
form for a variety of platforms, as well as the source code, so it
should be within reach for any developer wishing to use it.
The crypto scheme backing the digital signatures, make essentially impossible to an impostor to forge a version of my code, unless he manages to capture my private key. This means that the measures taken to protect this key become important to estimate the level of protection offered by this scheme.
These are some of the measures I take to protect the integrity of the code I distribute:
- The working private key is always with me
The private key that I use to sign the distributions before releasing them, follows me wherever I go, in a removable solid state storage device.
At the times when I need to separate physically from the device for more than a few minutes, this is kept in a safe or left under custody.
There are two backups of the private key, stored in a safety box on different storage media.
- Multiple levels of crypto protection for the key
The private key is stored within a GPG keyring, which is kept encrypted by the software using a simetrical algorithm feed by a pass-phrase (this is, a very long password).
Additionaly, this file is stored in a logical partition that is also kept encrypted by a simetrical algorithm feed with a different password.
In the event of loss or theft of the device, the attacker would have to crack the cypto scheme protecting the logical partition, mount it in an adequate system to extract the keyring (still protected by GPG) and them crack this last cypto layer to reach the private key. All this, before it is possible to tell the comunity through the revocation of the key, that has been compromised.
- Strictly off-line access to the working private key
The logical partition hosting the keyring is never mounted on systems connected to the Internet.
- Independent source code
-
By keeping source code archives independent of the ones used for distribution to the end users, I have a permanent base line that allows for the comparison and eventual correction in case that a published distribution was altered.
The source code file is periodically backed up on non-rewrittable media, which is then stored at multiple locations, under custody.
It is important to stress that regardless these protection measures, this does not constitute any warranty. These measures and actions can be discontinued at any time and do not convey any responsability on my part.
Remember that you're the sole responsible party for the code you install on your computer and the effect it may have.
Public keys to verify the code
PGP/GPG keys have an associated
fingerprint that allows their verification. The key with
which any distribution distributed by me must be signed, is identified
with the number 0x123F8610 (see it here) and its fingerprint is:
Besides, it must be digitally signed by my other keys, so it can be easily verifiable.
The process of verification requires the instalation of GPG or an
equivalent tool, and the obtention of my public key. You can use the
data I supplied earlier to find the key at any of the public key servers.
Once you have my public key, you must import it to your keyring. An easy way to do this is to copy it to a file, let's say pubkey. Then, use the adequate options to your GPG client. This is an example (lightly edited to hide my address from spammers) using my tool:
$ gpg --import < pubkey gpg: /h/lem/.gnupg: directory created gpg: new configuration file `/h/lem/.gnupg/gpg.conf' created gpg: keyblock resource `/h/lem/.gnupg/secring.gpg': file open error gpg: keyring `/h/lem/.gnupg/pubring.gpg' created gpg: /h/lem/.gnupg/trustdb.gpg: trustdb created gpg: key 123F8610: public key "Luis E. Munoz <luismunoz_at_cpan.org>" imported gpg: Total number processed: 1 gpg: imported: 1
After doing this, the public key has been imported into the GPG keyring and we're ready to verify the code. This is an example of how a correct verification looks like:
$ gpg --verify NetAddr-IP-3.14.tar.gz.asc NetAddr-IP-3.14.tar.gz gpg: Signature made Wed Nov 13 13:48:52 2002 VET using DSA key ID 123F8610 gpg: Good signature from "Luis E. Munoz <luismunoz_at_cpan.org>"
But if the code has been altered in the tinniest way, the result will be notably different:
$ gpg --verify NetAddr-IP-3.14.tar.gz.asc NetAddr-IP-3.14.tar.gz gpg: Signature made Wed Nov 13 13:48:52 2002 VET using DSA key ID 123F8610 gpg: BAD signature from "Luis E. Munoz <luismunoz_at_cpan.org>"
It is very important that you never use code distributed by me, that fails the digital signature check unless you are certain that you obtained it directly from me as part of a bug fixing process. You must also know that any distribution published after the beginning of 2003, must have been signed by me.
In case you find code failing the verification or lacking it, please let me know. It is very important in these cases, that you preserve the distributed files that did not pass the verification, intact.
