pkg-perl-maintainers team mailing list archive

[Christian Ehrhardt  <2046154@xxxxxxxxxxxxxxxxxx>]

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)
- ...?

** Changed in: libcryptx-perl (Ubuntu)
       Status: New => Incomplete

** Changed in: libcryptx-perl (Ubuntu)
     Assignee: Christian Ehrhardt  (paelzer) => Miriam España Acebal (mirespace)

-- 
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