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 ** Changed in: libcryptx-perl (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Debian Perl Group, which is subscribed to libcryptx-perl in Ubuntu. https://bugs.launchpad.net/bugs/2046154 Title: [MIR] libcryptx-perl (libmail-dkim-perl dependency) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libcryptx-perl/+bug/2046154/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~pkg-perl-maintainers Post to : pkg-perl-maintainers@lists.launchpad.net Unsubscribe : https://launchpad.net/~pkg-perl-maintainers More help : https://help.launchpad.net/ListHelp
