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 constraints to consider in that regard - not a rust package, no extra constraints to consider in that regard Problems: - embedded source present As I mentioned back in chrony (LP: #1744072) tomcrypt was not wanted in main as it would have been yet another crypto lib. Now this here is a full source copy (not just a bit) and it seems out of sync: diff -Naur libcryptx-perl/src/ltc/ libtomcrypt/src/ | diffstat ... ciphers/blowfish.c | 260 +++++++++++++++++----------------------------- ciphers/camellia.c | 26 ++-- ciphers/cast5.c | 57 ++++++---- ciphers/des.c | 631 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------------------- ... encauth/chachapoly/chacha20poly1305_memory.c | 26 ++-- encauth/chachapoly/chacha20poly1305_setiv.c | 16 ++ encauth/chachapoly/chacha20poly1305_setiv_rfc7905.c | 16 ++ encauth/ocb3/ocb3_test.c | 309 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ ... pk/ecc/ltc_ecc_points.c | 45 +++----- pk/ecc/ltc_ecc_projective_add_point.c | 66 +++++------ pk/ecc/ltc_ecc_projective_dbl_point.c | 125 +++++++--------------- pk/ecc/ltc_ecc_verify_key.c | 59 ---------- pk/ed25519/ed25519_export.c | 31 ----- pk/ed25519/ed25519_import.c | 35 ------ pk/ed25519/ed25519_import_pkcs8.c | 28 ---- ... 516 files changed, 17814 insertions(+), 18236 deletions(-) Picking one random one showed positively, that the copied libtomcrypt code in libcryptx-perl is more up to date than libtomcrypt itself. - fix https://github.com/libtom/libtomcrypt/commit/c5d7bfb2ccb6b8aeebb25b117bdf4d9ce049d2b8 - present in master https://github.com/libtom/libtomcrypt/blame/develop/src/ciphers/cast5.c - present in libcryptx-perl - but not present in libtomcrypt-1.18.2 as there was no release for 5 years - ... I mean just ... libcryptx-perl does it well but based on something not releasing and then still copying and ... I do not feel good about this. Interestingly ed25519 (what we need libcryptx-perl for) doesn't even exist in libtomcrypt. But since it is all munged together and we can only support libcryptx-perl or not this is hard. --- Aborting the review here until we have overcome what was found already. This seems too much of a No to spend the extra time. Options to overcome this IMHO: - finding a perl lib doing ed25519 cleanly And then change libmail-dkim-perl to use that - 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) - ...?