in reply to Re: cpan/cpanm integrity and authenticy checks concerns in thread cpan/cpanm integrity and authenticy checks concerns
Indeed, the keyserver has a very important role here (at least while
OpenPGP is the chosen approach). I actually believe this part is all
right as long as Internet access is avaiable.
But my point is that security is not enforced in any way. Seems
almost like it's an afterthought.
And actually, I think there might be some workarounds (some with
OpenPGP, some with other approaches):
-
With OpenPGP approach, maybe some keys from known developers
could be shipped together with perl (or maybe in separate
packages depending on the operating system). These keys take some
time to expire, and could be used to check for new other keys, in
a Web of Trust;
-
Outside of OpenPGP approach, however, there are options too. For
instance, I like OpenBSD's approach, with signify
. Every OpenBSD release contains the key necessary to verify
the next release, so indirectly every new key is signed by its
predecessor.
Maybe this could be applied to every Perl distribution, in
the sense that every distribution comes with the necessary key for
the next version. That way, at least every update will be safe.
It's worth noting these keys are relatively small (thanks to
ED25519 algorithm), so shipping them is cheap.
That way, only the first install would be unsafe, and a
compromised key could be easily detected during updates.
I know crypto solutions are not trivial, but I believe there are
options. I completely agree with the idea of giving choice to the
users, but I think security should be opt-out, not opt-in.
return on_success() or die;
Re^3: cpan/cpanm integrity and authenticy checks concerns
by eyepopslikeamosquito (Archbishop) on Jul 13, 2021 at 02:18 UTC
|
I agree.
This seems to be a hard problem, and broader than Perl's CPAN.
PyPI,
RubyGems, and
Npm, for example, all face similar problems:
It might be interesting to compare (and learn from) the security approaches taken by each of these similar mature open source repositories.
Update (2023)
> I'm not (yet) making heavy use of cpan or cpanm tools, and I'm still getting used to them
In case it helps, a detailed example of installing modules from CPAN securely on Linux, using cpan and cpanm,
can now be found here.
Thanks to your question, I now keep a long list of Security References (don't want to disappoint the LanX ;-):
| [reply] [d/l] [select] |
Re^3: cpan/cpanm integrity and authenticy checks concerns
by Anonymous Monk on Jul 14, 2021 at 16:31 UTC
|
Thanks for the idea. Shipping a root key with Perl and signing (perhaps via a few intermediaries) the developers' keys with it to let them sign their distributions would solve part of the Alice problem by providing a way for the user to verify that the package has been signed with a key known to the owner of the key (CPAN) which was signed by the root (Perl) key. I agree that having this system is better than not having a way to validate a developer's key and that this should protect from the evil mirror problem if the existing Perl installation is clean (and that latter assumption we just have to trust, see "Reflections on trusting trust" by Ken Thompson).
The current situation can be somewhat circumvented by only downloading packages from https://cpan.org/authors/id/... (effectively limiting oneself to a single mirror, which doesn't quite scale, and having to trust the HTTPS PKI, which is arguably not as good as a dedicated Perl PKI).
It should also be noted that typical supply chain attacks on modules involve typosquatting and taking over unmaintained modules, which, aside the author's public key visibly changing, wouldn't raise any louder alerts: the attacker would look the same as any other CPAN citizen, but the signed code supplied by them would also be malicious. But that's a social problem, likely impossible to solve by purely technical means.
| [reply] [d/l] |
|
But then, how would you know that the "shipped root key" is authentic?
| [reply] |
|
Well, if you're using system perl (and you trust the operating system
in the first place), than you can use the system perl provided key as a
first resource. Otherwise, that depends on how you obtained perl.
Clearly, we're always reaching a point of no-trust. This is an
unavoidable "chicken and egg" problem, because cryptography doesn't
magically create trust, despite what many folks out there say about
this. Making such assumptions might cause more trouble than not using
cryptography at all.
For it to work we must know the complexities and limits involved.
Trust depends on the physical world, and cannot be virtually
provided. So, however we use cryptography, it must be backed by physical
bounds. That's why we have some reasonable trust on integrated circuit
cards, while (hopefully) not so much on a credit card "security code",
which could be somehow leaked.
That said, you should only trust a key if:
- you obtain it directly from its owner;
- you obtain it from someone you absolutely trust to have obtained
it directly from its owner;
- you obtain it from someone you absolutely trust to have obtained
it from someone else who you also absolutely trust to have obtained
it directly from its owner;
- ... and so on (you get the picture). Needless to say, the bigger
this trust chain, the more fragile it is.
If such a trust chain cannot be created, then you must be willing to
accept some level of risk. Some measures can be taken to reduce that
risk, but it'll exist nonethless. One such measure is to disseminate
your public key over many channels, so that all of them would have to be
compromised by an attacker. Again, I'll mention OpenBSD with
signify on this:
... If you have either the chicken or the egg, you're all
set. But what about people with neither?
There are no key servers for signify. No web of trust. Just keys. The
good news is the keys are pretty small. As demonstrated. We can stick
them just about everywhere, and we do. They're on the web site, they're
on twitter, they're on the top side of CD. 56 base64 characters. You can
read it out loud over the phone in under a minute. Wide dispersion makes
it harder and harder to intercept all the ways you may get the key and
increases the risk of detection should anybody try some funny business.
Hopefully, key rotation will help on that. If you can't verify the
next key, then at least you know you had a compromised key. If you
follow its trail (how you obtained it), you might help to strenghten
the key distribution process.
return on_success() or die;
| [reply] |
|
|