© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
Here is the IRC transcript that prompted this bug:
<superm1> hi can an AA remove and block these from syncing https:/
<slangasek> superm1: hi! I had noticed things going on there and wanted to ask why both fwupd and fwupdate are now producing artifacts for EFI signing
<slangasek> maybe that's all resolved now and we only need to handle the -signed packages now
<superm1> slangasek, i sent some mail to sil2100 to explain it all
<superm1> but i guess that didn't float around to everyone that needs to know
<slangasek> yes, emailing an individual has that effect :)
<superm1> heh. so basically starting with fwupd 1.1.0 the library and EFI binaries were subsumed into the fwupd project
<superm1> they are installed dynamically at runtime now
<superm1> lots of various reasons for this, but the general expectation is that due to this change less bugs, better control on the process, easier to support problems
<superm1> the fwupdate project still exists and can be treated as a simple reference implementation of EFI firmware updates if you don't care about all the other stuff
<superm1> in my mind fwupdate and fwupdate-signed should move to universe in cosmic
<slangasek> superm1: http://
<superm1> see above two comments
<slangasek> so
<superm1> I unseeded fwupdate for this purpose on the next meta upload: https:/
<slangasek> we shouldn't be signing two streams of EFI binaries
<slangasek> we shouldn't be signing something that's just a "reference implementation"
<cyphermox> moo?
<superm1> Moo
<slangasek> and it's regrettable if sil2100 accepted these for signing on the basis of your conversation
<slangasek> we should instead drop the signing request bits from the package
<superm1> Debian is still going to sign both of them
<slangasek> I'm not responsible for Debian's EFI keys :)
<superm1> and let folks decide if they want to use one or the other
<cyphermox> oh my
<superm1> Sledge told me that infinity and cjwatson had interest in Debian's EFI signing system as well and are going to look into it. If Ubuntu adopts something akin to it it will be more difficult to drop the signed bits only from Ubuntu for fwupdate
<slangasek> sorry, if Ubuntu adopts something akin to what?
<superm1> the signing process for EFI binaries
<slangasek> ok
<superm1> right now what happens in Debian is that template packages are created and go itno the archive as binary packages
<slangasek> so, regardless, my expectation is that the set of objects signed with the EFI key will be gated on archive admin signoff
<superm1> a signing service runs and installs these template packages and produces new source packages "with the signed" binary
<superm1> and those source packages are uploaded to the archive
<superm1> so yes I would expect the gate to be on accepting "those" source packages
<superm1> slangasek, the other thing i'm worried about with demoting fwupdate to universe and dropping fwupdate-signed is I have no idea what that does to ubuntu core guys
<superm1> if they still use it for generating images or what
<superm1> it's in the "system-image" seed and I suspect they have an expectation that they get the EFI binary installed as part of "core" and not at runtime
<superm1> cjwatson, OK thanks, I sorta expected that
<cjwatson> There are pros and cons; it may be worth it for the sake of being in sync, and I can see the advantages
<cjwatson> Particularly reducing the number of round-trips for updates
<cjwatson> But it doesn't make it an easy change to implement :)
<superm1> yeah from a package maintainer perspective it's nice to not have to update a separate signed -source package
<cjwatson> And it's hard to justify spending time on it when it just streamlines things a bit rather than enabling new functionality
<superm1> I think Debian is still working out kinks with their system anyway, it doesn't run automatically just yet
<cjwatson> Indeed
<cjwatson> In a Launchpad context it would involve dispatching subsidiary builds, I think
<cjwatson> Which is ... complex
<superm1> I see
<cjwatson> I kind of know what sort of general shape I'd like it to be but haven't worked out the data model
<cjwatson> What we definitely *can't* do is construct debs somewhere other than on builders
<superm1> I think even in their model the debs would be constructed on builders
<cjwatson> Yeah, I haven't seen how the dispatch works there ...
<superm1> their model generates source packages that get uploaded
<cjwatson> Right, what I haven't worked out is how those get injected
<cjwatson> And whether there's any DB link between those and the unsigned versions
<cjwatson> I'd kind of rather construct the source packages on builders too
<cjwatson> Like recipes
<cjwatson> That means we get to use tools appropriate to the target series to build the source package, rather than having to either do it by hand or have interesting dependencies on the Ubuntu release that Launchpad happens to run on
<cjwatson> (ICBW but I suspect that Debian is taking something equivalent to the latter approach)
<cjwatson> Recipes have some pretty weird DB modelling though
<cjwatson> Anyway, that's as far as I've got
<superm1> building the source package outside of a builder is actually quite challenging from the debian side today
<superm1> if it fails to build you have no idea why
<superm1> so if you deviated from the "template" used by another signed package a little bit or have a minor typographical error you can't really debug
<superm1> so back on the initial question around fwupdate/
<cjwatson> https:/
<cjwatson> which I guess isn't awful since dpkg-dev is pretty stable, but I'd hope not to have to install it on LP systems
<cjwatson> we'd need an isolated signing service in the same way
<superm1> the other dimension I didn't mention is that there may be a need for backporting either fwupdate 12 or fwupd 1.1.1 back to bionic due to https:/
<ubot5> Ubuntu bug 1785165 in fwupdate-signed (Ubuntu) "firmware update on fwupdate version 10-3 not work on some AMI's firmwares" [Undecided,New]
<slangasek> superm1: I would have to check what's done with fwupdate in Ubuntu Core, but snaps are not necessarily built from the devel series and core snaps in particular are only built from LTSes. So any change that's appropriate to make here in terms of preferred EFI implementation for Ubuntu classic should also be tracked by Ubuntu Core in the next major series, and would not affect builds of the
<slangasek> current series.
<superm1> I guess this is now a bigger problem then for them that snaps probably can't put binaries into the ESP directly
<superm1> and they'll have to sort that in snapd by the next LTS?
<slangasek> quite possibly
<slangasek> do the two executables (fwupx64.efi, fwupdx64.efi) provide the same interface? Do they get installed to the same well known location on the ESP?
<superm1> they purposefully use a different EFI NVRAM variable to communicate information
<superm1> and both get installed into respective binary names (fwupx64.efi or fwupdx64.efi)
<superm1> to allow both implementations to be installed side by side
<slangasek> well, that does make a transition more complicated
<superm1> depends on which lens you look at it from. it allows the contents of the NVRAM interface variable to change in incompatible ways in the futur