Bug 2118421

Summary: kpcli version 4.0 will need File::KDBX to be packaged
Product: [Fedora] Fedora Reporter: Lester Hightower <lester.hightower>
Component: kpcliAssignee: Charles R. Anderson <cra>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 38CC: barsnick, chazmcgarvey, cra, echevemaster, lester.hightower, mkreder
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2239146 (view as bug list) Environment:
Last Closed: 2023-10-25 16:43:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2239146, 2239462    
Bug Blocks: 2233135    
Attachments:
Description Flags
perl-File-KDBX build.log none

Description Lester Hightower 2022-08-15 19:38:26 UTC
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)

Comment 1 Fedora Admin user for bugzilla script actions 2022-11-29 00:20:10 UTC
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Comment 2 Ben Cotton 2023-02-07 14:53:36 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

Comment 3 barsnick 2023-09-12 12:23:13 UTC
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?

Comment 4 Lester Hightower 2023-09-12 13:38:40 UTC
(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

Comment 5 Charles R. Anderson 2023-09-13 00:19:02 UTC
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

Comment 6 Charles R. Anderson 2023-09-13 01:33:57 UTC
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.

Comment 7 Lester Hightower 2023-09-13 12:54:04 UTC
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.

Comment 8 Charles R. Anderson 2023-09-13 13:28:46 UTC
(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

Comment 9 Charles R. Anderson 2023-09-13 13:30:03 UTC
Created attachment 1988657 [details]
perl-File-KDBX build.log

Comment 10 Lester Hightower 2023-09-13 13:49:51 UTC
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.

Comment 11 Lester Hightower 2023-09-14 20:58:06 UTC
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.

Comment 12 Lester Hightower 2023-09-14 21:02:54 UTC
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)

Comment 13 Charles McGarvey 2023-09-15 03:37:09 UTC
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

Comment 14 Charles McGarvey 2023-09-15 03:53:57 UTC
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

Comment 15 Charles R. Anderson 2023-09-15 12:07:01 UTC
(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

Comment 16 Lester Hightower 2023-09-15 12:14:01 UTC
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.

Comment 17 Lester Hightower 2023-09-15 12:18:15 UTC
(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.

Comment 18 Charles R. Anderson 2023-09-15 12:42:28 UTC
(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.

Comment 19 Fedora Update System 2023-09-15 13:00:23 UTC
FEDORA-2023-74977d8d92 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-74977d8d92

Comment 20 Fedora Update System 2023-09-15 13:01:36 UTC
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.

Comment 21 Lester Hightower 2023-09-15 13:17:10 UTC
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.

Comment 22 Fedora Update System 2023-09-15 13:31:49 UTC
FEDORA-2023-174b1a814e has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-174b1a814e

Comment 23 Fedora Update System 2023-09-15 13:32:16 UTC
FEDORA-2023-c694005278 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c694005278

Comment 24 Fedora Update System 2023-09-15 13:32:38 UTC
FEDORA-2023-c1045623bf has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c1045623bf

Comment 25 Charles R. Anderson 2023-09-15 13:36:16 UTC
(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.

Comment 26 Lester Hightower 2023-09-16 13:18:43 UTC
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>