Re: Can the legacy HAVE_LIBGCRYPT_AEAD check be removed?

[John Thacker <johnthacker () gmail com>]

On Tue, Jul 13, 2021 at 2:26 AM Pascal Quantin <pascal () wireshark org> wrote:

> Hi Matthias,
>
> Le lun. 12 juil. 2021 à 21:22, Dr. Matthias St. Pierre <
> Matthias.St.Pierre () ncp-e com> a écrit :
>
> > Hi all,
> >
> > in wsgcrypt.h the libgcrypt version is checked to ensure that it supports
> > AEAD ciphers:
> >
> >         #if GCRYPT_VERSION_NUMBER >= 0x010600 /* 1.6.0 */
> >         /* Whether to provide support for authentication in addition to
> > decryption. */
> >         #define HAVE_LIBGCRYPT_AEAD
> >         #endif
> >
> >         (see [1])
> >
> > Given the fact that libgcrypt 1.6.0 was released in 2013-12-16 (see [2]),
> > I was wondering whether after such a long time it would be acceptable to
> > simplify
> > all the conditional code depending on HAVE_LIBGCRYPT_AEAD by making
> > GCRYPT_VERSION_NUMBER >= 0x010600 a requirement and removing  the
> > #else code parts.
> >
> > The reason why I am asking is because the packet-isakmp dissector has
> > some conditional code to emulate AES-GCM using AES-CTR in the absence
> > of HAVE_LIBGCRYPT_AEAD which I'd like to remove. I did some git history
> > research and noticed that there were some recent commits in 2020 related
> > to fixing compilation without HAVE_LIBGCRYPT_AEAD  (see [3]). However,
> > I'm not sure whether this was done deliberately to support libgcrypt < 1.6.0
> > or just out of habit because nobody considered the option of removing the
> > legacy check.
>
> If some changes were done to fix the compilation, it means that some
> people still use a libgcrypt version older than 1.6.0. And as seen in our
> CMakeLists.txt file,
> the minimum version required for now is 1.5.0.

The minimum version being stuck at 1.5.0 is, I believe, almost entirely due
to RHEL/CentOS 7 being stuck at 1.5.3
(
https://gitlab.com/wireshark/wireshark/-/wikis/Development/Support_library_version_tracking#libgcrypt
)

It's a widely used enough distribution, still scheduled for 3 more years of
support, that I think that for now the current approach of supporting it is
reasonable. We do warn about it in strong terms.
(The RH package may have some backports of features from later versions,
but I haven't looked into it.)

If at some point we want to drop RHEL 7 (and in a similar fashion, SUSE
Enterprise Server 12), there's a number of packages whose version could be
bumped, as seen on that page.

John Thacker

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe