Re: SB: signing service questions
Am 16.04.2018 um 18:24 schrieb Helen Koike:
> Thank you all for participating in the SB sprint.
> I am writing this email to clarify the current status of the signing
> service and to discuss some things that were not clear.
> Current state of the signing service:
> - We successfully tested signing and preparing the source package for
> shim, fwupdate and linux kernel (we didn't tested grub)
If you want to test grub, I put my version in my repo:
> deb [trusted=yes] https://people.debian.org/~pmhahn/packages/secure-boot/ unstable main
> Things I want to discuss/clarify:
> - State table (incomplete/failed/signed/submitted):
> We didn't implemented the way it was written in the etherpad, we
> started discussing this on Sunday but some people had already left.
> * We decided to not remove anything from the table, so we can save the
> error messages and leave the history there.
> QUESTION: should we remove them as we previously discussed (removing
> older versions)? Or letting it grow forever is ok?
I guess space is not that much an issue nowadays, so just let it grow
for now. If ever we fill up the disk, we then can add some garbage
During the initial setup period I for keeping all data, which hopefully
simplifies debugging if things go wrong.
> * Our current table is composed by:
> id = Column(Integer, primary_key=True)
> ts = Column(DateTime, default=datetime.datetime.now)
> template_package_name = Column(String)
> template_package_version = Column(String)
> state = Column(String(64), nullable=False)
> error_msg = Column(String) # empty if state is not "failed"
> suite = Column(String)
> architecture = Column(String)
> * We still don't have a counter to save how many time we failed (this
> is a TODO), the idea is to notify when we failed more the X times.
Just leave all entries in the table and do a "SELECT count(*)" to get
the number of previous failures. I think you need to keep the previous
entries there anyway as the error message can be different for each try:
disk full, HW error, ...
> * We are not (re)signing a package if it has the same
> [template_package_name, template_package_version, architecture, suite],
> and has "failed" or "submitted" state (but we need to change that to
> consider how many times we failed)
> NOTE: we ignore the archive, because the packages submitted to
> security-master are submitted to dak again to ftp-master latter, and we
> don't want to sign the package twice
> QUESTION: shouldn't we drop the suite as well? Or is it possible to
> have different packages in the same suite with the same
> package+version+architecture? When
> a package migrate from unstable to testing does it goes through dak
> again? When a package gets uploaded from security-master to ftp-master
> is the suite always the same?
My understanding is that package+version must be unique and should never
be re-used, as a lot of tools assumes (like apt-ftparchive) assume that
the mapping from file-name to content is unique.
> QUESTION: can't we drop the architecture as well? The architecture is
> already part of the name of the template package no? Well, doesn't hurt
> to leave it there thought
Probably not, as grub2 has this in debian/control:
> 240 Package: grub-efi-ia32-bin
> 241 Architecture: any-i386 any-amd64
> 329 Package: grub-efi-amd64
> 330 Architecture: i386 kopensolaris-i386 any-amd64
My understanding is that you sometimes needs the 32-bit version of grub
on amd64 if you also want to boot other 32-bit EFI apps.
@steve: Please clarify if I'm wrong.
But there questions remains, if we should also support signed version
for foreign architectures.
(I hope I got it correct for the signing template, so if you can
test-sign my test-package mentions above would help to iron out that case).