Hi Michael,
On Mon, 14 Dec 2015 21:59:27 -0600
Michael Shuler <mich...@pbandjelly.org> wrote:
> Thanks for your thoughts. A separate package is an interesting interim
> idea, but in looking at what redhat has done, I think a more complete
> transition to trust type buckets is preferred, along with including a
> code-signing cert bucket. I think it's the extra package and updating
> deps for a short-term solution that I'm not fond of. That would need
> another update of deps and proper solution in the long term.
Thanks for considering my suggestions. While I agree that using
separate trust buckets is the best solution, I'm concerned that the
time it takes to triage and patch other packages will unnecessarily
prolong the risk to users who don't even use S/MIME. So I suggest
making the short-term solution a stepping stone for the long-term
solution, so that work doesn't have to be undone later.
Specifically, I propose changing the ca-certificates source package to
generate three binary packages:
1. ca-certificates-server
2. ca-certificates-email
3. ca-certificates - a metapackage that depends on
ca-certificates-server, and (at most) suggests ca-certificates-email
For now, ca-certificates-server and ca-certificates-email will install
roots to the same location. Once separate root stores are supported,
it will be a simple change to these packages to install to separate
locations instead.
Other packages could continue to depend on just ca-certificates because
it will pull in ca-certificates-server automatically. Over time,
packages could be modified to have a more fine-grained dependency on
ca-certificates-server and/or ca-certificates-email, but there's no
urgency to this and there would be no need to switch dependencies back
later. In fact, until separate stores are supported, *no* package
should depend on ca-certificates-email, not even MUAs that support
S/MIME. Just because a MUA supports S/MIME doesn't mean that users use
it. The majority of users of such MUAs only need root certificates for
secure SMTP/IMAP/POP, not S/MIME, and they should be able to avoid the
email-only roots until they're properly segregated.
As for the code signing trust store, note that Mozilla is
discontinuing their code signing root program[1], so Debian would need
to either operate its own root program or find another root program to
use for code signing. Do you know if there is any demand for
code-signing roots in Debian?
I should also mention that Mozilla's email trust store is on life
support, and is at risk of being discontinued if no one steps up to help
maintain it[2]. Splitting it into a separate package in Debian could
be a good way to get the word out to people who rely on it that they
should consider contributing upstream to prevent its discontinuation.
Regards,
Andrew
[1]
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02409.html
[2]
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02413.html
