rmustacc: it looks good, unfortunately that system I saw it on is being used for several different things at the moment, but maybe sometime next week I might be able to sneak a build w/ those changes on it if that'd be helpful

also... for IPD14 aside from KRB5_KDB_EXPIRATION, krb5int_gmt_mktime() limits itself (even on 64-bit) to INT32_MAX (effectively)

(we're working on a fix since Win 2025 returns a timestamp in the year 2100 to mean 'no expiration')

which fails to decode

have you (RT) thought about refreshing krb5?

not yet, there's so much custom crap that sun added, and then it seems like the krb5 code is scattered all over the place that it'd be a fairly signifiant project

it is scattered, true, but I think, it is not totally hopeless:D significant for sure.

and the good thing is, we do not have to support the sun product (cant recall its name)...

honestly, i wouldn't mind (just personal opinion) throwing it out and using a purpose-built client and leave the server stuff as something the distros can package from MIT or whoever

every time I try looking at the code, it feels like it was only half integrated and seems like the worst of both worlds as a result -- a bunch of changes from upstream we have to make sense of and try to maintain, while also not taking advantage of facilities that'd make things easier because they're not portable

i take it i'm not the first to make such observations :)

jbk: I did a lot of work at a previous job with early krb5 and I've looked at how it's integrated into the gate and ... every time I just back away.

I believe we removed much of it from the gate and replaced it with the upstream code in the userland gate (though that's still somewhat patched, not pure upstream)

err, make that heavily patched: github.com/oracle/solaris-userland/…tree/master/components/krb5/patches

I get the sense that there are no kerberos libraries that are not a disaster

yeah... kinda like ldap (not that they're a disaster, but just they're not great, and pretty much all of them are basically minor variations of the original ldap library from like 1996)

I guess is there anything that really wants to use a specific kerberos API, or are most things using GSSAPI (which IIUC is kinda intended to be a more abstract interface that just in practice ends up a wrapper around kerberos)

?

(i.e. if someone were to come up with something less terrible, would there be a big concern about breakage?

Yeah I dunno

jbk: Are you working on TPM 2.0 stuff?

alan's link answers the biggest kerberos question, which is "What the heck did Sun do to this and why?"

jclulow: yes

i have a working driver, but it's limited to 1 open connection

Neat!

Are you able to use it for, like, ECDSA HSM purposes?

i don't see why you couldn't...

i have a number of patches to the tpm2-utils as well so they'll build on illumos

including for pkgsrc

though there's still a little bit of polish for the pkgsrc version

one thing to keep in mind is most TPMs have a very small amount of nvram

Yeah that's fair. I'm just trying to figure out if I can stop putting smart cards in the desktops we use on the manufacturing line

they just contain an ECDSA key (generated inside the card) to use as a machine principal today

the general idea (I'm simplifying a bit) is there's a master key that's created and never leaves the TPM, and you use it to wrap child keys (which themselves can wrap keys, etc)

and so you load the key + decrypt it in the TPM's memory to do stuff

(or load,decrypt, load child key, unload parent, etc)

but yeah that probably would work

jasonbking/illumos-gate 5c4b011 is the squashed commit for everything

that should be fairly usable (with the 1 connection caveat)

there are a few spots where the resource manager bits are meant to drop in

once i'm finished (they're almost there, but had to do some other stuff, so ahven't had time to finish those off)

and I might need to work some more on the big theory comment

the one unfortnate bit is TCG didn't really seem to think/care about tpm1.2 vs tpm2.0 in terms of consumers, so while they specify a fairly decent C client API, there's nothing standardized to be able to tell 'am I talking to a TPM1.2 chip or TPM2.0' aside from hueristics

so the pkcs11_tpm stuff probably won't work

probably not a concern for what you're doing, but also something i'm trying to figure out the best way to deal with in terms of integration

(I also refactored things so if/when we want to remove 1.2 support -- the mechanisms it supports really aren't useful -- it should be fairly simple to do)

github.com/jasonbking/pkgsrc/tree/t…-tss-2024/sysutils/tpm2-tss/patches are the tpm2 patches

i'd suggest starting with the tpm2-utils

tah

there's also a fairly decent free pdf that discusses tpms (far easier reading than the 1000+ pages of specs)

I guess I will get a machine and poke at it!

let me know if you run into anything.. i'm using the same patch (+ a static /etc/devlink.tab + /etc/minor_perms patch) on smartos (mostly just for better RNG so far) and haven't had any issues

as well as doing more stuff on some lab boxes at work

on our distro