From nobody Mon Sep 08 22:31:38 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cLMBj6l8Jz67CVD for ; Mon, 08 Sep 2025 22:31:57 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cLMBj4QtCz3KLG; Mon, 08 Sep 2025 22:31:57 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-6188b7550c0so6410546a12.2; Mon, 08 Sep 2025 15:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757370711; x=1757975511; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qKtHwjaw0TgG+Jm7m9Zio6IiWVdomh9ctLgh0+VuNIs=; b=cRgB2cGPBsrtNH/aRkagvplq+1XDDoAyTRuivggSd5i7NLkWrra/qF8jSQvVbfMr8m Y0jZP2VA/HwWpVVLegO/270lbfqPC4WiyOFCK1RgrB12RPZm/7lgMibUp6nC/9VsxKJS M49WDE5gvWCqYgeU8z5vGTq0EW9/eqMmvQ5SNMnK+PcbWGRSHPumJXFvePYWcaIwlEfZ c/efwRXRLBKsK9bj2dxt20fGZ/td1ZZxxPKDYBwwX+7PBhQp1VneTvTlIdOyZAFsOpfj YSR3symqFFyPM4MA3esBNs28vKJCB+XtB5h4KNy2AwNottcslMS29JFZeSqcuoJT67jF kVyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757370711; x=1757975511; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qKtHwjaw0TgG+Jm7m9Zio6IiWVdomh9ctLgh0+VuNIs=; b=Rh+p/AZEtxo3xe3VxrWV1VT49bccvV/TdwpI+/kFYsu8Yl0nketNuSXlr11YJHhFs+ jM8aaxitAnr8A5lD+Sst47TS50LB2V9oH9R77+2dYHgSx8FSHjDRwrDN+SPNcDX6h57p G14r+UICVN+yd06d7E1EkhU5pOb7fDtjt7FcyfarQ68pGWoNNd+7Y0lgescEsb+RydKP 7I9JimXatBgbNUtQ+x2IGPiuJfz4jZ6RIg8rpCtuG9QOqVGqvYPzY7g15LxL/U4rWV7r yE1xFedOupcX2LFBRIjtlVW5hwFT92NDxcv1Gn1vv25+olp6QiGw1N7guU+mQvQ6PC3M velQ== X-Forwarded-Encrypted: i=1; AJvYcCWfiqH3cWpXq86TdSfoY6ZUhMYyqqKUrcLz83kpDdDGqgVXb0Imgj6d4LBm0YG2yZojso+Jm80pYdakMu+vMqs=@freebsd.org X-Gm-Message-State: AOJu0YyDdDWMrBG0V1rwfTFWz0OF5EWXZytvmEHvtVuWSpS/OTMct1N7 n3yGVMcv/9NmsOUqSRRA++moOhkwPauxGo8eMoUx4YBQw0JLVPFxXPTIRAHlmKcwUqUi+e65r9+ 3KSf5y3AXTGdw9o5tV9AbF1y9nYGsNOWb X-Gm-Gg: ASbGncuSYT5w7mE+e17aTJZc6UGvTNY3idI/gPTBSeTikYoWi4SB38fiDnQjc8YUOkX +zPV8Cr2q4WqB/xsHd8sahSLYNRQFjAYza27evSVnNFEhrp5k9raeVun5JKB3wkkd072ytla1cm Kj3ThDvr/2KX7oVSI95Xjz6nfqEXzo0aUIY90lScG2AnZ5Y/HBg/0EPxNdcBa26DEiNAmR4C5S0 NsuphHrV+Nc2cS1uCR9c+RrxTpV6jk3VtWDISs= X-Google-Smtp-Source: AGHT+IE9UPtieQw4bHJ4EoAKkYVfhGSCkOBh70c9iwVPWAIrd3JzqfH30TbBwLvIAea7SpKRXJC9p5GNTWzRu4mukmE= X-Received: by 2002:a05:6402:42cb:b0:628:eb99:982c with SMTP id 4fb4d7f45d1cf-628eb9999d6mr4264252a12.28.1757370710296; Mon, 08 Sep 2025 15:31:50 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> <20250903043714.370F5311@slippy.cwsent.com> <20250908202353.854F9286@slippy.cwsent.com> In-Reply-To: <20250908202353.854F9286@slippy.cwsent.com> From: Rick Macklem Date: Mon, 8 Sep 2025 15:31:38 -0700 X-Gm-Features: AS18NWCZCQlRUoXJPOjCSqoGWVJIHwgvo5BigfzeJIz2n_MAOxkTqMsYQ4nrm34 Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Cy Schubert Cc: Gleb Smirnoff , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cLMBj4QtCz3KLG On Mon, Sep 8, 2025 at 1:23=E2=80=AFPM Cy Schubert wrote: > > In message om> > , Rick Macklem writes: > > On Wed, Sep 3, 2025 at 8:28=3DE2=3D80=3DAFAM Rick Macklem > > wrote: > > > > > > On Tue, Sep 2, 2025 at 10:10=3DE2=3D80=3DAFPM Rick Macklem > com> wrote: > > > > > > > > On Tue, Sep 2, 2025 at 9:37=3DE2=3D80=3DAFPM Cy Schubert > rt.com> wrote: > > > > > > > > > > In message > gmail.c > > > > > om> > > > > > , Rick Macklem writes: > > > > > > On Sun, Aug 31, 2025 at 5:58=3D3DE2=3D3D80=3D3DAFPM Rick Mackle= m > cklem@gmail.co=3D3D > > > > > > m> wrote: > > > > > > > > > > > > > > On Sun, Aug 31, 2025 at 5:41=3D3DE2=3D3D80=3D3DAFPM Rick Mack= lem > macklem@gmail.=3D3D > > > > > > com> wrote: > > > > > > > > > > > > > > > > On Sat, Aug 30, 2025 at 9:47=3D3DE2=3D3D80=3D3DAFPM Rick Ma= cklem > k.macklem@gmai=3D3D > > > > > > l.com> wrote: > > > > > > > > > > > > > > > > > > On Sat, Aug 30, 2025 at 4:22=3D3DE2=3D3D80=3D3DAFPM Rick = Macklem > ick.macklem@gm=3D3D > > > > > > ail.com> wrote: > > > > > > > > > > > > > > > > > > > > On Sat, Aug 30, 2025 at 8:56=3D3DE2=3D3D80=3D3DAFAM Ric= k Macklem =3D > > > > > > > gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > On Fri, Aug 29, 2025 at 1:05=3D3DE2=3D3D80=3D3DAFPM R= ick Mackle=3D > > m > > > > > m@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Aug 29, 2025 at 7:43=3D3DE2=3D3D80=3D3DAFAM= Rick Mack=3D > > lem > > > > > lem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 8:39=3D3DE2=3D3D80=3D3DAF= PM Rick Ma=3D > > cklem > > > > > cklem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 7:43=3D3DE2=3D3D80=3D3D= AFPM Rick =3D > > Macklem > > > > > macklem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 9:35=3D3DE2=3D3D80=3D= 3DAFAM Gle=3D > > b Smirnoff > > > > > ebius@freebsd.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, G= leb =3D > > Smirnoff=3D3D > > > > > > wrote: > > > > > > > > > > > > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700= , Ri=3D > > ck Mackl=3D3D > > > > > > em wrote: > > > > > > > > > > > > > > > > T> R> Ok. If you install FreeBSD-13.5 and t= hen =3D > > "pkg ins=3D3D > > > > > > tall heimdal", you get a > > > > > > > > > > > > > > > > T> R> working Heimdal-7.8 in ports. > > > > > > > > > > > > > > > > T> R> > > > > > > > > > > > > > > > > T> R> Now, I have another challenge. Fixing= the=3D > > master =3D3D > > > > > > passwords. > > > > > > > > > > > > > > > > T> R> I'll work on it later to-day. > > > > > > > > > > > > > > > > T> > > > > > > > > > > > > > > > > T> I have applied two commits from Heimdal = from=3D > > 2012 th=3D3D > > > > > > at add 'kadmin dump -f MIT' > > > > > > > > > > > > > > > > T> feature to our base heimdal and polished= the=3D > > m to com=3D3D > > > > > > pile. So far it doesn't > > > > > > > > > > > > > > > > T> work yet, either create an empty dump or= cre=3D > > ate a co=3D3D > > > > > > re dump, instead of > > > > > > > > > > > > > > > > T> database dump :) I'll see how difficult = it i=3D > > s going =3D3D > > > > > > to further resolve that to > > > > > > > > > > > > > > > > T> a working condition. If I succeed, then = havi=3D > > ng 'dump=3D3D > > > > > > -f MIT' in base without > > > > > > > > > > > > > > > > T> any ports would be the best solution. C= an a=3D > > lso be m=3D3D > > > > > > erged to FreeBSD 14.4. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Good news. In the above paragraph I was te= stin=3D > > g my cha=3D3D > > > > > > nge incorrectly - threw > > > > > > > > > > > > > > > > the new binary on a system running unpatche= d li=3D > > braries.=3D3D > > > > > > When run correctly, > > > > > > > > > > > > > > > > it successfully produced something that loo= ks l=3D > > ike a co=3D3D > > > > > > rrect dump in MIT format. > > > > > > > > > > > > > > > > I haven't yet tried to load it into MIT kdc= yet=3D > > , though=3D3D > > > > > > . > > > > > > > > > > Well, would you like the not so bad news or the bad new= s??;=3D > > -) > > > > > > > > > > Your patch works, in that it produces a dump that "kdb5= _uti=3D > > l load > > > > > > > > > > -update" can load. > > > > > > > > > > After loading, if the principal only has keys for the n= ewer=3D > > encrypt=3D3D > > > > > > ion types of > > > > > > > > > > aes256-cts-hmac-sha1-96 > > > > > > > > > > aes128-cts-hmac-sha1-96 > > > > > > > > > > then you can look at the principal via kadmin.local, bu= t th=3D > > e passwo=3D3D > > > > > > rd must > > > > > > > > > > be changed before it works. > > > > > > > > > > --> This is the same behaviour as you get if you use He= imda=3D > > l-7.8 to=3D3D > > > > > > do the > > > > > > > > > > dump conversion. > > > > > > > > > > So far, so good... > > > > > > > > > > > > > > > > > > > > Now, the not so good news. Once you update the Heimdal = libr=3D > > aries > > > > > > > > > > (libhdb.so and libkadm5srv.so) "kadmin -l" is broken on= the=3D > > system > > > > > > > > > > running the old KDC. "kadmin -l dump" works, but someth= ing =3D > > like: > > > > > > > > > > # kadmin -l > > > > > > > > > > kadmin> get rmacklem > > > > > > > > > > kadmin: get rmacklem: Service key not available > > > > > > > > > > - I have not yet looked in your patched sources to see = wher=3D > > e this > > > > > > > > > > failure comes from? > > > > > > > > > > > > > > > > > > > > Now, more not so good news... > > > > > > > > > > My patch doesn't help. > > > > > > > > > > It does re-encrypt the key in the master key from the M= IT K=3D > > DC > > > > > > > > > > system, but that doesn't make the password work. > > > > > > > > > > When I compared the dump generated via kadmin with both > > > > > > > > > > your patch and mine, the key for aes256-cts-hmac-sha1-9= 6 > > > > > > > > > > is 34bytes long. > > > > > > > > > > After doing the change_password so that it works, a dum= p > > > > > > > > > > generated by "kdb5_util dump -r13" (the same dump forma= t) > > > > > > > > > > has a key that is 62bytes long. > > > > > > > > > > --> So, there is more to converting the key than just r= e-ec=3D > > rypting > > > > > > > > > > it. (I'll try and find where the MIT code encrypt= s a =3D > > key in a=3D3D > > > > > > master > > > > > > > > > > key to see why it ends up at 62bytes and whether = that=3D > > can be =3D3D > > > > > > done > > > > > > > > > > in the old code.) > > > > > > > > > > > > > > > > > > > > So, if we are going to continue with this... > > > > > > > > > > - We need to figure out why your patch breaks "kadmin" = for =3D > > other > > > > > > > > > > things and fix that. > > > > > > > > > > - I/we need to figure out how to convert the 34byte key= to =3D > > the MIT > > > > > > > > > > 62byte key (and then maybe the password won't need to= be =3D > > changed?=3D3D > > > > > > ). > > > > > > > > > > > > > > > > > > > > Or do we just say "When you convert the KDC database, a= ll t=3D > > he passw=3D3D > > > > > > ords > > > > > > > > > > must be changed to get them to work?". > > > > > > > > > All I've got sofar is this patch... > > > > > > > > > https://people.freebsd.org/~rmacklem/print.patch > > > > > > > > > > > > > > > > > > It tweaks entry2mit_string_int() so that it skips over th= e ke=3D > > ys for > > > > > > > > > old encryption types and fills in a fake "modified by" en= try =3D > > if none > > > > > > > > > exists. > > > > > > > > > > > > > > > > > > These changes at least make the MIT dump such that the re= cord=3D > > s > > > > > > > > > don't end up "incomplete or corrupted" when you try to do= som=3D > > ething > > > > > > > > > like "get_principal " in kadmin.local. > > > > > > > > > > > > > > > > > > As noted, your patch makes "kadmin -l" break for most thi= ngs, > > > > > > > > > reporting "Service key not available". The failures go aw= ay i=3D > > f > > > > > > > > > you revert back to the non-patched libraries. > > > > > > > > > I have not located the problem yet. > > > > > > > > > > > > > > > > > > As for the passwords...no luck yet, rick > > > > > > > > Finally..it works. (First off, apologies for all the posts,= jus=3D > > t ignore > > > > > > > > them.;-) > > > > > > > > > > > > > > > > The patch is at: > > > > > > > > https://people.freebsd.org/~rmacklem/kadmin.patch > > > > > > I just updated the patch with a fix for the case where the > > > > > > Heimdal principal does not have any keys for string encryption. > > > > > > (That is fixed now and I haven't found any other bugs, so I > > > > > > think I am done playing with it. Yippee!!) > > > > > > > > > > > > Please test when you can find the time, rick > > > Outstanding issue/question w.r.t. converting the KDC database > > > from Heimdal 1.5.2->MIT. > > > > > > Right now, the patch I have drops the weak encryption type keys > > > (des3.. and arcfour..). > > > If the principal in the Heimdal KDC does not have keys for either > > > of: > > > aes256-cts-hmac-sha1-96 > > > aes128-cts-hmac-sha1-96 > > > the patch generates a "fake" one. As a result, a change_password > > > for the principal is needed for this case. > > > > > > The alternative to doing this would be an option that converts > > > the weak keys, but... > > > - The MIT KDC will find the principal "incomplete or corrupted" > > > for at least the "out-of-the-box" configuration. > > > - It might accept them if "accept_weak_ecntypes" is set in > > > the kdc.conf. > > > This leads to a couple of questions: > > > - Does anyone know if MIT 1.22 still allows > > > "accept_weak_enctypes? > > > If it does not allow them, I don't think there is much use > > > for this option? > > > > > > Given the release schedule, it would be nice to get this > > > resolved soon. > > Since no one reported whether or not they saw the > > "Service key not available" errors from the patched kadmin > > for commands like "get", I poked at it and found it was caused > > by some code the cherry-pick from the newer Heimdal added, > > related to historical keys (which are not supported by Heimdal 1.5.2.) > > > > Commenting out one new function the cherry-pick added along > > with the two calls to it seems to have fixed the problem. > > > > I've updated my patch at: > > https://people.freebsd.org/~rmacklem/kadmin.patch > > to include these changes. > > > > So, can you guys test this and get it into main? > > (You are welcome to include my patch in the commit, > > That is probably faster than doing it as a separate one.) > > At this point, it works for everything I have tested and, yes, > > the passwords do work after the dump is loaded into the > > MIT KDC! > > > > rick > > ps: I cannot test it more than I have already done until it > > is in a snapshot that I can install for further testing. > > The patch doesn't apply here. Do I need to apply a prerequisite patch? It applies on top of glebius@'s branch. I think you can get it by.. git clone https://github.com/glebius/FreeBSD - and then git checkout kadmin-dump-MIT and then the patch should apply on top of that. I built it via "make buildworld" with WITHOUT_MITKRB5=3D"yes" in my /etc/src.conf. (It took days because I couldn't figure out how to get a universe machine to build it?) rick > > slippy$ git apply /tmp/kadmin.patch > error: patch failed: crypto/heimdal/kadmin/dump.c:72 > error: crypto/heimdal/kadmin/dump.c: patch does not apply > error: patch failed: crypto/heimdal/lib/hdb/common.c:156 > error: crypto/heimdal/lib/hdb/common.c: patch does not apply > error: patch failed: crypto/heimdal/lib/hdb/mkey.c:458 > error: crypto/heimdal/lib/hdb/mkey.c: patch does not apply > error: patch failed: crypto/heimdal/lib/hdb/print.c:378 > error: crypto/heimdal/lib/hdb/print.c: patch does not apply > slippy$ > slippy$ > slippy$ patch -C -p1 < /tmp/kadmin.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |commit 66bbcc907b21adea8af90ac080faed14dd4be439 > |Author: Rick Macklem > |Date: Fri Aug 29 07:05:00 2025 -0700 > | > | kadmin: Add support for conversion to MIT's master key > | > | 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. > | > | However, there are a couple of issues: > | - 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. > | This is also true if there is no modified_by component > | in the dump line for a principal. > | - 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: > | - Does not dump the weak keys. > | If a principal does not have a key for any strong > | key encryption type, a strong key is generated for it, > | but is not encrypted in the MIT master key. > | As such, this principal will need a change_password > | after being loaded into the MIT KDC. > | - If there is no modified_by field in the principal's > | database entry, a fake one is generated. > | - Re-encrypts the keys in MIT's master key if the argument > | to "-f" is actually the MIT KDC's master key keytab file > | and not "MIT" or "Heimdal". > | To make this work, the command > | "kadmin -l dump -f .k5.YOUR.REALM mit.dump" > | must be done on the Heimdal KDC, where .k5.YOUR.REALM > | is the master key keytab file for the MIT KDC. > | Then "mit.dump" must be copied to the MIT KDC and > | loaded into the MIT KDC's database via the command > | "kdb5_util load -update mit.dump". > | > | This patch is currently only tested for the simple > | setup I am running. > | > |diff --git a/crypto/heimdal/kadmin/dump.c b/crypto/heimdal/kadmin/dump.c > |index 0f2ed7445126..2c302eced210 100644 > |--- a/crypto/heimdal/kadmin/dump.c > |+++ b/crypto/heimdal/kadmin/dump.c > -------------------------- > Patching file crypto/heimdal/kadmin/dump.c using Plan A... > Hunk #1 failed at 72. > 1 out of 1 hunks failed while patching crypto/heimdal/kadmin/dump.c > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |diff --git a/crypto/heimdal/lib/hdb/common.c b/crypto/heimdal/lib/hdb/co= mmo > n.c > |index 90e600521e34..80482e7a4c1c 100644 > |--- a/crypto/heimdal/lib/hdb/common.c > |+++ b/crypto/heimdal/lib/hdb/common.c > -------------------------- > Patching file crypto/heimdal/lib/hdb/common.c using Plan A... > Hunk #1 failed at 156. > Hunk #2 failed at 181. > 2 out of 2 hunks failed while patching crypto/heimdal/lib/hdb/common.c > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |diff --git a/crypto/heimdal/lib/hdb/hdb.h b/crypto/heimdal/lib/hdb/hdb.h > |index 562cceead8ec..4c4c2c2b1a5c 100644 > |--- a/crypto/heimdal/lib/hdb/hdb.h > |+++ b/crypto/heimdal/lib/hdb/hdb.h > -------------------------- > Patching file crypto/heimdal/lib/hdb/hdb.h using Plan A... > Hunk #1 succeeded at 256. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |diff --git a/crypto/heimdal/lib/hdb/hdb_locl.h b/crypto/heimdal/lib/hdb/= hdb > _locl.h > |index cb5040080e4e..5aad504589df 100644 > |--- a/crypto/heimdal/lib/hdb/hdb_locl.h > |+++ b/crypto/heimdal/lib/hdb/hdb_locl.h > -------------------------- > Patching file crypto/heimdal/lib/hdb/hdb_locl.h using Plan A... > Hunk #1 succeeded at 67 (offset -2 lines). > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |diff --git a/crypto/heimdal/lib/hdb/mkey.c b/crypto/heimdal/lib/hdb/mkey= .c > |index ff68aa1bb23d..78a9e51a132c 100644 > |--- a/crypto/heimdal/lib/hdb/mkey.c > |+++ b/crypto/heimdal/lib/hdb/mkey.c > -------------------------- > Patching file crypto/heimdal/lib/hdb/mkey.c using Plan A... > Hunk #1 succeeded at 403 (offset -12 lines). > Hunk #2 succeeded at 433 (offset -12 lines). > Hunk #3 succeeded at 451 with fuzz 2 (offset -12 lines). > Hunk #4 failed at 584. > Hunk #5 failed at 633. > 2 out of 5 hunks failed while patching crypto/heimdal/lib/hdb/mkey.c > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |diff --git a/crypto/heimdal/lib/hdb/print.c b/crypto/heimdal/lib/hdb/pri= nt. > c > |index 444db39493fc..d5359f538056 100644 > |--- a/crypto/heimdal/lib/hdb/print.c > |+++ b/crypto/heimdal/lib/hdb/print.c > -------------------------- > Patching file crypto/heimdal/lib/hdb/print.c using Plan A... > No such line 377 in input file, ignoring > Hunk #1 failed at 378. > Hunk #2 failed at 391. > Hunk #3 failed at 418. > Hunk #4 failed at 434. > Hunk #5 failed at 453. > Hunk #6 failed at 470. > Hunk #7 failed at 481. > Hunk #8 failed at 495. > Hunk #9 failed at 531. > 9 out of 9 hunks failed while patching crypto/heimdal/lib/hdb/print.c > done > slippy$ > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e**(i*pi)+1=3D0 > >