Comment 2 for bug 2046154

Thanks Christian for the review.

Following your "Options to overcome this IMHO:"

1- finding a perl lib doing ed25519 cleanly
  And then change libmail-dkim-perl to use that

Doing a search on metacpan (https://metacpan.org/search?size=20&q=Ed25519) I found between the 17 results one that could be promising:

https://metacpan.org/pod/Crypt::Perl::Ed25519 (last release on Oct 2022), which doesn't depend on CryptX (unlike [2], which could be another option). In fact, in the Crypt::Perl repository [1] you can read:

" This is useful if you don’t have access to other tools that do this work like OpenSSL, CryptX, etc."

But:
- It is not packaged as a debian package (a New/needs-packaging task should be started for this, and after that, MIR it).
- It contains other crypto items and algorithms, as RSA (already in main from libcrypt-openssl-rsa-perl as you said above).

A more experienced PERL developer than I could shed light on this in the sense if it's worth using this Perl module or if she/he has experience with it (asking that in IRC, actually).

2- separating the ed25519 functions from bin:libcryptx-perl
  then let libmail-dkim-perl depend on libcryptx-perl-ed25519
  and we'd only promote libcryptx-perl-ed25519 (if that code is ok)

I have been researching this too: the TL;DR is I'm afraid we cannot get rid of tomcrypt. Following is the explanation:

 In the interface file between perl and C CryptX.xs, line 151 we can see:

typedef struct ed25519_struct { /* used by Crypt::PK::Ed25519 */
  prng_state pstate;
  int pindex;
  curve25519_key key;
  int initialized;
} *Crypt__PK__Ed25519;

and, for example, curve25519_key is declared in:

src/ltc/headers/tomcrypt_pk.h:
  340 unsigned char pub[32];
  341: } curve25519_key;

ok, but maybe we don't need (or better said, dkim doesn't need) to pass from ed25519 to curve2551. Fair, but it still use a prng_state struct defined in

src/ltc/headers/tomcrypt_prng.h:
   71 LTC_MUTEX_TYPE(lock) /* lock */
   72: } prng_state;
   73

The whole ed25519_struct structure is used in the inc/CryptX_PK_Ed25519.xs.inc for initialize theEd25519 class, using other functions that belong to tomcrypt library (like rng_make_prng from src/ltc/headers/tomcrypt_prng.h). Apart from that, I discovered it uses a header file produced by https://metacpan.org/release/ATOOMIC/Devel-PPPort-3.68/source, and that this file (ppport.h) is behind that version (3.52, outdated) because it is embedded in CryptX source tree.

3- ...?
   (Not cool/friendly for the users) What if we switch off the commit that introduced this dependency while doing 1 ? The commit in upstream repo is this [3].

[1] https://github.com/FGasper/p5-Crypt-Perl
[2] https://metacpan.org/pod/Net::SSH::Perl::Key::Ed25519
[3] https://github.com/fastmail/mail-dkim/pull/18/files