Bug#1001279: bullseye-pu: package publicsuffix/20211207.1025-0+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: d...@fifthhorseman.net Control: affects -1 src:publicsuffix Please consider an update to publicsuffix in debian bullseye. This package reflects the state of the network, and keeping it current is useful for all the packages that depend on it. The debdiff from the previous version in bullseye is attached. This proposed release is also available at the "publicsuffix_debian/20211207.1025-0+deb11u1" tag on the "debian/bullseye" branch at the git repo for publicsuffix packaging: https://salsa.debian.org/debian/publicsuffix Please followup on this ticket to confirm whether I should upload this revision to bullseye. publicsuffix_20211109.1735-0+deb11u1_20211207.1025-0+deb11u1.debdiff.gz Description: application/gzip
Bug#1001251: debcargo changed names of a feature package
Package: debcargo Version: 2.5.0-2 Control: affects -1 src:rust-buffered-reader debcargo 2.4.4 packaged rust-buffered-reader 1.0.1 with four non-virtual packages: librust-buffered-reader-dev librust-buffered-reader+bzip2-dev librust-buffered-reader+compression-dev librust-buffered-reader+compression-deflate-dev buffered-reader 1.1.1 does not differ in its features at all from 1.0.1, but when i try to package it with debcargo 2.5.0, it produces the following list instead: librust-buffered-reader-dev librust-buffered-reader+bzip2-dev librust-buffered-reader+compression-dev librust-buffered-reader+flate2-dev note that previously, …+compression-deflate-dev Provides: a virtual …+flate2-dev package. Now, …+flate2-dev Provides: a virtual …+compression-deflate-dev package. Note that the [features] section of the upstream Cargo.toml has not changed: [features] compression = ["compression-deflate", "compression-bzip2"] compression-bzip2 = ["bzip2"] compression-deflate = ["flate2"] default = ["compression"] This change does make for a consistency between the way the packages represent the bzip2 and flate2 features, but the fact that the non-virtual package name has changed means we're incurring a needless round trip through NEW, which incurs more friction between the rust and FTP teams. To avoid the friction, i'll probably work around by overriding the generated debian/control, but this is kind of a sledgehammer approach to fix a problem that i think debcargo was meant to solve. If there are any suggestions for how to handle this more gracefully, i'd be interested. --dkg signature.asc Description: PGP signature
Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1
On Wed 2021-12-01 09:43:18 +, Adam D. Barratt wrote: > It looks like you've hit a (fairly) common issue with trying to upload > the same upstream version to multiple suites in a short time. thanks for keeping an eye on this, and giving a quick diagnosis, Adam. > I assume both of your uploads included the .orig.tar.gz and were made > close together. This is exactly right. > At this point your options are either to re-upload the .orig.tar.gz > directly, or dcut and re-upload the complete bullseye upload. i've taken the former approach, uploading directly with sftp. hopefully that'll work :) > In general, either don't include the orig in the later upload, or space > them apart so that you receive the queued confirmation for the first > before uploading the second. (If the orig is already in the archive, as > I assume is the case here, then you don't actually need to include it > in either upload.) Thanks, this is useful guidance for a workaround. I can't help but wonder whether there isn't some way to avoid the need for a workaround in the backend anyway, though. for example, if the orig.tar.gz is missing, look in neighboring suites for one with the matching digest. Where would i look for a bug report on the infrastructure that would cover this? --dkg signature.asc Description: PGP signature
Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1
On Mon 2021-11-29 20:46:25 +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Wed, 2021-11-10 at 16:09 -0500, Daniel Kahn Gillmor wrote: >> Please consider an update to publicsuffix in debian bullseye. >> >> This package reflects the state of the network, and keeping it >> current >> is useful for all the packages that depend on it. >> > > Please go ahead. thanks, uploaded just now. --dkg
Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1
On Mon 2021-11-29 20:46:25 +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Wed, 2021-11-10 at 16:09 -0500, Daniel Kahn Gillmor wrote: >> Please consider an update to publicsuffix in debian bullseye. >> >> This package reflects the state of the network, and keeping it >> current >> is useful for all the packages that depend on it. >> > > Please go ahead. Thanks, uploaded just now. --dkg
Bug#999496: inkscape: Extensions >> Manage Extensions... fails unless python3-appdirs is installed
Package: inkscape Version: 1.1.1-2 Severity: normal X-Debbugs-Cc: d...@fifthhorseman.net I have inkscape open. from the Extensions menu, i choose "Manage Extensions..." i get an error message about "appdirs" being a missing python module. If i "apt install python3-appdirs" and then try again, a dialog box comes up. I note that when doing that it looks like a folder "org.inkscape.inkman" is created in ~/.config/inkscape/extensions which includes a bunch of python code. Does this mean that clicking "Manage Extensions..." is actually fetching code from the internet, installing it, and running it unsandboxed on my behalf? if so, this might also be a DFSG-free issue (i think browsers have run into similar problems, e.g. with the cisco h.265 codecs, though it's not a clean analogy). Let me know if i can help diagnose further! if it's not a DFSG issue, maybe the right way to fix this is to add python3-appdirs to Recommends. --dkg -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages inkscape depends on: ii libatkmm-1.6-1v5 2.28.2-1 ii libboost-filesystem1.74.0 1.74.0-12 ii libc6 2.32-4 ii libcairo2 1.16.0-5 ii libcairomm-1.0-1v5 1.12.2-4 ii libcdr-0.1-1 0.1.6-2 ii libdbus-glib-1-2 0.112-2 ii libdouble-conversion3 3.1.5-7 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.11.0+dfsg-1 ii libgc1 1:8.0.4-3 ii libgcc-s1 11.2.0-10 ii libgdk-pixbuf-2.0-02.42.6+dfsg-2 ii libglib2.0-0 2.70.1-1 ii libglibmm-2.4-1v5 2.66.2-1 ii libgomp1 11.2.0-10 ii libgsl25 2.7+dfsg-2 ii libgspell-1-2 1.9.1-2 ii libgtk-3-0 3.24.30-3 ii libgtkmm-3.0-1v5 3.24.5-1 ii libharfbuzz0b 2.7.4-1 ii libjpeg62-turbo1:2.0.6-4 ii liblcms2-2 2.12~rc1-2 ii libmagick++-6.q16-88:6.9.11.60+dfsg-1.3 ii libpango-1.0-0 1.48.10+ds1-1 ii libpangocairo-1.0-01.48.10+ds1-1 ii libpangoft2-1.0-0 1.48.10+ds1-1 ii libpangomm-1.4-1v5 2.46.1-1 ii libpng16-161.6.37-3 ii libpoppler-glib8 20.09.0-3.1 ii libpoppler102 20.09.0-3.1 ii libpotrace01.16-2 ii libreadline8 8.1-2 ii librevenge-0.0-0 0.0.4-6+b1 ii librsvg2-common2.50.7+dfsg-2 ii libsigc++-2.0-0v5 2.10.4-2 ii libsoup2.4-1 2.74.1-1 ii libstdc++6 11.2.0-10 ii libvisio-0.1-1 0.1.7-1+b1 ii libwpg-0.3-3 0.3.3-1 ii libx11-6 2:1.7.2-2+b1 ii libxml22.9.12+dfsg-5 ii libxslt1.1 1.1.34-4 ii python33.9.7-1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages inkscape recommends: pn aspell pn fig2dev pn imagemagick pn libimage-magick-perl pn libwmf-bin ii python3-lxml 4.6.3+dfsg-1 ii python3-numpy 1:1.19.5-1 pn python3-scour Versions of packages inkscape suggests: pn dia ii inkscape-tutorials1.1.1-2 pn libsvg-perl pn pstoedit pn python3-uniconvertor ii ruby 1:2.7.6 -- no debconf information
Bug#999430: buster-pu: package publicsuffix/20211109.1735-0+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: d...@fifthhorseman.net Control: affects -1 src:publicsuffix Please consider an update to publicsuffix in debian buster. This package reflects the state of the network, and keeping it current is useful for all the packages that depend on it. The debdiff from the previous version in buster is attached. This proposed release is also available at the "publicsuffix_debian/20211109.1735-0+deb10u1" tag on the "debian/buster" branch at the git repo for publicsuffix packaging: https://salsa.debian.org/debian/publicsuffix Please followup on this ticket to confirm whether I should upload this revision to buster. publicsuffix_20190925.1705-0+deb10u1_20211109.1735-0+deb10u1.debdiff.gz Description: application/gzip
Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: d...@fifthhorseman.net Control: affects -1 src:publicsuffix Please consider an update to publicsuffix in debian bullseye. This package reflects the state of the network, and keeping it current is useful for all the packages that depend on it. The debdiff from the previous version in bullseye is attached. This proposed release is also available at the "publicsuffix_debian/20211109.1735-0+deb11u1" tag on the "debian/bullseye" branch at the git repo for publicsuffix packaging: https://salsa.debian.org/debian/publicsuffix Please followup on this ticket to confirm whether I should upload this revision to bullseye. publicsuffix_20210108.1309-1_20211109.1735-0+deb11u1.debdiff.gz Description: application/gzip
Bug#998848: thunderbird: please build against librnp-dev (and Depend: on librnp0) directly
On Mon 2021-11-08 20:11:06 +0100, Carsten Schoenert wrote: > But I think it's a bit more complicated currently, a quick look into the > source shows me that the upstream build system doesn't support the usage > of an external librnp-dev package right now. > This needs to get addressed upstream I think so we can build against the > system library. Thanks, I've opened https://bugzilla.mozilla.org/show_bug.cgi?id=1740320 so that upstream is aware of the issue. --dkg signature.asc Description: PGP signature
Bug#998848: thunderbird: please build against librnp-dev (and Depend: on librnp0) directly
Package: thunderbird Version: 1:78.14.0-1+b2 Control: affects -1 + librnp-dev librnp0 Hi Thunderbird devs-- librnp has made it into debian testing (0.15.2-6 as of right now). I think thunderbird is currently building from an embedded copy of librnp. RNP Upstream has been collaborating nicely by fixing issues i've raised with them that highlight concerns in debian. It would be better if we could avoid the embedded code copy by building thunderbird against the debian librnp-dev package, and depending on librnp0. Thanks for maintaining thunderbird in debian! Regards, --dkg signature.asc Description: PGP signature
Bug#983770: Acknowledgement (rnp: FTBFS on 32-bit platforms (test suite failures))
Version: 0.15.2-4 rnp upstream version 0.15 fixed the timestamp issues that were causing https://bugs.debian.org/983770 on 32-bit architectures. 0.15.2-4 is the latest version of rnp in debian; if the builds are successful, it should not be prohibited from migration to testing. --dkg signature.asc Description: PGP signature
Bug#993835: rnp FTBFS: rnp_tests.test_key_add_userid (Failed)
Version: 0.15.2-1 The RNP test suite no longer fails on test_key_add_userid as of version 0.15.2-1. There are new failures on armel and armhf with test_sym_encryption__rnp_aead, sigh, but i'll try to diagnose those in a separate bug report. --dkg On Tue 2021-09-07 05:52:14 +0300, Adrian Bunk wrote: > Source: rnp > Version: 0.14.0-6 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/package.php?p=rnp&suite=sid > > ... > test 135 > Start 135: rnp_tests.test_key_add_userid > > 135: Test command: /<>/build/src/tests/rnp_tests > "--gtest_filter=rnp_tests.test_key_add_userid" > "--gtest_also_run_disabled_tests" > 135: Environment variables: > 135: RNP_TEST_DATA=/<>/src/tests/data > 135: Test timeout computed to be: 3000 > 135: Note: Google Test filter = rnp_tests.test_key_add_userid > 135: [==] Running 1 test from 1 test suite. > 135: [--] Global test environment set-up. > 135: [--] 1 test from rnp_tests > 135: [ RUN ] rnp_tests.test_key_add_userid > 135: unknown file: Failure > 135: C++ exception with description "rnp_exception" thrown in the test body. > 135: [ FAILED ] rnp_tests.test_key_add_userid (31 ms) > ... > > 99% tests passed, 1 tests failed out of 213 > > Total Test time (real) = 650.07 sec > > The following tests FAILED: > 135 - rnp_tests.test_key_add_userid (Failed) > Errors while running CTest > make[1]: *** [Makefile:129: test] Error 8 signature.asc Description: PGP signature
Bug#998076: darkslide: contains embedded fonts with licenses that aren't accounted for
Package: darkslide Version: 6.0.0-2 darkslide contains: /usr/share/doc/darkslide/examples/_assets/SourceSansPro.woff2 this appears to be the SourceSansPro font, which is otherwise only referenced (and also distributed?) in debian in texlive-fonts-extra package. (i can't figure out what licensing is appropriate for SourceSansPro from a quick scan of /usr/share/doc/texlive-fonts-extra/copyright) and the following files appear to embed base64-encoded versions fonts in the Alegreya Sans family in the following files: /usr/lib/python3/dist-packages/darkslide/themes/abyss/css/theme.css /usr/lib/python3/dist-packages/darkslide/themes/default/css/theme.css /usr/lib/python3/dist-packages/darkslide/themes/white/css/theme.css /usr/lib/python3/dist-packages/darkslide/themes/void/css/theme.css Alegreya Sans is in the fonts-alegreya-sans package, but /usr/share/doc/fonts-alegreya-sans/copyright claims it is licensed under OFL-1.1, while /usr/share/doc/darkslide/copyright makes no mention of OFL-1.1 i also note that these embedded fonts end up taking up more than 75% of the darkslide package (on the order of 400KiB each, i think). Not sure what the right resolution here is. it'd be nice to reduce the weight of the package by stripping them, which would also significantly reduce the size of any slideshow generated using darkslide --embed (though it might not render the same on a machine that doesn't have the associated fonts available). Thanks for maintaining darkslide in debian! --dkg signature.asc Description: PGP signature
Bug#997967: weasyprint: new upstream version 53.3 available
Package: src:weasyprint Version: 51-2 Severity: wishlist Control: block -1 by 997910 Weasyprint upstream version 53.3 was released 2021-09-10. Since 53.0, it depends on the pydyf python module instead of cairo (see #997910) It'd be great to get latest version of weasyprint in debian unstable. Regards, --dkg signature.asc Description: PGP signature
Bug#997910: RFP: pydyf -- A low-level PDF generator library (python)
Package: wnpp Severity: wishlist * Package name: pydyf Version : 0.1.1 Upstream Author : CourtBouillon * URL : https://www.courtbouillon.org/pydyf * License : BSD 3-clause Programming Lang: Python Description : A low-level PDF generator library (python) pydyf is a low-level PDF generator written in Python and based on PDF specification 1.7. This is useful to have in debian because the latest revision of weasyprint (53) depends on pydyf instead of cairo.
Bug#997896: darkslide: new upstream version 6.0.0 is available
Package: src:python-darkslide Version: 5.1.0-1 darkslide upstream released 6.0.0 last year. It would be great to have it updated in Debian. Thanks for maintaining darkslide in debian! --dkg signature.asc Description: PGP signature
Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks
Control: affects 968525 + libgpg-error-dev On Thu 2021-08-19 20:52:16 -0400, Daniel Kahn Gillmor wrote: > Control: affects 968525 - libgpg-error-dev > Control: retitle 968525 lintian: breakout-link reported for > /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks > > On Thu 2021-08-19 19:20:16 -0400, Daniel Kahn Gillmor wrote: >> I see the same issue in libgpg-error-dev with lintian 2.104.0. If I try >> to fix it in libgpg-error-dev (i.e. by moving the symlink into lib/ >> instead of usr/lib), > > hm, on further experimentation, i now take it back -- this warning > appeared in libgpg-error-dev because debian/rules in libgpg-error source > was manually adding an additional breakout-link. In particular, i think > for libgpg-error-dev the problem was that there was a link in lib/ that > was pointing to usr/lib/ (the other way around from what Aurelian > reported). > > After removing the override_dh_link target in libgpg-error, lintian > doesn't complain about either breakout-link or > lacks-unversioned-link-to-shared-library i'm now more confused than ever about this situation. Apparently, clearing this lintian warning in libgpg-error introduced #992573 (a grave bug) despite my testing it locally and it seeming to work (perhaps my test was on a merged-/usr machine? i don't have the artifacts from that test any longer to confirm). The fact that silencing this warning in the expected way ended up injecting a grave bug seems problematic. The test probably needs more thought and fine-tuning. --dkg signature.asc Description: PGP signature
Bug#994434: mypy: new upstream version (0.910) available
Package: mypy Version: 0.812-1 Severity: wishlist Dear Maintainer, back in June, mypy upstream released 0.910: https://mypy-lang.blogspot.com/2021/06/mypy-0910-released.html note that this includes a switch to modular typeshed, as referenced here: https://mypy-lang.blogspot.com/2021/05/the-upcoming-switch-to-modular-typeshed.html it'd be great to have the most recent mypy available in debian. thanks for maintaining mypy! --dkg -- System Information: Debian Release: 11.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mypy depends on: ii python3 3.9.2-3 ii python3-mypy 0.812-1 mypy recommends no packages. Versions of packages mypy suggests: ii mypy-doc 0.812-1 -- no debconf information
Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks
Control: affects 968525 - libgpg-error-dev Control: retitle 968525 lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks On Thu 2021-08-19 19:20:16 -0400, Daniel Kahn Gillmor wrote: > I see the same issue in libgpg-error-dev with lintian 2.104.0. If I try > to fix it in libgpg-error-dev (i.e. by moving the symlink into lib/ > instead of usr/lib), hm, on further experimentation, i now take it back -- this warning appeared in libgpg-error-dev because debian/rules in libgpg-error source was manually adding an additional breakout-link. In particular, i think for libgpg-error-dev the problem was that there was a link in lib/ that was pointing to usr/lib/ (the other way around from what Aurelian reported). After removing the override_dh_link target in libgpg-error, lintian doesn't complain about either breakout-link or lacks-unversioned-link-to-shared-library sorry for the additional confusion, --dkg signature.asc Description: PGP signature
Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks
Control: affects 968525 + libgpg-error-dev libc6-dev Control: found 968525 2.104.0 Control: retitle 968525 lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks, conflicts with lacks-unversioned-link-to-shared-library On Mon 2020-08-17 00:00:07 +0200, Aurelien Jarno wrote: > Since recent version of lintian, the following tags are reported against > the libc6-dev package: > > W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libBrokenLocale.so -> > lib/x86_64-linux-gnu/libBrokenLocale.so.1 I see the same issue in libgpg-error-dev with lintian 2.104.0. If I try to fix it in libgpg-error-dev (i.e. by moving the symlink into lib/ instead of usr/lib), then instead i get a lintian warning lacks-unversioned-link-to-shared-library, whose description reads in part: N: The symlink is generally expected in the same directory as the library N: itself. The major exception to this rule is if the library is N: installed in (or beneath) /lib, where the symlink must be installed in N: the same dir beneath /usr. So these two lintian tags appear to be in conflict! --dkg signature.asc Description: PGP signature
Bug#989406: wireguard-dkms makes little sense with the bullseye kernel
Control: severity 989406 normal Control: retitle 989406 wireguard-dkms is unneeded for stock kernels > 5.6 I'm downgrading the severity to keep wireguard-dkms in bullseye -- we can increase it again once bullseye is released to keep wireguard-dkms out of bookworm. Adrian or others, if you would prefer that we handle this differently, please give a bit more detail about the timeline you'd prefer and why. Regards, --dkg signature.asc Description: PGP signature
Bug#989406: wireguard-dkms makes little sense with the bullseye kernel
On Thu 2021-06-03 01:37:25 +0300, Adrian Bunk wrote: > Overall it feels like a package with high CVE risk and 0 users > in bullseye. I agree with Jason that some people may use non-standard, older kernels with bullseye, so there is some value in continuing to provide wireguard-dkms in bullseye to help those folks. (i'm thinking about people running older hardware that has had support dropped in newer kernels, for example). It is not going to be exactly 0 users, but i expect the number to be small. At the same time, a package with a small number of users presents a smaller attack surface if a CVE does come up. The stock kernels already avoid people accidentally pulling in wireguard-dkms by default if they just "apt install wireguard". At some point, though, people who choose to run their own (non-debian) kernel will need to effectively take responsibility for their kernel modules as well, so i do not expect Debian to continue shipping wireguard-dkms indefinitely. I do not expect to ship it in bookworm (bullseye+1), for example. --dkg
Bug#968683: resolvconf and wireguard-tools
On Mon 2020-10-12 09:35:56 +0200, Jack Henschel wrote: > I also just ran into this issue yesterday. > I installed `wireguard-tools` on a minimal Debian Buster system and > `wg-quick` gave me the same error: > >> wg-quick up wg0 >> ... >> >> [#] resolvconf -a wg0 -m 0 -x >> /usr/bin/wg-quick: line 32: resolvconf: command not found > > Is there a particular reason why `wireguard-tools` only "suggests" resolvconf > but does not depend on it? > From my point of view, resolvconf should be a hard dependency. > > As mentioned before, installing the `resolvconf` package fixed the issue. Some users of wireguard-tools may never need to use wg-quick (e.g. they might just use /usr/bin/wg) Or, if they do use wg-quick, they might not use it with a configuration that tries to adjust the system resolvers. Finally, the resolvconf interface might be supplied by a number of different implementations -- either resolvconf, openresolv, or systemd-resolved's alias of resolvectl could be the relevant implementations. please see #930735 for more discussion. --dkg signature.asc Description: PGP signature
Bug#970275: lintian: Please allow /usr/share/gtk-doc/html without emitting package-contains-documentation-outside-usr-share-doc
Control: affects 970275 + libgmime-3.0-doc On Mon 2020-09-14 09:13:02 +0100, Simon McVittie wrote: > However, it currently causes Lintian to emit > package-contains-documentation-outside-usr-share-doc. Perhaps there could > be logic like this pseudocode? > > for each file outside /usr/share/doc that looks like documentation: > if there is a symlink in /usr/share/doc to the file or one of > its ancestor directories: > # assume it is used or read by programs > no tag > else: > package-contains-documentation-outside-usr-share-doc I agree with Simon that this is the right thing to do. the gmime packages are affected by this as well, and it makes lintian output very noisy for that package. I imagine that any package that uses the gtk-doc tooling will trigger this warning unnecessarily. --dkg signature.asc Description: PGP signature
Bug#989058: Acknowledgement (dumpasn1: new upstream version 20200928)
Version: 20200928-0.1 I uploaded the new version of dumpasn1 to experimental, and somehow forgot about my plan to use DELAYED/7, so it's live in experimental already. That's my bad, and i hope i didn't ruffle any feathers. I can revert the changes with a 20200928-0.2 if they're problematic! please let me know. Regards, --dkg signature.asc Description: PGP signature
Bug#989058: dumpasn1: new upstream version 20200928
Package: dumpasn1
Version: 20191022-2
Severity: wishlist
Tags: patch
Peter Gutmann released dumpasn1 20200928 last year. It'd be great to
have it in debian, as it includes a default configuration with many more
OIDs than the version currently patched.
I looked into the packaging and it looks like a straightforward upgrade.
In reviewing the two outstanding patches, i realized that they're
actually the same feature (handling non-ASCII strings) -- one was a
cleanup of the other patch, so i consolidated them.
I also updated to dh 13, trimmed out unused files for debian packaging,
added a couple build-time and runtime tests to exercise the non-ASCII
handling.
I'm attaching a consolidated diff here, but I've pushed my edits to the
debian/experimental branch in salsa so the individual commits have
better detail.
Mathieu, given that you're listed at
https://wiki.debian.org/LowThresholdNmu, i'll probably NMU the update to
experimental DELAYED/7 shortly unless I hear an objection (i'm sure this
kind of change is too much to expect in unstable during the freeze).
Feel free to reject it if there are problems, my feelings won't be hurt,
and I'd be happy to learn what you prefer.
Regards,
--dkg
diff --git a/debian/changelog b/debian/changelog
index 59fab36..996f357 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,23 @@
+dumpasn1 (20200928-0.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload
+ * New upstream release
+ * use https:// in debian-specific files
+ * move to idiomatic dh 13
+ * bump standards-version to 4.5.1 (no changes needed)
+ * Rules-Requires-Root: no
+ * add hardening features
+ * build and clean up generated manpage
+ * d/copyright: move to DEP 5
+ * drop unneeded files from debian/
+ * wrap-and-sort -ast
+ * add tests (both build-time and autopkgtest) covering certificates
+with UTF8Strings and BMPStrings
+ * get-orig-source: avoid using deprecated $GZIP env var
+ * refresh and consolidate patches
+
+ -- Daniel Kahn Gillmor Mon, 24 May 2021 14:13:11 -0400
+
dumpasn1 (20191022-2) unstable; urgency=medium
* d/rules: Make sure to build man page during build
@@ -27,13 +47,13 @@ dumpasn1 (20170309-1) unstable; urgency=medium
dumpasn1 (20150808-3) unstable; urgency=medium
- * Really fix segfaults on valid certificate. Closes: #840771
+ * Really fix segfaults on valid certificate. Closes: #840771
-- Mathieu Malaterre Thu, 20 Oct 2016 09:18:29 +0200
dumpasn1 (20150808-2) unstable; urgency=medium
- * Fix segfaults on valid certificate. Closes: #840771
+ * Fix segfaults on valid certificate. Closes: #840771
* Bump Std-Vers to 3.9.8, no changes needed
-- Mathieu Malaterre Wed, 19 Oct 2016 20:33:47 +0200
@@ -120,4 +140,3 @@ dumpasn1 (20020612-1) unstable; urgency=low
* Initial Release.
-- Oliver Kurth Mon, 2 Sep 2002 17:13:04 +0200
-
diff --git a/debian/clean b/debian/clean
index bdc3274..b2eca8a 100644
--- a/debian/clean
+++ b/debian/clean
@@ -1,2 +1,4 @@
dumpasn1
Makefile
+debian/dumpasn1.1
+dumpasn1.o
diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index ec63514..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-9
diff --git a/debian/control b/debian/control
index 4870ded..a3ebc8b 100644
--- a/debian/control
+++ b/debian/control
@@ -2,15 +2,21 @@ Source: dumpasn1
Section: utils
Priority: optional
Maintainer: Mathieu Malaterre
-Build-Depends: debhelper (>= 9), help2man
-Homepage: http://www.cs.auckland.ac.nz/~pgut001/
+Build-Depends:
+ debhelper-compat (= 13),
+ help2man,
+ valgrind ,
+Homepage: https://www.cs.auckland.ac.nz/~pgut001/
Vcs-Git: https://salsa.debian.org/debian/dumpasn1.git
Vcs-Browser: https://salsa.debian.org/debian/dumpasn1
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
+Rules-Requires-Root: no
Package: dumpasn1
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
Description: ASN.1 object dump program
An ASN.1 object dump program which will dump data encoded using any of the
ASN.1 encoding rules in a variety of user-specified formats.
diff --git a/debian/copyright b/debian/copyright
index 7c6df59..3844b49 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,27 +1,38 @@
-This package was debianized by Oliver Kurth on
-Mon, 2 Sep 2002 17:13:04 +0200.
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: dumpasn1
+Upstream-Contact: Peter Gutmann
+Source: https://www.cs.auckland.ac.nz/~pgut001/
-It was downloaded from http://www.cs.auckland.ac.nz/~pgut001/
+Files: *
+Copyright: 1997-2020 dumpasn1 authors, including Peter Gutmann,
+ David Kemp,
+ Matthew Hamrick,
+ Bruno Couillard,
+ Hallvard Furuseth,
+ Geoff Thorpe,
+ David Boyce,
+ John Hughes,
+ 'Life is hard, and then you die',
+ Hans-Olof Hermansson,
+ Tor Rustad,
+ Kjetil Barvik,
+ James Sweeny,
+ Chris Ridd,
+ David Leml
Bug#988436: RFP: certlint -- X.509 certificate linter
On Thu 2021-05-13 03:14:23 +, Paul Wise wrote: > On Wed, 12 May 2021 23:00:52 -0400 Daniel Kahn Gillmor wrote: > >> This and zlint (#915788) are apparently the two dominant X.509 >> certificate checkers > > A third one by a Debian person is x509lint: > > https://github.com/kroeckx/x509lint Yep, this would be a good thing to have in debian too. Kurt, would you be willing to consider packaging x509lint for debian? I can file a formal RFP if that would encourage you to do it :) --dkg signature.asc Description: PGP signature
Bug#915788: RFP: zlint -- X.509 certificate linter
On Thu 2021-05-13 10:47:55 +0800, Paul Wise wrote: > Control: forcemerge 915788 988435 > > On Wed, 12 May 2021 22:43:51 -0400 Daniel Kahn Gillmor wrote: > >> * Package name: zlint > > On Thu, 06 Dec 2018 22:41:03 +0300 Daniel Kahn Gillmor wrote: > >> * Package name: zlint > > Merging these duplicate RFP bugs :) hah, thanks, pabs. I checked the wrong section of https://www.debian.org/devel/wnpp, and forgot to check my own mailbox. Ryan Sleevi recently identified zlint and certlint as the two most well-developed X.509 certificate linters, and it occurred to me (again, apparently) that it'd be really useful to have them in debian: https://twitter.com/sleevi_/status/1392120487749300226 I'm filing an RFP for certlint shortly. --dkg signature.asc Description: PGP signature
Bug#988436: RFP: certlint -- X.509 certificate linter
Package: wnpp Severity: wishlist * Package name: certlint Version : 1.3.0 Upstream Author : Rob Stradling * URL : https://github.com/certlint/certlint * License : Apache 2.0 Programming Lang: Ruby, C Description : X.509 certificate linter This linter identifies likely problems with X.509 certificates, including ways that they can be out of compliance with RFCs, CABForum baseline requirements, and other standards. --- Note that this requires building of the asn1validator extension to ruby, which is included in the repository (as C source, afaict). This and zlint (#915788) are apparently the two dominant X.509 certificate checkers, according to Ryan Sleevi, who is in a good position to know: https://twitter.com/sleevi_/status/1392120487749300226 Regards, --dkg
Bug#988435: RFP: zlint -- X.509 certificate linter
Package: wnpp Severity: wishlist * Package name: zlint Version : 3.1.0 Upstream Author : ZMap team (University of Michigan) * URL : https://github.com/zmap/zlint * License : Apache 2.0 Programming Lang: Go Description : X.509 certificate linter ZLint is a X.509 certificate linter written in Go that checks for consistency with standards (e.g. RFC 5280) and other relevant PKI requirements (e.g. CA/Browser Forum Baseline Requirements). It can be used as a command line tool or as a library integrated into CA software. --- This would be a great command-line tool to have easily available in debian. I note that upstream recently changed to depend on go 1.16, so it may be difficult to package in debian right now (1.15~1 is the latest golang-go, iiuc), but i wanted to flag this for useful inclusion. --dkg
Bug#987324: rust-hashbrown: missing ahash feature makes building hashlink crate impossible
Package: rust-hashbrown Version: 0.9.1-2 Control: forwarded -1 https://github.com/kyren/hashlink/issues/6 I'm trying to build the hashlink crate, which is needed by a transitive dependency of future work on Sequoia (https://sequoia-pgp.org). However, the build of hashlink 0.6.0 fails with an error: ``` error[E0599]: no variant or associated item named `default` found for enum `DefaultHashBuilder` in the current scope --> src/linked_hash_map.rs:50:57 | 50 | hash_builder: hash_map::DefaultHashBuilder::default(), | ^^^ variant or associated item not found in `DefaultHashBuilder` error[E0599]: no variant or associated item named `default` found for enum `DefaultHashBuilder` in the current scope --> src/linked_hash_map.rs:60:57 | 60 | hash_builder: hash_map::DefaultHashBuilder::default(), | ^^^ variant or associated item not found in `DefaultHashBuilder` error: aborting due to 2 previous errors ``` I reported this to the hashlink project upstream, and @nathaniel-daniel identified the problem as being the stripping of the ahash feature from the hashbrown crate in debian. Presumably this means that we need the ahash crate in debian first; and then we should enable that feature for the hashbrown crate. --dkg signature.asc Description: PGP signature
Bug#985907: rnp: accepts weak cryptographic primitives
Package: src:rnp Version: 0.14.0-6 Control: forwarded -1 https://github.com/rnpgp/rnp/issues/1281 rnp currently accepts signatures over weak or untrustworthy cryptographic primitives. At the moment, there is no API for adjusting which mechanisms are acceptable, and all implemented algorithms are accepted, including (for example) signatures from very small RSA keys, or made over known-broken digests like MD5. This is probably not a responsible way to ship the library. maybe we want to follow thunderbird's approach of baking in a more strict policy via patches until upstream offers an API that lets the library user select their desired policy. --dkg signature.asc Description: PGP signature
Bug#985804: rust-coreutils manpages cleanup
Package: rust-coreutils Version: 0.0.4-1~exp2 Thanks for rust-coreutils. Very interesting project. A few thoughts about how to improve the documentation (manual pages in particular): - the manpages seem to be generated with help2man. that's cool, but i recommend supplying the --no-info argument to avoid clauses like this: --- SEE ALSO The full documentation for tac is maintained as a Texinfo manual. If the info and tac programs are properly installed at your site, the com‐ mand info tac should give you access to the complete manual. --- - naming the manpage rust-foo is a bit confusing when the contents of the manpage refer to "foo". I'd suggest that a manual subsection would be better (e.g. 1rust, by analogy with 1ssl from OpenSSL). then the file could be named simply foo.1rust.gz. Then a user can read it with "man 1rust tac" or "man 'tac(1rust)'" - The manpage doesn't clearly identify the source as uutils (or "Rust coreutils" or whatever), so it's hard when looking at it to see what's going on there. You can resolve this with help2man by invoking it this way (using tac as an example): help2man --source "uutils (Rust) coreutils $VERSION" \ --section 1rust \ --no-info \ --output tac.1rust \ /usr/lib/cargo/bin/coreutils/tac Additionally: - the formatting of the --help output isn't quite what help2man wants to parse. In particular, I'm seeing rendered output like this: --- NAME tac - manual page for tac 0.0.4 DESCRIPTION tac 0.0.4 Usage: tac [OPTION]... [FILE]... Write each file to standard output, last line first. OPTIONS --- Instead, i think you want: --- NAME tac - concatenate and print files in reverse SYNOPSIS tac [OPTION]... [FILE]... DESCRIPTION Write each file to standard output, last line first. OPTIONS --- I don't know how to solve this particular just by fiddling with help2man, though In particular: (a) I don't know where to find the "concatenate and print files in reverse" string (it's not in the --help output), but if you do, you should be able to supply it as the "--name" parameter to help2man. And (b) i'm not sure why help2man is confused about the SYNOPSIS section -- it probably presumes something about the output format. For tac it looks like it can be fixed directly in src/uu/tac/src/tac.rs, because the format-string is distinct from the text produced by GNU tac. Hopefully these notes are useful. i considered filing them upstream, but i noticed that there is no mention of help2man upstream, so i think the bulk of this needs to be fixed in debian/rules. Regards, --dkg signature.asc Description: PGP signature
Bug#985762: debcargo fails to mark --all-features tests as non-flaky
Package: debcargo Version: 2.4.4 Control: affects -1 src:rust-sequoia-openpgp I'm updating sequoia-openpgp's debcargo.toml to currently contain the following: --- # sequoia always needs at least one crypto backend and nettle is # currently the only crypto-backend available on debian systems. # Since crypto-nettle is included in the default, and in # --all-features we should expect those tests to succeed as well. # See https://bugs.debian.org/985741 for more info. [packages.lib] test_is_broken = true [packages."lib+crypto-nettle"] test_is_broken = false [packages."lib+default"] test_is_broken = false [packages."lib+@"] test_is_broken = false --- I'd expect this to produce a batch of tests where the only tests *not* marked flakey are those tests that include the crypto-nettle feature (see also #985741). However, debcargo 2.4.4 generates a debian/tests/control file that includes this stanza (note that the "flaky" restriction is included): --- Test-Command: /usr/share/cargo/bin/cargo-auto-test sequoia-openpgp 1.1.0 --all-targets --all-features Features: test-name=rust-sequoia-openpgp:@ Depends: dh-cargo (>= 18), librust-quickcheck-0.9-dev, librust-rand-0.7-dev, librust-rpassword-5+default-dev, @ Restrictions: allow-stderr, skip-not-installable, flaky --- I'll try to override this using the *.debcargo.hint mechanism, but i don't understand why the [packages."lib+@"] special section isn't useful for stripping the "flaky" restriction from the --all-features test, as it appears to be documented in the example debcargo.toml. --dkg signature.asc Description: PGP signature
Bug#985741: debcargo 2.4.4 adds --no-default-features to every feature-specific test in debian/tests/control
Package: debcargo Version: 2.4.4 Control: affects -1 src:rust-sequoia-openpgp in rust-sequoia-openpgp 1.0.0-1 (generated with debcargo 2.4.3), we see this example test of the "compression-deflate" feature: Test-Command: /usr/share/cargo/bin/cargo-auto-test sequoia-openpgp 1.0.0 --all-targets --features compression-deflate Features: test-name=librust-sequoia-openpgp+compression-deflate-dev But in rust-sequoia-openpgp 1.1.0-1 (generated with debcargo 2.4.4, with no upstream changes to compression-related stuff), we have this test of the "compression-deflate" feature: Test-Command: /usr/share/cargo/bin/cargo-auto-test sequoia-openpgp 1.1.0 --all-targets --no-default-features --features compression-deflate Features: test-name=librust-sequoia-openpgp+compression-deflate-dev:compression-deflate The test is named slightly differently, but the biggest change is that it now includes the --no-default-features flag. This is a subtle but important difference. Here is a full set of feature-related tests that we can imagine running: a) no features enabled at all b) all features enabled together c) only default features, enabled together d) one test per non-default feature, with the default features also enabled e) one test per feature, with no other features enabled. This change from 2.4.3 to 2.4.4 effectively swaps out the tests in (d) for the tests in (e). (fwiw, i can also imagine some sort of horrible combinatorial explosion where we try to test every possible combination of features; i won't get into that here) For rust-sequoia-openpgp, where at least one crypto-backend feature must be enabled (and nettle is the only crypto-backend feature on debian systems), and the default featureset does include crypto-nettle, all the tests in (d) should succeed, while most of the tests in (e) are likely to fail. I'd prefer to test the combinations of features in rust-sequoia-openpgp that feel most useful to me (and to minimize the number of tests that we need to mark as flakey) so i'd prefer to cover (d) instead of (e). I can see a handful of different possible ways to resolve this: 0) revert to the 2.4.3 behavior, by dropping --no-default-features from the feature-specific tests. 1) introduce a variable debcargo.toml that lets the maintainer choose between (d) and (e), e.g., "test_with_default_features" as a variable for the packages.lib section. 2) generate even more tests per package, including both (d) and (e) automatically (and distinctly) as long as there are some default features. 3) stick with the 2.4.4 behavior, but clearly document that these extra tests will be run with --no-default-features. Regards, --dkg signature.asc Description: PGP signature
Bug#985729: rust-regex empty pattern support is flawed
Package: src:rust-regex
Version: 1.3.7-1
Control: forwarded -1 https://gitlab.com/sequoia-pgp/sequoia/-/issues/694
Control: affects -1 src:rust-sequoia-openpgp
Control: clone -1 -2
Control: reassign -2 src:rust-regex-syntax 0.6.17-1
In the above-mentioned report for Sequoia's OpenPGP crate, we observe
how the regex crate fails to support some of the test cases that sequoia
includes.
This appears to be the main changelog issue between these two
regex-related crates from their debian-related version to the next
upstream version: regex-syntax (0.6.17 vs. 0.6.18) and regex (1.3.7
vs. 1.3.8).
I could work around this test failure in rust-sequoia-openpgp by patching
out the relevant test lines, but given that the changes between the
versions mentioned above seem fairly closely targeted to the minor
version bump in the regex-related packages, and this change is pretty
much the only thing in those packages, it might make more sense to just
bump rust-regex{,-syntax} to include these fixes for better handling of
empty regex patterns.
--dkg
signature.asc
Description: PGP signature
Bug#984594: gpgme always emits --with-keygrip, breaking its use with gpg1
On Fri 2021-03-05 10:21:37 -0500, Daniel Kahn Gillmor wrote: > It's not clear to me that the proposed upstream API is particularly easy > to use, but maybe it's better to drop the remaining patch and align with > upstream expectations, because: > > - the test suite already has dropped coverage of the relevant parts, >so the test suite won't fail. > > - in T4820, upstream appears concerned about additional compute cost of >generating keygrips (though i haven't seen any attempt to >characterize the total compute cost) > > - alignment with upstream is good in itself > > One possible consequence of doing this this is that gpgme-dependent > tools that expect the keygrip field to be populated (as it indeed was by > default when gpgme was backed with older versions of gpg) may break > until they learn to apply GPGME_KEYLIST_MODE_WITH_KEYGRIP (which in turn > would oblige them to depend on gpgme >= 1.14.0). > > Another alternative would be to make > debian/patches/0006-gpg-Send-with-keygrip-when-listing-keys.patch > conditional on the version -- only do that when the backend is known to > be version 2.2.x or higher. > > I'm leaning toward just dropping the patch. So i've dropped the patch in debian experimental, but i haven't done anything for the version currently in unstable/testing. I'd be curious to hear other people's thoughts about whether it's right to make the change before the freeze for Debian bullseye as well. Arguments for trying to make the change for bullseye are described above. arguments for not making the change for bullseye include: - this seems to introduce gratuitous breakage for some tools that use gpgme, expect the keygrip, but don't know about GPGME_KEYLIST_MODE_WITH_KEYGRIP - it seems to be trying to support gpg1, which we are otherwise already trying to figure out how to phase out I'm unsure of the right tradeoff here, but i welcome input on it. --dkg signature.asc Description: PGP signature
Bug#984627: debcargo: should ignore build-dependencies that are marked cfg(target_env = "msvc")
Package: debcargo
Version: 2.4.4-1
Control: affects -1 src:rust-nettle-sys
in Cargo.toml from nettle-sys 2.0.5, we see:
[target."cfg(target_env = \"msvc\")".build-dependencies.vcpkg]
version = "0.2.9"
But debcargo 2.4.4 translates that into actual Build-Depends: and
Depends: fields, despite the target environment not being the MSVC
compiler. It generates:
-
Source: rust-nettle-sys
Section: rust
Priority: optional
Build-Depends: debhelper (>= 12),
dh-cargo (>= 24),
cargo:native ,
rustc:native ,
libstd-rust-dev ,
librust-bindgen-0.55-dev | librust-bindgen-0.54-dev |
librust-bindgen-0.53-dev (>= 0.53.1-~~) ,
librust-pkg-config-0.3+default-dev ,
librust-vcpkg-0.2+default-dev (>= 0.2.9-~~) ,
nettle-dev (>= 3.5.1~~) ,
llvm
Maintainer: Debian Rust Maintainers
Uploaders:
Daniel Kahn Gillmor ,
kpcyrd
Standards-Version: 4.5.1
Vcs-Git: https://salsa.debian.org/rust-team/debcargo-conf.git [src/nettle-sys]
Vcs-Browser:
https://salsa.debian.org/rust-team/debcargo-conf/tree/master/src/nettle-sys
Rules-Requires-Root: no
Package: librust-nettle-sys-dev
Architecture: any
Multi-Arch: same
Depends:
${misc:Depends},
librust-bindgen-0.55-dev | librust-bindgen-0.54-dev | librust-bindgen-0.53-dev
(>= 0.53.1-~~),
librust-pkg-config-0.3+default-dev,
librust-vcpkg-0.2+default-dev (>= 0.2.9-~~),
nettle-dev (>= 3.5.1~~)
Provides:
-
So, i'll probably patch this out of the upstream sources for now, but
debcargo should have handled this more cleanly.
--dkg
signature.asc
Description: PGP signature
Bug#984594: gpgme always emits --with-keygrip, breaking its use with gpg1
Package: src:gpgme1.0 Version: 1.13.1-2 Control: affects -1 gpg1 In gpgme 1.13.1-2, I added debian/patches/0006-gpg-Send-with-keygrip-when-listing-keys.patch in an attempt to fix https://dev.gnupg.org/T4820. Upstream's alternative fix was instead to not test the output that breaks with older, known-buggy GnuPG versions (see upstream commits cff600f1f65a2164ab25ff2b039cba008776ce62 and 5c0d1c7f76c95bad8bce4ad3bafd121ec5101d3c), and to add an extra flag (GPGME_KEYLIST_MODE_WITH_KEYGRIP) that users of GPGME need to supply if they want to ensure that the keygrip field of the gpgme_subkey_t object is populated (see c8048bf8eb988f22b20215197f4739bedafc4264) I now see in the OpenPGP test interoperability test suite (https://tests.sequoia-pgp.org) a terse report that "GPGME uses --with-keygrip unconditionally, breaking GnuPG 1.4". Indeed, gpg1 does not appear to support the --with-keygrip flag at all. It's not clear to me that the proposed upstream API is particularly easy to use, but maybe it's better to drop the remaining patch and align with upstream expectations, because: - the test suite already has dropped coverage of the relevant parts, so the test suite won't fail. - in T4820, upstream appears concerned about additional compute cost of generating keygrips (though i haven't seen any attempt to characterize the total compute cost) - alignment with upstream is good in itself One possible consequence of doing this this is that gpgme-dependent tools that expect the keygrip field to be populated (as it indeed was by default when gpgme was backed with older versions of gpg) may break until they learn to apply GPGME_KEYLIST_MODE_WITH_KEYGRIP (which in turn would oblige them to depend on gpgme >= 1.14.0). Another alternative would be to make debian/patches/0006-gpg-Send-with-keygrip-when-listing-keys.patch conditional on the version -- only do that when the backend is known to be version 2.2.x or higher. I'm leaning toward just dropping the patch. --dkg signature.asc Description: PGP signature
Bug#983780: impass: impass gui fails silently when trying to create a new password when ~/.impass/keyid refers to an OpenPGP certificate incapable of signing
Package: impass Version: 0.12.2-1 After transitioned to a new key (but failing to update ~/.impass/keyid), i tried to use impass to create a new password (yes, i saw the red warning message about being unable to verify the signature). Clicking "Create" in the gui after entering the new context string did nothing -- it just silently failed. on stderr, i see: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/gpg/core.py", line 308, in encrypt self.op_encrypt_sign(recipients, flags, plaintext, ciphertext) File "/usr/lib/python3/dist-packages/gpg/core.py", line 163, in wrapper return _funcwrap(self, *args) File "/usr/lib/python3/dist-packages/gpg/core.py", line 141, in _funcwrap return errorcheck(result, name) File "/usr/lib/python3/dist-packages/gpg/errors.py", line 129, in errorcheck raise GPGMEError(retval, extradata) gpg.errors.GPGMEError: gpgme_op_encrypt_sign: Unspecified source: Unusable secret key During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/impass/gui.py", line 466, in simpleclicked self.create(None) File "/usr/lib/python3/dist-packages/impass/gui.py", line 486, in create self.db.save() File "/usr/lib/python3/dist-packages/impass/db.py", line 227, in save encdata = self._encryptDB(cleardata, keyid) File "/usr/lib/python3/dist-packages/impass/db.py", line 124, in _encryptDB encdata, _, _ = self._gpg.encrypt(data, [recipient], File "/usr/lib/python3/dist-packages/gpg/core.py", line 324, in encrypt raise errors.InvalidSigners( gpg.errors.InvalidSigners: F20691179038E5C6: No secret key It's appropriate that impass should not be able to make such a signature (and therefore probably appropriate to fail), but inappropriate to fail silently. there should be clearer diagnostics presented to the user in this case. --dkg signature.asc Description: PGP signature
Bug#983770: rnp: FTBFS on 32-bit platforms (test suite failures)
Package: rnp Version: 0.14.0-5 Severity: critical Control: forwarded -1 https://github.com/rnpgp/rnp/issues/1436 RNP's test suites are failing on all of the 32-bit platforms in debian. I've reported this upstream so that hopefully it can be resolved. It should not migrate into testing in this current state. --dkg signature.asc Description: PGP signature
Bug#983069: lintian: please check that upstream signature is made with a modern hash (warn or error on MD5, SHA1, or RIPEMD160)
On Fri 2021-02-26 04:48:50 -0800, Felix Lechner wrote:
> That's a great idea! As a first step, I would like to show a
> classification tag with the hash algorithm. (It could be used for
> statistics.) Can 'gpgv' output such signature characteristics?
sure, we have several different tools (like pgpdump or "sq packet dump",
or python3-pgpy) that could provide this check.
If you're already using gpgv, you might just try verifying the signature
with "gpgv --weak-digest SHA1 --weak-digest RIPEMD160 …" -- that should
fail if the signature is weak, and produce some semi-readable warnings
for the user as well.
If you want to learn a lot more about the signature, you've got a lot of
options, but they're all pretty hairy.
gpgv produces data about the signature on its status FD:
$ gpg --dearmor < debian/upstream/signing-key.asc >
debian/upstream/signing-key.pgp
$ gpgv --status-fd 3 3>sig.status --keyring debian/upstream/signing-key.pgp
../xml2rfc_3.5.0.orig.tar.gz.asc ../xml2rfc_3.5.0.orig.tar.gz
gpgv: Signature made Wed 18 Nov 2020 05:20:56 AM EST
gpgv:using RSA key 4E9B574B8FBB171A
gpgv: Good signature from "Henrik Levkowetz "
$ awk < sig.status '/^\[GNUPG:\] VALIDSIG/ { print $10 }'
2
$
Yes, that "2" means "SHA1" (see
https://tools.ietf.org/html/rfc4880#section-9.4) (the "print $10" comes
from searching for VALIDSIG in /usr/share/doc/gnupg/DETAILS.gz)
So, that is rather opaque. Other techniques include sq, pgpdump, hot
(from hopenpgp-tools), and "gpg --list-packets"
$ sq packet dump ../xml2rfc_3.5.0.orig.tar.gz.asc
Signature Packet, old CTB, 540 bytes
Version: 4
Type: Binary
Pk algo: RSA (Encrypt or Sign)
Hash algo: SHA1
Hashed area:
Signature creation time: 2020-11-18 10:20:56 UTC
Unhashed area:
Issuer: 4E9B 574B 8FBB 171A
Digest prefix: D29F
Level: 0 (signature over data)
$ pgpdump ../xml2rfc_3.5.0.orig.tar.gz.asc
Old: Signature Packet(tag 2)(540 bytes)
Ver 4 - new
Sig type - Signature of a binary document(0x00).
Pub alg - RSA Encrypt or Sign(pub 1)
Hash alg - SHA1(hash 2)
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Wed Nov 18 05:20:56 EST 2020
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0x4E9B574B8FBB171A
Hash left 2 bytes - d2 9f
RSA m^d mod n(4094 bits) - ...
-> PKCS-1
$ gpg --list-packets < ../xml2rfc_3.5.0.orig.tar.gz.asc
# off=0 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid 4E9B574B8FBB171A
version 4, created 1605694856, md5len 0, sigclass 0x00
digest algo 2, begin of digest d2 9f
hashed subpkt 2 len 4 (sig created 2020-11-18)
subpkt 16 len 8 (issuer key ID 4E9B574B8FBB171A)
data: [4094 bits]
$ hot dearmor < ../xml2rfc_3.5.0.orig.tar.gz.asc | hot dump
--output-format YAML
hot (hopenpgp-tools) 0.23.6
Copyright (C) 2012-2021 Clint Adams
hot comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions.
hot (hopenpgp-tools) 0.23.6
Copyright (C) 2012-2021 Clint Adams
hot comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions.
signature:
- tag: BinarySig
- tag: RSA
- tag: SHA1
- - _sspCriticality: false
_sspPayload:
sigCreationTime:
unThirtyTwoBitTimeStamp: 1605694856
- - _sspCriticality: false
_sspPayload:
issuer:
eoki: 4E9B574B8FBB171A
- 53919
- - unMPI: […]
$
Warning: GnuPG upstream has explicitly said for years that *no one*
should try to programmatically parse the output of --list-packets.
> The warning you asked for would then take place on top of that—perhaps
> with different severities depending how dated the algorithm is.
The most detailed set of categories i can imagine wanting want are (in
order of severity, worse ones first):
a) no signature is available / signature does not validate from
debian/upstream/signing-key.asc
b) only available signature depends on MD5
c) only available signature depends on SHA1 or RIPEMD160
d) valid signature with any other OpenPGP digest
If we want to collapse to fewer categories, my main priority is that (d)
stands apart from any of (a), (b), or (c).
In no case should lintian suggest that a signature that depends on a
weak digest (b) or (c) is *worse* than having no signature at all (a)
If you want to look at other cryptographic checks like this, maybe you
want to warn based on the contents of the OpenPGP certificates in
debian/upstream/signing-key.pgp.
Things that would be worth warning or errors on on:
- No signing-capable keys (primary key or subkeys)
- Weak primary key
Bug#982258: [pkg-gnupg-maint] Bug#982258: gpgv1: Consider removing parts of the tools which aren't recommended to be used
On Sun 2021-02-07 20:19:19 +, Dominic Hargreaves wrote: > In the discussion at [1] it was suggested that perhaps gnupg1 could be > updated to explicitly remove support for operations other than > decrypting old messages. that discussion suggests that the only two things that people are likely to still use GnuPG for are: a) signing with old keys that gpg2 thinks are too weak to consider using b) decrypting old messages Surely from (a) it follows that there are others who need: c) verifying signatures from those old keys(?) For (b), do we have a sample of an old message that modern gpg is unable to decrypt, along with a sample key? for (a) and (c), do we have a sample of a usenet control message and key that are in use today? Is there an estimate of how many of those keys are still relied upon? Here are some features that it sounds to me like we could "safely" remove or disable in gpg1, while encouraging users who needed that specific functionality to migrate to modern gpg: - secret key generation - encryption - keyserver and other network access (including auto-key-locate?) - certification (aka "keysigning") - trust models other than direct (and always)? Any thoughts? --dkg signature.asc Description: PGP signature
Bug#973004: dpkg-sig: outdated digest format
On Tue 2020-10-27 07:52:16 +0100, Konstantinos Dalamagkidis wrote: > currently dpkg-sig uses MD5/SHA1 for the digest. Both are insufficient > for integrity protection and according to the Debian Wiki SHA-1 is being > phased out. This is really not acceptable. It's 2021, we've known that both MD5 and SHA-1 are inappropriate to use for applications where poor collision-resistance is a risk. Cryptographic verification of software packages *definitely* falls into this category. As far as i can tell (the documentation i could find is rather sparse), there is no other purpose for dpkg-sig. So I think its dependence on weak digests makes dpkg-sig entirely unfit for purpose. It should be removed from debian until/unless it is improved to use modern cryptographic primitives. --dkg signature.asc Description: PGP signature
Bug#983078: critical flag indicator image fails to render in X.509 certificate viewer
Package: thunderbird
Version: 1:78.7.1-1
In Thunderbird, i went to Preferences » Privacy and Security » Manage
Certificates » Authorities and selected "COMODO RSA Certification
Authority".
Then i clicked "View". in the viewer, there are different attributes of
the X.509 certificate. Two of those attributes ("Basic Constraints" and
"Key Usages") have an empty square box to the left of the attribute name
(see attached picture).
If I use the mouse to select those label regions, and then copy/paste
into some other tool, they show:
[This extension has been marked as critical, meaning that clients must reject
the certificate if they do not understand it.] Basic Constraints
and:
[This extension has been marked as critical, meaning that clients must reject
the certificate if they do not understand it.] Key Usages
So i think that empty square box is supposed to indicate that the
extension is a "critical" extension. (and the copy/paste is grabbing
something equivalent to HTML alt-text).
Problems with this situation:
- the empty square box doesn't communicate criticality -- presumably
this is an image resource that is failing to render properly.
- if this is actually just an image resource that is missing or fails
to render, then the alt text should show in its place, right? but it
doesn't; it just shows the blank image.
Thanks for maintaining Thunderbird in Debian!
--dkg
signature.asc
Description: PGP signature
Bug#983069: lintian: please check that upstream signature is made with a modern hash (warn or error on MD5, SHA1, or RIPEMD160)
Package: lintian Version: 2.104.0 Control: clone -1 -2 Control: reassign -2 devscripts Control: retitle -2 [uscan] deprecate upstream signatures made using weak hashes like MD5, SHA1, or RIPEMD160 Some upstream packages are signed with OpenPGP using old, deprecated digest algorithms. See for example xml2rfc having a recent signature made with SHA-1: https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/G89V9M7_qSGxDVBb0QpSIqzznVc/ If lintian is scanning a package that includes a cryptographic signature from upstream, it should warn (or produce an error) if that signature uses a weak cryptographic digest algorithm. In particular, MD5, SHA1, and RIPEMD160 should all be considered weak. likewise, uscan should provide at least a warning (perhaps an error) if it fetches an OpenPGP signature that appears to be made using a weak digest. For both of these cases (uscan and lintian), I say "warn" by default instead of "error" because of course a package with a weak signature shouldn't be treated worse than a package with *no* signature. Some OpenPGP implementations (like "sqop verify" or "sq verify", both from sequoia) already deprecate recently-made SHA1 signatures. If you're using gpgv to verify signatures, you can use the --weak-digest argument, like so: $ gpgv --weak-digest RIPEMD160 --weak-digest SHA1 --keyring debian/upstream/signing-key.pgp ../xml2rfc_3.5.0.orig.tar.gz.asc ../xml2rfc_3.5.0.orig.tar.gz gpgv: Signature made Wed 18 Nov 2020 05:20:56 AM EST gpgv:using RSA key 4E9B574B8FBB171A gpgv: Note: signatures using the SHA1 algorithm are rejected gpgv: Can't check signature: Invalid digest algorithm 2 $ (MD5 is already marked as a "weak digest" by default, so no need to include it specifically) Thanks for considering this! --dkg signature.asc Description: PGP signature
Bug#983066: xml2rfc: new 3.5.0 version available upstream
Package: src:xml2rfc Version: 2.47.0-1 upstream version 3.5.0 is available upstream in xml2rfc: https://pypi.org/project/xml2rfc/ I'm working on packaging this new version for debian. If it works cleanly, I'll likely put it in experimental for now due to the freeze, but if other people have a specific reason that they think it should be in unstable, i'm fine with moving it there too. --dkg signature.asc Description: PGP signature
Bug#983057: ruby-kramdown-rfc2629: kramdown-rfc2629 --version produces "unknown-version"
Package: ruby-kramdown-rfc2629 Version: 1.3.28-1 I would have expected "kramdown-rfc2629 --version" to report either the upstream version (1.3.28) or the debian revision (1.3.28-1), but instead i get "unknown-version": 0 dkg@alice:~$ kramdown-rfc2629 --version kramdown-rfc2629 unknown-version 0 dkg@alice:~$ I haven't dug deep enough to know whether this is an upstream bug or an issue with an impedence mismatch between debian packages and ruby gems, but i do note that from irb i see the same issue. kramdown-rfc2629 has this source: KDRFC_VERSION=Gem.loaded_specs["kramdown-rfc2629"].version rescue "unknown-version" and from irb: irb(main):001:0> require 'kramdown-rfc2629' => true irb(main):002:0> Gem.loaded_specs["kramdown-rfc2629"] => nil irb(main):003:0> Gem.loaded_specs["kramdown-rfc2629"].version Traceback (most recent call last): 4: from /usr/bin/irb:23:in `' 3: from /usr/bin/irb:23:in `load' 2: from /usr/lib/ruby/gems/2.7.0/gems/irb-1.2.6/exe/irb:11:in `' 1: from (irb):3 NoMethodError (undefined method `version' for nil:NilClass) irb(main):004:0> Gem.loaded_specs["kramdown-rfc2629"].version rescue 'unknown-version' => "unknown-version" irb(main):005:0> I defer to debian ruby packagers who have much deeper knowledge than i do about how this stuff all works. Upstream is pretty responsive, fwict, so if it's an upstream issue, please forward it to https://github.com/cabo/kramdown-rfc2629/issues Regards, --dkg signature.asc Description: PGP signature
Bug#983054: ruby-kramdown-rfc2629: new upstream version 1.3.34
Package: ruby-kramdown-rfc2629 Version: 1.3.28-1 Upstream has released version 1.3.34, which contains a helpful transformation for a document i'm working on. updating the debian packaging to that version would be great! (i note that 1.3.28 is a day away from transitioning to testing, so maybe either an upload to experimental, or a delayed upload would be wise so that at least 1.3.28 transitions) thanks for maintaining ruby-kramdown-rfc2629 in debian! --dkg signature.asc Description: PGP signature
Bug#944914: [pkg-gnupg-maint] Bug#944914: libgpgme11: Buffer overflow while using claws-mail
On Sun 2021-02-14 06:28:54 +0100, de...@sumpfralle.de wrote: > In fact the problem disappeared - probably around the time when I migrated my > 32bit system to 64bit (just the Debian packages; not hardware). Good to know, thanks for noting it here. > Thus if my "32 bit theory" does not trigger any more ideas, then I > would suggest to close this bug report as non-reproducible or invalid. hm, i've got nothing ☹ So i'm closing this report for now -- it's already marked as unreproducible. if someone else manages to replicate, please unarchive and reopen this bug report with the details! --dkg signature.asc Description: PGP signature
Bug#979840: dns-root-data: autopkgtest regression in testing: failed to query server 127.0.0.1@53
Thanks Paul for reviewing this, and Robert for looking into it further. I think my conclusions differ a little bit from Robert's. On Thu 2021-02-11 22:22:18 -0500, Robert Edmonds wrote: > I have investigated this report. The purpose of the dns-root-data > package is to ship, as static content, the list of IANA DNS root > nameserver IP addresses, and the IANA DNSSEC root zone trust anchor. > According to > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation: > > It can be appropriate to file an RC bug against the depended-on > package, if the regression amounts to an RC bug in the depending > package, and to keep it open while the matter is investigated. That > will prevent migration of an RC regression. > > I have confirmed that the current version of the package (2019052802) is > shipping the correct root nameserver hints and root zone trust anchor > content and that no RC regression exists, so I am lowering the severity > of this bug report. > > The problem seems to be that the test depends on the Knot Resolver's > kresd daemon, whose service unit is masked and is not started after > installing the knot-resolver package. I would guess something like the > following would fix the regression in the test: hmm, kresd.service is masked, because kresd is managed via the kresd@.service template (to enable cheap and easily-supervised multi-process parallelism). The problem seems to be that kresd isn't starting up automatically on package installation: Feb 12 20:23:01 alice systemd[1]: Stopping Knot Resolver daemon... Feb 12 20:23:01 alice systemd[382608]: kresd@1.service: Changing to the requested working directory failed: No such file or directory Feb 12 20:23:01 alice systemd[382608]: kresd@1.service: Failed at step CHDIR spawning /usr/bin/env: No such file or directory Feb 12 20:23:01 alice systemd[1]: kresd@1.service: Control process exited, code=exited, status=200/CHDIR Feb 12 20:23:01 alice systemd[1]: kresd@1.service: Failed with result 'exit-code'. Feb 12 20:23:01 alice systemd[1]: Stopped Knot Resolver daemon. Feb 12 20:23:17 alice systemd[1]: /lib/systemd/system/kresd@.service:25: Failed to assign slice system-kresd.slice to unit kresd@1.service, ignoring: Device or resource busy I've updated the autopkgtest script to try to manually ensure that the kresd@1 service is started and released a new version of dns-root-data to try to cover it. Meanwhile, I've also reported #982660 against knot-resolver for this strange startup situation. --dkg signature.asc Description: PGP signature
Bug#982660: knot-resolver: fails to start
Package: knot-resolver Version: 5.2.1-1 Severity: normal Control: blocks -1 979840 Control: affects -1 dns-root-data When i "apt install knot-resolver" on an otherwise clean system running systemd, the default configuration should start a listener on port 53 on 127.0.0.1. However, that listener often fails to start. This leads to failures in autopkgtests that depend on the kresd package producing such a functioning listener, like dns-root-data, which is suffering from #979840 as a result. Here's an example transcript of the installation (note "failed to load properly"): ``` The following NEW packages will be installed: knot-resolver 0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded. Need to get 292 kB of archives. After this operation, 976 kB of additional disk space will be used. Get:1 http://ftp.debian.org/debian bullseye/main amd64 knot-resolver amd64 5.2.1-1 [292 kB] Fetched 292 kB in 0s (790 kB/s) Preconfiguring packages ... Selecting previously unselected package knot-resolver. (Reading database ... 447962 files and directories currently installed.) Preparing to unpack .../knot-resolver_5.2.1-1_amd64.deb ... Unpacking knot-resolver (5.2.1-1) ... Setting up knot-resolver (5.2.1-1) ... Failed to try-restart kresd@1.service: Unit kresd@1.service failed to load properly: Device or resource busy. See system logs and 'systemctl status kresd@1.service' for details. Created symlink /etc/systemd/system/kresd.target.wants/kres-cache-gc.service → /lib/systemd/system/kres-cache-gc.service. Created symlink /etc/systemd/system/multi-user.target.wants/kresd.target → /lib/systemd/system/kresd.target. Processing triggers for man-db (2.9.3-2) ... Processing triggers for libc-bin (2.31-9) ... ``` The reason that it failed to start is that the working director doesn't appear to exist: ``` Feb 12 20:23:01 alice systemd[1]: Stopping Knot Resolver daemon... Feb 12 20:23:01 alice systemd[382608]: kresd@1.service: Changing to the requested working directory failed: No such file or directory Feb 12 20:23:01 alice systemd[382608]: kresd@1.service: Failed at step CHDIR spawning /usr/bin/env: No such file or directory Feb 12 20:23:01 alice systemd[1]: kresd@1.service: Control process exited, code=exited, status=200/CHDIR Feb 12 20:23:01 alice systemd[1]: kresd@1.service: Failed with result 'exit-code'. Feb 12 20:23:01 alice systemd[1]: Stopped Knot Resolver daemon. ``` Interestingly, the service *does* start successfully if you just do: ``` systemctl start kresd@1.service ``` after the "apt install" has finished running. here's the systemd unit: ``` # /lib/systemd/system/kresd@.service # SPDX-License-Identifier: CC0-1.0 [Unit] Description=Knot Resolver daemon Documentation=man:kresd.systemd(7) Documentation=man:kresd(8) Wants=kres-cache-gc.service Before=kres-cache-gc.service Wants=network-online.target After=network-online.target [Service] Type=notify Environment="SYSTEMD_INSTANCE=%i" WorkingDirectory=/var/lib/knot-resolver ExecStart=/usr/sbin/kresd -c /usr/lib/x86_64-linux-gnu/knot-resolver/distro-pre> ExecStopPost=/usr/bin/env rm -f "/run/knot-resolver/control/%i" User=knot-resolver Group=knot-resolver CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETPCAP AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_SETPCAP TimeoutStopSec=10s WatchdogSec=10s Restart=on-abnormal LimitNOFILE=524288 Slice=system-kresd.slice [Install] WantedBy=kresd.target ``` Seems like this might be an issue of postinst script ordering or something, but i don't fully understand it. how is /var/lib/knot-resolver supposed to change ownership to kresd? I can see that /etc/init.d/kresd does a chown, but i wouldn't expect that to be executed at all on a systemd system. I'm a bit stumped on this, and would welcome help figuring out why the startup fails. --dkg -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages knot-resolver depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.74 ii dns-root-data 2019052802 ii libc6 2.31-9 ii libdnssec8 3.0.4-2 ii libedit2 3.1-20191231-2+b1 ii libfstrm0 0.6.0-1+b1 ii libgcc-s1 10.2.1-6 ii libgnutls303.7.0-5 ii libknot11 3.0.4-2 ii liblmdb0 0.9.24-1 ii libluajit-5.1-22.1.0~beta3+dfsg-5.3 ii libnghttp2-14 1.42.0-1 ii libprotobuf-c1 1.3.3-1+b2 ii libstdc++6 10.2.1-6 ii libsystemd0247.3-1 ii libuv1
Bug#982630: marked as pending in lintian
Thanks for the rapid followup, Felix! I really appreciate your ongoing attention to detail with lintian. It's a very useful tool. On Fri 2021-02-12 19:21:39 +, Felix Lechner wrote: > Based on the information we have, the unversioned /usr/bin/python is > going away in the upcoming 'bullseye' release. The corresponding > changes were made in response to this merge request > > https://salsa.debian.org/lintian/lintian/-/merge_requests/334 > > in this and surrounding commits: > > > https://salsa.debian.org/lintian/lintian/-/commit/69d52d7b4c9dbf391b23dced6e6de920905f54ac > > Please file a bug for the unversioned Python interpreter to be > recognized as valid, if the information we have about the 'bullseye' > release is incorrect. I don't have any more information than you do about the specific plan for python in bullseye -- but what you're suggesting seems both plausible and reasonable to me. I was worried about the intended semantics for what "python" means, but https://www.python.org/dev/peps/pep-0394/#recommendation has this recommendation for distributors: >>> When packaging third party Python scripts, distributors are >>> encouraged to change less specific shebangs to more specific >>> ones. This ensures software is used with the latest version of >>> Python available, and it can remove a dependency on Python 2. The >>> details on what specifics to set are left to the distributors; >>> though. Example specifics could include: >>> >>> - Changing python shebangs to python3 when Python 3.x is supported. So this is probably something I should be fixing when packaging gpgme itself. Perhaps lintian could include a pointer to this reference in the description text for example-unusual-interpreter. Regards, --dkg signature.asc Description: PGP signature
Bug#982627: schleuder: fails with more recent versions of gpg
On Fri 2021-02-12 11:47:07 -0500, Daniel Kahn Gillmor wrote: > When GnuPG was upgraded to 2.2.27-1, schleuder's autopkgtests broke: I've applied the proposed patch and uploaded it as an NMU for 3.6.0-1.1. I pushed the relevant changes (and a tag) to a fork of the salsa repo, and submitted a merge request here: https://salsa.debian.org/ruby-team/schleuder/-/merge_requests/1 (i don't have push privileges for the ruby-team/schleuder repo or i would have pushed the changes directly there) Hopefully this addresses the concerns with GnuPG 2.2.27. --dkg
Bug#982630: lintian: example-unusual-interpreter is confused/confusing when example script has #!/usr/bin/env python
Package: lintian Version: 2.104.0 Control: affects -1 python3-gpg This is a peculiar error message: lintian seems confused about what the interpreter is for an example python script shipped in python3-gpg: $ lintian python3-gpg_1.14.0-1+b2_amd64.deb | head -n1 P: python3-gpg: example-unusual-interpreter usr/share/doc/python3-gpg/examples/assuan.py #!python $ head -n1 /usr/share/doc/python3-gpg/examples/assuan.py #!/usr/bin/env python $ lintian's warning completely elides the "/usr/bin/env" part of the interpreter, which makes it look like lintian doesn't know what the actual interpreter is. If that's the case, then lintian is confused. If lintian is in fact trying to complain about "python" vs "python3" (if we're trying to ensure that we don't have anything pointing to "python"), that is a sufficiently important, specific situation that it should offer a dedicated tag for it. Either way, the warning message shouldn't omit /usr/bin/env if it's present in the file in question, as the mismatch between the warning and the file is a distraction from the intent of the message. fwiw, i don't know whether upstream would change these examples to have a python3 shebang line, and i'm not inclined to ask them to do so -- i've got bigger fish to fry, and technically /usr/bin/python is supposed to be used for things that are both py3- and py2-compatible (which hopefully these examples all are). Thanks for maintaining lintian! --dkg signature.asc Description: PGP signature
Bug#982627: schleuder: fails with more recent versions of gpg
Package: schleuder
Version: 3.6.0-1
Control: tags -1 + patch upstream
Control: affects -1 + gpg src:gnupg2
Forwarded: https://0xacab.org/schleuder/schleuder/-/merge_requests/358
When GnuPG was upgraded to 2.2.27-1, schleuder's autopkgtests broke:
https://ci.debian.net/data/autopkgtest/testing/amd64/s/schleuder/10394911/log.gz
they were working fine with GnuPG was at 2.2.20-1:
https://ci.debian.net/data/autopkgtest/testing/amd64/s/schleuder/10384390/log.gz
The failures are reported as:
```
Failures:
1) Schleuder::Runner#run mails not encrypted to the list key handles a mail
which was encrypted to a passphrase and returns DecryptionFailed error
Failure/Error: result = Schleuder::Runner.new().run(mail, list.email)
GPGME::Error:
No such file or directory
# ./spec/schleuder/runner_spec.rb:246:in `block (4 levels) in '
# ./spec/spec_helper.rb:48:in `block (3 levels) in '
# ./spec/spec_helper.rb:47:in `block (2 levels) in '
```
I reported this to upstream, and paz produced the merge request linked
above, and the proposed patch attached here.
I'm trying to apply it to 3.6.0-1, and can NMU if there are no
objections.
--dkg
From: paz
Date: Fri, 12 Feb 2021 15:40:38 +0100
Subject: Change way to block passphrase interaction
This changes the way we block gpg from asking interactively for a
passphrase, ever. It's also a less hacky way to force this. This works
with gpg-2.0.26+gpgme-1.5.1, gpg-2.1.18+gpgme-1.8.0,
gpg-2.2.27+gpgme-1.14.0, and gpg-2.2.27+gpgme-1.15.1, which makes me
optimistic that it's universally working.
The previous solution brought problems for some platforms and specific
combinations of gnupg with gpgme (resulting in "GPGME::Error no such
file or directory").
(cherry picked from commit 0b7c3a9ffd0178c7610752899e569758704ffd32)
---
lib/schleuder.rb | 3 ---
lib/schleuder/mail/message.rb | 4 +++-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/lib/schleuder.rb b/lib/schleuder.rb
index f164420..b87becd 100644
--- a/lib/schleuder.rb
+++ b/lib/schleuder.rb
@@ -68,9 +68,6 @@ ENV["SCHLEUDER_CONFIG"] ||= '/etc/schleuder/schleuder.yml'
ENV["SCHLEUDER_LIST_DEFAULTS"] ||= '/etc/schleuder/list-defaults.yml'
ENV["SCHLEUDER_ENV"] ||= 'production'
ENV["SCHLEUDER_ROOT"] = rootdir.to_s
-# Ensure that gnupg never-ever tries to ask for a passphrase.
-ENV["GPG_TTY"] = "/nonexistant-#{rand}"
-ENV["DISPLAY"] = nil
GPGME::Ctx.set_gpg_path_from_env
GPGME::Ctx.check_gpg_version
diff --git a/lib/schleuder/mail/message.rb b/lib/schleuder/mail/message.rb
index e0875f7..8eadbca 100644
--- a/lib/schleuder/mail/message.rb
+++ b/lib/schleuder/mail/message.rb
@@ -24,7 +24,9 @@ module Mail
# Message#initialize.
def setup
if self.encrypted?
-new = self.decrypt(verify: true)
+# Specify 'loopback'-pinentry-mode to ensure that gnupg never-ever
+# tries to interactively ask for a passphrase.
+new = self.decrypt(verify: true, pinentry_mode: GPGME::PINENTRY_MODE_LOOPBACK)
# Test if there's a signed multipart inside the ciphertext
# ("encapsulated" format of pgp/mime).
if encapsulated_signed?(new)
signature.asc
Description: PGP signature
Bug#840642: Acknowledgement (gpgme binding cleanup)
Back in 2016, in https://bugs.debian.org/840642, i wrote: > we also have several remaining copies of GPGME bindings in > debian, and it would be good to reduce their number. This will save the > sanity of our users; will provide better focus for upstream developers; > and will be easier for us to maintain going forward. I believe all of this cleanup has been done, and only officially upstream-supported versions of gpgme are in debian (a few copies remain in oldstable, but that's on its way out). So I'm closing this report, as it has served its purpose. Thanks to all the developers and maintainers who helped make this happen. --dkg signature.asc Description: PGP signature
Bug#944914: [pkg-gnupg-maint] Bug#944914: libgpgme11: Buffer overflow while using claws-mail
Control: tags 944914 + moreinfo unreproducible
Hi Lars--
On Sun 2019-11-17 16:53:33 +0100, Lars Kruse wrote:
> I am using the claws-mail package for handling emails (Debian testing
> on i386).
>
> Due to repeated crashes, I started to collect stack traces.
Are you still having these problems?
Bernhard Übelacker wrote:
>Maybe it is of some help, following seem to be locations with the
>missing symbols:
>...
>#8 0xb6441a7a in __fdelt_chk (d=194142480) at fdelt_chk.c:25
>#9 0xb27e5281 in () at libgpgme.so.11, in _gpgme_io_select at
> ../../src/posix-io.c:788
>#10 0xb27bf7fc in () at libgpgme.so.11, in _gpgme_wait_on_condition
> at ../../src/wait-private.c:87
>#11 0xb27bf9ec in () at libgpgme.so.11, in _gpgme_wait_one at
> ../../src/wait-private.c:170
>#12 0xb27c5201 in gpgme_op_verify () at libgpgme.so.11,
> ../../src/verify.c, line 1197.
>...
if i'm understanding correctly, this failure in fdelt_chk, which is due
to a violation of a precondition of one of the FD_* macros:
https://stackoverflow.com/questions/41212302/c-debugging-terminated-with-sigabrt
the referenced code in _gpgme_io_select (taken from 1.13.1-1, with
debian patches applied) is almost 20 years old:
```
781 d61bf6c13 gpgme/posix-io.c (Marcus Brinkmann2007-07-17 12:36:04
+ 781) /* The variable N is used to optimize it a little bit. */
782 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 782) for (n = count, i = 0; i < nfds && n; i++)
783 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 783) {
784 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 784) if (fds[i].fd == -1)
785 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 785) ;
786 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 786) else if (fds[i].for_read)
787 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 787) {
788 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 788)if (FD_ISSET (fds[i].fd, &readfds))
789 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 789) {
790 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 790)fds[i].signaled = 1;
791 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 791)n--;
792 6bf05e9c0 gpgme/posix-io.c (Werner Koch 2000-11-22 17:10:48
+ 792) }
793 6bf05e9c0 gpgme/posix-io.c (Werner Koch 2000-11-22 17:10:48
+ 793) }
794 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 794) else if (fds[i].for_write)
795 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 795) {
796 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 796)if (FD_ISSET (fds[i].fd, &writefds))
797 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 797) {
798 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 798)fds[i].signaled = 1;
799 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann2002-03-18 00:04:06
+ 799)n--;
800 6bf05e9c0 gpgme/posix-io.c (Werner Koch 2000-11-22 17:10:48
+ 800) }
801 6bf05e9c0 gpgme/posix-io.c (Werner Koch 2000-11-22 17:10:48
+ 801) }
802 6bf05e9c0 gpgme/posix-io.c (Werner Koch 2000-11-22 17:10:48
+ 802) }
803 d61bf6c13 gpgme/posix-io.c (Marcus Brinkmann2007-07-17 12:36:04
+ 803) return TRACE_SYSRES (count);
804 6bf05e9c0 gpgme/posix-io.c (Werner Koch 2000-11-22 17:10:48
+ 804) }
```
And yes, it does appear to be triggering on FD_ISSET -- so either
fds[i].fd is < 0, or it is > FD_SETSIZE:
https://sourceware.org/git/?p=glibc.git;a=blob;f=debug/fdelt_chk.c;h=7fe243d2174211257976ca95091b507c2a9499bd;hb=HEAD
But code earlier in _gpgme_io_select appears to try to verify that we
don't overflow these bounds, as described in
https://dev.gnupg.org/rM8173c4f1f8a145c4b1d454f6f05e26950e23d675, and i
don't see how ctx->fdt.fds could land in that range anyway.
So i'm pretty stumped as to why or how this could be happening (and i
haven't been able to hit it myself). If it's still going on, or if
you've found a way that i might be able to reproduce it, please respond
to this bug report.
Thanks,
--dkg
signature.asc
Description: PGP signature
Bug#945537: building thunderbird against a system rnp
Control: affects 945537 src:thunderbird Hi Debian Thunderbird devs-- Thanks very much for your work maintaining Thunderbird in Debian! I just wanted to give you a heads-up that i've prepared a debian package rnp. The packaging source can be found at https://salsa.debian.org/debian/rnp. It should close #945537 once it clears NEW. If it's possible to build thunderbird against a system version of librnp, that would be good to know. Hopefully it even makes the thunderbird build marginally quicker ☺, and if there are OpenPGP-specific security issues that get handled in rnp in the future we should be able to update them without needing to trigger a thunderbird rebuild. It should also serve as a validation of the rnp shared library interface. This transition doesn't need to happen right away, and is probably best done for now with staging in experimental. One potential wrinkle for adoption is that I'm in discussions with upstream about library naming: see https://github.com/rnpgp/rnp/issues/1406 . If that gets resolved by upstream the way I'm hoping it will, then the debian package names themselves will change from librnp-0-0 and librnp-0-dev to the simpler librnp0 and librnp-dev. Having rnp and librnp in debian should be useful generally, even if Thunderbird decides not to use the system librnp library, but I hope that Thunderbird will be able to use it. If there are specific reasons why this doesn't work, i'd be happy to hear those too. And if there's anything I can do to make it easier/smoother, please let me know. All the best, --dkg signature.asc Description: PGP signature
Bug#982575: ncmpc: fails with "unknown tag type" when talking to older mpd servers
Package: ncmpc
Version: 0.43-1
Tags: patch
Severity: important
Control: forwarded -1 https://github.com/MusicPlayerDaemon/ncmpc/issues/93
After upgrading to 0.43-1 on debian testing/unstable, ncmpc no longer
offers a useful connection to my mpd server, instead showing Unknown tag
type in red.
This makes ncmpc completely unusable for me, as I cannot reach the
playlist, the file browser, or even adjust the volume.
the server in question is running mpd version 0.21.5-3 (from debian stable)
Other mpd clients (like mpc version 0.33-1, and an Android mpd client)
continue to work fine with the same server.
Upstream offered the attached patch, which I've tested locally; it
resolves the problem for me. It (or an even better fix) will probably
be part of 0.45 whenever upstream gets around to releasing that version.
Regards,
--dkg
From: Max Kellermann
Date: Thu, 11 Feb 2021 21:44:15 +0100
Subject: mpdclient: make "tagtypes" errors non-fatal
This makes ncmpc usable even if applying the tag mask fails (for
whatever reason).
This fixes https://github.com/MusicPlayerDaemon/ncmpc/issues/93 (but a
better fix will follow).
(cherry picked from commit 7ce348cd21862e1f6b8228acbbff1a7df4df90d7)
---
src/mpdclient.cxx | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/mpdclient.cxx b/src/mpdclient.cxx
index cc04743..b6e6ba2 100644
--- a/src/mpdclient.cxx
+++ b/src/mpdclient.cxx
@@ -331,9 +331,12 @@ mpdclient::OnConnected(struct mpd_connection *_connection) noexcept
mpd_connection_cmp_server_version(connection, 0, 21, 0) >= 0 &&
!SendTagWhitelist(connection, tag_whitelist)) {
InvokeErrorCallback();
- Disconnect();
- mpdclient_failed_callback();
- return false;
+
+ if (!mpd_connection_clear_error(connection)) {
+ Disconnect();
+ mpdclient_failed_callback();
+ return false;
+ }
}
#endif
signature.asc
Description: PGP signature
Bug#979379: [pkg-gnupg-maint] Bug#979379: ITS: src:gnupg2
Hi Christoph and gniibe-- Many thanks to you both for preparing and proposing fixes for the GnuPG packaging in debian. I've done some review and cleanup and just uploaded 2.2.27-1 to unstable based on your work. In particular, i pulled from gniibe's git repository (which included Christoph's dependency tightening patches), and i cleaned up a bunch of fairly inconsequential lintian warnings. We're still shipping a lot of binaries in /usr/lib/gnupg and home-grown manpages, but without convincing upstream to adopt the manpages, or to ship the binaries someplace else, i don't know how the debian packaging is going to do that differently. On Fri 2021-01-22 10:17:45 +0100, Christoph Biedl wrote: > So consider this a request to join the team. I'm also in the IRC channel > but it seems you are not (or you have changed the nick). I'm back on the #debian-gnupg IRC channel, sorry for my absence from there earlier. I welcome and encourage more work on the packages maintained by this team, and though i don't think we have any formal membership process, i can say that you have more contributions to the packaging than many people who have been considered "team members" over the last few years. So please do keep contributing! Regards, --dkg signature.asc Description: PGP signature
Bug#981855: bash completion for man fails to identify manpages for subcommands ("man git bis" should complete to "man git bisect ")
Package: bash-completion
Version: 1:2.11-2
Control: affects -1 + man-db git sq libreswan
Control: forwarded -1 https://github.com/scop/bash-completion/issues/495
bash-completion ships tab completion for /usr/bin/man that identifies
specific manpages.
However, recent versions of man are clever enough to know that a request
for a subcommand like "man 1 git bisect" is not a request for two manpages
("git.1" and "bisect.1") but rather a request for the manpage for the
subcommand "git-bisect.1".
When i try to tab-complete the string "man git bis" it would be
better if the tab completion would prduce "man git bisect ", rather than
what it currently does (on my system, it offers completions to "bison",
"bison.yacc", or "bisque").
man does this cleverness when the command name and subcommand name are
joined together in the manpage title by either a hyphen ("-") (e.g.,
"git-revert.1" from git) or underscore ("_") (e.g., "ipsec_show.8" from
libreswan).
There is some level of ambiguity here, of course: when the user runs
"man git commit", it produces git-commit.1, but when the user runs "man
commit git" it produces commit.7 (from postgresql-client-13) followd
git.1.
So when completing from "man XXX Y", bash could include the
following candidates:
a) all manpage names that begin with XXX[-_]Y, with the XXX[-_] prefix
trimmed
b) all manpage names that begin with Y
From a usability perspective, most people are trying to read a single
manpage at a time. So i would argue that if (a) is non-empty, nothing
from (b) should be offered.
Similarly, if someone tries to complete "man XXX ", and subcommand
manpages exist, it would make more sense to offer the user only the
available subcommand manpages, not all possible manpages.
--dkg
(as i was writing this report, i realized that it's probably mainly an
upstream bug, so i filed it at the URL above, but i figure it's worth
tracking in the BTS as well since it affects other packages)
signature.asc
Description: PGP signature
Bug#981843: man is unable to find manpages for sub-subcommands, for example "man sq packet dump"
Package: man-db Version: 2.9.3-2 Severity: wishlist Control: affects -1 + sq It's great that /usr/bin/man can Do The Right Thing™ when a manpage is requested for a subcommand like "man git tag". Some utilities these days have sub-subcommands, though, with manpages to match, and man doesn't handle those as well as it could. A good example of this is "sq", the Sequoia OpenPGP implementation, which has sub-subcommands like "sq packet dump" and also ships a manpage at /usr/share/man/man1/sq-packet-dump.1.gz But, if i do "man sq packet dump", then I see the sq-packet.1.gz manpage, follwed by an error message "No manual entry for dump" It would be great to generalize man's cleverness here into sub-subcommands as well. --dkg signature.asc Description: PGP signature
Bug#855653: libreswan: /etc/init.d/ipsec is missing
Control: tags 855653 + moreinfo On Sat 2017-11-18 08:02:34 +0800, Daniel Kahn Gillmor wrote: > Great, i'm glad to hear it. Do you have a patch to provide for the > debian packaging? I've already offered to review such a patch (in the > text that you quoted above). Just following up on #855653 because I haven't seen anyone offer a tested, considered patch for the debian libreswan packaging to handle sysvinit. Looking in the upstream source tree, i see: initsystems/sysvinit/init.debian.in but it has a fair amount of fiddliness in it, and it is clearly out of date (even in version 4.2, it references KLIPS!) so i suspect this is not something anyone is actually maintaining. Again, I'm happy to review proposed patches from someone who has tested them on a system running sysvinit. --dkg signature.asc Description: PGP signature
Bug#981712: no-dh-sequencer false positive on faketime
Package: lintian Version: 2.104.0 Control: affects -1 src:faketime faketime's debian/rules contains: %: PREFIX=/usr dh $@ this is due to an idiosyncracy of the upstream build system, which sets PREFIX to /usr/local by default unless it is set explicitly in the environment. I could do the same thing with some sort of "export PREFIX=/usr" line elsewhere, but i prefer to not set environment variables more widely than necessary. But lintian clams no-dh-sequencer on the faketime package, despite the fact that it's clearly using dh. I'm open to suggestions about other ways to invoke dh in a way that lintian can identify that faketime is doing so. But it'd also be great if lintian could figure it out directly without having to change faketime's packaging. --dkg signature.asc Description: PGP signature
Bug#965349: regression in dh_installchangelogs or dh_missing causes fatal error when installing upstream changelog from debian/tmp
Control: affects 965349 + src:faketime On Mon 2020-07-20 12:56:33 -0400, Nicholas D Steeves wrote: > dh_missing: warning: changelog exists in debian/tmp but is not installed to > anywhere […] > I am explicitly installing it in rules with 'dh_installchangelogs > debian/tmp/changelog' and have confirmed the file exists in each of the > binary packages for both debhelper-compat 12 and 13. fwiw, i'm running into a similar issue when packaging an updated version faketime. The source for faketime contains ./NEWS, but the "install" make target also places the NEWS file into debian/tmp/usr/share/doc/faketime/NEWS dh_installchangelogs installs the NEWS file as expected (in /usr/share/doc/faketime/changelog.gz), but then dh_missing complains that debian/tmp/usr/share/doc/faketime/NEWS isn't installed anywhere. If i go ahead and add usr/share/doc/faketime/NEWS to debian/libfaketime.docs to satisfy dh_missing, then i get a *different* lintian warning: W: libfaketime: duplicate-changelog-files usr/share/doc/libfaketime/NEWS.gz usr/share/doc/libfaketime/changelog.gz i could add usr/share/doc/faketime/NEWS to debian/not-installed, but that seems bogus too -- it *is* installed, but it's installed by dh_installchangelogs. (this is likely to be my near-term workaround, ugly as it is) Seems like dh_missing could: - observe the cryptographic digest of the file installed by dh_installchangelogs (maybe both as installed and decompressed) - for each potentially "missing" file: - digest it (possibly decompressing it first?) and compare it against the changelog digest(s). if they match, skip it. hope this is useful. thanks a lot for all the work on dh and on lintian. they're both super helpful toolchains for kicking the ecosystem into doing the Right Thing. --dkg signature.asc Description: PGP signature
Bug#981587: fontconfig prefers Bold and Oblique variants of DejaVu Sans Mono over Inconsolata or other regular monospace fonts
Package: fontconfig Version: 2.13.1-4.2 Severity: normal Control: affects -1 src:fonts-dejavu DejaVu Sans Mono font variants "Bold" and "Oblique" don't get appropriately pruned when the user searches fontconfig for a "monospace" font. if i use `fc-match --all monospace` i see all Bitstream Vera Mono font variants come first: 0 dkg@alice:~$ fc-match --all monospace | head VeraMono.ttf: "Bitstream Vera Sans Mono" "Roman" VeraMoBd.ttf: "Bitstream Vera Sans Mono" "Bold" VeraMoIt.ttf: "Bitstream Vera Sans Mono" "Oblique" VeraMoBI.ttf: "Bitstream Vera Sans Mono" "Bold Oblique" DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book" DejaVuSansMono-Bold.ttf: "DejaVu Sans Mono" "Bold" DejaVuSansMono-Oblique.ttf: "DejaVu Sans Mono" "Oblique" DejaVuSansMono-BoldOblique.ttf: "DejaVu Sans Mono" "Bold Oblique" Inconsolata.otf: "Inconsolata" "Medium" Andale_Mono.ttf: "Andale Mono" "Regular" 0 dkg@alice:~$ But while using --sort (which applies pruning) removes the "Bold" and "Oblique" and "Bold Oblique" variants of Bitstream Vera Mono, as i'd expect: 0 dkg@alice:~$ fc-match --sort monospace | head VeraMono.ttf: "Bitstream Vera Sans Mono" "Roman" DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book" DejaVuSansMono-Bold.ttf: "DejaVu Sans Mono" "Bold" DejaVuSansMono-Oblique.ttf: "DejaVu Sans Mono" "Oblique" Inconsolata.otf: "Inconsolata" "Medium" Andale_Mono.ttf: "Andale Mono" "Regular" Courier_New.ttf: "Courier New" "Regular" Courier_New_Italic.ttf: "Courier New" "Italic" n022003l.pfb: "Nimbus Mono L" "Regular" NimbusMonoPS-Regular.otf: "Nimbus Mono PS" "Regular" But note that above, the "Bold" and "Oblique" variants of DejaVu Sans Mono remain unpruned (the "Bold Oblique" variant is pruned, for some reason). I confess i don't really understand fontconfig very well, but this seems inconsistent and problematic. Certainly, if the standard "Book" form of DejaVu Sans Mono was unavailable for some reason, a fallback to the "Medium" form of Inconsolata would be better than a fallback to "Bold" or "Oblique" DejaVu Sans Mono. Please do to reassign this to DejaVu Sans Mono if that's the appropriate place for the fix. --dkg PS i stumbled into this while researching https://bugs.debian.org/981577 -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fontconfig depends on: ii fontconfig-config 2.13.1-4.2 ii libc6 2.31-9 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 fontconfig recommends no packages. fontconfig suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#981577: Chromium mis-renders UTF-8 text tables due to Bitstream Vera Sans Mono missing Unicode box drawing characters
Package: ttf-bitstream-vera Version: 1.10-8.1 Control: affects -1 chromium fontconfig python-matplotlib-data src:fonts-dejavu Textual tables drawn with standard UTF-8 box drawing characters (U+2500…U+25FF) are being mis-rendered by Chromium in a common default configuration. https://dkg.fifthhorseman.net/table.txt ships a text/plain; charset=UTF-8 file contains a simple textual table for testing: ╒══╤═══╤═╕ │ This is a Table │It contains text │ Implemented with│ ╞══╪═══╪═╡ │ Unicode │ Box drawing │ Characters │ └──┴───┴─┘ It is mis-rendered by default on chromium on systems that have Bitstream Vera Mono installed, like so: If I remove ttf-bitstream-vera from the system, then Chromium renders the text with DejaVu Sans Mono instead, yielding a correct view: I think what's happening is that Chromium selects Vera Sans through fontconfig, and then when it discovers missing glyphs, it falls back to rendering those glyphs in some other font, which does not have the same width as Vera Sans. This results in mis-rendered tables that use unicode box drawing. Possible Solutions -- I see a few different possible fixes, in different places: - Bitstream Vera Mono could implement monospaced glyphs for the unicode box drawing characters - fontconfig could prefer more complete fonts when searching for a match, which would prioritize dejavu sans (or some other more complete font) over bitstream vera - fontconfig could manually prefer DejaVu Sans Mono over Bitstream Vera Mono when given the search string "monospace" - chromium, when substituting missing glyphs in a monospace font, could ensure that the substitute glyphs are appropriately sized for the font they are filling in for. - chromium could hardcode (and depend on?) a preferred monospace font by default that is more complete than Bistream Vera as its default monospace font - We could drop ttf-bitstream-vera from the archive, which would affect packages like python-matplotlib-data, gravit-data, and the ~20 other packages that Depend on ttf-bitstream-vera directly. I can't afford to just purge the package from my system because i need matplotlib :( - fonts-dejavu-core (or fonts-dejavu-extra?) could Provide: ttf-bitstream-vera, since it appears to provide aliases for Bitstream Vera in e.g. /etc/fonts/conf.avail/57-dejavu-sans-mono.conf -- i don't know whether this is sufficient for all the explicit Dependencies of ttf-bitstream-vera, though. Diagnosis - Chromium's default monospace font appears to rely on fontconfig for selection. In particular, i think it sends font-config the "monospace" search term, which when Bitstream Vera is installed results in: 0 dkg@alice:~$ fc-match monospace VeraMono.ttf: "Bitstream Vera Sans Mono" "Roman" 0 dkg@alice:~$ Without bitstream-vera installed, it looks like fontconfig will prefer dejavu sans mono, which contains these glyphs and doesn't break the rendering: 0 dkg@alice:~$ fc-match --sort monospace | head VeraMono.ttf: "Bitstream Vera Sans Mono" "Roman" DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book" DejaVuSansMono-Bold.ttf: "DejaVu Sans Mono" "Bold" DejaVuSansMono-Oblique.ttf: "DejaVu Sans Mono" "Oblique" Inconsolata.otf: "Inconsolata" "Medium" Andale_Mono.ttf: "Andale Mono" "Regular" Courier_New.ttf: "Courier New" "Regular" Courier_New_Italic.ttf: "Courier New" "Italic" n022003l.pfb: "Nimbus Mono L" "Regular" NimbusMonoPS-Regular.otf: "Nimbus Mono PS" "Regular" 0 dkg@alice:~$ To verify my suspicion about font replacement characters, i used "fontimage" from the fontforge package to render the files in question explicitly: I tried rendering the table using fontimage with the two fonts: fontimage -o veramono.png --pixelsize 10 \ --text '╒══╤═══╤═╕' \ --text '│ This is a Table │It contains text │ Implemented with │' \ --text '╞══╪═══╪═╡' \ --text '│ Unicode │ Box drawing │ Characters │' \ --text '└──┴───┴─┘' \ /usr/share/fonts/truetype/ttf-bitstream-vera/VeraMono.ttf fontimage -o dejavusansmono.png --pixelsize 10 \ --text '╒══╤═══╤═╕' \ --text '│ This is a Table │It contains text │ Implemented with │' \ --text '╞══╪═══╪═╡' \ --text '│ Unicode │ Box drawing │ Characters
Bug#981301: elvish: please document where you want tab completion directives installed
On Fri 2021-01-29 12:47:53 +0800, Shengjing Zhu wrote: > It doesn't support global completion files yet. Author just says he will > consider this after 0.15. OK, thanks for the heads-up! When you know where the global completion files are likely to be looked for (even if the upstream version is not released yet), please follow up on this ticket. That way, we can ship the files in the right place in debian, and when elvish gains that capability, there will already be some completion files available. (also, if there's a known place to ship .elv files, then elvish users in the meantime can copy them into wherever their local completion files are supposed to go, right?) All the best, --dkg signature.asc Description: PGP signature
Bug#981367: ruby-kramdown-rfc2629 new upstream version 1.3.24 is available
Package: src:ruby-kramdown-rfc2629 Version: 1.3.9-1 Looks like ruby-kramdown-rfc2629 upstream version 1.3.24 is available, with a series of fairly minor bugfixes. It'd be great to have that up-to-date in debian. I can NMU it if necessary, but i'd also be happy not to :) --dkg signature.asc Description: PGP signature
Bug#981301: elvish: please document where you want tab completion directives installed
Package: src:elvish
Version: 0.15.0~rc3-1
Control: affects -1 src:rust-sequoia-sq src:rust-sequoia-sqv
I'm packaging a few rust binaries built using the "clap" crate, which
auto-generates completion files for bash, fish, zsh, elvish, and
powershell.
I know how to ship the bash, fish, and zsh tab completion directives.
But i don't know how to ship the elvish tab completion directives, or
how to test that they work as expected. i'm including an example sq.elv
that is produced by the rust-sequoia-sq package when it's built, for
reference.
It would be great if we could document in the elvish source package
debian/ directory at least (or even better, in the binary package, in
/usr/share/doc/elvish).
If it's already documented someplace and i'm just unaware, feel free to
close this report with a pointer to the right location!
Thanks for maintaining elvish in debian!
--dkg
edit:completion:arg-completer[sq] = [@words]{
fn spaces [n]{
repeat $n ' ' | joins ''
}
fn cand [text desc]{
edit:complex-candidate $text &display-suffix=' '(spaces (- 14 (wcswidth
$text)))$desc
}
command = 'sq'
for word $words[1:-1] {
if (has-prefix $word '-') {
break
}
command = $command';'$word
}
completions = [
&'sq'= {
cand --known-notation 'Adds NOTATION to the list of known notations'
cand -f 'Overwrites existing files'
cand --force 'Overwrites existing files'
cand -h 'Prints help information'
cand --help 'Prints help information'
cand -V 'Prints version information'
cand --version 'Prints version information'
cand decrypt 'Decrypts a message'
cand encrypt 'Encrypts a message'
cand sign 'Signs messages or data files'
cand verify 'Verifies signed messages or detached signatures'
cand armor 'Converts binary to ASCII'
cand dearmor 'Converts ASCII to binary'
cand inspect 'Inspects data, like file(1)'
cand key 'Manages keys'
cand keyring 'Manages collections of keys or certs'
cand certify 'Certifies a User ID for a Certificate'
cand packet 'Low-level packet manipulation'
cand help 'Prints this message or the help of the given
subcommand(s)'
}
&'sq;decrypt'= {
cand -o 'Writes to FILE or stdout if omitted'
cand --output 'Writes to FILE or stdout if omitted'
cand -n 'Sets the threshold of valid signatures to N'
cand --signatures 'Sets the threshold of valid signatures to N'
cand --signer-cert 'Verifies signatures with CERT'
cand --recipient-key 'Decrypts with KEY'
cand --dump-session-key 'Prints the session key to stderr'
cand --dump 'Prints a packet dump to stderr'
cand -x 'Prints a hexdump (implies --dump)'
cand --hex 'Prints a hexdump (implies --dump)'
cand -h 'Prints help information'
cand --help 'Prints help information'
cand -V 'Prints version information'
cand --version 'Prints version information'
}
&'sq;encrypt'= {
cand -o 'Writes to FILE or stdout if omitted'
cand --output 'Writes to FILE or stdout if omitted'
cand --recipient-cert 'Encrypts for all recipients in CERT-RING'
cand --signer-key 'Signs the message with KEY'
cand --mode 'Selects what kind of keys are considered for
encryption.'
cand --compression 'Selects compression scheme to use'
cand -t 'Chooses keys valid at the specified time and sets the
signature''s creation time'
cand --time 'Chooses keys valid at the specified time and sets the
signature''s creation time'
cand -B 'Emits binary data'
cand --binary 'Emits binary data'
cand -s 'Adds a password to encrypt with'
cand --symmetric 'Adds a password to encrypt with'
cand --use-expired-subkey 'Falls back to expired encryption subkeys'
cand -h 'Prints help information'
cand --help 'Prints help information'
cand -V 'Prints version information'
cand --version 'Prints version information'
}
&'sq;sign'= {
cand -o 'Writes to FILE or stdout if omitted'
cand --output 'Writes to FILE or stdout if omitted'
cand --merge 'Merges signatures from the input and SIGNED-MESSAGE'
cand --signer-key 'Signs using KEY'
cand -t 'Chooses keys valid at the specified time and sets the
signature''s creation time'
cand --time 'Chooses keys valid at the specified time and sets the
signature''s creation time'
cand --notation 'Adds a notation to the certification.'
cand -B 'Emits binary data'
cand --b
Bug#947258: lintian: spare-manual-page is too strict (false positives for subcommand man pages)
Control: retitle 947258 lintian: spare-manual-page is too strict (false positives for subcommand man pages) Control: affects 947258 + sq Just noticed that manpage-without-executable was renamed to spare-manual-page, so i'm updating the title of this bug report to match. I also noticed the same failure for Sequoia's sq command-line OpenPGP utility, which i'm packaging (see ITP #929385), and has the same manpage-per-subcommand documentation layout. --dkg signature.asc Description: PGP signature
Bug#981152: ncmpc: Assertion failed: i < filelist->size() during "Browse" while another client is repeatedly clearing the playlist queue
Package: ncmpc Version: 0.42-1 Severity: important running ncmpc to connect to an mpd server, i get a crash with a warning about "Assertion failed: ncmpc: ../src/FileListPage.cxx:492: virtual void FileListPage::PaintListItem(WINDOW*, unsigned int, unsigned int, unsigned int, bool) const: Assertion `i < filelist->size()' failed. Aborted I get this warning by going into the "Browse" view (hitting '3') and then navigating to any of the listed folders by hitting enter. It seems to do this when viewing any of the subfolders i investigate using "Browse". Below is a backtrace from such an assertion: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x77ae8537 in __GI_abort () at abort.c:79 #2 0x77ae840f in __assert_fail_base (fmt=0x77c51128 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55593307 "i < filelist->size()", file=0x5559320b "../src/FileListPage.cxx", line=492, function=) at assert.c:92 #3 0x77af7662 in __GI___assert_fail (assertion=assertion@entry=0x55593307 "i < filelist->size()", file=file@entry=0x5559320b "../src/FileListPage.cxx", line=line@entry=492, function=function@entry=0x55593420 "virtual void FileListPage::PaintListItem(WINDOW*, unsigned int, unsigned int, unsigned int, bool) const") at assert.c:101 #4 0x55573070 in FileListPage::PaintListItem (this=, w=, i=, y=1, width=, selected=) at ../src/FileListPage.cxx:492 #5 0x5557497d in ListWindow::Paint (this=0x55608798, renderer=...) at ../src/ListWindow.cxx:56 #6 0x5556eaa7 in ScreenManager::Paint (this=0x7fffe0a8, main_dirty=) at ../src/screen_paint.cxx:51 #7 0x5556dd18 in ScreenManager::Update (this=, c=..., seek=...) at ../src/screen.cxx:226 #8 0x5556496e in mpdclient_idle_callback (events=) at ../src/Main.cxx:193 #9 0x555676c8 in mpdclient::OnIdle (this=0x7fffdeb0, _events=) at ../src/mpdclient.cxx:72 #10 0x55565c8c in mpdclient::GetConnection (this=this@entry=0x7fffdeb0) at ../src/mpdclient.cxx:471 #11 0x55573321 in screen_file_load_list (filelist=..., current_path=0x556087f8 "cd-tracks", c=0x7fffdeb0) at ../src/FileBrowserPage.cxx:92 #12 FileBrowserPage::Reload (this=this@entry=0x55608780, c=...) at ../src/FileBrowserPage.cxx:111 #13 0x55573465 in FileBrowserPage::ChangeDirectory (this=this@entry=0x55608780, c=..., new_path=...) at ../src/FileBrowserPage.cxx:123 #14 0x555736fd in FileBrowserPage::ChangeToEntry (this=0x55608780, c=..., entry=...) at ../src/FileBrowserPage.cxx:163 #15 0x55573c25 in FileBrowserPage::HandleEnter (this=0x55608780, c=...) at ../src/FileBrowserPage.cxx:196 #16 0x55572c11 in FileListPage::OnCommand (cmd=Command::PLAY, c=..., this=0x55608780) at ../src/FileListPage.cxx:431 #17 FileListPage::OnCommand (this=this@entry=0x55608780, c=..., cmd=cmd@entry=Command::PLAY) at ../src/FileListPage.cxx:372 #18 0x55573cdd in FileBrowserPage::OnCommand (this=0x55608780, c=..., cmd=Command::PLAY) at ../src/FileBrowserPage.cxx:350 #19 0x5556e338 in ScreenManager::OnCommand (this=0x7fffe0a8, c=..., seek=..., cmd=cmd@entry=Command::PLAY) at ../src/screen.cxx:232 #20 0x55564558 in do_input_event (event_loop=..., cmd=cmd@entry=Command::PLAY) at ../src/Main.cxx:231 #21 0x5556b89a in AsyncUserInput::OnSocketReady (this=0x7fffe360) at ../src/event/SocketEvent.hxx:94 #22 0x5558dc79 in EventLoop::Run (this=this@entry=0x7fffde50) at ../src/event/Loop.cxx:332 #23 0x55564a54 in Instance::Run (this=this@entry=0x7fffde50) at ../src/Instance.cxx:100 #24 0x5556385c in main (argc=-8624, argv=0x7fffe4b8) at ../src/Main.cxx:351 One thing to note: i only see this behavior when the same mpd server has another client connected to it that is misbehaving. In particular, the misbehaving client is constantly clearing the queue (imagine another ncmpc client attached to a machine where the keyboard is erroneously sending the "c" keypress). So this might be some sort of TOCTOU failure associated with testing membership in the current queue when displaying a list of folders during browsing? Feel free to forward the report upstream if you think it's not a debian-specific issue. I can reproduce the error (though not as reliably) on a debian buster system as well, as long as the same misbehaving mpd client is connected to the same server. Thanks for maintaining ncmpc in debian! --dkg -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8,
Bug#980723: autopkgtests aren't being run for rust-sequoia-sqv or rust-sequoia-keyring-linter or rust-sequoia-sop
Control: reassign 980723 debcargo Control: retitle 980723 debcargo-built binary crates have no way to run upstream tests Control: affects 980723 + rust-sequoia-sqv rust-sequoia-sop rust-sequoia-keyring-linter On Wed 2021-01-20 20:14:45 -0500, Daniel Kahn Gillmor wrote: > I think this is because some rust packages needed specifically for > testing are not available in the archive. Hm, on further investigation, i think it is actually because the debcargo-based packaging workflow just doesn't run cargo's tests on binary-only crates. The upstream tests associated with "cargo test" aren't run during the build (dh_auto_test) on any crate, fwict, but they *are* run during the autopkgtest. I'm glad that they're run during autopkgtest because that means that they can be re-run without a package rebuild when new versions of dependencies are uploaded. But, binary-only crates don't file any rust source in /usr/share/cargo/registry/ so running (for example) /usr/share/cargo/bin/cargo-auto-test sequoia-sop 0.22.0 from an unpacked rust-sequoia-sop source tree just yields: crate directory not found: /usr/share/cargo/registry/sequoia-sop-0.22.0 so they aren't run in autopkgtest for binary-only crates. I think we might need to rethink how debcargo handles the upstream tests for binary-only crates. Perhaps the dh --buildsystem cargo needs to adjust how that's done? weirdly, i note that rust-sequoia-sop 0.22 has these two lines in debian/rules: override_dh_auto_test: dh_auto_test -- test --all but rust-sequoia-sqv 1.0.0 does not. Both source packages are assembled with debcargo 2.4.3, i think, and their debcargo.toml files don't differ meaningfully. --dkg
Bug#980723: autopkgtests aren't being run for rust-sequoia-sqv or rust-sequoia-keyring-linter or rust-sequoia-sop
Package: rust-sequoia-sqv Version: 1.0.0-1 Looks like the autopkgtests are not being run for rust-sequoia-sqv (or for sq-keyring-linter or sqop). I think this is because some rust packages needed specifically for testing are not available in the archive. We should add them to the archive so that the autopkgtest suites get run. (they do not appear to be run during the build) --dkg
Bug#969057: libreswan make opportunistic and cavp autopkgtest skippable
On Tue 2021-01-12 18:33:55 +0100, Eduardo Barretto wrote: > Feel free to correct me at any point, but here is what I've experienced. > > It seems like this issue appeared after Launchpad builders started to > recognize the needs-internet restriction, and it seems that > needs-internet is not enough. Here is what the test was returning > before: > opportunisticSKIP unknown restriction needs-internet > And after, when I was applying some fixes: > opportunisticFAIL non-zero exit status 1 > > That's why we added the skippable and exit 77. ok, but what does "recognize the needs-internet restriction" mean? the definition of "needs-internet" [0] is: The test needs unrestricted internet access, e.g. to download test data that's not shipped as a package, or to test a protocol implementation against a test server. Please also see the note about Network access later in this document. [0] https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst The "Network access" section also says: […] In Ubuntu's infrastructure access to sites other than *.ubuntu.com and *.launchpad.net happens via a proxy (limited to DNS and http/https). The patches you've proposed, if i'm understanding them correctly, cause the test to be skipped because the test really does use unrestricted Internet -- not only DNS and HTTP/HTTPS. This makes me think that either Ubuntu's infrastructure shouldn't consider itself as offering "unrestricted internet access" (meaning, it should automatically skip any test with a "needs-internet" restriction), or it should run any test that has a "needs-internet" restriction outside of the proxied filter. If there's a need for a different constraint (like "needs-only-dns-and-http") to match what ubuntu's infrastructure offers, that might be a separate question. But either the documentation of what "needs-internet" means needs to change, or Ubuntu's infrastructure should not claim to support it, if i'm reading the docs correctly. thanks for raising this issue! I'm happy to talk about it more if you've got a different interpretation. Regards, --dkg signature.asc Description: PGP signature
Bug#934327: libreswan: addconn crash on ipsec.conf
Version: 4.1-1 Control: tags 934327 + moreinfo On Fri 2019-09-27 20:50:33 +, Ray Klassen wrote: > Further on this. It seems to relate to having esp= in the default > 'conn' and overriding it with phase2alg= in a specific 'conn.' I had > that crash again on another router and after using phase2alg in both > stanzas the problem went away. I'm not sure how to replicate this bug report, and perhaps it has been fixed in 4.1-1. I'm closing this while also asking for more information. If you can replicate it with 4.1-1, please provide a sample configuration snippet that we can use to replicate the problem, and reopen the bug report (i'm happy to reopen it for you if you aren't sure how to do that). All the best, --dkg signature.asc Description: PGP signature
Bug#969057: libreswan make opportunistic and cavp autopkgtest skippable
Control: tags 969057 + moreinfo Hi Eduardo-- Both of these tests are already marked as "needs-internet" -- shouldn't that be sufficient for autopkgtest runners to know to skip them if regular internet access is not available? I'm not sure why we should use the skippable feature as well. Can you help me understand why we need both? Given that the only reason to need to skip is because the test needs the internet, it seems redundant (and possibly too lax) to have both methods available to bypass the test. (i might be misunderstanding something about how autopkgtest works -- please help me understand better if that's the case, i'm not opposed to adjusting the tests in general!) --dkg On Wed 2020-08-26 17:04:52 -0300, Eduardo Barretto wrote: > Depending on the builder being used it is not possible to reach the > internet, making, e.g. opportunistic, tests to fail. This patch makes > opportunistic and cavp tests skippable and makes it exit 77 in case of > failure, as specified by: > https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst signature.asc Description: PGP signature
Bug#947258: lintian: manpage-without-executable is too strict (false positives for subcommand man pages)
Control: affects 947258 + libreswan On Fri 2020-05-22 10:46:29 -0700, Felix Lechner wrote: > So far, I learned that 'man' interprets two commands by default as a > sub-command [1] […] > [1] https://stackoverflow.com/a/32750157 Thanks for this pointer, interesting! > but I do not know how to tell from a man page that it is for a > sub-command like 'git add' instead of a command called git-add. > > I do not believe there is an annotation for it, although there > probably should be. I'm also unaware of anything like this. I don't know where would be the best place to try to establish such a convention. Any suggestions? > Unless someone has a better idea, I think we have parse the output > generated by 'groff -man -Tascii'. Similar to man's strategy [1] a man > page would be deemed to relate to a sub-command when the first two > words in the synopsis, connected by a hyphen, are the same as the file > name. It's not just the hyphen -- we should consider connection by an underscore as well (as libreswan's manpages do). --dkg signature.asc Description: PGP signature
Bug#979379: [pkg-gnupg-maint] Bug#979379: ITS: src:gnupg2
Hi all-- GnuPG is team-maintained -- i've uploaded most of the recent uploads, but i'm definitely not intending to be the sole maintainer, and i would be happy to have more active contributors to the team: https://wiki.debian.org/Teams/GnuPG Thanks Gniibe and Christoph for your work on this! Thanks gniibe in particular for your updates to patches that seem relevant for debian work but might not be carried upstream in 2.2. i can review and upload this work in the followin gweek if that'd be helpful, but i also don't object to anyone picking this up and running with it in a responsible way. Thanks all, --dkg On Thu 2021-01-07 12:08:51 +0900, NIIBE Yutaka wrote: > Hello, > > On 2021-01-05 +0100, Christoph Biedl wrote: >> | missing upstream releases, >> >> Several. Debian has 2.20, uploaded in March. Upstream is at 2.26. > > FYI, I tried to build GnuPG 2.2.26-1-of-mine package: > > https://salsa.debian.org/gniibe/gnupg2 > > I did: > > * fetch by 'git fetch ' > * import upstream tar balls by 'gbp import-orig' > * refresh patches > * add a line to debian/rules for Windows (building regexp.a). > * follow the changes of upstream (gpgsplit and symcryptrun). > * merge pull request for scdaemon configuration > * add one patch of mine to fix #868550, #972525. > > It builds well for me (and works for me). > > I have no intention of NMU at all for this work. As one of upstream > maintainers, I'd like to make sure Debian version of GnuPG works well. > Please note that the patch for #868550, #972525 is a backport from > master, which is only for Debian (it won't be in 2.2 series of > upstream). > > I hope my changes above help Debian GnuPG packaging. > -- > > ___ > pkg-gnupg-maint mailing list > pkg-gnupg-ma...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-gnupg-maint signature.asc Description: PGP signature
Bug#979028: "hokey lint" says yellow for ECDH subkey algo/size line
Package: hopenpgp-tools Version: 0.23.5-1 similar to #978991, ECDH subkeys now say: algo/size: ECDH 256 where ECDH is in yellow (presumably a warning). ECDH isn't limited to curve25519 -- it could also use the NIST curves or the Brainpool curves. so i think you'll want to keep a size check if possible, but just know that there's no reason to warn for ECDH key sizes >= 256 (so, cv25519, NIST p256, etc). (same thing might be happening with NIST curves, i haven't checked). thanks for maintaining hopenpgp-tools! --dkg signature.asc Description: PGP signature
Bug#978991: hokey lint complains about 256-bit keysize for ed25519 and cv25519 keys (but it should not)
Package: hopenpgp-tools Version: 0.23.1-1+b1 "hokey lint" provides a red "256" next to the algorithm/size notes about ed25519 and cv25519 keys. I don't think it should warn about this size -- these asymmetric cryptographic sizes are widely considered to have roughly the same cryptographic strength as the symmetric AES128. --dkg signature.asc Description: PGP signature
Bug#978990: "hokey lint" fails to identify cross-signature on ed25519 signing-capable subkey
Package: hopenpgp-tools
Version: 0.23.1-1+b1
my ed25519/cv25519 OpenPGP certificate (attached) gets a complaint from
"hokey lint" that the signing-capable subkey does not have an embedded
cross cert.
In particular, the line is:
embedded cross-cert: False
which shows up twice. (it should only show up once, for the
encryption-capable cv25519 subkey -- it should *not* show up for the
ed25519 signing-capable subkey)
however, the embedded cross cert is there, because gpg --list-packets
(on the same data) says:
critical hashed subpkt 32 len 189 (signature: v4, class 0x19, algo 22,
digest algo 10)
I note that GnuPG typically creates these cross-certs in the unhashed
subpacket section, and doesn't mark them as "critical". Maybe "hokey
lint" doesn't recognize the cross-cert because of its
placement/positioning?
thanks for working on hopenpgp-tools!
--dkg
PS here's a transcript with the relevant error message underlined with s
```
0 dkg@alice:~$ gpg --export C29F8A0C01F35E34D816AA5CE092EB3A5CA10DBA | hokey
lint
hokey (hopenpgp-tools) 0.23.1
Copyright (C) 2012-2019 Clint Adams
hokey comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions.
Key has potential validity: good
Key has fingerprint: C29F 8A0C 01F3 5E34 D816 AA5C E092 EB3A 5CA1 0DBA
Checking to see if key is OpenPGPv4: V4
Checking to see if key is RSA or DSA (>= 2048-bit): EdDSA 256
Checking user-ID- and user-attribute-related items:
:
Self-sig hash algorithms: [SHA-512]
Preferred hash algorithms: [SHA-512, SHA-256]
Key expiration times: [2y11m26d59400s = Sun Dec 24 16:22:55 UTC 2023]
Key usage flags: [[certify-keys]]
:
Self-sig hash algorithms: [SHA-512]
Preferred hash algorithms: [SHA-512, SHA-256]
Key expiration times: [2y11m26d59400s = Sun Dec 24 16:22:55 UTC 2023]
Key usage flags: [[certify-keys]]
Daniel Kahn Gillmor:
Self-sig hash algorithms: [SHA-512]
Preferred hash algorithms: [SHA-512, SHA-256]
Key expiration times: [2y11m26d59400s = Sun Dec 24 16:22:55 UTC 2023]
Key usage flags: [[certify-keys]]
Checking subkeys:
one of the subkeys is encryption-capable: True
fpr: 2DB5 491C 9DF0 DC8F 4328 63CF 3E9D 7173 71DE 565C
version: v4
timestamp: 20201227-162255
algo/size: EdDSA 256
binding sig hash algorithms: [SHA-512]
usage flags: [[sign-data]]
embedded cross-cert: False
^^
cross-cert hash algorithms: [SHA-512]
fpr: 61C1 E3C2 410D 201D DB6F 8168 4C39 437E A528 5697
version: v4
timestamp: 20201227-162255
algo/size: ECDH 256
binding sig hash algorithms: [SHA-512]
usage flags: [[encrypt-storage, encrypt-communications]]
embedded cross-cert: False
cross-cert hash algorithms: [SHA-512]
0 dkg@alice:~$
```
dkg-openpgp-2021.pgp
Description: application/pgp-keys
signature.asc
Description: PGP signature
Bug#919642: emacs-common: mml-secure-check-user-id chokes on User IDs with no e-mail address (wrong-type-argument char-or-string-p nil)
On Tue 2019-02-26 02:59:54 -0500, Antoine Beaupré wrote: > The patch was accepted upstream, but I would suggest it might be a good > addition to buster as well... > > Any takers? It's a fairly trivial patch... fwiw, i think this should be included in the next buster point release, if we can get a new version of emacs in there. the one-line patch is pretty straightforward and shouldn't cause any problems. You can even cherry-pick it from upstream based on commit ID 90177d7f12d25e403abc6f1bdf242aed308a7bb8, which is also attached here. (i'd offer a patch myself on salsa, but it seems to be using git-dpm, and i don't really understand git-dpm well enough to try) --dkg From 90177d7f12d25e403abc6f1bdf242aed308a7bb8 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Fri, 18 Jan 2019 03:12:07 -0500 Subject: [PATCH] Avoid elisp crash for OpenPGP User IDs with no e-mail address * lisp/gnus/mml-sec.el (mml-secure-check-user-id): Verify that there is an e-mail address in the current User ID before trying to downcase it. (Bug#34121) Copyright-paperwork-exempt: yes --- lisp/gnus/mml-sec.el | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lisp/gnus/mml-sec.el b/lisp/gnus/mml-sec.el index 8c485fec376..4fca4ce67b7 100644 --- a/lisp/gnus/mml-sec.el +++ b/lisp/gnus/mml-sec.el @@ -658,6 +658,8 @@ The passphrase is read and cached." (catch 'break (dolist (uid uids nil) (if (and (stringp (epg-user-id-string uid)) + (car (mail-header-parse-address + (epg-user-id-string uid))) (equal (downcase (car (mail-header-parse-address (epg-user-id-string uid (downcase (car (mail-header-parse-address -- 2.29.2 signature.asc Description: PGP signature
Bug#977894: gui is broken, python3-xdo
On Thu 2020-12-24 09:37:46 -0400, Joey Hess wrote:
> Daniel Kahn Gillmor wrote:
>> thanks for the diagnosis, Joey! this looks like a change between the
>> ctypes module between python 3.8 and 3.9. I'll fix it in python3-xdo,
>> and hopefully that will resolve your problem.
>
> Independent of getting this fixed, I think it's concerning that ctypes
> falls back to looking for library files in cwd when a shared library is
> unavailable. That has potential to be part of a security exploit chain,
> although I have not dug deeply enough to know if it's exploitable.
I agree with you that this sounds sketchy, but i think the functionality
you're concerned about is in the find_library function:
https://docs.python.org/3/library/ctypes.html#finding-shared-libraries
which says:
>>> On Linux, find_library() tries to run external programs
>>> (/sbin/ldconfig, gcc, objdump and ld) to find the library file. It
>>> returns the filename of the library file.
Not sure what to make of this, but if you end up reporting it upstream
i'd be interested to see a pointer.
I didn't see any report that is obviously related to security and
find_library.
https://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid&ignore=file%3Acontent&%40search_text=find_library+security&submit=search&status=-1%2C1%2C2%2C3
for the python xdo module bindings for libxdo, i suppose we could also
avoid calling find_library("xdo") on linux, since it won't work against
SONAMEs other than 3. that is, we could maybe just hardcode
"libxdo.so.3" as the library name, assuming that these bindings are only
used on GNU/Linux systems. I don't know whether i'd be as comfortable
hardcoding "libc.so.6" though.
--dkg
signature.asc
Description: PGP signature
Bug#976637: Bug#977894: gui is broken, python3-xdo
Control: affects 976637 + impass python3-xdo I just noticed #976637 after working on resolving #977894 in impass/python3-xdo. I'm working around the problem by using "c" instead of "libc" in libxdo, but just wanted to note the relationship between the two issues in the BTS. --dkg signature.asc Description: PGP signature
Bug#977894: gui is broken, python3-xdo
Control: forwarded 977894 https://bugs.python.org/issue42580 On Thu 2020-12-24 08:24:19 -0500, Daniel Kahn Gillmor wrote: > thanks for the diagnosis, Joey! this looks like a change between the > ctypes module between python 3.8 and 3.9. I'll fix it in python3-xdo, > and hopefully that will resolve your problem. fwiw, this was reported as a regression in python 3.9 by doko at the URL above. --dkg signature.asc Description: PGP signature
Bug#977894: gui is broken, python3-xdo
Control: reassign 977894 python3-xdo
Control: affects 977894 + impass
Control: severity critical
Control: retitle 977894 python3-xdo: fails with python3.9 due to bad libc
linkage
thanks for the diagnosis, Joey! this looks like a change between the
ctypes module between python 3.8 and 3.9. I'll fix it in python3-xdo,
and hopefully that will resolve your problem.
--dkg
On Wed 2020-12-23 20:46:42 -0400, Joey Hess wrote:
> Yes, I get the same backtrace from both the 2 line script and the
> modified impass:
>
> joey@darkstar:~>impass gui
> Traceback (most recent call last):
> File "/usr/bin/impass", line 11, in
> load_entry_point('impass==0.12', 'console_scripts', 'impass')()
> File "/usr/lib/python3/dist-packages/impass/__main__.py", line 620, in main
> func(args)
> File "/usr/lib/python3/dist-packages/impass/__main__.py", line 350, in gui
> import xdo
> File "/usr/lib/python3/dist-packages/xdo/__init__.py", line 8, in
> from ._xdo import libxdo as _libxdo
> File "/usr/lib/python3/dist-packages/xdo/_xdo.py", line 14, in
> libc = ctypes.CDLL(ctypes.util.find_library('libc'))
> File "/usr/lib/python3.9/ctypes/util.py", line 341, in find_library
> _get_soname(_findLib_gcc(name)) or _get_soname(_findLib_ld(name))
> File "/usr/lib/python3.9/ctypes/util.py", line 147, in _findLib_gcc
> if not _is_elf(file):
> File "/usr/lib/python3.9/ctypes/util.py", line 99, in _is_elf
> with open(filename, 'br') as thefile:
> FileNotFoundError: [Errno 2] No such file or directory: b'liblibc.a'
>
> And so I modified /usr/lib/python3/dist-packages/xdo/_xdo.py as follows,
> which fixed the problem:
>
> - libc = ctypes.CDLL(ctypes.util.find_library('libc'))
> + libc = ctypes.CDLL(ctypes.util.find_library('c'))
signature.asc
Description: PGP signature
Bug#977894: gui is broken, python3-xdo
Control: affects 977894 python3-xdo
On Wed 2020-12-23 15:50:43 -0400, Joey Hess wrote:
> Ok, this is super weird, and I'm afraid also likely a security hole.
ugh, thanks for digging around on this with us, Joey.
it looks to me like the liblibc.a business is happening due to gobject
introspection, since it doesn't happen when impass isn't in gui mode.
> openat(AT_FDCWD, "liblibc.a", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
> or directory)
> write(2, "The xdo module is not found, so "..., 100The xdo module is not
> found, so the 'xdo' paste method is not available.
> Please install python3-xdo.) = 100
> write(2, "\n", 1
> ) = 1
> rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER,
> sa_restorer=0x7f56ccd6a140}, {sa_handler=0x63fb20, sa_mask=[],
> sa_flags=SA_RESTORER, sa_restorer=0x7f56ccd6a140}, 8) = 0
> munmap(0x7f56cc405000, 135168) = 0
> exit_group(1) = ?
> +++ exited with 1 +++
>
> What is this "liblibc.a" from CWD?! I have no clue at all, but if it
> does anything with it after opening it, then there would be security
> consequences.
>
> The strace -f also shows it execing ldconfig and gcc. I've attached the whole
> thing.
I'm seeing comparable weird behavior, including the invocations of
ldconfig and gcc, even if i don't see your particular failure. yikes.
But, a simple file like this produces the same behavior (with ldconfig
and gcc):
~~~
#!/usr/bin/python3
import xdo
~~~
Perhaps this is related to how python's ctypes module works?
(python3-xdo depends on ctypes)
I still don't understand why we're seeing that xdo isn't found, though.
Perhaps you could try applying the diff below to __main__.py in impass,
removing liblibc.a, and trying impass gui again?
diff --git a/impass/__main__.py b/impass/__main__.py
index 236e4c5..29957d6 100755
--- a/impass/__main__.py
+++ b/impass/__main__.py
@@ -332,7 +332,7 @@ def gui(args, method=os.getenv('IMPASS_XPASTE', 'xdo')):
if method == 'xdo':
try:
import xdo
-except:
+except ModuleNotFoundError:
error(1, """The xdo module is not found, so the 'xdo' paste method
is not available.
Please install python3-xdo.""")
# initialize xdo
This is testing the hypothesis that there's some other error that
happens when importing the xdo module, and we're imagining that it means
the module isn't found.
we should probably have a more conservative exception handler here anyway.
> I am cautious about sending a strace with that file created, because the GUI
> did open and sanitizing my password info would take time,
yes, please be cautious about sending straces with impass!
Regards,
--dkg
signature.asc
Description: PGP signature
Bug#977894: gui is broken, python3-xdo
On Tue 2020-12-22 10:13:43 -0400, Joey Hess wrote: > I do have that recommends installed. I did try to reinstall > it in case it was somehow broken. Real problem is that the gui does > not appear, I don't know if that's due to whatever the problem > is with python3-xdo. this is odd, and it makes me think that there's some python module path failure happening. if it can't find the system xdo, maybe it also can't find the gobject introspection libraries that are used to interface with GTK? is it possible that this is being run from within some sort of python virtualenv? --dkg signature.asc Description: PGP signature
Bug#975480: rust-bzip2-sys: autopkgtest failure: crate directory not found: /usr/share/cargo/registry/bzip2-sys-0.1.9+1.0.8
Control: affects 975480 debcargo On Sun 2020-11-22 19:21:45 +0100, Paul Gevers wrote: > autopkgtest [09:47:16]: test librust-bzip2-sys-dev: > /usr/share/cargo/bin/cargo-auto-test bzip2-sys 0.1.9+1.0.8 --all-targets > --no-default-features > autopkgtest [09:47:16]: test librust-bzip2-sys-dev: [--- > crate directory not found: /usr/share/cargo/registry/bzip2-sys-0.1.9+1.0.8 > autopkgtest [09:47:16]: test librust-bzip2-sys-dev: ---] This is a bug in debcargo 2.4.3 and earlier. in debcargo 2.4.4, debcargo emits the debian version here, based on commit 293fb88f2156d0db6262349aa4b1c4d3a3b1186a in the debcargo repo. Until debcargo 2.4.4 lands in unstable, i'll just work around it in rust-bzip2-sys. --dkg signature.asc Description: PGP signature
Bug#977627: librust-block-buffer-dev: should Provides: librust-block-buffer+block-padding-dev
Package: librust-block-buffer-dev Version: 0.9.0-3 Control: affects -1 debcargo src:rust-sha3 In an attempt to avoid creating an empty "feature" package, the packaging for rust-block-buffer removed the optionalness of block-buffer's dependency on block-padding. The result is that the debcargo-generated .deb doesn't know that it should add any Provides: entries like librust-block-buffer+block-padding-dev. This makes it so a pending update to rust-sha3 can't currently build, because it depends on block-buffer with the block-padding feature. I tried patching in a few lines to rust-block-buffer's Cargo.toml: [features] block-padding = [] But the result from that was this error: Something failed: failed to parse manifest at `…/debcargo-conf/build/block-buffer/Cargo.toml` Caused by: Features and dependencies cannot have the same name: `block-padding` If we can release a version of debcaro with the collapse_features mechanism, then an update of rust-block-buffer with that enabled should resolve this. In the meantime, i'm going to work around it by fiddling with the dependencies of rust-sha3. --dkg signature.asc Description: PGP signature
Bug#977491: debcargo: no clear way to indicate that a "feature" is actually a build-dep for a binary crate
Package: debcargo
Version: 2.4.3-3+b1
I'm looking at the sha1collisiondetection crate. this crate produces a
library and a binary ("sha1cdsum").
The binary needs to build against the structopt crate, but the library
doesn't need it.
Upstream represents this as the library having a structopt "feature",
which the binary requires.
But debcargo maps this into wanting to produce a "structopt" feature for
the library. We don't *want* that additional feature package. Or,
under the new rust packaging regime, we don't want that additional
dependency for the bundled all-Provides librust-*-dev package.
So i'd like for debcargo to have a way to indicate that a particular
feature should be ignored when packaging the library (but not ignored as
a build-depends).
--dkg
signature.asc
Description: PGP signature
Bug#977421: rust-sha1collisiondetection: FTBFS on architectures with unsigned char
Package: rust-sha1collisiondetection Version: 0.2.2-1 Severity: critical Control: forwarded -1 https://gitlab.com/sequoia-pgp/sha1collisiondetection/-/issues/1 Looks like rust-sha1collisiondetection code isn't as portable as upstream expected it to be. It is failing on platforms with an unsigned char, with errors like: ~~~ error[E0308]: mismatched types --> lib/lib.rs:252:31 | 252 | ... input.as_ptr() as *const i8, | ^^^ expected `u8`, found `i8` | = note: expected raw pointer `*const u8` found raw pointer `*const i8` ~~~ This means that the package fails to build from source on arm, powerpc, riscv, and s390 architectures. This is reported to upstream at https://gitlab.com/sequoia-pgp/sha1collisiondetection/-/issues/1 so hopefully they'll sort it out shortly. --dkg signature.asc Description: PGP signature
Bug#959010: zytrax effects
Hi Gürkan-- thanks for the followup, and sorry for the delay. On Wed 2020-04-29 08:03:22 +0200, Gürkan Myczko wrote: > The tutorial says for me Settings -> Preferences, then browse path, I > tried /usr/lib64/ > and then hit Scan, it found 22 effects for me: > http://bootes.ethz.ch/zytrax.png Hm, on my debian system, there is no /usr/lib64 (we use the more-flexible multiarch filesystem layout, see https://help.ubuntu.com/community/MultiArch). so i tried putting /usr/lib instead of /usr/lib64/ And sure enough it claimed to find 22 effects (which look like the same that you found from the png above). But if i'm understanding it correctly, those were the 22 that were already loaded and available -- they are all of "Type: Effect", so they aren't synthesizers. > Let's figure out which plugins to recommend are useful? Can you try > the above steps, and make an example song, with recommendations? I'm still stuck on creating a song without any synth elements. I don't know how to do it. But maybe i'm just holding the tool wrong? have you managed to make a song on it? what am i missing? --dkg signature.asc Description: PGP signature
Bug#973836: pipewire 0.3.14-1 causes pulseaudio failures on gnome desktop
Version: 0.3.15-1 Control: tags 973836 - moreinfo On Sun 2020-11-08 16:25:56 +, Simon McVittie wrote: > I think this may have been a regression in 0.3.14 that was fixed in 0.3.15 > (pipewire's experimental PulseAudio server reimplementation was enabled by > default, but shouldn't have been). Please try with 0.3.15-1? I can confirm that after upgrading to pipewire 0.3.15-1, the problem i had reported as https://bugs.debian.org/973836 went away. Thanks for the prompt fix, Simon! --dkg signature.asc Description: PGP signature
Bug#973836: pipewire 0.3.14-1 causes pulseaudio failures on gnome desktop
Package: src:pipewire Version: 0.3.14-1 Severity: important Control: notfound -1 0.3.12-1 I'm running debian unstable on a (fairly old) Sony Vaio laptop, with what a standard GNOME desktop. I often run "pavucontrol" to get into detailed fiddling with my audio. When pipewire upgraded to 0.3.14-1, pavucontrol no longer gives me any sort of control over the audio device (the error text says it's waiting). Similarly, other pulseaudio-using applications don't work right -- in some cases hanging for ~30 seconds while (i think) waiting to hear back from a pulseaudio service. If i downgrade all the pipewire packages to 0.3.12-1, then things start working again. In all these tests, I have pulseaudio 13.0-5 installed correctly on the relevant system. --dkg signature.asc Description: PGP signature
Bug#973052: (unbound unaccountably crashes inside libevent (Assertion nread >= 0 failed in evmap_io_del_))
On Wed 2020-10-28 16:29:14 -0400, Robert Edmonds wrote: > OK, I made a patch incorporating those fixes recommended by upstream and > sent them to #962459. Looks like that doesn't work at all. thanks for doing that, Robert. Bummer that it didn't work. > I'm not sure picking a random 1.9.x release is the right thing either. well, Benno (from upstream) recommended 1.9.2 specifically, even though 1.9.2 isn't even their latest 1.9.x release (i think that'd be 1.9.6). Maybe we should ask him why he proposed 1.9.2? > Overhauling the packaging in the buster branch would probably make > things unpleasant for stable reviewers, so I would not recommend doing > that. Sure, makes sense if we're cherry-picking patches. but if we're moving to a new upstream version maybe this change is enough "in the noise" to make it make sense to align the packaging strategy with the unstable packaging strategy? Not sure what the next steps are, but i appreciate your looking into this and thinking about it, Robert. Users of Debian stable deserve to have a non-crashy version one way or another. --dkg signature.asc Description: PGP signature
Bug#973052: (unbound unaccountably crashes inside libevent (Assertion nread >= 0 failed in evmap_io_del_))
Hi Robert-- thanks for the followup! On Wed 2020-10-28 02:56:55 -0400, Robert Edmonds wrote: > I've never been able to reproduce this bug, but your branch looks good > to me as far as backporting this commit to 1.9.0. It's commit > 225534e5ab22d16ab32fa1011733f3c69c7b28ba in the upstream repo which was > released in 1.9.1. I don't have any objection if you want to propose a > stable update for unbound with just this fix. Personally I've been > keeping unbound in buster-backports up to date with testing lately and I > don't have any buster machines running the version of unbound in buster > :-) Over on https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4227 upstream suggested two different things: - upgrade to 1.9.2, (which incorporates this and several other bugfixes), or - cherry-pick a list of other commits which they think are also relevant to this specific fix: 348cbab016f824a336b65d0091310fe5cd58e762 2b47ca080eb91e209fb86cd1dc90a6aff32e2a1f and four more, related to spoolbuf: 0b77c9d6763686264d44dfd926c8cb4f2f03a43a 6067ce6d2b82ce2e80055e578fdfd7ba3e67c523 af6c5dea43fc63452d49b2339e607365b6652987 a08fe8ca609b651c8d8c8379780aad508d492421 I'm assuming that the release team would prefer that we go the latter route (cherry-picked patches), but i haven't tried to get a direct verdict from them on that. I confess i don't really understand the way that unbound's buster packaging is working -- i think it's neither git-dpm nor gbp -- so i don't exactly know how i'd assemble an update for the next buster point release without overhauling it. (i'd be fine with overhauling it to use gbp (as i think the unstable version of the packaging is) as long as you're ok with that, but i also don't know whether that would make the changes more unpleasant for the release team. Any suggestions? --dkg signature.asc Description: PGP signature
Bug#973052: (unbound unaccountably crashes inside libevent (Assertion nread >= 0 failed in evmap_io_del_))
I've pushed the patch in #973052 to a new branch named bug-973052 in the https://salsa.debian.org/dns-team/unbound repo (on top of branches/1.9.0-2_deb10). Hopefully one of the other DNS folks will review it and merge it if it looks reasonable. Not sure whether we should release a new version with just this fix, but it might be worth proposing it. --dkg signature.asc Description: PGP signature
