Bug#941766: RFP: sblg -- static blog utility
Package: wnpp Severity: wishlist * Package name: sblg Version : 0.5.7 Upstream Author : Kristaps Dzonsons * URL : https://kristaps.bsd.lv/sblg/ * License : ISC Programming Lang: C Description : static blog utility It's dead simple. > sblg is a utility for creating static blogs. It knits together > articles with templates to generate static HTML files, Atom feeds, and > JSON files. It's built for use with make(1). No PHP, no database: just > a simple UNIX tool for pulling data from articles and populating > templates. The ever so popular `jekyll` and `hugo` packages (available in Debian) are big, considerably even over-engineered static HTML site generators. They use Markdown for generating documents, instead of HTML that sblg uses. For an argument against Markdown, see: https://undeadly.org/cgi?action=article&sid=20170304230520 Additionally, due to Markdown's syntax limitations, static generated blogs with `jekyll` or `hugo` might not be able to use HTML description lists and embed images, or they do with some Markdown extensions or by embedding HTML into the Markdown source. sblg has been actively maintained since 2014: https://kristaps.bsd.lv/sblg/archive.html The lowdown utility from the same upstream author is not required for sblg, but may compliment it to add Markdown translation support. The upstream's BSD.lv projects include other notable projects (for BSD), such as acme-client, openrsync and mandoc.
Bug#910999: RFP: mxisd -- Federated Matrix Identity Server
On Sun, Oct 14, 2018 at 03:54:16PM +, Johannes Keyser wrote: > * Package name: mxisd > Version : 1.2.0 > Upstream Author : Max Dor > * URL : https://github.com/kamax-matrix/mxisd > * License : AGPL-3.0 > Programming Lang: Java > Description : Federated Matrix Identity Server As of mxisd 1.3.1, mxisd depends on undertow (libundertow-java) instead of Spring Boot. undertow is not going to be included in Buster release: https://bugs.debian.org/903916 I also looked at the potential dependencies required. > mxisd dependencies missing from Debian GNU/Linux: > > * matrix-java-sdk > * ormlite-jdbc > * eddsa > * libphonenumber-java (`8.7.1`) – there is `7.1.0` available, and a > newer Python package for `8.9.10` > * firebase-admin > * sqlite-jdbc (?) > * twilio (Java) > * sendgrid > * zt-exec > > Testing stuff missing: > > * wiremock > * unboundid > * greenmail > > Other stuff: > > * `libc3p0-java` exists, but an older verison: `0.9.1.2`. mxisd >depends on version `0.9.5.2` it seems. > * `libmariadb-java` is quite much (?) newer in Debian than what mxisd >depends on. > * libundertow-java is `1.4.25` in Debian, mxisd depends on >`2.0.16.Final` I've also understood from a conversation with the upstream author he's not very interested to spend a lot of time on mxisd after the upcoming 1.4.0 release, but focus on gridepo stuff instead. Rewriting mxisd from undertow to some other HTTP library (e.g. Jetty) is unlikely at this time. Attached is the output of gradle dependencies from mxisd 1.3.1 (current stable version). :dependencies Root project apiElements - API elements for main. (n) No dependencies archives - Configuration for archive artifacts. No dependencies compile - Dependencies for source set 'main' (deprecated, use 'implementation ' instead). +--- org.slf4j:slf4j-simple:1.7.25 |\--- org.slf4j:slf4j-api:1.7.25 +--- commons-io:commons-io:2.5 +--- org.yaml:snakeyaml:1.23 +--- io.kamax:matrix-java-sdk:0.0.14-8-g0e57ec6 |+--- org.slf4j:log4j-over-slf4j:1.7.25 ||\--- org.slf4j:slf4j-api:1.7.25 |+--- org.apache.commons:commons-lang3:3.7 |+--- commons-io:commons-io:2.5 |+--- commons-codec:commons-codec:1.11 |+--- com.squareup.okhttp3:okhttp:3.11.0 ||\--- com.squareup.okio:okio:1.14.0 |+--- com.google.code.gson:gson:2.8.0 |\--- net.i2p.crypto:eddsa:0.1.0 +--- com.j256.ormlite:ormlite-jdbc:5.0 |\--- com.j256.ormlite:ormlite-core:5.0 +--- net.i2p.crypto:eddsa:0.1.0 +--- org.apache.directory.api:api-all:1.0.0 |+--- org.slf4j:slf4j-api:1.7.25 |+--- org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:1.1.4c_7 |+--- org.apache.servicemix.bundles:org.apache.servicemix.bundles.dom4j:1.6.1_5 ||\--- xml-apis:xml-apis:1.0.b2 |+--- xml-apis:xml-apis:1.0.b2 |+--- commons-pool:commons-pool:1.6 |+--- org.apache.mina:mina-core:2.0.16 ||\--- org.slf4j:slf4j-api:1.7.21 -> 1.7.25 |+--- commons-lang:commons-lang:2.6 |+--- commons-collections:commons-collections:3.2.2 |+--- org.apache.servicemix.bundles:org.apache.servicemix.bundles.antlr:2.7.7_5 |\--- commons-codec:commons-codec:1.10 -> 1.11 +--- dnsjava:dnsjava:2.1.8 +--- org.apache.httpcomponents:httpclient:4.5.3 |+--- org.apache.httpcomponents:httpcore:4.4.6 |+--- commons-logging:commons-logging:1.2 |\--- commons-codec:commons-codec:1.9 -> 1.11 +--- com.googlecode.libphonenumber:libphonenumber:8.7.1 +--- javax.mail:javax.mail-api:1.6.2 +--- com.sun.mail:javax.mail:1.6.2 |\--- javax.activation:activation:1.1 +--- com.google.firebase:firebase-admin:5.3.0 |+--- com.google.api-client:google-api-client:1.22.0 ||+--- com.google.oauth-client:google-oauth-client:1.22.0 |||+--- com.google.http-client:google-http-client:1.22.0 ||||+--- com.google.code.findbugs:jsr305:1.3.9 -> 3.0.0 ||||\--- org.apache.httpcomponents:httpclient:4.0.1 -> 4.5.3 (*) |||\--- com.google.code.findbugs:jsr305:1.3.9 -> 3.0.0 ||+--- com.google.http-client:google-http-client-jackson2:1.22.0 |||+--- com.google.http-client:google-http-client:1.22.0 (*) |||\--- com.fasterxml.jackson.core:jackson-core:2.1.3 -> 2.8.7 ||\--- com.google.guava:guava-jdk5:17.0 |+--- com.google.api-client:google-api-client-gson:1.22.0 ||+--- com.google.api-client:google-api-client:1.22.0 (*) ||\--- com.google.http-client:google-http-client-gson:1.22.0 || +--- com.google.http-client:google-http-client:1.22.0 (*) || \--- com.google.code.gson:gson:2.1 -> 2.8.0 |+--- com.google.http-client:google-http-client:1.22.0 (*) |+--- org.json:json:20160810 |+--- com.google.guava:guava:20.0 |+--- com.google.cloud:google-cloud-storage:1.2.1 ||+--- com.google.cloud
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
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
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 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: ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
Package: wnpp
Severity: wishlist
Owner: Linda Lapinlampi
* Package name: matrix-archive-keyring
Version : 2015.12.09
Upstream Author : The Matrix.org Foundation CIC
* 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
Bug#921676: RFP: webext-decentraleyes -- web extension for local emulation of Content Delivery Networks
Package: wnpp Severity: wishlist * Package name: webext-decentraleyes Version : 2.0.9 Upstream Author : Thomas Rientjes * URL : https://decentraleyes.org/ * AMO : https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/ * VCS : https://git.synz.io/Synzvato/decentraleyes * License : MPL-2.0 (+ MIT, BSD, etc. for bundled resources) Programming Lang: Javascript Description : web extension for local emulation of Content Delivery Networks > Websites have increasingly begun to rely much more on large > third-parties for content delivery. Canceling requests for ads or > trackers is usually without issue, however blocking actual content, not > unexpectedly, breaks pages. The aim of this add-on is to cut-out the > middleman by providing lightning speed delivery of local (bundled) files > to improve online privacy. I've been using this web extension on Firefox for a long while, alongside webext-ublock-origin package from Debian to improve my privacy experience while browsing. Potential packagers, please note: It may be desirable to integrate this web extension with libjs-* packages (/usr/share/javascript/*), where supported.
Bug#921673: RFP: webext-decentraleyes -- web extension for local emulation of Content Delivery Networks
Package: wnpp Severity: wishlist * Package name: webext-decentraleyes Version : 2.0.9 Upstream Author : Thomas Rientjes * URL : https://decentraleyes.org/ * AMO : https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/ * VCS : https://git.synz.io/Synzvato/decentraleyes * License : MPL-2.0 (+ MIT, BSD, etc. for bundled resources) Programming Lang: Javascript Description : web extension for local emulation of Content Delivery Networks > Websites have increasingly begun to rely much more on large > third-parties for content delivery. Canceling requests for ads or > trackers is usually without issue, however blocking actual content, not > unexpectedly, breaks pages. The aim of this add-on is to cut-out the > middleman by providing lightning speed delivery of local (bundled) files > to improve online privacy. I've been using this web extension on Firefox for a long while, alongside webext-ublock-origin package from Debian to improve my privacy experience while browsing. Potential packagers, please note: It may be desirable to integrate this web extension with libjs-* packages (/usr/share/javascript/*), where supported.
