FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2026-01-31T17:00:44Z 2026-01-31T17:00:44Z John Baldwin jhb@FreeBSD.org 2026-01-31T17:00:44Z urn:sha1:b26a7af438f36dcde86f39a681123cc2140affb2 This fixes a warning reported by GCC 14 on stable/14: crypto/heimdal/lib/hdb/keys.c:241:13: warning: 'free' called on pointer 'ext' with nonzero offset 16 [-Wfree-nonheap-object] 241 | free(hist_keys); | ^~~~~~~~~~~~~~~ crypto/heimdal/lib/hdb/keys.c:234:15: note: returned from 'calloc' 234 | ext = calloc(1, sizeof (*ext)); | ^~~~~~~~~~~~~~~~~~~~~~~~ Reviewed by: rmacklem, cy Fixes: 5000d023a446 ("heimdal-kadmin: Add support for the -f dump option") Differential Revision: https://reviews.freebsd.org/D54932 2026-01-31T17:00:15Z John Baldwin jhb@FreeBSD.org 2026-01-31T17:00:15Z urn:sha1:8a8dc73ef87b538c369abc1b642e2a40b52c53c2 This fixes the build with GCC 14 on stable/14 which raises fatal -Wimplicit-function-declaration warnings. Reviewed by: rmacklem, cy Fixes: 5000d023a446 ("heimdal-kadmin: Add support for the -f dump option") Differential Revision: https://reviews.freebsd.org/D54931 2025-10-05T16:18:35Z Rick Macklem rmacklem@FreeBSD.org 2025-10-05T16:18:35Z urn:sha1:5000d023a446b81f6d45ed59aa379607ec814f01 The "-f" dump option allows a dump of the Heimdal KDC in a format that the MIT kdb5_util command can load into a MIT KDC's database. This makes transitioning from the Heimdal KDC to the current MIT one feasible without having to re-create the KDC database from scratch. glebius@ did the initial work, cherry picking these commits from the Heimdal sources on github and then doing extensive merge conflict resolution and other fixes so that it would build. Heimdal commit fca5399 authored by Nico Williams: Initial commit for second approach for multiple kvno. NOT TESTED! Heimdal commit 57f1545 authored by Nico Williams: Add support for writing to KDB and dumping HDB to MIT KDB dump format Before this change Heimdal could read KDBs. Now it can write to them too. Heimdal can now also dump HDBs (including KDBs) in MIT format, which can then be imported with kdb5_util load. This is intended to help in migrations from MIT to Heimdal by allowing migrations from Heimdal to MIT so that it is possible to rollback from Heimdal to MIT should there be any issues. The idea is to allow a) running Heimdal kdc/kadmind with a KDB, or b) running Heimdal with an HDB converted from a KDB and then rollback by dumping the HDB and loading a KDB. Note that not all TL data types are supported, only two: last password change and modify-by. This is the minimum necessary. PKINIT users may need to add support for KRB5_TL_USER_CERTIFICATE, and for databases with K/M history we may need to add KRB5_TL_MKVNO support. This resulted in a Heimdal kadmin that would dump the KDC database in MIT format. However, there were issues when this dump was loaded into the current MIT KDC in FreeBSD current/15.0. The changes I did to make the dump more useful are listed below: When "-f MIT" is used for "kadmin -l dump" it writes the dump out in MIT format. This dump format is understood by the MIT kdb5_util command. The patch modifies the above so that the MIT KDC's master key keytab file can be provided as the argument to "-f" so that the principals are re-encrypted in it. This allows any principal with at least one strong encryption type key to work without needing a change_password. The strong encryption types supported by the Heimdal KDC are: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 The issues my changes address are: - If there are weak encryption keys in a principal's entry, MIT's kadmin.local will report that the principcal's entry is incomplete or corrupted. - The keys are encrypted in Heimdal's master key. The "-d" option can be used on the "kadmin -l dump" to de-encrypt them, but the passwords will not work on the current MIT KDC. To try and deal with the above issues, this patch modied the above to: - Does not dump the weak keys. - Re-encrypts the strong keys in MIT's master key if the argument to "-f" is actually a filename which holds the MIT KDC's master key keytab and not "MIT". - For principals that only have weak keys, it generates a fake strong key. This key will not work on the MIT KDC, but the principal entry will work once a change_password is done to it. - It always generates a "modified_by" entry, faking one if not already present in the Heimdal KDC database. This was necessary, since the MIT kadmin will report that the principal entry is "incomplete or corrupted" without one. It also fixed a problem where "get principal" no longer worked after the initial patch was applied. A man page update will be done as a separate commit. I believe this commit is acceptable since the Heimdal sources are now essentially deprecated in favor of the MIT sources and that this new "-f" patch simplifies the transition to the MIT KDC. Discussed with: glebius, cy MFC after: 3 days 2025-03-26T13:59:24Z Cy Schubert cy@FreeBSD.org 2025-03-26T13:43:54Z urn:sha1:d5c804138845a1c8d81fbbce48de676806de32e6 Patch supplied by mi@ through a private email. Bump __FreeBSD_version for ports that might need this. PR: 280025 MFC after 1 week 2024-07-30T19:24:17Z Dimitry Andric dim@FreeBSD.org 2024-07-30T18:31:47Z urn:sha1:6f25b46721a18cf4f036d041e7e5d275800a00b3 This fixes a clang 19 warning: crypto/heimdal/lib/krb5/deprecated.c:75:17: error: comparison of different enumeration types ('krb5_keytype' (aka 'enum ENCTYPE') and 'enum krb5_keytype_old') [-Werror,-Wenum-compare] 75 | if (keytype != KEYTYPE_DES || context->etypes_des == NULL) | ~~~~~~~ ^ ~~~~~~~~~~~ In https://github.com/heimdal/heimdal/commit/3bebbe5323 this was solved by adding a cast. That commit is rather large, so I'm only applying the one-liner here. MFC after: 3 days 2024-04-24T05:54:20Z Cy Schubert cy@FreeBSD.org 2014-01-10T19:18:06Z urn:sha1:a0d7d68a2dd818ce84e37e1ff20c8849cda6d853 Fix build when WITH_OPENLDAP defined. PR: 278430 Obtained from: Upstream c1c7da7f79 2024-04-17T17:49:30Z Dimitry Andric dim@FreeBSD.org 2024-04-17T17:49:30Z urn:sha1:219b6e442308d5353b2af5f0771ce9b887b70754 Import upstream 6747e1628: asn1: Use unsigned bitfields for named bitsets Signed 1-bit bitfields are undefined in C. This should fix the following warnings, which for unknown reasons are errors in CI: /usr/src/crypto/heimdal/lib/hx509/ca.c:1020:22: warning: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Wsingle-bit-bitfield-constant-conversion] 1020 | ku.digitalSignature = 1; | ^ ~ /usr/src/crypto/heimdal/lib/hx509/ca.c:1021:21: warning: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Wsingle-bit-bitfield-constant-conversion] 1021 | ku.keyEncipherment = 1; | ^ ~ /usr/src/crypto/heimdal/lib/hx509/ca.c:1028:17: warning: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Wsingle-bit-bitfield-constant-conversion] 1028 | ku.keyCertSign = 1; | ^ ~ /usr/src/crypto/heimdal/lib/hx509/ca.c:1029:13: warning: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Wsingle-bit-bitfield-constant-conversion] 1029 | ku.cRLSign = 1; | ^ ~ PR: 276960 Fixes: 1b7487592987 MFC after: 1 week 2024-04-17T16:12:43Z Dimitry Andric dim@FreeBSD.org 2024-04-16T18:56:37Z urn:sha1:1b7487592987c91020063a311a14dc15b6e58075 Import upstream 19d378f44: ASN.1 INTEGERs will now compile to C int64_t or uint64_t, depending on whether the constraint ranges include numbers that cannot be represented in 32-bit ints and whether they include negative numbers. Template backend support included. check-template is now built with --template, so we know we're testing it. Tests included. Also adjusts the generated files: * asn1parse.c, asn1parse.h (not strictly necessary, but nice to have) * der-protos.h, which needs a bunch of new prototypes. I copied these from a der-protos.h generated by the upstream build system, which uses a perl script for this. * adjust printf format strings for int64_t. Upstream uses %lld for this, but that is not portable, and leads to lots of -Werror warnings. This should fix target-dependent differences between headers generated by asn1_compile. For example, when cross compiling world from amd64 to i386, the generated cms_asn1.h header has: CMSRC2CBCParameter ::= SEQUENCE { rc2ParameterVersion INTEGER (0..-1), iv OCTET STRING, } while a native build on i386 has: CMSRC2CBCParameter ::= SEQUENCE { rc2ParameterVersion INTEGER (0..2147483647), iv OCTET STRING, } These are _both_ wrong, since the source file, cms.asn1, has: CMSRC2CBCParameter ::= SEQUENCE { rc2ParameterVersion INTEGER (0..4294967295), iv OCTET STRING -- exactly 8 octets } PR: 276960 Reviewed by: cy, emaste MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D44814 Differential Revision: https://reviews.freebsd.org/D44815 2024-03-07T00:55:11Z Brooks Davis brooks@FreeBSD.org 2024-03-07T00:55:11Z urn:sha1:cec2adb0d3ef91fc4279529a65975a934bcd2ff4 For one reason or another these symbols aren't present so don't try to make them available for linkage. In the case of libroken these seem to be compatability bits we don't need a thus don't compile. For others it seems to rot upstream, but I've not investigated deeply. Reviewed by: cy Differential Revision: https://reviews.freebsd.org/D44246 2024-03-07T00:54:55Z Brooks Davis brooks@FreeBSD.org 2024-03-07T00:54:55Z urn:sha1:de4386d174146781c45907204a61aec4cbbb2b44 This symbol table entry came in with the 1.5 import (commit 7c450da7b446), but the only other mention is a commented out entry in lib/wind/libwind-exports.def. Reviewed by: cy Differential Revision: https://reviews.freebsd.org/D44245