Description of problem:
We have some internal scripts that use various perl modules. We also want to move from Fedora (where the scripts work fine) to Centos 7 or maybe RHEL (for LTS reasons). However, in C7 some Perl modules are missing and trying to rebuild them (mock --rebuild <f27 .src.rpm>) showed other Perl modules were also missing. The tip of our iceberg is comprised of these modules:
I will try again to build them and add here what other perl modules i found to be required.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Additional info: I'm thinking that maybe is easier to add all the missing perl modules instead of hunt them one by one, but i'm not knowledgeableenough to test this big hammer locally.
On the other hand, maybe i/we should try to rebuild F19 modules because these share the perl version (5.16) with C7.
hmmm, it seems that File::Basename is actually builtin. Still checking :(
Additional modules missing for me :
Some of these dependencies are coming from perl-Net-SSH-Perl. Currently we have an old version of this in Fedora because the current version replaces a lot of old, unmaintained (upstream) crypto modules with perl-CryptX, which is actively maintained by its upstream developer. However, nobody has yet packaged that for Fedora. It has been looked at in the past but nothing happened with it because it included a bundled libtomcrypt, which may not be as big an issue these days, or it might even be possible to unbundle it.
If someone could package that, we could update perl-Net-SSH-Perl and some of these other dependencies would go away.
Blowfish rebuild worked (from f19).
New required packages for me:
(In reply to Paul Howarth from comment #4)
> Some of these dependencies are coming from perl-Net-SSH-Perl. Currently we
> have an old version of this in Fedora because the current version replaces a
> lot of old, unmaintained (upstream) crypto modules with perl-CryptX, which
> is actively maintained by its upstream developer. However, nobody has yet
> packaged that for Fedora. It has been looked at in the past but nothing
> happened with it because it included a bundled libtomcrypt, which may not be
> as big an issue these days, or it might even be possible to unbundle it.
> If someone could package that, we could update perl-Net-SSH-Perl and some of
> these other dependencies would go away.
Thank you, but is not clear for me what i would need to do here in order to package the newer version. If there is some tutorial somewhere or at least somebody can provide the details i can as well try it.
perl-Term-ReadPassword rebuild worked also. so indeed we're left with perl-Net-SSH-Perl and its dependencies.
Looking at CryptX's Makefile.PL (https://metacpan.org/source/MIK/CryptX-0.057/Makefile.PL), it appears that it's now possible to use an unbundled libtomcrypt, by specifying $CRYPTX_CFLAGS and/or $CRYPTX_LDFLAGS in the environment.
Jitka, Petr, any comments? Could we get together and produce a perl-CryptX package now?
I was able to hunt the dependencies and rebuild those two modules but it still would be nice to have this already available in upstream.
CryptX-0.057 not only bundles libtomcrypt, it also patches it to add implementations for IDEA, SERPENT, SALSA20, SOSEMANUK, and RABBIT stream ciphers. And then it require their implementation in CryptX.xs unconditionally.
Libtomcrypt recently had a new release:
Though I don't know whether it includes all the requirements now, but worth to check, anyway (and update it in Fedora if needed).
Even If I disable/comment all these additional bindings and typemaps, I still get mismatch in <tomcrypt_pk.h> on struct ltc_ecc_set_type. The bundled structure has additional members (A, cofactor, oid) and the binding code expects them.
(In reply to Denis Fateyev from comment #11)
> Libtomcrypt recently had a new release:
> Though I don't know whether it includes all the requirements now, but worth
> to check, anyway (and update it in Fedora if needed).
Fedora already delivers 1.18.1.
The cofactor is being added in <https://github.com/libtom/libtomcrypt/commit/79f553c9b76cea00b635044ff3d5c5a1112b12ce>. Not yet in the master branch.
I requested new branch and built these packages for EPEL 7. I am maintainer of them.
The other packages are owned by different users and I don't want to maintain EPEL 7 branches for them.
(In reply to Jitka Plesnikova from comment #15)
> The other packages are owned by different users and I don't want to maintain
> EPEL 7 branches for them.
> FAS: ixs
> FAS: berrange
> FAS: pghmcfc
None of these (apart from perl-Net-SSH-Perl) are needed if we get perl-CryptX and the new version of Net-SSH-Perl that uses it.
Given that CryptX is bundling a patched version of libtomcrypt, I think it's viable to create a perl-CryptX package that includes the bundled libtomcrypt (with Provides: bundled(libtomcrypt) = 1.18) until such time as the differences are merged upstream. Anyone disagree?
I don't think this ever happen. CryptX author always develops on his libtomcrypt fork. I'd rather try packaging an older CryptX version that could work with upstream libtomcrypt. I don't think it's wise to bundle, especially a cryptographic library.
It looks like 0.053 can be packaged if I disable ECC support. I will try that and put the package on review.
Bug #1545816 is perl-CryptX review.
The current version of Net-SSH-Perl requires IO::Socket::Socks.
Bug #1546648 is perl-IO-Socket-Socks review.
What is the current status of this bug?
All current Fedora releases have a CryptX-based version of Net-SSH-Perl now, though most of the ECC-related functionality is missing as it was stripped out of perl-CryptX.
Would that be OK for you if it was in EPEL-7?
I don't know if Petr is prepared to build this hobbled perl-CryptX for EPEL.
No match for argument: perl-File-Basename
I know i've said it's builtin but i don't remember why :)
Everything else i've mentioned above can be installed.
$ rpm -q --whatprovides 'perl(File::Basename)'
Should be this bug finally closed?
perl-File-Basename as perl
Paul wrote that none of them was needed if perl-CryptX had been available. I will look if it is possible to port Fedora's perl-CryptX to EPEL 7.
It isn't. perl-CryptX requires a support for Adler32 (and many other algorithms) in libtomcrypt. EPEL's libtomcrypt-1.17-25.el7 does not support it. I asked its maintainer for an upgrade (bug #2008832).
I clear the needinfo status because it's sending me one email each day.
Maybe it makes sense to bump the version to "epel9" and provide package(s) there.
In this case, it will require much less efforts with backporting and upgrading, just providing all required packages in epel9 from rawhide.
The same applies to RHBZ#2008832 dependency.
perl-Net-SSH-Perl will be ready in EPEL-9 soon. All of the remaining dependencies are maintained by me so it should be available in testing in the next few days.
perl-Net-SSH-Perl for EPEL-9:
fwiw, I've pushed perl-CryptX 0.076 with bundled libtommath/libtomcrypt to EPEL 7/8/9 as well as Fedora 36/37.
Un-hobbled versions of perl-Net-SSH-Perl will need a new (to Fedora) package perl-Crypt-Curve25519 (Bug #2060852).
perl-Net-SSH-Perl-2.14-15.fc37 is now un-hobbled. Updates for F-36 and EPEL will follow in due course.
Assigned to perl-Net-SSH-Perl rather than perl-Net-SSH since that is what this ticket has always been about.
EPEL-7 and EPEL-8 builds of perl-Net-SSH-Perl will be done in the next day or two.
FEDORA-EPEL-2022-5cb84f5ed2 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-5cb84f5ed2
FEDORA-EPEL-2022-5cb84f5ed2 has been pushed to the Fedora EPEL 7 testing repository.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-5cb84f5ed2
See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Now that we have (or will have shortly) fully CryptX-based versions of perl-Net-SSH-Perl in F-36, F-37 and all EPELs, it looks to me that there are no remaining dependents of perl-Crypt-RSA in Fedora (other than the Suggests: for it in perl-Net-SSH-Perl, but I can get rid of that in due course).
I'm seriously considering retiring the following group of packages, which are only currently used by perl-Crypt-RSA as far as I can tell:
The last release of Crypt-RSA was in 2009. Dana Jacobsen created an alternative implementation (https://metacpan.org/dist/Alt-Crypt-RSA-BigInt) that avoided the need for Math::Pari, which would be a big win itself, but that doesn't look to have gained any traction.
Does anyone see any issues with retiring these packages in Fedora? I can ask on the Perl devel list too but I think most of the interested parties are here anyway.
FEDORA-EPEL-2022-5cb84f5ed2 has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.