pkg-perl-maintainers team mailing list archive

[Miriam España Acebal <2046154@xxxxxxxxxxxxxxxxxx>]

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