Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
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.
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
On Tue, Feb 19, 2019 at 12:07:19PM +0100, Andrej Shadura wrote: > On Tue, 19 Feb 2019 at 12:03, Linda Lapinlampi wrote: > > 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.
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
On Tue, 19 Feb 2019 at 12:03, Linda Lapinlampi wrote: > > 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. -- Cheers, Andrej
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
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. :) matrix-archive-keyring_2015.12.09+debian0.15.tar.xz Description: application/xz
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
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. matrix-archive-keyring_2015.12.09+debian0.10.tar.xz Description: application/xz
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
Quoting Linda Lapinlampi (2019-02-13 16:41:06) > On Tue, Feb 12, 2019 at 09:40:30PM +0100, Jonas Smedegaard wrote: > > Quoting Jonas Smedegaard (2019-02-12 19:38:57) > > > I believe this package belongs in contrib, as its only use-case is > > > with together with software outside of Debian main. > > > > ...and now posting to the actual bugreport as well. > > I'm not opposed to having this matrix-archive-keyring package in the > 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). Thanks for comparing with similar packages: That indicates you go that 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. > 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. Cool! > (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? 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 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
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.
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). agreed. > ubuntu-keyring does that; most other keyrings sadly do not follow this. file bugs? -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
On Wed, 2019-02-13 at 15:41 +, Linda Lapinlampi wrote: > 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. 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
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
On Tue, Feb 12, 2019 at 09:40:30PM +0100, Jonas Smedegaard wrote: > Quoting Jonas Smedegaard (2019-02-12 19:38:57) > > I believe this package belongs in contrib, as its only use-case is with > > together with software outside of Debian main. > > ...and now posting to the actual bugreport as well. I'm not opposed to having this matrix-archive-keyring package in the 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?
Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
Quoting Jonas Smedegaard (2019-02-12 19:38:57) > [ adding d-devel@ to the discussion ] > > Quoting Linda Lapinlampi (2019-02-12 18:51:39) > > 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). > > I believe this package belongs in contrib, as its only use-case is with > together with software outside of Debian main. ...and now posting to the actual bugreport as well. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
