hi, Am Freitag, den 20.01.2017, 09:43 -0500 schrieb George Gross: > Hi, > > at the risk of wading into the weeds, you mentioned below that: > > "...it also has the advantage that the core and kernel snaps are > signed > readonly squashfses and can not just be modified which adds a great > amount of extra security." > > Is there a Wiki or document explaining the signature private key's > life > cycle management? For example, what process happens when the key > expires > or is compromised? Who is the entity that actually *signs* the file > system?
this is probably something the security and store teams can answer better than me. > > If you built a custom kernel and/or device drivers, how would your > binaries interact with this file system signature's verification? Can > you substitute your own software factory/store's signature? you would create a complete own image based on your own developer signature using a signed model assertion. https://docs.ubuntu.com/core/en/guides/build-device/image-building has details on this. > > If you operate your own private CA and sign some file objects within > the > snap, does that CA need to be cross-certified with the trust anchor > CA > that is vouching for the identity applying the core/kernel file > system > signature? again something the store people are better suited to answer, i dont exactly know how the CA store side is set up here :) ciao oli
signature.asc
Description: This is a digitally signed message part
-- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
