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