[13:00] <rtg> tseliot, have you built nVidia against a 4.6 kernel yet ? we've got one for you in the yakkety pocket of https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa
[13:38] <tseliot> rtg: I have built 361 with a patch for 4.6, and I'll use that kernel for testing now, thanks
[13:38] <rtg> tseliot, great!
[14:15] <tseliot> rtg: ok, the patch seems to need more work. I'll let you know when it's ready
[14:23] <rtg> tseliot, ack
[20:39] <Laney> anyone know of a guide that'll tell me how to make dkms sign modules it builds?
[20:42] <apw> Laney, sign them with what
[20:42] <Laney> this key that I made
[20:42] <Laney> and then added to the mok thingy
[20:42] <apw> Laney, i know of no existing mecahnaism for that
[20:42] <Laney> wl.ko is now signed so I'm at least online :)
[20:43] <Laney> but the next kernel will I guess not have that
[20:43] <apw> no indeed, but having the signing key on the machine seems like a lawed security position
[20:44] <Laney> it's at least root only
[20:44] <Laney> I haven't thought about this *that* much
[20:44] <rtg> Laney, https://docs.google.com/document/d/1Z1_jR3MmxuvqolQH4PORkJCgENkb2Tlw4FVA-sHqdMw
[20:45] <apw> rtg, i think he has done the equivalent of that
[20:45] <Laney> yeah
[20:45] <rtg> I think cyphermox is working on the user space components for DKMS signing
[20:46] <Laney> okay, so not there yet
[20:46] <apw> is there any sane configuration where you have the signing key on disk?  if you do you might as well just turn secure boot of at MOK ?
[20:46] <Laney> I should read aout the arguments around this signing stuff
[20:54] <Laney> I suppose it's something like -
[20:54] <Laney> The key database is 'secure' even in the face of the system being rooted
[20:55] <Laney> and so an attacker that has root wouldn't be able to make the kernel load things if they don't have the signing key
[20:55] <apw> in theory, the practice is much less clear
[20:56] <Laney> then you have to never let the private key touch the machine
[20:57] <apw> right and that part is what makes the dkms side difficult
[20:58] <Laney> quite an interesting problem
[20:58] <Laney> would be keen to see the spec cyphermox is working to if there is one
[20:58] <Laney> also I managed to get upgraded to a kernel which refused to load wl.ko
[20:58] <apw> i am unclear of the bigger picture inthe plan
[20:59] <Laney> without knowing that it was going to happen in advance, so I rebooted and had no network
[20:59] <Laney> that was a bit sad
[20:59] <apw> yes, out of tree drivers are not first class citizens in a lot of ways,secure boot is one of them
[20:59] <apw> thoughyou should have been told to turn off secure boot because dkms was installed
[21:00] <apw> but perhaps that is only done as we transition from no dkms -> dkms installed
[21:00] <apw> hmmm
[21:00] <Laney> perhaps update-manger or the release upgrader would have done that
[21:01] <apw> the dkms asking you to disable secureboot via mok happens as part of dkms installing even at the command line
[21:01] <apw> but perhaps not on upgrades or something
[21:02] <Laney> I can't rule out that I missed or ignored it either
[21:02]  * Laney checks dkms
[21:02] <rtg> Laney, I've gotten a couple of reports of basically the same thing happening
[21:08] <Laney> rtg: Hmm
[21:08] <Laney> It's confusing now because cyphermox moved to a new script in yakkety
[21:08] <Laney> and I didn't have a new enough shim-signed to have the "update-secureboot-policy" thing installed
[21:08] <Laney> so I wouldn't have been prompted to disable it
[21:09] <Laney> *however* I should have seen the old debconf questions
[21:09] <rtg> Laney, I think upgrading Wily to Xenial definitely has issues
[21:09] <Laney> which have now been unregistered by the new dkms
[21:09] <Laney> so probably out of luck to find out what happened to me
[21:09] <apw> Laney, man its a minefiled
[21:09] <Laney> warrants some testing for sure
[21:09] <Laney> get that davmor2 on it
[21:10] <Laney> apw: Be glad you're not on the front line of this one :)
[21:13] <cyphermox> Laney: what's the issue?
[21:14]  * cyphermox reads backlog
[21:14] <Laney> hey cyphermox 
[21:14] <Laney> I may not have been asked to disable SB but can't prove it any more
[21:15] <Laney> and also was wondering if there's a story about signing for dkms
[21:16] <cyphermox> Laney: you're not the first to mention it; I remember Steve pinged me a few weeks ago about not being prompted on upgrade, but being prompted afterwards when it probably should not, but that was also unreproducible
[21:17] <cyphermox> Laney: tbh I don't know how to sign the modules, do we have a userland too to do that?
[21:17] <Laney> There's some script shipped by the kernel
[21:17] <cyphermox> well, I suppose we do, the question is more, do we ship it and is it usable by the common mortal
[21:17] <cyphermox> right
[21:17] <Laney> sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der /lib/modules/4.4.0-23-generic/updates/dkms/wl.ko
[21:17] <rtg> apw has update sbsign to include the module signing tool
[21:18] <apw> sbsigntool includes kmodsign in the versions in -proposed
[21:18] <cyphermox> I haven't really looked into that yet -- the story to start with was to either have free things and all signed with our kernel package, or have third-party drivers and disable shim validation
[21:18] <cyphermox> ah, great
[21:19] <cyphermox> Laney: the SB disabling should only prompt if it can see that you're booting with secure boot enabled and that it's not already disabled
[21:19] <Laney> yeah I am in that situation
[21:20] <Laney> right chaps
[21:20] <Laney> thanks for educating me a bit while I was cooking me dinner
[21:20] <Laney> it is now ready - ttyl :)
[21:20] <cyphermox> Laney: ping me later and we can chat more about it
[21:20] <Laney> sure
[21:20] <Laney> see you!