[MIR] libcryptx-perl (libmail-dkim-perl dependency)

[Miriam España Acebal]

[MIR] libcryptx-perl (libmail-dkim-perl dependency)

Package: libcryptx-perl

[Availability]
The package libcryptx-perl is already in Ubuntu universe.
The package libcryptx-perl build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x (any)
Link to package https://launchpad.net/ubuntu/+source/libcryptx-perl

[Rationale]
The package libcryptx-perl is required in Ubuntu main for libmail-dkim-perl .
The package libcryptx-perl will not generally be useful for a large part of
our user base, but is important/helpful still because is required as runtime dependency by libmail-dkim-perl that is already in main.

libmail-dkim-perl it's a perl module to cryptographically identify the sender of email (implementing the new Domain Keys Identified Mail (DKIM)), used by spamassassin and amavisd-new. The following changes have been added to libmail-dkim-perl since the version we have released in noble:

1.20230911 2023-09-11 UTC
  * Option to add custom tags to generated ARC signatures and seals

1.20230630 2023-06-30 UTC
  * Add support for Ed25519 signature types
    Thanks to Matthäus Wander @mwander
  * Option to add custom tags to generated signatures

the 'Add support for Ed25519' is the one that requires the use of Crypt::PK::Ed25519, provided by the libcryptx-perl package.

Apparently, no other packages provide similar functionality:

root@Nlib-dkim-perl:~# apt-file search Ed25519 | grep perl
 libcryptx-perl: /usr/lib/x86_64-linux-gnu/perl5/5.36/Crypt/PK/Ed25519.pm
 libcryptx-perl: /usr/share/man/man3/Crypt::PK::Ed25519.3pm.gz

The package libcryptx-perl is required in Ubuntu main as soon as possible, since libmail-dkim-perl depends on it and libmail-dkim-perl is already in main.

[Security]
No CVEs/security issues in this software in the past:
  - (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libcryptx-perl
  - (0) https://ubuntu.com/security/cves?q=&package=libcryptx-perl
  - (0) https://security-tracker.debian.org/tracker/source-package/libcryptx-perl
No `suid` or `sgid` binaries.
No executables in `/sbin` and `/usr/sbin`.
Package does not install services, timers or recurring jobs.
Package does not open privileged ports (ports < 1024).
Package does not expose any external endpoints.
Package contains extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...);
It's a Perl module that provides a self-contained cryptographic toolkit :
CryptX is a self-contained cryptgraphico toolkit based on https://github.com/libtom/libtomcrypt.
It provides cyphers, block cipher modes, authenticated encryption modes, hash functions, message authentication
codes, public key cryptography, cryptographically secure random number generators, key derivation functions.
The package provides a shared library for this too.

[Quality assurance - function/usage]
The package works well right after the install.

[Quality assurance - maintenance]
The package is maintained well in Debian/Ubuntu and does
not have too many, long-term & critical, open bugs:
   - Ubuntu (1) https://bugs.launchpad.net/ubuntu/+source/libcryptx-perl/+bug
   - Debian (0) https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libcryptx-perl
   - Upstream's bug tracker (4) https://github.com/DCIT/perl-CryptX/issues
     + Upstream's repo last activity: https://github.com/DCIT/perl-CryptX
       - last commit: in master, Oct 17, 2023
       - Issues without answer: 3
       - Updated issue/PR: Oct 30, 2023
       - last fixed/closed/merged issue: Oct 9, 2023
       - last merged PR: Oct 9, 2023
The package has an important/old open bug on upstream, affecting FreeBSD initially:
 - SIGILL when calling verify_message (https://github.com/DCIT/perl-CryptX/issues/98)

The package does not deal with exotic hardware we cannot support.

[Quality assurance - testing]
The package runs a test suite on build time, if it fails
it makes the build fail: https://launchpad.net/ubuntu/+source/libcryptx-perl/0.080-2/+build/27021219/+files/buildlog_ubuntu-noble-amd64.libcryptx-perl_0.080-2_BUILDING.txt.gz :

   dh_auto_test
 make -j4 test TEST_VERBOSE=1
make[1]: Entering directory '/<<PKGBUILDDIR>>'
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- CryptX.bs blib/arch/auto/CryptX/CryptX.bs 644
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" t/*.t

The package runs an autopkgtest (via autodep8 using 'Testsuite: autopkgtest-pkg-perl' in d/control file - https://git.launchpad.net/ubuntu/+source/libcryptx-perl/tree/debian/control#n5 -),
that runs essentialy the above build-time test suite. It is currently passing on
this list of architectures (amd64, arm64, armhf, i386, ppc64el, s390x): https://autopkgtest.ubuntu.com/packages/l/libcryptx-perl

[Quality assurance - packaging]
debian/watch is present and works.

debian/control defines a correct Maintainer field : Debian Perl Group <email address hidden> ( https://git.launchpad.net/ubuntu/+source/libcryptx-perl/tree/debian/control#n2)

This package does not yield massive lintian Warnings, Errors
  - recent build log of the package https://launchpad.net/ubuntu/+source/libcryptx-perl/0.080-2/+build/27021219/+files/buildlog_ubuntu-noble-amd64.libcryptx-perl_0.080-2_BUILDING.txt.gz
  - full output from `lintian --pedantic` :
    #source
    ❯ lintian -EvIL +pedantic --show-overrides
      W: libcryptx-perl: changelog-distribution-does-not-match-changes-file unstable != noble [usr/share/doc/libcryptx-perl/changelog.Debian.gz:1]
      W: libcryptx-perl changes: distribution-and-changes-mismatch noble unstable
      I: libcryptx-perl: typo-in-manual-page octects octets [usr/share/man/man3/Crypt::Checksum::Adler32.3pm.gz:136]
      I: libcryptx-perl: typo-in-manual-page octects octets [usr/share/man/man3/Crypt::Checksum::Adler32.3pm.gz:163]
      I: libcryptx-perl: typo-in-manual-page octects octets [usr/share/man/man3/Crypt::Checksum::CRC32.3pm.gz:136]
      I: libcryptx-perl: typo-in-manual-page octects octets [usr/share/man/man3/Crypt::Checksum::CRC32.3pm.gz:163]
      I: libcryptx-perl: typo-in-manual-page octects octets [usr/share/man/man3/Crypt::PRNG.3pm.gz:128]
      I: libcryptx-perl: typo-in-manual-page octects octets [usr/share/man/man3/Crypt::PRNG.3pm.gz:135]
      I: libcryptx-perl: typo-in-manual-page octects octets [usr/share/man/man3/Crypt::PRNG.3pm.gz:142]
      I: libcryptx-perl: typo-in-manual-page octects octets [usr/share/man/man3/Crypt::PRNG.3pm.gz:149]

    #binary
    ❯ lintian -EvIL +pedantic --show-overrides ../libcryptx-perl_0.080-2.dsc
      X: libcryptx-perl source: debian-watch-does-not-check-openpgp-signature [debian/watch]
      X: libcryptx-perl source: update-debian-copyright 2017 vs 2023 [debian/copyright:88]
      X: libcryptx-perl source: very-long-line-length-in-source-file 1103 > 512 [t/data/binary-test.file:16]
      X: libcryptx-perl source: very-long-line-length-in-source-file 1124 > 512 [t/mbi_ltm/bigfltpm.inc:913]
      X: libcryptx-perl source: very-long-line-length-in-source-file 1239 > 512 [t/pk_ecc_test_vectors_openssl.t:20]
      X: libcryptx-perl source: very-long-line-length-in-source-file 1430 > 512 [t/data/ssh/ssh_rsa_8192.pub:1]
      X: libcryptx-perl source: very-long-line-length-in-source-file 1655 > 512 [t/jwk.t:21]
      X: libcryptx-perl source: very-long-line-length-in-source-file 2071 > 512 [t/sshkey.t:73]
      X: libcryptx-perl source: very-long-line-length-in-source-file 571 > 512 [t/pk_dh.t:98]
      X: libcryptx-perl source: very-long-line-length-in-source-file 614 > 512 [t/data/ssh/ssh_dsa_1024.pub:1]
      X: libcryptx-perl source: very-long-line-length-in-source-file 699 > 512 [t/mode_ecb.t:28]
      X: libcryptx-perl source: very-long-line-length-in-source-file 745 > 512 [t/mode_cbc.t:40]
      X: libcryptx-perl source: very-long-line-length-in-source-file 750 > 512 [t/data/ssh/ssh_rsa_4096.pub:1]
      X: libcryptx-perl source: very-long-line-length-in-source-file 7992 > 512 [t/pk_dsa_test_vectors_openssl.t:13]
      X: libcryptx-perl source: very-long-line-length-in-source-file 8771 > 512 [t/pk_rsa_test_vectors_openssl.t:38]

This package does not rely on obsolete or about to be demoted packages.
This package has no python2 or GTK2 dependencies.

The package will not be installed by default.

Packaging and build is easy, link to debian/rules: https://git.launchpad.net/ubuntu/+source/libcryptx-perl/tree/debian/rules

[UI standards]
Application is not end-user facing (does not need translation).

[Dependencies]
There are further dependencies not yet in main. Listing then:

- libmath-bigint-perl
  + libscalar-list-utils-perl

but the modules provided by libmath-bigint-perl are provided also by perl-modules-5.36 (i.e. , /usr/share/perl/5.36.0/Math/Big{Float,Int}.pm ). To double confirm that processing these dependencies to a MIR is not needed by now, in the control file of the perl package we found a Break for libmath-bigint-perl since version 1.999830:

https://git.launchpad.net/ubuntu/+source/perl/tree/debian/control#n196

and Replaces:

https://git.launchpad.net/ubuntu/+source/perl/tree/debian/control#n243

alongside the Provides for that version:

https://git.launchpad.net/ubuntu/+source/perl/tree/debian/control#n330.

However, new version for libmath-bigint-perl in noble-proposed is 2.002000-1, above the one provided by the incoming perl transition 5.38:

https://tracker.debian.org/media/packages/p/perl/control-5.38.2-1

Maybe version 2.002000-1 will be included in perl 5.40 (scheduled in May 2024,
https://groups.google.com/g/linux.debian.bugs.dist/c/J5E_eGT8fC8 ), but nothing for sure yet, as also no notice of that inclusion can be read at https://tracker.debian.org/pkg/libmath-bigint-perl ( Could be libmath-bigint-gmp-perl https://tracker.debian.org/pkg/libmath-bigint-gmp-perl choosen instead? ).

[Standards compliance]
This package correctly follows FHS and Debian Policy (4.6.2)

[Maintenance/Owner]
Owning Team will be Ubuntu Server Team.
Team is not yet, but will subscribe to the package before promotion.
This does not use static builds.
This uses vendored code:
  - src/ltc : LibTomCrypt: https://github.com/libtom/libtomcrypt
  - src/ltm: LibTomMath: https://github.com/libtom/libtommath
Both are packaged in Ubuntu: libtomcrypt-dev and libtommath-dev .

This package is not rust based.

A previous version of the package was successfully built during the most recent test rebuild : https://launchpad.net/ubuntu/+archive/test-rebuild-20230830-mantic/+build/26595349/+files/buildlog_ubuntu-mantic-amd64.libcryptx-perl_0.078-1_BUILDING.txt.gz

[Background information]
The Package description explains the package well.
Upstream Name is CryptX .
Link to upstream project https://metacpan.org/dist/CryptX

This has been in the archive since at least 2017 (Bionic, 0.054-1).
It had a bug filed against it in Launchpad, for upgrading Bionic's version: https://bugs.launchpad.net/ubuntu/+source/libcryptx-perl/+bug/1840382.

[Christian Ehrhardt  (paelzer)]

Review for Source Package: libcryptx-perl

[Summary]
MIR team NACK until the constraint to resolve listed below are sorted out.

This does need a security review, but we are not there yet so I'll
not yet assign ubuntu-security

@Security - I feel there likely is already a lib doing Ed25519 PK operations
            for perl, but failed to find it. Do you happen to know?

List of specific binary packages to be promoted to main: libcryptx-perl
Specific binary packages built, but NOT to be promoted to main: n/a

Required TODOs:
#1 - This duplicated all code in a lib that is itself not in main
     They diverged, this package covers a zillion of crypto
     funtions and we'd only need one.
     Please read through below findings and give it a shot at looking
     to resolve it via one of the alternatives (at the end) or something new
     options you might bring up.
     Come to the MIR meeting with whatever you have found, let us see if anyone
     else knows a better option.

[Rationale, Duplication and Ownership]
OK:
- There is no other package in main providing the same functionality.
- A team is committed to own long term maintenance of this package.
- The rationale given in the report seems valid and useful for Ubuntu

Problem:
- In regard to crypto libs you want as few as possible and them being good.
  I remember explicitly not wanting tomcrypt back in (LP: #1744072) and
  changing dependencies to accomodate that.
  Most of libcrypt-* also is in universe just e.g. libcrypt-openssl-rsa-perl
  is in main.

  The two things that libmail-dkim-perl uses are:
  lib/Mail/DKIM/PublicKey.pm:17:use Crypt::OpenSSL::RSA;
  lib/Mail/DKIM/PublicKey.pm:18:use Crypt::PK::Ed25519;
  lib/Mail/DKIM/PrivateKey.pm:18:use Crypt::OpenSSL::RSA;
  lib/Mail/DKIM/PrivateKey.pm:19:use Crypt::PK::Ed25519;

  Of those Crypt::OpenSSL::RSA is from the mentioned libcrypt-openssl-rsa-perl
  which is in main.

  So only https://metacpan.org/pod/Crypt::PK::Ed25519 is from libcryptx-perl.
  As the name suggests it uses it for Ed25519 public key operations, I failed
  to find anything but
   https://metacpan.org/dist/Crypt-Ed25519/source/Ed25519.pm
   https://www.example-code.com/perl/jwt_create_ed25519.asp
  Which both are worse.
  I can't overcome the feeling that I'm just not enough into perl, but I
  feel that might already be part of some already-in-main lib for perl.
  I'll put an extra note for the security team if they happen to know.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
  all in main already: libcommon-sense-perl libjson-perl
  libjson-xs-perl libtypes-serialiser-perl
  Note: do not fall for libmath-bigint-perl - while that is in universe
  it is also (nowadays) provided by src:perl itself and therefore
  not a component mismatch to resolve.
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems:
- well, depends on how we want to look
  It says it is libtomcrypt, but not linking to it.
  It is all local C code

[Embedded sources and static linking]

OK:
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra...

[Miriam España Acebal (mirespace)]

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

[Mark Esler (eslerm)]

Including some randomness functions to create libcryptx-perl-ed25519 may be reasonable. Those rng functions don't need to be exposed except to the ed25519 functions. And then inc/CryptX_PK_DSA.xs.inc etc can be disabled. I'll check with the crypto folks.

I'm a little concerned about the maintainability of option 1.

side note: libmail-dkim-perl was promoted in 2008 [0]. Issues in libmail-dkim-perl are worth addressing [1]. In one of the issues [2] the maintainer filed an issue to libcryptx-perl-ed25519 upstream [3].

[0] https://bugs.launchpad.net/ubuntu/+source/libmail-dkim-perl/+bug/243313
[1] https://github.com/fastmail/mail-dkim/issues
[2] https://github.com/fastmail/mail-dkim/issues/24
[3] https://github.com/DCIT/perl-CryptX/issues/98

[Mark Esler (eslerm)]

I spoke to @tobhe for a crypto review.

Unfortunately Crypt::Perl::Ed25519 is not base on crypto RFCs. It is a port from Javascript and the math appears dubious [0].

Static analyzer results on libcryptx-perl are not happy, but fixable--especially after reducing the codebase. If libtomcrypt were updated to upstream's most recent commit instead of version, it *might* be a cleaner implementation for minimization.

Ideally we could use crypto software we already maintain, like OpenSSL. Please consider creating and maintaining a wrapper for `Crypt::OpenSSL::Ed25519` as a fourth option. The wrapper would be for [1].

The maintainers of libmail-dkim-perl might switch over if we do this :)

[0] https://metacpan.org/release/FELIPE/Crypt-Perl-0.38/source/lib/Crypt/Perl/Ed25519/Math.pm
[1] https://www.openssl.org/docs/man3.0/man7/Ed25519.html

[Miriam España Acebal (mirespace)]

Hi Mark, Christian,

Mark your fourth option seems to me like a great solution in the long term, but I'm worried about the feasibility of doing it before reaching the LTS Feature Freeze for that package to be MIR-ack, being a NEW package first.

In the short term, should it be upgrading tomcrypt to the latest upstream commit and checking if that codebase is easier (or not :( ) to split it in terms of creating libcryptx-ed25519-perl something we can do to get this feature of DKIM included for the LTS? Keeping in mind that I(we) am committed to get libcrypt-openssl-ed25519-perl as a proper solution later on as soon as possible.

Any other ideas are also welcome if both solutions above can be considered risky because of the time we have to do it.

[Christian Ehrhardt  (paelzer)]

After discussion with Miriam we concluded with a decision:

Short term:
- libcryptx-perl was only needed for the ed25519 of dkim
- We didn't want to lack ed25519, but we also can not add it in unmaintainable fashion
- For now we would complete the rest (mostly bug 2023971) of the spamassassin->dmarc/dkim MIR tree (but without ed25519 support)

Mid term:
- Create libcrypt-openssl-ed25519-perl
- Wrapper compatible with the perl interface `Crypt::OpenSSL::Ed25519` using [1] underneath
- That is potentially a 24.10 item and nothing to rush
- Once available we'd work on a MIR of that new package
- Then we'd aim for a) late upload or b) (after release) NEW+SRU of that to Noble
- Then we'd enable ed25519 in nobles dkim stack using that

That should overall achieve better long term maintainability for the coming LTS, without saying no to the whole stack now nor giving up on having ed25519 ever.

If we are lucky and get the mid-term done before release of noble that would be awesome, but we can not guarantee that yet until Miriam had more of a look.

Requirement:
- Get a pre-ack by SRU team for this course of action
- Mention it in release notes referring to this bug

[1] https://www.openssl.org/docs/man3.0/man7/Ed25519.html

[Robie Basak (racb)]

I don't anticipate a problem with this, at least in principle, from an SRU team perspective. However I can't give a pre-ack because it would depend on a review of the specifics that we don't have right now.

New features are permitted to be added in LTSes. Further, Ed25519 support for DKIM in spamassassin seems like something that would fall under our "changes in the environment, server protocols, web services, and similar" policy category and therefore would be allowed in principle at any time, even if not planned in advance (which is even better!).

I will double-check with the SRU team that the team's view as a whole matches mine.

[Christian Ehrhardt  (paelzer)]

This goes back to Miriam until the planned change is made.

[John Chittum (jchittum)]

Alternative idea, what about instead of writing a wrapper:

1. look at https://packages.ubuntu.com/noble/libnet-ssleay-perl
   a. libnet-ssleay-perl is in main
2. add eddsa-25519 to the list of constants upstream
   a. if i'm reading correctly, there's a mapping in a helper_scripts/constants.txt that contains a list of all algorithms, that is then used to autgen C and perl bindings. if libssl or libgrypt on the system already has eddsa-25519, it should "just work"
3. switch to using libnet-ssleay-perl for the backend of these calls
   a. bonus, you could see if you could switch _everything_. it'd make sense to me...

I don't know if this ends up being a heavier or lighter lift. and it takes updating libnet-ssleay-perl upstream, but reading the list of constants, it could benefit from someone going through and fleshing out current libssl and libcrypt support.

[Christian Ehrhardt  (paelzer)]

Oh for sure, extending something existing sounds way better than coming up with our own from scratch.

Not only might it be easier by not doing all the first-time-mistakes, we also do not want to be a competition to established things. We only want to be able provide eddsa-25519 with a backend that seems more maintainable.

And yes, already being in main makes it even simpler to the end of it.

The question now really is if/how that could be modified and then used from the stack dmarc/dkim stack.

Thanks for spotting John, really seems to be worth a try IMHO.

[Christian Ehrhardt  (paelzer)]

From here we found libs that are even closer, already doing EC handling.
But not yet supporting EVP which is the new high level interface via which you'd also reach ed25519 - but this still made it much closer.

We drafted a plan how to get started on this based on that and verifying in C (as all examples are in that) that we can handle the steps needed in this stack. Then we can try to wrap that through perl and use it from there. Still complex, but much closer.