I'm having some minor issues with pgpverify. The primary issue is that
the gpg command executed is failing:

../bin/pgpverify -test < control.test
<SNIP>
gpg: invalid option "--allow-weak-digest-algos"

The --allow-weak-digest-algos option is not available in my version of
GnuPG. Apparently it was introduced in GnuPG 2.0.23, but CentOS/RHEL 7
installs 2.0.22.

When I remove --allow-weak-digest-algos from pgpverify it executes, but
I'm wondering whether this portion of the output is expected:

[GNUPG:] TRUST_UNDEFINED
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.

I followed the tail end of the INSTALL document exactly for setting up
the keyring, but unsure whether this portion is related:

"You can safely answer "no" to questions about whether you want to sign,
trust, or certify keys. And you may afterwards do:

cp <pathetc in inn.conf>/pgp/pubring.gpg <pathetc in
inn.conf>/pgp/trustedkeys.gpg"

It seems the warning is related to the trust status of the key, but it
doesn't seem like pgpverify is concerned about this, and unsure whether
I should be or not.

Cheers,

Jesse Rehmer

Jesse Rehmer schrieb:

> The --allow-weak-digest-algos option is not available in my version of
> GnuPG.

You'll need GnuPG 1.x to verify old keys.

Hi Thomas,

>> The --allow-weak-digest-algos option is not available in my version of
>> GnuPG.
>
> You'll need GnuPG 1.x to verify old keys.

Besides 1.x, older versions in the 2.0.x branch can also verify old keys I think.
It changed in GnuPG 2.0.23:

What's New in 2.0.23
====================

* gpg: Reject signatures made using the MD5 hash algorithm unless the
new option --allow-weak-digest-algos or --pgp2 are given.

Jesse, did you try to install the previous version of pgpverify?
You'll see at the beginning of pgpverify 1.30, shipped with INN 2.7.0 (and since INN 2.6.2):

# Changes from 1.29 -> 1.30
# -- Support for GnuPG's gpg binary (in addition to gpgv). gpg (from
# GnuPG 1.x before 1.4.20, and GnuPG 2.0.x) still validates signatures
# made with weak digest algorithms like MD5 whereas current versions
# of gpgv no longer do.
# -- This new release of pgpverify requires at least GnuPG 1.4.20 or 2.1.0.
# If you're using an older version of GnuPG, you have to keep using
# pgpverify 1.29.

You should try pgpverify 1.29 from INN 2.6.1:
https://raw.githubusercontent.com/InterNetNews/inn/2.6.1/control/pgpverify.in

Update the first two lines with your paths.

Does it change anything in the behaviour you see?

--
Julien ÉLIE

« – Tu parles ?
– Tu parles ! » (Astérix)

Jesse Rehmer <jesse.rehmer@blueworldhosting.com> writes:

> I'm having some minor issues with pgpverify. The primary issue is that
> the gpg command executed is failing:

> ./bin/pgpverify -test < control.test
> <SNIP>
> gpg: invalid option "--allow-weak-digest-algos"

> The --allow-weak-digest-algos option is not available in my version of
> GnuPG. Apparently it was introduced in GnuPG 2.0.23, but CentOS/RHEL 7
> installs 2.0.22.

The right fix here is probably to make sure you have gpg1 installed (I'm
think any vintage of Linux distro that has gpg v2 also has a gpg1
package), and then set GPG=/usr/bin/gpg1 (I think that will do it,
although not completely sure). You can also use an older version of
pgpverify, but using gpg1 is probably simplest.

In general, right now you want to use gpg1 instead of gpg v2 to verify
control messages since some control message issuers haven't updated their
keys and produce signatures that the current versions of gpg v2 can't
verify at all.

> When I remove --allow-weak-digest-algos from pgpverify it executes, but
> I'm wondering whether this portion of the output is expected:

> [GNUPG:] TRUST_UNDEFINED
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg: There is no indication that the signature belongs to the
> owner.

This is fine, INN doesn't use the trust database. Instead, all keys in
the keyring are considered trusted.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On 5/25/22 2:48 PM, Russ Allbery wrote:
> The right fix here is probably to make sure you have gpg1 installed (I'm
> think any vintage of Linux distro that has gpg v2 also has a gpg1
> package), and then set GPG=/usr/bin/gpg1 (I think that will do it,
> although not completely sure). You can also use an older version of
> pgpverify, but using gpg1 is probably simplest.
>
> In general, right now you want to use gpg1 instead of gpg v2 to verify
> control messages since some control message issuers haven't updated their
> keys and produce signatures that the current versions of gpg v2 can't
> verify at all.

When pgpverify 1.3.0 (with the --allow-weak-digest-algos option removed)
and installing the gnupg1 package, both the new and old style keys are
being verified:

gpg: Signature made Tue 24 May 2022 12:35:50 PM CDT using RSA key ID
970EB10B
[GNUPG:] SIG_ID xS054Q+uMF6z5F/P+0z0sq8qrrI 2022-05-24 1653413750
[GNUPG:] GOODSIG FA423E89970EB10B control@usenet-fr.news.eu.org
gpg: Good signature from "control@usenet-fr.news.eu.org"

gpg: Signature made Wed 09 Jul 1997 04:57:10 PM CDT using RSA key ID
B88DA9C1
[GNUPG:] SIG_ID LYzKW94Pg/EiHeH1VcutLWdrimY 1997-07-09 868485430
[GNUPG:] GOODSIG C25D3AD3B88DA9C1 news.announce.newgroups
gpg: Good signature from "news.announce.newgroups"

Thanks for the pointer about gpg1, I didn't need to set any variables by
the way.

Also - thanks to Julien for pointing out the change details. Will
admit, I glossed over that.

Cheers,

Jesse

Jesse Rehmer <jesse.rehmer@blueworldhosting.com> writes:

> When pgpverify 1.3.0 (with the --allow-weak-digest-algos option removed)
> and installing the gnupg1 package, both the new and old style keys are
> being verified:

So you still have to modify pgpverify with gpg1? Hm. I guess that makes
sense; both GnuPG implementations are too old to support the flag. Well,
that's irritating, although I guess we already knew that was going to be a
problem on some hosts.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Russ Allbery <eagle@eyrie.org> writes:
> Jesse Rehmer <jesse.rehmer@blueworldhosting.com> writes:

>> When pgpverify 1.3.0 (with the --allow-weak-digest-algos option
>> removed) and installing the gnupg1 package, both the new and old style
>> keys are being verified:

> So you still have to modify pgpverify with gpg1? Hm. I guess that
> makes sense; both GnuPG implementations are too old to support the flag.
> Well, that's irritating, although I guess we already knew that was going
> to be a problem on some hosts.

Oh, I see, you need to convince it to use gpgv and then I think it will
not pass that flag and might work. I'm not sure off-hand what the best
way to do that is. I think it only uses gpgv if it can't find gpg, so
forcing that situation is a little tricky.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On 5/25/22 8:05 PM, Russ Allbery wrote:

>> So you still have to modify pgpverify with gpg1? Hm. I guess that
>> makes sense; both GnuPG implementations are too old to support the flag.
>> Well, that's irritating, although I guess we already knew that was going
>> to be a problem on some hosts.
>
> Oh, I see, you need to convince it to use gpgv and then I think it will
> not pass that flag and might work. I'm not sure off-hand what the best
> way to do that is. I think it only uses gpgv if it can't find gpg, so
> forcing that situation is a little tricky.
>

Correct, if I don't remove that flag from pgpverify no matter what I try
I end with:

gpg: invalid option "--allow-weak-digest-algos"

I can sympathize that this is not an easy solution for developers to
work around given the large variation in "default" versions of GnuPG
between distributions. This particular issue is one example why I'm
considering moving to FreeBSD from Linux. Overall seems easier to get
specific (mostly newer) versions of packages installed, whether via
pre-built packages or ports.

I work in the RHEL world and kept my own machines in parity with 'work'
to keep things simple. Time is teaching me this is not always wise
depending on the use case.

Cheers,

Jesse

Jesse Rehmer <jesse.rehmer@blueworldhosting.com> writes:

> Correct, if I don't remove that flag from pgpverify no matter what I try I
> end with:

> gpg: invalid option "--allow-weak-digest-algos"

The thing to try would be to set $gpg to '' in INN::Config and make sure
$gpgv points to the gpgv binary on your system. I bet that will work, but
making it work automatically is harder. We'd have to somehow probe for
whether gpg supported the option.

It's one of those problems that will go away eventually when everyone
upgrades older systems with older versions of GnuPG.

> I can sympathize that this is not an easy solution for developers to work
> around given the large variation in "default" versions of GnuPG between
> distributions.

Yeah, it adds and removes a wild number of options and supported things
between versions.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On 5/25/22 8:25 PM, Russ Allbery wrote:
> Jesse Rehmer <jesse.rehmer@blueworldhosting.com> writes:
>
>> Correct, if I don't remove that flag from pgpverify no matter what I try I
>> end with:
>
>> gpg: invalid option "--allow-weak-digest-algos"
>
> The thing to try would be to set $gpg to '' in INN::Config and make sure
> $gpgv points to the gpgv binary on your system. I bet that will work, but
> making it work automatically is harder. We'd have to somehow probe for
> whether gpg supported the option.

Turns out, I don't need the gnupg1 package to verify old keys since
GnuPG 2.0.22 supports the old format. Apparently, my only issue is that
I didn't read the changes to know that my version of GnuPG isn't going
to work with pgpverify 1.3.0.

Cheers,

Jesse

Hi Russ,

>> Correct, if I don't remove that flag from pgpverify no matter what I try I
>> end with:
>
>> gpg: invalid option "--allow-weak-digest-algos"
>
> The thing to try would be to set $gpg to '' in INN::Config and make sure
> $gpgv points to the gpgv binary on your system. I bet that will work, but
> making it work automatically is harder. We'd have to somehow probe for
> whether gpg supported the option.

gpg seems to check its arguments in order, and it exits with status 2 if
an argument is not supported.
Why not just run:

gpg --allow-weak-digest-algos --version

If the option is supported, gpg displays several lines and exits
gracefully. Otherwise, it raises an error:

gpg: Invalid option "--allow-weak-digest-algos"
zsh: exit 2 gpg --allow-weak-digest-algos --version

--
Julien ÉLIE

« It's documented in The Book, somewhere… » (Larry Wall)

Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:

> gpg seems to check its arguments in order, and it exits with status 2 if
> an argument is not supported. Why not just run:

> gpg --allow-weak-digest-algos --version

> If the option is supported, gpg displays several lines and exits
> gracefully. Otherwise, it raises an error:

> gpg: Invalid option "--allow-weak-digest-algos"
> zsh: exit 2 gpg --allow-weak-digest-algos --version

Thanks, yes, that was exactly the kind of thing I was hoping for but was
too groggy from travel to think through.

I wonder if we could do something like that in configure and pass down
something to pgpverify via INN::Config to tell it whether or not to add
that flag. This will probably only be needed temporarily, but it looks
like we have at least one user who is going to run into that version
bound, so there will probably be more.

I think it's safe to make the assumption that any version of GnuPG too old
to support that flag will still support the weak digest algorithms,
although I admit that while I researched this while updating PGP::Sign, I
have now forgotten all of my conclusions other than the version bound I
decided to adopt.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On 5/26/22 10:00 AM, Russ Allbery wrote:
>
> I think it's safe to make the assumption that any version of GnuPG too old
> to support that flag will still support the weak digest algorithms,
> although I admit that while I researched this while updating PGP::Sign, I
> have now forgotten all of my conclusions other than the version bound I
> decided to adopt.
>

My understanding is that versions prior to 2.0.23 support the weak
digests without the flag. Version 2.0.23+ support them, but only when
using the flag that was introduced in 2.0.23.

Can confirm that 2.0.22 without the flag is good on my end.

Hi Russ,

>> gpg seems to check its arguments in order, and it exits with status 2 if
>> an argument is not supported. Why not just run:
>
>> gpg --allow-weak-digest-algos --version
>
>> If the option is supported, gpg displays several lines and exits
>> gracefully. Otherwise, it raises an error:
>
>> gpg: Invalid option "--allow-weak-digest-algos"
>> zsh: exit 2 gpg --allow-weak-digest-algos --version
>
> Thanks, yes, that was exactly the kind of thing I was hoping for but was
> too groggy from travel to think through.
>
> I wonder if we could do something like that in configure and pass down
> something to pgpverify via INN::Config to tell it whether or not to add
> that flag. This will probably only be needed temporarily, but it looks
> like we have at least one user who is going to run into that version
> bound, so there will probably be more.

Would the following changes correspond to what you had in mind?
(the patch is not complete, but has the main logic)

I'll bump the version number of pgpverify to 1.31 if that's OK for you.

--- a/configure.ac
+++ b/configure.ac
@@ -441,7 +441,9 @@

dnl Look for PGP 5.0's pgpv, then pgp, then pgpgpg (not sure why anyone would
dnl have pgpgpg and not gpgv, but it doesn't hurt). Separately look for
-dnl GnuPG (which we prefer).
+dnl GnuPG (which we prefer) and whether it supports a flag introduced in
+dnl GnuPG 2.0.23 to allow weak hash algorithms like MD5 in old PGP keys still
+dnl used to sign control articles.
DO_PGPVERIFY=true
AC_ARG_VAR([GPGV], [Location of GnuPG gpgv program])
AC_ARG_VAR([GPG], [Location of GnuPG gpg program])
@@ -454,6 +456,16 @@
AC_SUBST([DO_PGPVERIFY])

+GPG_HAS_ALLOW_WEAK_DIGEST_ALGOS_FLAG=0
+AS_IF([test x"$GPG" != x],
+ [AC_MSG_CHECKING([if GnuPG recognizes the --allow-weak-digest-algos flag])
+ AS_IF(["$GPG" --allow-weak-digest-algos --version >/dev/null 2>&1],
+ [GPG_HAS_ALLOW_WEAK_DIGEST_ALGOS_FLAG=1
+ AC_MSG_RESULT([yes])],
+ [AC_MSG_RESULT([no])])])
+AC_SUBST([GPG_HAS_ALLOW_WEAK_DIGEST_ALGOS_FLAG])
+ +
dnl Look for a program that takes an ftp URL as a command line argument and
dnl retrieves the file to the current directory. Shame we can't also use
dnl lynx -source; it only writes to stdout. ncftp as of version 3 doesn't

--- a/control/pgpverify.in
+++ b/control/pgpverify.in
@@ -143,8 +143,15 @@
# and the script is able to successfully include your INN::Config module,
# the value of $INN::Config::gpg will override this. On a recent Debian
# variant, use /usr/bin/gpg1 (from the gnupg1 package) if you want to
-# support old signatures with MD5 digest algorithms.
+# support old signatures with MD5 digest algorithms. Or you may want to use
+# a more recent version of GnuPG (2.0.23+), in which case a special flag must
+# be added when running gpg; you then have to set the value of
+# $gpg_has_allow_weak_digest_algos_flag to 1 if --allow-weak-digest-algos is
+# supported, and 0 otherwise. If your INN::Config module has been included,
+# the value of $INN::Config::gpg_has_allow_weak_digest_algos_flag will override
+# this.
# $gpg = '/usr/local/bin/gpg';
+# $gpg_has_allow_weak_digest_algos_flag = 0;

# Path to the GnuPG gpgv binary, if you have GnuPG. If you do, this will
# be used in preference to PGP. For most current control messages, you
@@ -220,7 +227,7 @@ $log_date = -t STDOUT; # Do it if STDOUT is to a terminal.
require 5;

use strict;
-use vars qw($gpg $gpgv $pgp $keyring $tmp $tmpdir $lockdir $syslog_method
- $syslog_facility $syslog_level $log_date $findid $test $messageid);
+use vars qw($gpg $gpg_has_allow_weak_digest_algos_flag $gpgv $pgp $keyring
+ $tmp $tmpdir $lockdir $syslog_method $syslog_facility $syslog_level
+ $log_date $findid $test $messageid);

use Fcntl qw(O_WRONLY O_CREAT O_EXCL);
@@ -243,6 +250,7 @@ $pgp = $INN::Config::pgp
if $INN::Config::pgp && $INN::Config::pgp ne "no-pgp-found-during-configure";
$gpgv = $INN::Config::gpgv if $INN::Config::gpgv;
$gpg = $INN::Config::gpg if $INN::Config::gpg;
+$gpg_has_allow_weak_digest_algos_flag
+ = $INN::Config::gpg_has_allow_weak_digest_algos_flag
+ if $INN::Config::gpg_has_allow_weak_digest_algos_flag;
$tmp = ($INN::Config::pathtmp ? $INN::Config::pathtmp : $tmpdir) . "/pgp$$";
$lockdir = $INN::Config::locks if $INN::Config::locks;
$syslog_facility = $INN::Config::syslog_facility if $INN::Config::syslog_facility;
@@ -462,7 +470,10 @@ sub pgp_verify {
my @command;
if ($pgpstyle eq 'GPG') {
if ($gpg) {
- @command = ($gpg, qw/--verify --allow-weak-digest-algos/);
+ @command = ($gpg, qw/--verify/);
+ if ($gpg_has_allow_weak_digest_algos_flag) {
+ push (@command, qw/--allow-weak-digest-algos/);
+ }
push (@command, qw/--quiet --status-fd=1 --logger-fd=1/);
} else {
@command = ($gpgv, qw/--quiet --status-fd=1 --logger-fd=1/);

--- a/perl/INN/Config.pm.in
+++ b/perl/INN/Config.pm.in
@@ -146,8 +146,9 @@ our $syslog_facility = lc('@SYSLOG_FACILITY@');
$syslog_facility =~ s/log_//;

## Set up some useful parameters.
-my @PARAMVAR = qw($do_dbz_tagged_hash);
+my @PARAMVAR = qw($do_dbz_tagged_hash $gpg_has_allow_weak_digest_algos_flag);
our $do_dbz_tagged_hash = '@DO_DBZ_TAGGED_HASH@';
+our $gpg_has_allow_weak_digest_algos_flag
+ = @GPG_HAS_ALLOW_WEAK_DIGEST_ALGOS_FLAG@;

## Set up some environment values.
if ($ovmethod && $ovmethod eq "ovdb") {

--
Julien ÉLIE

« Il n'y a que le premier pas qui coûte. » (Mme du Deffand)

Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:

> Would the following changes correspond to what you had in mind?
> (the patch is not complete, but has the main logic)

> I'll bump the version number of pgpverify to 1.31 if that's OK for you.

Yup, this looks great, that's exactly the sort of thing I was thinking of.
Thank you!

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On 5/28/22 3:30 PM, Russ Allbery wrote:
> Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:
>
>> Would the following changes correspond to what you had in mind?
>> (the patch is not complete, but has the main logic)
>
>> I'll bump the version number of pgpverify to 1.31 if that's OK for you.
>
> Yup, this looks great, that's exactly the sort of thing I was thinking of.
> Thank you!
>

Following up on this (in the correct thread this time), I think it
should be better documented that to successfully process the majority of
control articles and NoCeM notices you need GnuPG <2.1.0.

There are multiple references to 1.x and 2.x (see perl-nocem man page,
for example) scattered throughout documentation. Complete removal of
support for PGP-2 keys was done in GnuPG 2.1.0
(https://www.gnupg.org/faq/whats-new-in-2.1.html#nopgp2) regardless of
using the --with-weak-digest-algos flag.

To compound matters, there also exists a potential conflict of gpg/gpgv
binaries and which versions of GnuPG they point to based on
OS/distribution if GnuPG 1.4.x and 2.x packages are installed at the
same time. In the case of CentOS vs FreeBSD with both GnuPG packages
installed, CentOS's gpg and gpgv are symlinks to gpgv2 (so to get GnuPG
1.4 functionality I need to execute gpgv1), but on FreeBSD gpg and gpgv
are the v1 binary. Not sure if it is worth testing for this and
preferring the "gpg1" binary above all else?

Cheers,

Jesse

Jesse Rehmer <jesse.rehmer@blueworldhosting.com> writes:

> Following up on this (in the correct thread this time), I think it
> should be better documented that to successfully process the majority of
> control articles and NoCeM notices you need GnuPG <2.1.0.

Yes, that's a good point.

I will say, more generally, there's really no future to this. Almost no
one is going to keep running old versions of GnuPG just for Usenet, nor
should they. The option would be to only use GnuPG 1.4.x, but it's
essentially unmaintained at this point and I would not assume that it will
continue to stick around.

The only long-term solution is for control message issuers to modernize
their software, which in turn is going to require modernizing keys.

But for the upcoming release, I just pushed some updates to INSTALL to try
to capture the version requirements for some control messages.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Hi Jesse,

> Following up on this (in the correct thread this time)

I see that you indeed cancelled your previous message in another thread,
no problem!

> I think it
> should be better documented that to successfully process the majority of
> control articles and NoCeM notices you need GnuPG <2.1.0.

As far as NoCeM notices are concerned, all of the still active issuers
use a modern PGP key, so any version of GnuPG will be fine.
Control articles are the real limitation right now.

> To compound matters, there also exists a potential conflict of gpg/gpgv
> binaries and which versions of GnuPG they point to based on
> OS/distribution if GnuPG 1.4.x and 2.x packages are installed at the
> same time.  In the case of CentOS vs FreeBSD with both GnuPG packages
> installed, CentOS's gpg and gpgv are symlinks to gpgv2 (so to get GnuPG
> 1.4 functionality I need to execute gpgv1), but on FreeBSD gpg and gpgv
> are the v1 binary.  Not sure if it is worth testing for this and
> preferring the "gpg1" binary above all else?

This is already handled by INN at configure time. It checks for the
binary to use in the following order: gpg1, gpg, then gpg2.
So GnuPG 1.x will be selected, if present at configure time.

--
Julien ÉLIE

« Je n'aime pas faire du char-stop ! » (Astérix)

On 6/1/22 4:28 PM, Julien ÉLIE wrote:
>
> This is already handled by INN at configure time.  It checks for the
> binary to use in the following order:  gpg1, gpg, then gpg2.
> So GnuPG 1.x will be selected, if present at configure time.
>

Thank you, I forget many of these items are set from configure. Since
initially I had only the gnupg2 package installed when I built INN, I
understand I may need to re-configure/compile/update now.

Thanks again, Julien!

Cheers,

Jesse

Hi Jesse,

>> This is already handled by INN at configure time.  It checks for the
>> binary to use in the following order:  gpg1, gpg, then gpg2.
>> So GnuPG 1.x will be selected, if present at configure time.
>
> Thank you, I forget many of these items are set from configure.  Since
> initially I had only the gnupg2 package installed when I built INN, I
> understand I may need to re-configure/compile/update now.

Re-configuring/compiling/updating would work, yes.
More quickly, you can simply change the variables in
<pathlib>/perl/INN/Config.pm or whatever location you have for that file:

our $gpgv = '/usr/bin/gpgv1';
our $gpg = '/usr/bin/gpg1';

And of course make sure gpg1 has the keys in its ring.

--
Julien ÉLIE

« Pour une personne optimiste, le verre est à moitié plein. Pour une
personne pessimiste, il est à moitié vide. Pour l'informaticien, il
est deux fois plus grand que nécessaire. »