* Package name    : matrix-archive-keyring
  Version         : 2015.12.09
  Upstream Author : The Matrix.org Foundation CIC <packages@matrix.org>
* URL             : https://matrix.org/packages/debian/repo-key.asc
* License         : GPLv3+ (key: public domain)
  Programming Lang: Make, sh
  Description     : OpenPGP archive key for the Matrix.org package repository

The Matrix.org Debian package repository distributes digitally signed
releases of Matrix.org related packages. This package contains the
archive key used to verify those files, required by apt(8).

matrix-archive-keyring will also attempt to harden the apt-secure(8)
infrastructure by removing known previously installed (untrusted)
Matrix.org archive key(s) from apt(8)'s global trust database, which
have often been erroneously added via apt-key(8).
----

Hi, so there's few packages in Debian already such as matrix-synapse.
[1] And then there's Debian packages from third-party Matrix.org and
Riot.im package repositories at upstream.

The issue: Signing keys added to /etc/apt/trusted.gpg{,.d} will be
trusted by apt(8) for every repository, including Debian's main package
repository.

I'm currently seeing a "trend" on the Internet where tutorials and
guides suggest to use "apt-key add" to install Matrix.org's package
repository archive key recklessly without any regard to apt-secure(8).
More so, Matrix.org links to one of these guides itself. [2] Riot.im
(related to the same people running Matrix.org) also suggests "apt-key
add". [3] Synapse 0.99.0's `INSTALL.md` guide suggests to download a key
and add it via apt-key(8) too, [4] while this package is also available
from Debian.

The solution: A keyring package, as suggested by apt-secure(8).

If the sysadmin wants to install from Matrix.org or Riot.im package
repositories (instead of Debian's), fine. Who am I to argue? At least I
I can make their life more convenient while hardening APT's security for
everyone, while Debian doesn't have packages available for every
upstream package yet.

I have made this package install an OpenPGP-armored keyring to
/usr/share/keyrings (instead of /etc/apt/trusted.gpg.d); I'm also using
a db_install(8) postinst script to ensure that the keys in question
don't show up in two keyrings at once.

I will be also looking to configure debconf(1) to ask if the user also
wants to install the appropriate sources.list(5) file for the Matrix.org
and/or Riot.im repository with signed-by option.

Packages similar to this one exist in Debian: ubuntu-keyring,
leap-archive-keyring, pkg-mozilla-archive-keyring, etc.

I will be looking for a sponsor. I know someone from the Matrix
Packaging Team at Debian whom I'll be asking to kindly sponsor this
package. If they refuse, I know where to ask.

Thanks for your attention.

[1]: https://wiki.debian.org/Matrix
[2]: https://matrix.org/docs/guides/installing-synapse
[3]: https://riot.im/desktop.html
[4]: https://github.com/matrix-org/synapse/blob/release-v0.99.0/INSTALL.md

Quoting Jonas Smedegaard (2019-02-12 19:38:57)

...and now posting to the actual bugreport as well.

 - Jonas

contrib area, although for comparison I should note leap-archive-keyring
has no rdepends, the keyring package is available from Debian's main
archive area and is valid for verifying package signatures from leap.se.
An example of a package from deb.leap.se is bitmask-core (which is not
available in Debian), and it's not in the contrib area in the leap.se
repository.

Maybe this is an error/bug in the leap-archive-keyring package, but it
does seem confusing. The other *-archive-keyring packages in Debian main
seem to be at least vaguely related to the Debian Project or its teams,
although they are all (with the exception of debian-archive-keyring)
meant to be used with third-party data sources (usually with APT).

As of yesterday, there is also this high-priority debconf(1) question
template in the matrix-archive-keyring package:

Template: matrix-archive-keyring/sources.list
Type: boolean
Default: false
_Description: Use APT data sources from Matrix.org?
 The Matrix.org Debian package repository distributes supplemental Matrix.org
 related packages intended to work with the Debian distribution, but require
 software software outside of the distribution to either build or function.
 These packages are digitally signed with keys from matrix-archive-keyring.
 .
 The Debian Project will be unable to directly support issues faced from using
 supplemental packages from this third-party repository. Packages from these
 APT sources may be non-conforming to the technical requirements set in the
 Debian Policy for the Debian distribution.

(Sorry if I fell under the assumption the package will be usable on
Debian only, and not derivative distributions with different names.)

Choosing "yes" here would obviously enable the contrib bits from the
default of "false". And as I said, packages from Matrix.org are already
in the contrib area (Section: contrib/*).

If this debconf(1) question makes it a hard-requirement of contrib
archive area, I could split the main parts (keyring) and the debconf(1)
question (sources.list) to seperate packages in main and contrib
sections respectively if that is more desirable.

I have currently set the package's "Section:" to "contrib/misc", in any
case.

What do you think?

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).

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

Ansgar

agreed.

file bugs?

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

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):

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.

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

Quoting Linda Lapinlampi (2019-02-13 16:41:06)
extra mile in striving towards perfection in your packaging - Cool!

Please file bugreports for such other packages that you notice - should
be fine filing such bugs with high severity, since it is a violation of
a "must" in Debian Policy § 2.2.1.

Cool!

The addition of a debconf question - with default being false - seems an
excellent improvement over the package silently activating the keys (if
that was the previous behaviour - I am only guessing here).

I find the keys themselves to be the reason for the package belonging in
contrib, however - regardless of adding that nice debconf message.

Thanks a lot for your contribution to Debian!


 - Jonas

A small update on this ITP:

The attached source is the current state of this package, UNRELEASED.
It's not fit for the Debian distribution just yet; but I'll allow eager
early testers to find the source from here.

+debian1 version should follow soon for sid, to be sponsored. I'll
polish it a little further and go through the Debian Policy once more to
check for any remaining issues before this.

An update:

While I don't have a salsa.d.o account yet for hosting the source,
attached is the current state of this package UNRELEASED. Technically,
this might be ready for the experimental distribution tree right now?
I'd have to check, to make sure.

I've split the source package "matrix-archive-keyring" into two binary
packages: "matrix-archive-keyring" and "matrix-archive-config".

I'm excited to close this ITP bug with a +debian1 release in sid /
experimental soon. :)

I’ll have a look soon.

No big changes expected anymore, but I'm preparing 2015.12.09+ds.1 for
experimental or sid today. I'll probably upload to mentors.debian.net
then.

+debian was a misnomer, I forgot it should've been +ds.

I believe this package is ready for Debian now. I'm looking for a
sponsor now; more details in a RFS issue to follow.

Thanks to the few people in the #debian-matrix:matrix.org room for
testing experimental pre-releases.