Bug#1022200: CPAN should be more helpful on missing key when check_sigs is enabled (Was: Re: cpan: cannot check signatures)

2022-10-22 Thread Vincent Lefevre
On 2022-10-22 17:33:03 +0200, Clément Hermann wrote:
> Le 22/10/2022 à 15:59, Vincent Lefevre a écrit :
> > I agree. There should be at least sufficient documentation when the
> > error occurs. If Debian could automatically provide the key and use
> > it, this would be better, IMHO: less work for the user, and this
> > would ensure (if correctly done) that the key is correct and still
> > valid.
> 
> Thing is, Debian cannot anticipate what modules you want to install via CPAN
> (so outside of Debian), so which developer keys to get, and also cannot
> install keys from all CPAN contributors in the user keyring…

I had to fetch a single key to be able to install 4 modules from
different developers. I hope that this isn't due to a bug.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Bug#1022200: CPAN should be more helpful on missing key when check_sigs is enabled (Was: Re: cpan: cannot check signatures)

2022-10-22 Thread Clément Hermann

Hi,

Le 22/10/2022 à 15:59, Vincent Lefevre a écrit :

Hi,

On 2022-10-22 14:31:24 +0200, Clément Hermann wrote:

I could reproduce your issue if I enable check_sigs option in CPAN
(which is _not_ the default).


OK, I forgot about that (though I think that it should be the default
for security reasons, and IIRC, this was recommended for this reason
in some other thread).


I do think it's a good idea to enable it.


Thing is, it's not a bug, really. Or not quite. It's a result of the
correction of a bug in CPAN < 2.29 who would succeed silently if there is no
signature/no way to check the key.

You can find some context in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015985 and
http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html


I didn't know that. In particular, I had not got any announce,
probably because it is still not fixed in Debian/stable. And
AFAIK, http is also still used by default in Debian/stable, so
that this makes the security even worse.


http or not won't change much, since CPAN uses a mirror network 
(arguably with only "safe" mirrors now). Checking the signature of the 
hashes is the right way to make sure a downloaded module is really the 
one a developer makes available.



I do agree that it's bad UX that CPAN isn't more helpful when the key isn't
available, e.g. asking for it or suggesting a way to get it, but the fact
that it fails if the key isn't available while the Checksums are signed is
the right behavior, and your workaround (getting the key) is the right
solution.

CPAN doesn't have a way to centralize key themself, and probably shouldn't,
either. Not sure how such error can be avoided completely (the Debian method
of having a preconfigured keyring won't do for CPAN IMO), but it should at
least suggest a solution.


I agree. There should be at least sufficient documentation when the
error occurs. If Debian could automatically provide the key and use
it, this would be better, IMHO: less work for the user, and this
would ensure (if correctly done) that the key is correct and still
valid.


Thing is, Debian cannot anticipate what modules you want to install via 
CPAN (so outside of Debian), so which developer keys to get, and also 
cannot install keys from all CPAN contributors in the user keyring…


A way to fix this would be to make the message in CPAN more helpful and 
propose to get the key from a known source (e.g. keyserver), but I think 
that really ought to be done upstream.


Note that in my current installation, a more helpful message is 
displayed at the end (possibly because I installed 
libmodule-signature-perl):


```
Module::Signature verification returned value 0E0

The manual says for this case: Cannot verify the
OpenPGP signature, maybe due to the lack of a network connection to
the key server, or if neither gnupg nor Crypt::OpenPGP exists on the
system. You probably want to analyse the situation and if you cannot
fix it you will have to decide whether you want to stop this session
or you want to turn off signature verification. The latter would be
done with the command 'o conf init check_sigs'
```

I'm guessing the key would be donwloaded with Crypt::OpenPGP installed 
(unfortunately not in Debian yet), but I didn't test.


Please report if you test with Crypt::OpenPGP installed via CPAN: if 
that makes the behaviour better UX-wise, we should package it (there are 
a few deps but I don't see any issue at a glance).


Cheers,


--
nodens



Bug#1022200: CPAN should be more helpful on missing key when check_sigs is enabled (Was: Re: cpan: cannot check signatures)

2022-10-22 Thread Vincent Lefevre
Hi,

On 2022-10-22 14:31:24 +0200, Clément Hermann wrote:
> I could reproduce your issue if I enable check_sigs option in CPAN
> (which is _not_ the default).

OK, I forgot about that (though I think that it should be the default
for security reasons, and IIRC, this was recommended for this reason
in some other thread).

> Thing is, it's not a bug, really. Or not quite. It's a result of the
> correction of a bug in CPAN < 2.29 who would succeed silently if there is no
> signature/no way to check the key.
> 
> You can find some context in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015985 and
> http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html

I didn't know that. In particular, I had not got any announce,
probably because it is still not fixed in Debian/stable. And
AFAIK, http is also still used by default in Debian/stable, so
that this makes the security even worse.

> I do agree that it's bad UX that CPAN isn't more helpful when the key isn't
> available, e.g. asking for it or suggesting a way to get it, but the fact
> that it fails if the key isn't available while the Checksums are signed is
> the right behavior, and your workaround (getting the key) is the right
> solution.
> 
> CPAN doesn't have a way to centralize key themself, and probably shouldn't,
> either. Not sure how such error can be avoided completely (the Debian method
> of having a preconfigured keyring won't do for CPAN IMO), but it should at
> least suggest a solution.

I agree. There should be at least sufficient documentation when the
error occurs. If Debian could automatically provide the key and use
it, this would be better, IMHO: less work for the user, and this
would ensure (if correctly done) that the key is correct and still
valid.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Bug#1022200: CPAN should be more helpful on missing key when check_sigs is enabled (Was: Re: cpan: cannot check signatures)

2022-10-22 Thread Clément Hermann

Hi!

Thanks for your report.

I could reproduce your issue if I enable check_sigs option in CPAN 
(which is _not_ the default).


Thing is, it's not a bug, really. Or not quite. It's a result of the 
correction of a bug in CPAN < 2.29 who would succeed silently if there 
is no signature/no way to check the key.


You can find some context in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015985 and
http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html

I do agree that it's bad UX that CPAN isn't more helpful when the key 
isn't available, e.g. asking for it or suggesting a way to get it, but 
the fact that it fails if the key isn't available while the Checksums 
are signed is the right behavior, and your workaround (getting the key) 
is the right solution.


CPAN doesn't have a way to centralize key themself, and probably 
shouldn't, either. Not sure how such error can be avoided completely 
(the Debian method of having a preconfigured keyring won't do for CPAN 
IMO), but it should at least suggest a solution.


So setting the severity back to normal, but still leaving the bug open, 
since it's confusing for the user, and it could be done better (upstream).


Cheers,

--
nodens