01:48:56 <gitomat> [illumos-gate] 18349 pchsmbus panics on unexpected I/O error -- Robert Mustacchi <rm⊙fo>
07:48:47 <gitomat> [illumos-gate] 18235 nvme: don't panic on I/O to a removed shared namespace -- Alexey Romanov <romanov.alexey2000⊙gc>
12:27:19 <gitomat> [illumos-gate] 18408 core(5) should describe the old NOTE segment as historical -- Andy Fiddaman <illumos⊙fn>
12:27:20 <gitomat> [illumos-gate] 18398 SCTP sockets reject all IPPROTO_IP options following 18351 -- Andy Fiddaman <illumos⊙fn>
14:47:24 <gemelen> a generic illumos and solaris question: for an encrypted zfs homedir, were there any solutions to bridge pam_zfs_key usage in case of passwordless remote user login (say ssh pubkey or others)?
16:19:01 <jbk> i'm not aware of any offhand...
16:20:17 <jbk> the problem is mounting an encrypted zfs dataset requires a key, so where does it go and how do you get it to zfs?
16:20:51 <jbk> IIUC, pam_zfs_key prompts the user
16:21:10 <jbk> but if you're not going to do that, then how do you get it in a manner that's still secure?
16:23:01 <jbk> you could maybe escrow the zfs key somewhere wrapped by your ssh public key, but then where do you keep that?
16:23:44 <jbk> (triton does something kinda like this, but it assumes that is the only way the dataset is being unlocked
16:24:02 <jbk> (it also doesn't use pam)
17:28:40 <sommerfeld> perhaps an ssh protocol or ssh-agent protocol extension to pass the keys around when you're connected.   but there's also the question of crisply defining your threat model and ensuring the key management is consistent with it..