Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add LibreSSL patch for app-crypt/mit-krb5 #577

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

blucybrb14de
Copy link

@blucybrb14de blucybrb14de commented Oct 31, 2024

@blucybrb14de Can you try this patch?

mit-krb5-1.21.3-libressl.patch.txt

It builds, but I am unsure if it works. The tests fail on my end with a failure like this Gentoo issue and I am unsure if its related to libressl or not.

  • Fixes app-crypt/mit-krb5 emake failed #571 , as it does not appear that the error here, is due to cryptographic functions used by LibreSSL.
  • It appears that the error is also consistent with ppc, using openssl for that user.
  • It seem to show that it builds successfully, with the tests on my end, with realm trust path navigation, and ticket granting ticket retrieval working as expected.
  • Fixes it as a build dependency for other packages.

@orbea
Copy link
Contributor

orbea commented Oct 31, 2024

With all due honesty I am a little hesitant to proceed yet when the tests fail for different reasons for both of us and your test case is blocked for yet another reason...

@blucybrb14de
Copy link
Author

With all due honesty I am a little hesitant to proceed yet when the tests fail for different reasons for both of us and your test case is blocked for yet another reason...

After re-testing, and taking a look at the error, it seems that it is likely caused by my configuration because of the last line.

 *** Output of last command:
t_kadm5srv: /var/tmp/portage/app-crypt/mit-krb5-1.21.3-r1/work/krb5-1.21.3/src/lib/kadm5/t_kadm5.c:826: test_init_destroy: Assertion `ret == (rpc ? KADM5_MISSING_KRB5_CONF_PARAMS : ENOENT)' failed.
For details, see: /var/tmp/portage/app-crypt/mit-krb5-1.21.3-r1/work/krb5-1.21.3/src-abi_x86_64.amd64/lib/kadm5/testlog
Or re-run this test script with the -v flag:
    cd /var/tmp/portage/app-crypt/mit-krb5-1.21.3-r1/work/krb5-1.21.3/src-abi_x86_64.amd64/lib/kadm5
    PYTHONPATH=/var/tmp/portage/app-crypt/mit-krb5-1.21.3-r1/work/krb5-1.21.3/src/util /usr/bin/python3.13 /var/tmp/portage/app-crypt/mit-krb5-1.21.3-r1/work/krb5-1.21.3/src/lib/kadm5/t_kadm5.py -v

Use --debug=NUM to run a command under a debugger.  Use
--stop-after=NUM to stop after a daemon is started in order to
attach to it with a debugger.  Use --help to see other
options.
make[2]: *** [Makefile:704: check-pytests] Error 1
make[2]: Leaving directory '/var/tmp/portage/app-crypt/mit-krb5-1.21.3-r1/work/krb5-1.21.3/src-abi_x86_64.amd64/lib/kadm5'
make[1]: *** [Makefile:973: check-recurse] Error 1
make[1]: Leaving directory '/var/tmp/portage/app-crypt/mit-krb5-1.21.3-r1/work/krb5-1.21.3/src-abi_x86_64.amd64/lib'
make: *** [Makefile:1520: check-recurse] Error 1
 * ERROR: app-crypt/mit-krb5-1.21.3-r1::cybrnet-overlay failed (test phase):
 *   emake failed
 *
 * If you need support, post the output of `emerge --info '=app-crypt/mit-krb5-1.21.3-r1::cybrnet-overlay'`,
 * the complete build log and the output of `emerge -pqv '=app-crypt/mit-krb5-1.21.3-r1::cybrnet-overlay'`.
 * The complete build log is located at '/var/tmp/portage/app-crypt/mit-krb5-1.21.3-r1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/app-crypt/mit-krb5-1.21.3-r1/temp/environment'.
 * Working directory: '/var/tmp/portage/app-crypt/mit-krb5-1.21.3-r1/work/krb5-1.21.3/src-abi_x86_64.amd64'
 * S: '/var/tmp/portage/app-crypt/mit-krb5-1.21.3-r1/work/krb5-1.21.3/src'

It appears that there is a missing parameter that causes it to fail with USE=test. I just put this test configuration together, based off of what I could find online. Here is the configuration, that I am currently using:

 [libdefaults]
    default_realm = TEST.LOCAL
    dns_lookup_realm = false
    dns_lookup_kdc = false

[realms]
    TEST.LOCAL = {
        kdc = localhost
        admin_server = localhost
    }

[domain_realm]
    .test.local = TEST.LOCAL
    test.local = TEST.LOCAL

[logging]
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmin.log
    default = FILE:/var/log/krb5lib.log

Is anyone able to provide their configuration to see, if they are either able to reproduce this, or if I am able to test some other configuration, just to eliminate the possibility of it being related to LibreSSL, or if this is sufficient to proceed?

@orbea
Copy link
Contributor

orbea commented Nov 9, 2024

Is anyone able to provide their configuration to see, if they are either able to reproduce this, or if I am able to test some other configuration, just to eliminate the possibility of it being related to LibreSSL, or if this is sufficient to proceed?

The basic problem is lacking some way to test that mit-krb5 is not entirely broken at runtime with LibreSSL. Generally the tests would help here, but given the number of test failures in the Gentoo issue tracker and how we are both failing for different reasons I am skeptical how useful they are.

Alternatively knowing dotnet-sdk and your own personal use case works would probably be good enough to make sure mit-krb5 at least somewhat works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

app-crypt/mit-krb5 emake failed
2 participants