/srv/irclogs.ubuntu.com/2015/10/09/#ubuntu-kernel.txt

=== adrian is now known as alvesadrian
apwjdstrand, oh ... could you have been running the same ABI number?  as installing over the kernel you are running and then needing to load a module might do it17:13
jdstrandapw: I think I was on 104 which I thought was a different abi number17:13
* jdstrand checks17:14
apw104 is a different abi from any of the double uploads we have done since indeed17:14
apw105 and 106 are the same abi and 107 and 108 are the same17:15
jdstrandso, 106 would've replaced 10517:15
jdstrandbut 104 would've stuck around17:15
jdstrandlet me take a closer look17:15
apwyeah 106 would drop over the very same files, yet another good reason we should bump abi always17:16
apwthough we do for everything but teeny emergency fixes, such as we have dropped out in those two pairs17:16
jdstrandoh17:16
jdstrandoh, I see on 9/30 I installed linux-image-3.13.0-65-generic17:16
jdstrandand then on 10/8 I installed... linux-image-3.13.0-65-generic17:17
jdstrandso yes, this seems likely17:17
apwok then yes, that was the emergency cve update, so that would drop replacement .ko's on you which have different signature keys17:17
TJ-jdstrand: that matches the ~8 days uptime timestamp I noticed17:17
jdstrandI thought I must've been running 104 cause it was installed, but I forgot the same abi would not be there17:17
=== lborda is now known as lborda-sprint
jdstrandah, this is good. mystery solved :)17:18
apwyeah, it is smeothing we need to consider when doing these emergency things, particularly if that ever becomes an enforced thing17:18
jdstrandyeah, indeed17:18
jdstrandand it will need to be an enforced thing in the not so distant future17:19
infinityapw: Yeah, if/when we start enforcing module sigs, I think we have no choice but to always bump ABI, which means we can drop the abi.build versioning entirely, as ABI and build will always be equal.20:56
infinityapw: The only other option is a central signing key instead of a throwaway, but that's dangerously fiddly to get right.20:56
infinityapw: (Still worth discussing as an option, though)20:56
infinityapw: At least with recent packaging changes, one of the complaints about ABI bumps for security fixes (massive unreviewable delta) is somewhat under control.20:59
apwinfinity, yeah, we need to put it on the agenda for our next meetup21:06
infinityapw: Good thing we have two of those coming up.21:06
infinityapw: Maybe we should invite Peter Jones to Austin. :P21:07
infinityapw: Since he was the one that accosted us in the hallway at Plumbers and said "yeah, we want to enforce from shim down, have fun", and the answer to "how will RedHat deal with third party modules" was a shrug.21:07
apwinfinity, heh21:09
infinityslangasek: Not entirely facetiously, if we want to be having discussions about turtles^wsecure boot all the way down, it might not be a terrible idea to invite some non-Canonical/Ubuntu people to the discussion.21:09
infinityapw: Speaking of gross deltas, did you examine the control.stub thing and determine if I was right about that being Yet Another Interim File we shouldn't be shipping in the source package?21:11
infinityapw: Given it contains ABI numbers instead of variables, and isn't debian/control, I can't see how it's anything but cruft, unless it's mistakenly re-read at build time.21:12
infinityslangasek: Such a meeting would, unfortunately, look more like a gathering of "Adam's favourite drinking buddies" (Peter, Matthew, Andy, Leif...), but I can't help it if all my friends are weird.21:17
apwinfinity, not had a chance to look at .stub yet, but it is very likely21:25
infinityapw: http://paste.ubuntu.com/12728158/21:33
infinityapw: You can see what I mean there.  The debian/control delta is unforunate, but expected, but then it's pretty much completely duplicated in control.stub21:33
slangasekinfinity: you think pjones would actually engage constructively to solve our problems instead of just sitting there with drink in hand laughing at us for supporting binary modules?21:34
slangaseks/binary/third-party/21:34
infinityslangasek: I expect a combination of both behaviours, to be fair. ;)21:34
slangasekI think we have a pretty clear idea of what the requirements are, and we just need to work through the implementation details on the Ubuntu side21:35
infinityslangasek: Perhaps.  I'm less enamoured with the likely baby+bathwater approach that will lead to "if you need dkms, you don't get module signing" and would love a workable cross-distro solution to that.21:37
apwi thought the point was you could register your own keys, and use those to load dkms modules21:53
apwand its all about the how to make that easy21:53
slangasekapw: as long as those keys are being registered via the firmware, then the trust model is intact and it's ok21:59
slangasekand we do have a way to register those keys via the firmware (MOKmanager)21:59
infinityapw: Right, it's all conceptually there, but "you can do this thing if you figure it out yourself" isn't exactly an end-user solution either.22:22
infinityAnd there's also the question of large-scale deployments, where one would generally want a build service with the signing key well-protected, rather than the insanely insecure single-machine solution of "your signing key is on the same filesystem as the modules you're trying to protect".22:23

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!