Securing CPAN

--000000000000de8a3e05a6569eda
Content-Type: text/plain; charset="UTF-8"

CPAN Members,

Greetings! I was hoping to understand the community's interest and appetite
for helping to secure CPAN. I noticed that CPAN out-of-the-box uses FTP or
HTTP for module downloads, sets check_sigs to 0 by default, doesn't require
Module::Signature or include it in Bundle::CPAN, and that some packages
don't have a signed CHECKSUMS file.

This combination of factors mean that users of CPAN are vulnerable to
man-in-the-middle attacks by default and broadcast their module activity on
the network. Many other popular language repositories (pip, npm, crates,
golang, composer) support or enforce the use of HTTPS for downloading
third-party code from authoritative sources. This helps to ensure the
integrity of downloaded source code and masks network activity.

I felt like a reasonable first step would be to see whether current CPAN
mirrors already support HTTPS. In surveying mirrors listed in MIRRORED.BY,
a majority - 99 of the 192 HTTP mirrors - already correctly support vending
CPAN over HTTPS. Huzzah! A further ten vended an outdated and/or
self-signed cert (easily enough fixed with LetsEncrypt - I took the liberty
of notifying these mirror admins of the misconfiguration), and another 13
vended a valid cert but with the wrong CNAME. (FYI, one mirror didn't even
have DNS that resolved and responded to my email that his mirror is
permanently offline.) So we're already quite close to a majority of current
CPAN mirrors vending on HTTPS. The "hard work" is mostly done!

The next thing to do would be to add *dst_https* for these mirrors to
MIRRORED.BY and update CPAN.pm to be able to connect to HTTPS repositories
and validate server certificates (the hard parts here are already
implemented with LWP::Protocol::https and Mozilla::CA). Over time it would
seem sensible to *prefer* HTTPS when available and then at a later time
make HTTPS *required* by default so CPAN users can out-of-the-box have some
mild assurance they're downloading the software they think they're
downloading.

I've written up some thoughts and the details of such a plan at:
https://docs.google.com/document/d/1DRkiCJhJu4RDI0u_JppBpFa0djouskxEyNHax912U_w/edit#
and would *really appreciate input and comments*. I also have an
embarrassingly broken, untested, and incomplete pull request at
https://github.com/andk/cpanpm/pull/119 but before further embarking on
polishing the PR I wanted to ask whether this is something the community is
interested in / has thought about / others have already made progress on?

Cheers,
 David E. Weekly (@dweekly)

--000000000000de8a3e05a6569eda
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">CPAN Members,<br><br>Greetings! I was hoping to understand=
 the community&#39;s interest and appetite for helping to secure CPAN. I no=
ticed that CPAN out-of-the-box uses FTP or HTTP for module downloads, sets =
check_sigs to 0 by default, doesn&#39;t require Module::Signature or includ=
e it in Bundle::CPAN, and that some packages don&#39;t have a signed CHECKS=
UMS file.<div><br></div><div>This combination of factors mean that users of=
 CPAN are vulnerable to man-in-the-middle attacks by default and broadcast =
their module activity on the network. Many other popular language repositor=
ies (pip, npm, crates, golang, composer) support or enforce the use of HTTP=
S for downloading third-party code from authoritative=C2=A0sources. This he=
lps to ensure the integrity of downloaded source code and masks network act=
ivity.</div><div><br></div><div>I felt like a reasonable first step would b=
e to see whether current CPAN mirrors already support HTTPS. In surveying m=
irrors listed in <a href=3D"http://MIRRORED.BY">MIRRORED.BY</a>, a majority=
 - 99 of the 192 HTTP mirrors - already correctly support vending CPAN over=
 HTTPS. Huzzah! A further ten vended an outdated and/or self-signed cert (e=
asily enough fixed with LetsEncrypt - I took the liberty of notifying these=
 mirror admins of the misconfiguration), and another 13 vended a valid cert=
 but with the wrong CNAME. (FYI, one mirror didn&#39;t even have DNS that r=
esolved and responded to my email that his mirror is permanently offline.) =
So we&#39;re already quite close to a majority of current CPAN mirrors vend=
ing on HTTPS. The &quot;hard work&quot; is mostly done!</div><div><br></div=
><div>The next thing to do would be to add <font face=3D"monospace"><b>dst_=
https</b></font> for these mirrors to <a href=3D"http://MIRRORED.BY">MIRROR=
ED.BY</a> and update CPAN.pm to be able to connect to HTTPS repositories an=
d validate server certificates (the hard parts here are already implemented=
 with LWP::Protocol::https and Mozilla::CA). Over time it would seem sensib=
le to <i>prefer</i>=C2=A0HTTPS when available and then at a later time make=
 HTTPS <i>required</i>=C2=A0by default so CPAN users can out-of-the-box hav=
e some mild assurance they&#39;re downloading the software they think they&=
#39;re downloading.</div><div><br></div><div>I&#39;ve written up some thoug=
hts and the details of such a plan at:=C2=A0<a href=3D"https://docs.google.=
com/document/d/1DRkiCJhJu4RDI0u_JppBpFa0djouskxEyNHax912U_w/edit#">https://=
docs.google.com/document/d/1DRkiCJhJu4RDI0u_JppBpFa0djouskxEyNHax912U_w/edi=
t#</a>=C2=A0 and would <i>really appreciate input and comments</i>. I also =
have an embarrassingly broken, untested, and incomplete pull request at=C2=
=A0<a href=3D"https://github.com/andk/cpanpm/pull/119">https://github.com/a=
ndk/cpanpm/pull/119</a>=C2=A0but before further embarking on polishing the =
PR I wanted to ask whether this is something the community is interested in=
 / has thought about / others have already made progress on?</div><div><div=
><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_signature" data-sma=
rtmail=3D"gmail_signature">Cheers,<br> =C2=A0David E. Weekly (@dweekly)<br>=
</div></div></div></div></div>

--000000000000de8a3e05a6569eda--