| === adrian is now known as alvesadrian | ||
| apw | jdstrand, 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 it | 17:13 |
|---|---|---|
| jdstrand | apw: I think I was on 104 which I thought was a different abi number | 17:13 |
| * jdstrand checks | 17:14 | |
| apw | 104 is a different abi from any of the double uploads we have done since indeed | 17:14 |
| apw | 105 and 106 are the same abi and 107 and 108 are the same | 17:15 |
| jdstrand | so, 106 would've replaced 105 | 17:15 |
| jdstrand | but 104 would've stuck around | 17:15 |
| jdstrand | let me take a closer look | 17:15 |
| apw | yeah 106 would drop over the very same files, yet another good reason we should bump abi always | 17:16 |
| apw | though we do for everything but teeny emergency fixes, such as we have dropped out in those two pairs | 17:16 |
| jdstrand | oh | 17:16 |
| jdstrand | oh, I see on 9/30 I installed linux-image-3.13.0-65-generic | 17:16 |
| jdstrand | and then on 10/8 I installed... linux-image-3.13.0-65-generic | 17:17 |
| jdstrand | so yes, this seems likely | 17:17 |
| apw | ok then yes, that was the emergency cve update, so that would drop replacement .ko's on you which have different signature keys | 17:17 |
| TJ- | jdstrand: that matches the ~8 days uptime timestamp I noticed | 17:17 |
| jdstrand | I thought I must've been running 104 cause it was installed, but I forgot the same abi would not be there | 17:17 |
| === lborda is now known as lborda-sprint | ||
| jdstrand | ah, this is good. mystery solved :) | 17:18 |
| apw | yeah, it is smeothing we need to consider when doing these emergency things, particularly if that ever becomes an enforced thing | 17:18 |
| jdstrand | yeah, indeed | 17:18 |
| jdstrand | and it will need to be an enforced thing in the not so distant future | 17:19 |
| infinity | apw: 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 |
| infinity | apw: The only other option is a central signing key instead of a throwaway, but that's dangerously fiddly to get right. | 20:56 |
| infinity | apw: (Still worth discussing as an option, though) | 20:56 |
| infinity | apw: 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 |
| apw | infinity, yeah, we need to put it on the agenda for our next meetup | 21:06 |
| infinity | apw: Good thing we have two of those coming up. | 21:06 |
| infinity | apw: Maybe we should invite Peter Jones to Austin. :P | 21:07 |
| infinity | apw: 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 |
| apw | infinity, heh | 21:09 |
| infinity | slangasek: 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 |
| infinity | apw: 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 |
| infinity | apw: 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 |
| infinity | slangasek: 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 |
| apw | infinity, not had a chance to look at .stub yet, but it is very likely | 21:25 |
| infinity | apw: http://paste.ubuntu.com/12728158/ | 21:33 |
| infinity | apw: 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.stub | 21:33 |
| slangasek | infinity: 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 |
| slangasek | s/binary/third-party/ | 21:34 |
| infinity | slangasek: I expect a combination of both behaviours, to be fair. ;) | 21:34 |
| slangasek | I 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 side | 21:35 |
| infinity | slangasek: 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 |
| apw | i thought the point was you could register your own keys, and use those to load dkms modules | 21:53 |
| apw | and its all about the how to make that easy | 21:53 |
| slangasek | apw: as long as those keys are being registered via the firmware, then the trust model is intact and it's ok | 21:59 |
| slangasek | and we do have a way to register those keys via the firmware (MOKmanager) | 21:59 |
| infinity | apw: 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 |
| infinity | And 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!