13:41:19 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 13:45:27 also... for IPD14 aside from KRB5_KDB_EXPIRATION, krb5int_gmt_mktime() limits itself (even on 64-bit) to INT32_MAX (effectively) 13:46:05 (we're working on a fix since Win 2025 returns a timestamp in the year 2100 to mean 'no expiration') 13:46:18 which fails to decode 13:46:57 have you (RT) thought about refreshing krb5? 13:48:01 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 13:48:40 it is scattered, true, but I think, it is not totally hopeless:D significant for sure. 13:50:54 and the good thing is, we do not have to support the sun product (cant recall its name)... 13:51:19 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 13:52:51 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 15:04:37 * danmcd bites his tongue... 15:06:38 i take it i'm not the first to make such observations :) 16:21:32 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. 16:56:57 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) 16:58:11 err, make that heavily patched: https://github.com/oracle/solaris-userland/tree/master/components/krb5/patches 18:09:04 I get the sense that there are no kerberos libraries that are not a disaster 18:12:10 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) 18:14:15 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) 18:14:19 ? 18:17:46 (i.e. if someone were to come up with something less terrible, would there be a big concern about breakage? 19:07:08 Yeah I dunno 19:07:33 jbk: Are you working on TPM 2.0 stuff? 19:11:44 alan's link answers the biggest kerberos question, which is "What the heck did Sun do to this and why?" 19:30:21 jclulow: yes 19:30:32 i have a working driver, but it's limited to 1 open connection 19:30:40 Neat! 19:30:53 Are you able to use it for, like, ECDSA HSM purposes? 19:31:26 i don't see why you couldn't... 19:31:38 i have a number of patches to the tpm2-utils as well so they'll build on illumos 19:31:48 including for pkgsrc 19:31:57 though there's still a little bit of polish for the pkgsrc version 19:32:51 one thing to keep in mind is most TPMs have a very small amount of nvram 19:33:27 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 19:33:41 they just contain an ECDSA key (generated inside the card) to use as a machine principal today 19:33:49 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) 19:34:15 and so you load the key + decrypt it in the TPM's memory to do stuff 19:34:26 (or load,decrypt, load child key, unload parent, etc) 19:34:40 but yeah that probably would work 19:36:27 https://github.com/jasonbking/illumos-gate/commit/5c4b01191fbf8099f403503c6c529c644e7102ab is the squashed commit for everything 19:36:43 that should be fairly usable (with the 1 connection caveat) 19:36:59 there are a few spots where the resource manager bits are meant to drop in 19:37:25 once i'm finished (they're almost there, but had to do some other stuff, so ahven't had time to finish those off) 19:37:57 and I might need to work some more on the big theory comment 19:39:52 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 19:40:05 so the pkcs11_tpm stuff probably won't work 19:40:26 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 19:41:09 (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) 19:43:11 https://github.com/jasonbking/pkgsrc/tree/tpm2-tss-2024/sysutils/tpm2-tss/patches are the tpm2 patches 19:43:27 i'd suggest starting with the tpm2-utils 19:45:41 tah 19:45:49 there's also a fairly decent free pdf that discusses tpms (far easier reading than the 1000+ pages of specs) 19:45:52 https://link.springer.com/book/10.1007/978-1-4302-6584-9 20:08:07 I guess I will get a machine and poke at it! 20:20:10 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 20:20:21 as well as doing more stuff on some lab boxes at work 20:20:27 on our distro