[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository



On Wed, Feb 13, 2019 at 05:17:27PM +0100, Ansgar wrote:
> More important is the question if the system should /trust/ the keys.
> 
> IMHO installing a non-Debian keyring should *not* make the keys trusted
> by APT by default (i.e. with the default answer if debconf is used).

I've agreed, it's the problem I'm trying to solve with this
matrix-archive-keyring package. As said in the OP of Bug#922155 (ITP):

> I have made this package install an OpenPGP-armored keyring to
> /usr/share/keyrings (instead of /etc/apt/trusted.gpg.d);

Since they are not in Dir::Etc::trusted or Dir::Etc::trustedparts, the
system won't trust the Matrix archive keys for APT by default (unless
the sysadmin has explicitly configured otherwise). By default,
sources.list(5) entries will need to specifically have

    [signed-by:/usr/share/keyrings/matrix-archive-keyring.gpg]
    
for APT to trust the data sources with this package.

To clarify, trust to keys in the matrix-archive-keyring package is all a
multi-step opt-in:

1. Using the keyring to manually verify packages from Matrix.org (yes)
2. Trusting the keyring for Matrix.org APT sources (default: no)
3. Trusting the keyring for any APT sources (default: hell no)

What the Internet says to do and what's currently happening in practice:

1. Using the repository key to manually verify packages from Matrix.org
2. Trusting the repository key for Matrix.org APT sources (yes, but...)
3. Trusting the repository key for any APT sources (yikes)

There is an additional low priority debconf(1) question in
matrix-archive-keyring if #3 should be true, but with sane default of
"false" and a warning about it being unnecessary in most cases.
Although it's so trivial, I'm open to removing this option altogether if
desired for lacking much real use.

The other debconf(1) question (#2) serves to answer if the user should
trust packages from the third-party repository. If you meant the
description of that question does not adequately ask if the user should
/trust/ packages from that repository (instead of just mentioning they
are supplemental packages which are not officially supported), would you
like me to change the description for the release to point out trust
more prominently? The alternative may be a seperate contrib package for
a sources.list source.

> ubuntu-keyring does that; most other keyrings sadly do not follow this.

I'd suggest to file bugs. I've found many issues in the past few days.


Reply to: