Description of problem: I wanted to give the packagers a heads-up that kpcli version 4.0 is on its way. Version 4 will add support for the newer, and often request KDBX4 file format, by making use of the File::KDBX Perl module that Charles McGarvey recently released: https://metacpan.org/dist/File-KDBX Version: 4.0-betaN: https://sourceforge.net/projects/kpcli/files/prereleases/ Additional info: In order for kpcli to provide KDBX4 file format to users, File::KDBX will need to be packaged and become a dependency of kpcli. A couple of File::KDBX's dependencies may also need to be packaged, and thus I wanted to provide some heads-up prior to releasing 4.0, which I plan to do in the coming weeks, as the bug count deteriorates. Sincerely, Lester (kpcli author)
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
Looking at AltLinux's packaging, it seems the BuildRequires missing in Fedora are: perl-File-KDBX-XS perl-POSIX-1003 perl-Pass-OTP Not sure whether these suffice as run-time Requires. I couldn't figure out whether perl-POSIX-1003's dependencies are fulfilled, the others seem safe. I didn't check the sources or even try to package them though. What became of cpan2rpm, BTW? Any alternatives?
(In reply to barsnick from comment #3) > Looking at AltLinux's packaging, it seems the BuildRequires missing in > Fedora are: > perl-File-KDBX-XS > perl-POSIX-1003 > perl-Pass-OTP > > Not sure whether these suffice as run-time Requires. > > I couldn't figure out whether perl-POSIX-1003's dependencies are fulfilled, > the others seem safe. I didn't check the sources or even try to package them > though. > > What became of cpan2rpm, BTW? Any alternatives? Thank you for working on this. Here are a few answers to your questions, in order from easiest to most difficult: - Pass::OTP - not used by kpcli so I'm not sure how/why that was referenced. - POSIX - is a core perl module and so you will not need to package it. - File::KeePass - required, but already packaged as perl-File-KeePass. - File::KDBX - required for KDBX4 support (the point of kpcli v4) and not packaged in Fedora today. - As best I can tell by perusing koji.fedoraproject.org, all of File::KDBX's dependencies are already packaged. - File::KDBX-XS is optional and only enhances the speed of File::KDBX. I am the kpcli author and don't even have it installed on my system. I hope that this helps. -- Lester
I've been working on this on and off all summer. (In reply to Lester Hightower from comment #4) > > What became of cpan2rpm, BTW? Any alternatives? I typically use cpanspec, sometimes in combination with rpmdev-newspec -t perl. cpanspec is really out of date and its output needs lots of manual fixing to pass current packaging guidelines. rpmdev-newspec creates a blank template where you need to fill in all the details. > - Pass::OTP - not used by kpcli so I'm not sure how/why that was > referenced. Good to know. I was working on gettting that into Fedora based on what cpanspec found: # === Test Recommends === # # Module Want Have # ---------- -------- ------- # CPAN::Meta 2.120900 missing # Pass::OTP any missing # # === Test Suggests === # # Module Want Have # ----------- ---- ------- # POSIX::1003 any missing # > - File::KDBX - required for KDBX4 support (the point of kpcli v4) and > not packaged in Fedora today. This is last piece I need to get added to Fedora. > - As best I can tell by perusing koji.fedoraproject.org, all of > File::KDBX's dependencies are already packaged. > - File::KDBX-XS is optional and only enhances the speed of File::KDBX. I > am the kpcli author and don't even have it installed on my system. > > I hope that this helps. Thanks. I'll see if I can get this done over the next week. I'm running into this currently: Test Summary Report ------------------- t/kdbx4.t (Wstat: 132 (Signal: ILL, dumped core) Tests: 0 Failed: 0) Non-zero wait status: 132 Parse errors: No plan found in TAP output t/kdf.t (Wstat: 132 (Signal: ILL, dumped core) Tests: 1 Failed: 0) Non-zero wait status: 132 Parse errors: No plan found in TAP output Files=27, Tests=178, 6 wallclock secs ( 0.04 usr 0.01 sys + 2.40 cusr 0.36 csys = 2.81 CPU) Result: FAIL Failed 2/27 test programs. 0/178 subtests failed. make: *** [Makefile:924: test_dynamic] Error 255
File::KeePass::KDBX seems non-optional for running tests. I'll need to get that into Fedora first, but there is a circular dependency: File::KDBX test (t/kdb.t) requires File::KeePass and File::KeePass::KDBX. File::KeePass:KDBX requires File::KDBX. I think I'm going to have to just disable some tests.
I downloaded File-KDBX-0.906 and spent a few minutes doing the obligatory "perl Makefile.PL" and then "make test" and things worked flawlessly on my Linux Mint 21 desktop. What I see indicates that File::KeePass, File::KeePass::KDBX, and Pass::OTP are all optional (tests are skipped if they are not available): t/kdb.t ................ skipped: File::KeePass and File::KeePass::KDBX required to test KDB files t/otp.t ................ skipped: Pass::OTP required to test one-time-passwords The core dumps that you are getting on t/kdbx4.t and t/kdf.t make me suspect that there is a problem with one of their dependencies and quite likely one of the crypto modules since it's core dumping (dying in compiled C code, not perl code). So, skipping those tests likely won't resolve the problem. Looking at the crypto-related dependencies of File::KDBX::KDF, File::KDBX::KDF::AES, File::KDBX::KDF::Argon2, and File::KDBX::Cipher::CBC, I suspect that your problem is most likely with one of these modules: Crypt::Cipher or Crypt::Argon2 or Crypt::PRNG. I suspect that the Fedora packaged version of one of those is too old and that the File::KDBX author is unaware because he never tested with older versions. Here is the list of Crypt::* modules that worked for me this morning, for your reference. I would tend to suspect that the problem lies with one of them where the File::KDBX package wants "any" versions but your packaged version may be older than what you see below: # === Runtime Requires === # # Module Want Have # ------------------------ ----- -------- [...snip...] # Crypt::Argon2 any 0.017 # Crypt::Cipher any 0.076 # Crypt::Cipher::AES any 0.076 # Crypt::Digest any 0.076 # Crypt::Mac::HMAC any 0.076 # Crypt::Misc 0.049 0.076 # Crypt::Mode::CBC any 0.076 # Crypt::PRNG any 0.076 # Crypt::Stream::ChaCha 0.048 0.076 # Crypt::Stream::Salsa20 0.055 0.076 [...snip...] Note that I believe that list only entails two packages: Crypt::Argon2 version 0.017 and CryptX version 0.076, and so I guess I am saying that I most highly suspect one of those two as the problem: perl-crypt-argon2 or perl-cryptx. Past that, my second suspicion would be XML processing, so likely this module: # XML::LibXML any 2.0134 I hope that this is helpful to you. Let me know if I can help in any other way.
(In reply to Lester Hightower from comment #7) > The core dumps that you are getting on t/kdbx4.t and t/kdf.t make me suspect > that there is a problem with one of their dependencies and quite likely one > of the crypto modules since it's core dumping (dying in compiled C code, not > perl code). So, skipping those tests likely won't resolve the problem. > > Looking at the crypto-related dependencies of File::KDBX::KDF, > File::KDBX::KDF::AES, File::KDBX::KDF::Argon2, and File::KDBX::Cipher::CBC, > I suspect that your problem is most likely with one of these modules: > Crypt::Cipher or Crypt::Argon2 or Crypt::PRNG. I suspect that the Fedora > packaged version of one of those is too old and that the File::KDBX author > is unaware because he never tested with older versions. > > Here is the list of Crypt::* modules that worked for me this morning, for > your reference. I would tend to suspect that the problem lies with one of > them where the File::KDBX package wants "any" versions but your packaged > version may be older than what you see below: > > # === Runtime Requires === > # > # Module Want Have > # ------------------------ ----- -------- > [...snip...] > # Crypt::Argon2 any 0.017 > # Crypt::Cipher any 0.076 > # Crypt::Cipher::AES any 0.076 > # Crypt::Digest any 0.076 > # Crypt::Mac::HMAC any 0.076 > # Crypt::Misc 0.049 0.076 > # Crypt::Mode::CBC any 0.076 > # Crypt::PRNG any 0.076 > # Crypt::Stream::ChaCha 0.048 0.076 > # Crypt::Stream::Salsa20 0.055 0.076 > [...snip...] > > > Note that I believe that list only entails two packages: Crypt::Argon2 > version 0.017 and CryptX version 0.076, and so I guess I am saying that I > most highly suspect one of those two as the problem: perl-crypt-argon2 or > perl-cryptx. > > Past that, my second suspicion would be XML processing, so likely this > module: > > # XML::LibXML any 2.0134 > > > I hope that this is helpful to you. Let me know if I can help in any other > way. Thanks for this. I have a newer Crypt::Argon2 and XML::LibXML: # === Runtime Requires === # # Module Want Have # ------------------------ ----- -------- [...] # Crypt::Argon2 any 0.019 # Crypt::Cipher any 0.076 # Crypt::Cipher::AES any 0.076 # Crypt::Digest any 0.076 # Crypt::Mac::HMAC any 0.076 # Crypt::Misc 0.049 0.076 # Crypt::Mode::CBC any 0.076 # Crypt::PRNG any 0.076 # Crypt::Stream::ChaCha 0.048 0.076 # Crypt::Stream::Salsa20 0.055 0.076 [...] # XML::LibXML any 2.0208 # XML::LibXML::Reader any 2.0208 I ran the tests with "make test TEST_VERBOSE=1" and will attach the entire build output here in case someone else wants to take a look. Strangely, the verbose test output doesn't show any failures: t/kdbx4.t .............. # Subtest: Verify Format400 No subtests run t/kdf-aes-pp.t ......... ok 1 - XS can be avoided ok 2 - AES KDF works without XS ok 3 - Transformation requires valid arguments 1..3 ok t/kdf.t ................ # Subtest: AES KDF ok 1 - AES KDF basically works ok 2 - Transformation requires valid arguments 1..2 ok 1 - AES KDF # Subtest: Argon2 KDF All 1 subtests passed Only the test summary at the end shows the failure: Test Summary Report ------------------- t/kdbx4.t (Wstat: 132 (Signal: ILL, dumped core) Tests: 0 Failed: 0) Non-zero wait status: 132 Parse errors: No plan found in TAP output t/kdf.t (Wstat: 132 (Signal: ILL, dumped core) Tests: 1 Failed: 0) Non-zero wait status: 132 Parse errors: No plan found in TAP output Files=26, Tests=235, 7 wallclock secs ( 0.03 usr 0.01 sys + 2.33 cusr 0.35 csys = 2.72 CPU) Result: FAIL Failed 2/26 test programs. 0/235 subtests failed. make: *** [Makefile:1101: test_dynamic] Error 255
Created attachment 1988657 [details] perl-File-KDBX build.log
I reached out to Charles McGarvey <ccm>, the author of File::KDBX, and pointed him to this bug. I have worked with Charles a few times in the past year or so, as I added KDBX4 support to kpcli using his module, and I found him to be very knowledgeable and responsive. I hope that he'll quickly see and point out the problem for us. If I don't hear anything from him in a day or two, I'll try to dig into this more deeply myself, perhaps by installing a Fedora VM, etc., but I would first like to give Charles a chance to chime in since he may already be aware of this issue and/or may very quickly identify the problem from his experience.
Charles - I had some time today to look into this more deeply. I installed a clean Fedora Server 38 VM, installed the packages that I needed to build File::KDBX, and got the exact same result that you reported here. Then I dug into t/kdbx4.t and t/kdf.t (using the tv command from Test::Verbose) and confirmed that both tests die in their "Argon2" test sections. I then used cpanm to install Crypt::Argon2 0.019 into my home directory (under ~/perl/) and confirmed that it (my locally built copy) works with File::KDBX but that the Crypt::Argon2 0.019 that is packaged in Fedora 38 causes a segmentation fault. For your reference, I used this cpanm command, run as hightowe (not root), to install Crypt::Argon2 0.019 into ~/perl/ for myself: cpanm -f Crypt::Argon2 ** Note that the -f (force) is required because otherwise cpanm will detect the packaged, system-wide Crypt::Argon2 0.019 and skip it. My test VM is now in a state where I can demonstrate both conditions immediately, as shown here: [hightowe@localhost File-KDBX-0.906]$ make test [...snip...] Test Summary Report ------------------- t/kdbx4.t (Wstat: 132 (Signal: ILL, dumped core) Tests: 0 Failed: 0) Non-zero wait status: 132 Parse errors: No plan found in TAP output t/kdf.t (Wstat: 132 (Signal: ILL, dumped core) Tests: 1 Failed: 0) Non-zero wait status: 132 Parse errors: No plan found in TAP output Files=27, Tests=178, 8 wallclock secs ( 0.04 usr 0.05 sys + 3.19 cusr 0.92 csys = 4.20 CPU) Result: FAIL Failed 2/27 test programs. 0/178 subtests failed. make: *** [Makefile:1103: test_dynamic] Error 255 [hightowe@localhost File-KDBX-0.906]$ PERL5LIB=/home/hightowe/perl5/lib/perl5/ make test [...snip...] All tests successful. Files=27, Tests=193, 8 wallclock secs ( 0.07 usr 0.03 sys + 3.72 cusr 0.63 csys = 4.45 CPU) Result: PASS The only difference in those two is which Crypt::Argon2 0.019 is being used, the Fedora packaged one in the first case and my locally built and installed one in the second case. There appears to be a problem with the packaging of Crypt::Argon2 0.019 in Fedora.
And just a little more follow up on this, kpcli-4.0 works perfectly when File::KDBX is installed locally, alongside a good Crypt::Argon2 0.019: # Installing File::KDBX into ~/perl5 using the Crypt::Argon2 from ~/perl5 $ PERL5LIB=/home/hightowe/perl5/lib/perl5/ cpanm File::KDBX --> Working on File::KDBX Fetching http://www.cpan.org/authors/id/C/CC/CCM/File-KDBX-0.906.tar.gz ... OK Configuring File-KDBX-0.906 ... OK Building and testing File-KDBX-0.906 ... OK Successfully installed File-KDBX-0.906 1 distribution installed # Running kpcli-4.0.pl with a preference for modules within ~/perl5 $ PERL5LIB=/home/hightowe/perl5/lib/perl5/ ./kpcli-4.0.pl KeePass CLI (kpcli-4.0) v4.0 is ready for operation. Type 'help' for a description of available commands. Type 'help <command>' for details on individual commands. kpcli-4.0:/> vers kpcli: 4.0 Perl: v5.36.1 Operating system: linux ("Fedora Linux 38 (Server Edition)") ReadLine being used: Term::ReadLine::Gnu Pivotal Perl Modules for kpcli * File::KeePass: 2.03 * File::KDBX: 0.906 * Term::ShellUI: 0.92 * Term::ReadKey: 2.38 * Term::ReadLine: 1.17 * Capture::Tiny: 0.48 * File::KDBX::Constants: 0.906 * File::KDBX::Key: 0.906 * Sub::Install: 0.929 * Term::ReadLine::Gnu: 1.45 * URI: 5.17 * Authen::OATH: not installed (optional) * Clipboard: not installed (optional) * Data::Password: not installed (optional) * Data::Password::passwdqc: not installed (optional) * Data::Password::zxcvbn: not installed (optional) * Math::Random::ISAAC: not installed (optional)
I replicated the crash by simply running Crypt::Argon2's own tests. Still looking for a cause. [chaz@fedora38 Crypt-Argon2-0.019]$ perl t/test.t # Subtest: argon2i(2, 64M, 1, password, somesalt) Illegal instruction (core dumped) [chaz@fedora38 Crypt-Argon2-0.019]$ coredumpctl info PID: 2613 (perl) UID: 1000 (chaz) GID: 1000 (chaz) Signal: 4 (ILL) Timestamp: Thu 2023-09-14 21:27:23 MDT (20s ago) Command Line: perl t/test.t Executable: /usr/bin/perl Control Group: /user.slice/user-1000.slice/session-1.scope Unit: session-1.scope Slice: user-1000.slice Session: 1 Owner UID: 1000 (chaz) Boot ID: f1d8f18262b84eb2964891089291de91 Machine ID: f1925e28d59a4b25badc43cd2f33a6a8 Hostname: *redacted* Storage: /var/lib/systemd/coredump/core.perl.1000.f1d8f18262b84eb2964891089291de91.2613.1694748443000000.zst (p> Size on Disk: 1.3M Message: Process 2613 (perl) of user 1000 dumped core. Module libcrypt.so.2 from rpm libxcrypt-4.4.36-1.fc38.x86_64 Stack trace of thread 2613: #0 0x00007f435b7e80ae blake2b_init_param (Argon2.so + 0x50ae) #1 0x00007f435b7e817d blake2b_init (Argon2.so + 0x517d) #2 0x00007f435b7e879a initial_hash (Argon2.so + 0x579a) #3 0x00007f435b7e8e76 initialize (Argon2.so + 0x5e76) #4 0x00007f435b7e98c9 argon2_ctx (Argon2.so + 0x68c9) #5 0x00007f435b7e9a5e argon2_hash (Argon2.so + 0x6a5e) #6 0x00007f435b7e9c4f S_argon2_pass (Argon2.so + 0x6c4f) #7 0x00007f435b7ea005 XS_Crypt__Argon2_argon2id_pass (Argon2.so + 0x7005) #8 0x00007f435bf265aa Perl_pp_entersub (libperl.so.5.36 + 0x1265aa) #9 0x00007f435bf17958 Perl_runops_standard (libperl.so.5.36 + 0x117958) #10 0x00007f435be8259d perl_run (libperl.so.5.36 + 0x8259d) #11 0x000055c64caa534a main (perl + 0x134a) #12 0x00007f435bc49b8a __libc_start_call_main (libc.so.6 + 0x27b8a) #13 0x00007f435bc49c4b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x27c4b) #14 0x000055c64caa5385 _start (perl + 0x1385) ELF object binary architecture: AMD x86-64
Here's a stack trace with debug info enabled: #0 blake2b_init_param (S=S@entry=0x7fffffffdb20, P=P@entry=0x7fffffffdac0) at src/blake2/blake2b.c:81 #1 0x00007ffff75e817d in blake2b_init (S=S@entry=0x7fffffffdb20, outlen=outlen@entry=64) at src/blake2/blake2b.c:116 #2 0x00007ffff75e879a in initial_hash (type=Argon2_i, context=0x7fffffffdd80, blockhash=0x7fffffffdc60 "\220\334\377\377\377\177") at src/core.c:547 #3 initial_hash (blockhash=blockhash@entry=0x7fffffffdc60 "\220\334\377\377\377\177", context=context@entry=0x7fffffffdd80, type=Argon2_i) at src/core.c:538 #4 0x00007ffff75e8e76 in initialize (context=0x7fffffffdd80, instance=0x7fffffffdd00) at src/core.c:631 #5 initialize (instance=instance@entry=0x7fffffffdd00, context=context@entry=0x7fffffffdd80) at src/core.c:612 #6 0x00007ffff75e98c9 in argon2_ctx (type=(unknown: 0x20), context=0x7fffffffdd80) at src/argon2.c:82 #7 argon2_ctx (context=context@entry=0x7fffffffdd80, type=type@entry=Argon2_i) at src/argon2.c:39 #8 0x00007ffff75e9a5e in argon2_hash (t_cost=t_cost@entry=2, m_cost=m_cost@entry=65536, parallelism=parallelism@entry=1, pwd=pwd@entry=0x555555c03ae0, pwdlen=<optimized out>, salt=salt@entry=0x555555cd8960, saltlen=8, hash=0x0, hashlen=32, encoded=0x555555595290 "\300m\277\367\377\177", encodedlen=86, type=Argon2_i, version=19) at src/argon2.c:151 #9 0x00007ffff75e9c4f in S_argon2_pass (my_perl=my_perl@entry=0x5555555592a0, type=type@entry=Argon2_i, password=password@entry=0x55555558d670, salt=salt@entry=0x55555558d5f8, t_cost=2, m_factor=<optimized out>, parallelism=1, output_length=32) at lib/Crypt/Argon2.xs:60 #10 0x00007ffff75ea005 in XS_Crypt__Argon2_argon2id_pass (my_perl=0x5555555592a0, cv=<optimized out>) at lib/Crypt/Argon2.xs:109 #11 0x00007ffff7d265aa in Perl_pp_entersub (my_perl=0x5555555592a0) at /usr/src/debug/perl-5.36.1-497.fc38.x86_64/pp_hot.c:5353 #12 0x00007ffff7d17958 in Perl_runops_standard (my_perl=0x5555555592a0) at /usr/src/debug/perl-5.36.1-497.fc38.x86_64/run.c:41 #13 0x00007ffff7c8259d in S_run_body (oldscope=<optimized out>, my_perl=<optimized out>) at /usr/src/debug/perl-5.36.1-497.fc38.x86_64/perl.c:2721 #14 perl_run (my_perl=0x5555555592a0) at /usr/src/debug/perl-5.36.1-497.fc38.x86_64/perl.c:2644 #15 0x000055555555534a in main (argc=<optimized out>, argv=<optimized out>, env=<optimized out>) at /usr/src/debug/perl-5.36.1-497.fc38.x86_64/perlmain.c:110
(In reply to Charles McGarvey from comment #13) > I replicated the crash by simply running Crypt::Argon2's own tests. Still > looking for a cause. > > [chaz@fedora38 Crypt-Argon2-0.019]$ perl t/test.t > # Subtest: argon2i(2, 64M, 1, password, somesalt) > Illegal instruction (core dumped) Interesting, I cannot replicate by running Crypt::Argon2's own tests. Note that I'm doing all builds and tests inside of a mock chroot: <mock-chroot> sh-5.2# prove --blib --verbose t/test.t .. # Subtest: argon2i(2, 64M, 1, password, somesalt) ok 1 - 2:64M:1(password, somesalt) encodes as expected ok 2 - 2:64M:1(password, somesalt) matches as expected ok 3 - 2:64M:1(password, somesalt) verifies as expected 1..3 ok 1 - argon2i(2, 64M, 1, password, somesalt) # Subtest: argon2i(2, 256k, 1, password, somesalt) ok 1 - 2:256k:1(password, somesalt) encodes as expected ok 2 - 2:256k:1(password, somesalt) matches as expected ok 3 - 2:256k:1(password, somesalt) verifies as expected 1..3 ok 2 - argon2i(2, 256k, 1, password, somesalt) # Subtest: argon2i(2, 256k, 2, password, somesalt) ok 1 - 2:256k:2(password, somesalt) encodes as expected ok 2 - 2:256k:2(password, somesalt) matches as expected ok 3 - 2:256k:2(password, somesalt) verifies as expected 1..3 ok 3 - argon2i(2, 256k, 2, password, somesalt) # Subtest: argon2i(1, 64M, 1, password, somesalt) ok 1 - 1:64M:1(password, somesalt) encodes as expected ok 2 - 1:64M:1(password, somesalt) matches as expected ok 3 - 1:64M:1(password, somesalt) verifies as expected 1..3 ok 4 - argon2i(1, 64M, 1, password, somesalt) # Subtest: argon2i(4, 64M, 1, password, somesalt) ok 1 - 4:64M:1(password, somesalt) encodes as expected ok 2 - 4:64M:1(password, somesalt) matches as expected ok 3 - 4:64M:1(password, somesalt) verifies as expected 1..3 ok 5 - argon2i(4, 64M, 1, password, somesalt) # Subtest: argon2i(2, 64M, 1, differentpassword, somesalt) ok 1 - 2:64M:1(differentpassword, somesalt) encodes as expected ok 2 - 2:64M:1(differentpassword, somesalt) matches as expected ok 3 - 2:64M:1(differentpassword, somesalt) verifies as expected 1..3 ok 6 - argon2i(2, 64M, 1, differentpassword, somesalt) # Subtest: argon2i(2, 64M, 1, password, diffsalt) ok 1 - 2:64M:1(password, diffsalt) encodes as expected ok 2 - 2:64M:1(password, diffsalt) matches as expected ok 3 - 2:64M:1(password, diffsalt) verifies as expected 1..3 ok 7 - argon2i(2, 64M, 1, password, diffsalt) # Subtest: needs_rehash ok 1 - No rehash with same parameters ok 2 - Rehash with different argon2 variant ok 3 - Rehash with different time cost ok 4 - Rehash with different memory cost ok 5 - Rehash with different parallelism ok 6 - Rehash with different output length ok 7 - Rehash with different salt length 1..7 ok 8 - needs_rehash 1..8 ok All tests successful. Files=1, Tests=8, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.47 cusr 0.21 csys = 0.70 CPU) Result: PASS
Just to put a little finer point on things (and credit to Charles McGarvey for this perl one-line example), this simple perl one-liner segfaults using the Fedora Server 38 perl-Crypt-Argon2 package: $ perl -MCrypt::Argon2=argon2i_raw -e'printf("%v02X\n", argon2i_raw("test", "somesalt", 2, "256k", 2, 32))' Illegal instruction (core dumped) ...and it works perfect when run with my locally-built Crypt::Argon2: $ PERL5LIB=/home/hightowe/perl5/lib/perl5/ perl -MCrypt::Argon2=argon2i_raw -e'printf("%v02X\n", argon2i_raw("test", "somesalt", 2, "256k", 2, 32))' 1D.F9.12.A7.CD.A4.D8.32.10.22.EA.CB.16.2E.2D.68.D8.8B.59.C0.E3.74.E3.4C.05.86.5E.86.80.29.6C.15 Like Charles, I don't see what is wrong with the perl-Crypt-Argon2 package, but I am convinced that it has a fatal problem, at least on Fedora Server 38.
(In reply to Charles R. Anderson from comment #15) > (In reply to Charles McGarvey from comment #13) > > I replicated the crash by simply running Crypt::Argon2's own tests. Still > > looking for a cause. > > > > [chaz@fedora38 Crypt-Argon2-0.019]$ perl t/test.t > > # Subtest: argon2i(2, 64M, 1, password, somesalt) > > Illegal instruction (core dumped) > > Interesting, I cannot replicate by running Crypt::Argon2's own tests. Note > that I'm doing all builds and tests inside of a mock chroot: > > <mock-chroot> sh-5.2# prove --blib --verbose > t/test.t .. > # Subtest: argon2i(2, 64M, 1, password, somesalt) > ok 1 - 2:64M:1(password, somesalt) encodes as expected > ok 2 - 2:64M:1(password, somesalt) matches as expected > ok 3 - 2:64M:1(password, somesalt) verifies as expected > 1..3 > ok 1 - argon2i(2, 64M, 1, password, somesalt) > # Subtest: argon2i(2, 256k, 1, password, somesalt) > ok 1 - 2:256k:1(password, somesalt) encodes as expected > ok 2 - 2:256k:1(password, somesalt) matches as expected > ok 3 - 2:256k:1(password, somesalt) verifies as expected > 1..3 > ok 2 - argon2i(2, 256k, 1, password, somesalt) > # Subtest: argon2i(2, 256k, 2, password, somesalt) > ok 1 - 2:256k:2(password, somesalt) encodes as expected > ok 2 - 2:256k:2(password, somesalt) matches as expected > ok 3 - 2:256k:2(password, somesalt) verifies as expected > 1..3 > ok 3 - argon2i(2, 256k, 2, password, somesalt) > # Subtest: argon2i(1, 64M, 1, password, somesalt) > ok 1 - 1:64M:1(password, somesalt) encodes as expected > ok 2 - 1:64M:1(password, somesalt) matches as expected > ok 3 - 1:64M:1(password, somesalt) verifies as expected > 1..3 > ok 4 - argon2i(1, 64M, 1, password, somesalt) > # Subtest: argon2i(4, 64M, 1, password, somesalt) > ok 1 - 4:64M:1(password, somesalt) encodes as expected > ok 2 - 4:64M:1(password, somesalt) matches as expected > ok 3 - 4:64M:1(password, somesalt) verifies as expected > 1..3 > ok 5 - argon2i(4, 64M, 1, password, somesalt) > # Subtest: argon2i(2, 64M, 1, differentpassword, somesalt) > ok 1 - 2:64M:1(differentpassword, somesalt) encodes as expected > ok 2 - 2:64M:1(differentpassword, somesalt) matches as expected > ok 3 - 2:64M:1(differentpassword, somesalt) verifies as expected > 1..3 > ok 6 - argon2i(2, 64M, 1, differentpassword, somesalt) > # Subtest: argon2i(2, 64M, 1, password, diffsalt) > ok 1 - 2:64M:1(password, diffsalt) encodes as expected > ok 2 - 2:64M:1(password, diffsalt) matches as expected > ok 3 - 2:64M:1(password, diffsalt) verifies as expected > 1..3 > ok 7 - argon2i(2, 64M, 1, password, diffsalt) > # Subtest: needs_rehash > ok 1 - No rehash with same parameters > ok 2 - Rehash with different argon2 variant > ok 3 - Rehash with different time cost > ok 4 - Rehash with different memory cost > ok 5 - Rehash with different parallelism > ok 6 - Rehash with different output length > ok 7 - Rehash with different salt length > 1..7 > ok 8 - needs_rehash > 1..8 > ok > All tests successful. > Files=1, Tests=8, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.47 cusr 0.21 > csys = 0.70 CPU) > Result: PASS I believe (but am not 100% sure) that prove actually builds and tests the package that you are working with (in the directory that you are sitting in). Said another way, I believe that prove sets PERL5LIB to use the *local* version that it built, whereas I believe that what Charles McGarvey did was to simply run "perl t/test.t" to run a test script by hand and, in doing that, the system-wide Crypt::Argon2 was used and that's where he sees the failure.
(In reply to Lester Hightower from comment #17) > I believe (but am not 100% sure) that prove actually builds and tests the > package that you are working with (in the directory that you are sitting > in). Said another way, I believe that prove sets PERL5LIB to use the *local* > version that it built, whereas I believe that what Charles McGarvey did was > to simply run "perl t/test.t" to run a test script by hand and, in doing > that, the system-wide Crypt::Argon2 was used and that's where he sees the > failure. Yes, I realize that now. Something is wrong with the Crypt::Argon2 build that is in the released package. I reproduced this: perl-Crypt-Argon2-0.019-2.fc37.x86_64 from Fedora 37 updates --> crash perl-Crypt-Argon2-0.019-2.fc37.x86_64 from rebuilt locally in Fedora 37 mock chroot --> works perl-Crypt-Argon2-0.019-2.fc37.x86_64 from rebuilt in Fedora Koji scratch-build --> works I'll bump and build an official perl-Crypt-Argon2-0.019-3.fc37.x86_64 update now.
FEDORA-2023-74977d8d92 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-74977d8d92
FEDORA-2023-74977d8d92 has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
I am really glad that we were able to figure this out, Charles, and thanks for your help in packaging File::KDBX and kpcli-4.0. It seems that the system auto-closed this bug with the successful update of perl-Crypt-Argon2 for Fedora 40, but that may not have been the intent. I did not want to reopen it myself because I am not very familiar with Fedora bug workflows, but I did want to comment about it.
FEDORA-2023-174b1a814e has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-174b1a814e
FEDORA-2023-c694005278 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c694005278
FEDORA-2023-c1045623bf has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c1045623bf
(In reply to Lester Hightower from comment #21) > I am really glad that we were able to figure this out, Charles, and thanks > for your help in packaging File::KDBX and kpcli-4.0. > > It seems that the system auto-closed this bug with the successful update of > perl-Crypt-Argon2 for Fedora 40, but that may not have been the intent. I > did not want to reopen it myself because I am not very familiar with Fedora > bug workflows, but I did want to comment about it. Yes, I messed up and should have cloned this bug to be specifically for Crypt::Argon2.
I downloaded and installed perl-Crypt-Argon2-0.019-5.fc38 from https://bodhi.fedoraproject.org/updates/FEDORA-2023-c694005278 into "Fedora Linux 38 (Server Edition)" and it supported a clean build of File::KDBX and kpcli-4.0 seemed to properly with it. However, when trying to perform a simple operation on a KDBX4 file with kpcli, it crashes with an "Illegal instruction (core dumped)" problem. And so, I suspect that perl-Crypt-Argon2-0.019-5.fc38 is an improvement, but that it did not fix the root problem on Fedora, whatever that is... Here is how to replicate the problem that I see (and this works perfectly on other OSes): [hightowe@localhost ~]$ kpcli-4.0.pl KeePass CLI (kpcli-4.0) v4.0 is ready for operation. Type 'help' for a description of available commands. Type 'help <command>' for details on individual commands. kpcli-4.0:/> newdb Choose your file format: 1. KDB - The original KeePass format (*.kdb). Supported using File::KeePass 2. KDBX3 - The first KeePass XML format (*.kdbx v3). Supported using File::KeePass 3. KDBX4 - The second KeePass XML format (*.kdbx v4). Supported using File::KDBX Choose: (1)/(2)/(3)/(c)ancel? 3 Done. Use the saveas command to write to disk. kpcli-4.0:/Root> stats File: N/A Type: KDBX v4.1 Key file: N/A Module: File::KDBX Cipher: AES256 Rounds: 10 Iterations: 10 KDF Cipher: Argon2d Compression: gzip Number of groups: 1 Number of entries: 0 kpcli-4.0:/Root> saveas foo.kdbx Provide the master password: ************************* Retype to verify: ************************* Illegal instruction (core dumped) [hightowe@localhost ~]$ ################### When it works properly, the "saveas foo.kdbx" command will yield this result: kpcli-4.0:/Root> saveas foo.kdbx Provide the master password: ************************* Retype to verify: ************************* You are now operating on a KDBX v4.1 file: foo.kdbx kpcli-4.0:/Root>