Hi!
The current support for .deb signatures (as implemented by debsigs
and debsig-verify, which dpkg can be configured to call by disabling
the «no-debsig» configuration option), has multiple limitations.
The following are the main redesign objectives, which try to fix
those limitations:
* Make it possible to implement in dpkg-deb (for signing and verification)
so all usual essential package restrictions and considerations apply
(like no or extremely minimal dependency additions, so no XML; or
just run-time optional ones).
* Make it possible to use only SOP/SOPV (remove all introspection of
OpenPGP object that requires GnuPG specific interfaces).
* Make it possible and acceptable for uploads to the Debian archive (even
if this ends up being not allowed, for example due to reproducibility
concerns).
* Make the format extensible to other signature formats or workflows
(such as x509, secure-boot, IMA, etc., even if there's currently no
intention to add support for any of this).
Parts of that redesign imply dropping support for current features and
use cases, where existing users could be impacted, so the main purpose
of this mail is to try to check whether the objectives of the redesign
and its consequences would not negatively affect those current uses (as
in whether current features/misdesigns would disappear which are being
relied on).
We had some discussions during DebConf25 with at least Steve and Ferenc
(both CCed), and tried to go over the redesign items, and whether things
seemed fine to drop. These mean the following broad potential user
impacting consequences:
* Dropping support for the current XML based policy framework and
transitioning to a simple keyring-based one, keyed on the origin
name on the filesystem, which would imply dropping the
optional/required/reject selectors, dropping support for selection
based on user IDs or fingerprints (of even subkeys).
* Whether to drop support for the policy roles, as it is not clear
if that still makes sense. Although given that it would be trivial
to keep, and should be easy to drop in the future, the current
thinking is that this can stay.
* Whether any signing policy makes sense at all, besides verified or
not-verified against a specified keyring. It's not clear how other
people (besides Steve and Ferenc) use the signing support? For
example by signing all of the base distribution and their overlaid
packages, or only signing their overlaid packages and running
debsig-verify outside dpkg, etc.
Currently, one of the main reasons for not having worked on most of
these changes in the past has been the very minimal visibility over
what and how this support is being used around, so it's hard to tell
what can be dropped easily. So it would be very helpful if people that
use debsigs and debsig-verify internally in their organizations, or
privately, etc, would mention how it is being used and whether the
above could break any current usage (feel free to reach out privately
if there are security concerns involved).
I'll be preparing in parallel a PoC, and an updated spec for the initial
proposed changes (these can always be revised/changed/etc).
Thanks,
Guillem
