Bug#1066903: libgnt: please drop runtime dependencies
This sounds reasonable to. It looks like you beat me to this with an
NMU. Thanks!
On 2024-03-15 04:08, Gianfranco Costamagna wrote:
Package: libgnt
Version: 2.14.4-1.1
Severity: serious
Tags: patch
Hello, I found some runtime dependencies, such as removed libglib2.0-0
breaking every 32bit build except i386 due to
time64_t transition.
Please update, remove them, let debhelper evaluate them via shlibs:Depends.
Also I added libxml2-dev build-dependency, looks like the support was
not enabled.
before:
Run-time dependency glib-2.0 found: YES 2.79.3
Run-time dependency gobject-2.0 found: YES 2.79.3
Run-time dependency gmodule-2.0 found: YES 2.79.3
Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency libxml-2.0 found: NO (tried pkgconfig and cmake)
Now:
Found pkg-config: YES (/usr/bin/pkg-config) 1.8.1
Run-time dependency glib-2.0 found: YES 2.79.3
Run-time dependency gobject-2.0 found: YES 2.79.3
Run-time dependency gmodule-2.0 found: YES 2.79.3
Run-time dependency libxml-2.0 found: YES 2.9.14
Also dpkg shows correct dependencies now:
Package: libgnt0t64
[...]
Depends: libc6 (>= 2.38), libglib2.0-0t64 (>= 2.75.3), libncursesw6 (>=
6), libtinfo6 (>= 6), libxml2 (>= 2.7.4)
Breaks: finch (<< 2.14.1), libgnt0 (<< 2.14.4-1.2)
Replaces: finch (<< 2.14.1), libgnt0
Provides: libgnt0 (= 2.14.4-1.2)
[...]
Thanks for considering the patch.
*** /tmp/tmpkfjro47y/libgnt_2.14.4-1.1ubuntu1.debdiff
diff -Nru libgnt-2.14.4/debian/control libgnt-2.14.4/debian/control
--- libgnt-2.14.4/debian/control 2024-03-08 06:22:50.0 +0100
+++ libgnt-2.14.4/debian/control 2024-03-15 09:59:05.0 +0100
@@ -1,6 +1,7 @@
libglib2.0-dev,
libglib2.0-doc,
libncurses-dev,
+ libxml2-dev,
meson,
Build-Depends-Indep: gtk-doc-tools,
Homepage: https://keep.imfreedom.org/libgnt/libgnt
@@ -18,10 +18,7 @@
Package: libgnt0t64
Provides: ${t64:Provides}
Architecture: any
-Depends: libglib2.0-0,
- libncursesw6,
- libxml2,
- ${misc:Depends},
+Depends: ${misc:Depends},
${shlibs:Depends},
Breaks: libgnt0 (<< ${source:Version}), finch (<< 2.14.1),
Replaces: libgnt0, finch (<< 2.14.1),
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1066081: ntpsec: ntpd reports error about missing /var/log/ntpsec
(Replying via mobile, so non-Debian address.) It should be reasonably possible to convert this to .d style. I will have to dig into this to fully consider all the implications, especially around handling upgrades. I think part of the issue here is that ntpd logs there by default. That is, you don’t turn on logging. I’m not sure if there is a way to turn off logging. But I have to check. I want to maintain the same posture we have now: - No logs by default. Most people don’t use them, so this is pointless I/O. - People can enable logs reasonably easily. - Installing ntpviz automatically enables logs. For upgrades, I can use the presence or absence of the directory for most of the handling. I do need to think through what happens / what to do if someone has customized any of the other log settings. -- Richard
Bug#1066081: ntpsec: ntpd reports error about missing /var/log/ntpsec
Control: reopen -1 On 2024-03-12 11:10, MOESSBAUER, Felix wrote: On Tue, 2024-03-12 at 10:33 -0500, Richard Laager wrote: This is intentional. The logging is optional and whether the directory exists controls this. Hi Richard, that's a quite uncommon interface. Is this at least documented somewhere? ntp.conf Also the "error" should be downgraded to a "warning" at least. Didn't I do that? commit b06f1d8177a9b0a2593947a2ebefcb43e94ac281 Author: Santiago Vila Date: Sun Dec 24 15:36:25 2023 -0600 Downgrade missing stats dir log severity The Debian package does not create /var/log/ntpsec by default. The admin is directed (by a comment in ntp.conf) to create it if and only if they want logging. However, upstream ntpsec logs an error message if the log directory does not exist. Closes: 1049424 Signed-off-by: Richard Laager [The commit message / patch description is my wording.] One advantage of that is the ntpsec-ntpviz package can create that directory to enable logging, which is required for ntpviz to be useful. Otherwise, it would have to edit the config file, which is riskier. Well... for that conf.d style configs are usually used. Yeah. ntpsec supports those _now_. (I don't know that it did at the time.) So maybe that's a better answer. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058451: ntpsec: FTBFS [Hurd] change Build-Depends: systemd to [linux-any]
I think, but am not sure, that this is now functionally a duplicate of #1060506. That one tells me to change it from systemd to systemd-dev because: Since systemd_253-2 [1], these two pkgconfig files have been split into a separate package named systemd-dev. This package is arch:all, so even available on non-Linux architectures, which will simplify the installation of upstream provided service files / udev rules. I have made that change. If that is NOT sufficient, please let me know and I'll adjust again. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064025: ntpsec does not sync to server if "iburst" is missing
I agree that the description, as provided, would be a bug. However, I cannot reproduce this. Can you provide your ntp.conf file, in full, please? -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065567: timedatectl does not recognize ntpsec
If I'm understanding this correctly, I just need to install a file with the contents "ntpsec.service" to /usr/lib/systemd/ntp-units.d/50-ntpsec.list. That's easy enough to do. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058451: ntpsec: FTBFS [Hurd] change Build-Depends: systemd to [linux-any]
On 2023-12-26 22:02, Martin-Éric Racine wrote: On Wed, Dec 27, 2023 at 5:54 AM Richard Laager wrote: On 2023-12-26 21:43, Martin-Éric Racine wrote: Looking at the diff for the Hurd port What Hurd port? https://deb.debian.org/debian-ports/pool-hurd-i386/main/n/ntp/ That is the wrong package (ntp vs ntpsec). That is not in any way relevant to this conversation. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058451: ntpsec: FTBFS [Hurd] change Build-Depends: systemd to [linux-any]
On 2023-12-26 21:43, Martin-Éric Racine wrote: Looking at the diff for the Hurd port What Hurd port? -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058451: ntpsec: FTBFS [Hurd] change Build-Depends: systemd to [linux-any]
On 2023-12-26 02:38, Martin-Éric Racine wrote:
On Mon, Dec 25, 2023 at 12:20 AM Richard Laager wrote:
If past me was correct, without systemd at build-time, waf will not
install the systemd units. Then we will end up with other failures in
debian/rules or from the .install files.
Not installing them on platforms where systemd has not been ported is
the correct action.
Agreed. My point was that additional work would be required, during the
package building process, to not blow up when those files are missing
from `waf install`.
It built enough to have ntpdate.
bin:ntpdate is just a transitional package to transition uses of the old
src:ntp's bin:ntpdate to src:ntpsec's bin:ntpsec-ntpdate. It is
Architecture: all, which is why it is available on Hurd.
In ntpsec, the ntpdate executable is just a thin wrapper around ntpdig,
which ships in the bin:ntpsec-ntpdig package (formerly, it was in
bin:ntpsec-ntpdate). While ntpdig is Python, so it doesn't actually
require compilation, it is presumably going to require some build steps
happen.
ifeq (hurd, $(DEB_HOST_ARCH_OS))
# hurd does not provided the system calls needed for ntpd to work.
exit 1
endif
I see a couple of ways forward here:
A) I properly indicate this package does not support HURD.
I think I would just replace the "Architecture: any" with
"Architecture: linux-any" on binary packages in debian/control, but
I would love confirmation on that.
Which is what this bug requested
I'm confused.
What you asked for was for me to limit "Build-Depends: systemd" to
[linux-any]. What I said here was that I'd limit all the built binary
packages to [linux-any], dropping any claims of support for HURD.
The rest of your email reads to me like you think this package should
support HURD to some degree. But here you are agreeing with the choice
that it should not support HURD _at all_.
I'm fine with dropping support for HURD entirely. I think that would be
more honest than the current state of affairs where the build just fails.
But if ntpdig is something that would be useful on HURD, I suppose it
would be nice if we could figure out how to make bin:ntpsec-ntpdig (and
some other packages) build for HURD.
If you are interested in HURD support, could you start with the attached
patch to ntpsec, try to build it, and see what happens?
--
Richard
diff --git a/debian/control b/debian/control
index a33a26ecb..2b1bc2a18 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@
python3,
python3-dev,
python3-gps,
- systemd,
+ systemd [linux-any],
xsltproc,
xz-utils,
Build-Conflicts: libavahi-compat-libdnssd-dev,
@@ -31,7 +31,7 @@
Homepage: https://www.ntpsec.org
Package: ntpsec
-Architecture: any
+Architecture: [linux-any]
Pre-Depends: ${misc:Pre-Depends},
Depends: adduser,
netbase,
diff --git a/debian/rules b/debian/rules
index dc23970f5..ff816974d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,10 +12,6 @@
dh $@ --with apache2,python3
override_dh_auto_configure:
-ifeq (hurd, $(DEB_HOST_ARCH_OS))
- # hurd does not provided the system calls needed for ntpd to work.
- exit 1
-endif
# Only build with refclocks NOT slated for removal. See also
# debian/patches/update-refclock-docs.patch. However, if the reason
# for deprecation is only "two digit years", I *am* keeping it.
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1058451: ntpsec: FTBFS [Hurd] change Build-Depends: systemd to [linux-any]
On 2023-12-12 04:52, Martin-Éric Racine wrote: Build-Depends: systemd must be changed to systemd [linux-any], since systemd has not been powerted to non-Linux platforms. I suspect that change would be necessary, but not sufficient. In commit 7f969a0ecab4ef3ab50defd4fe9d7e7a47817dbe, I wrote: Build-Depend on systemd This is required for the pkg-config file, so that waf will detect systemd and install the systemd units. If past me was correct, without systemd at build-time, waf will not install the systemd units. Then we will end up with other failures in debian/rules or from the .install files. HURD is the only non-Linux platform that Debian supports these days, right? kFreeBSD is gone, IIRC. The ntpsec package (like ntp before it, IIRC) does not build on HURD anyway. From debian/rules: ifeq (hurd, $(DEB_HOST_ARCH_OS)) # hurd does not provided the system calls needed for ntpd to work. exit 1 endif I see a couple of ways forward here: A) I properly indicate this package does not support HURD. I think I would just replace the "Architecture: any" with "Architecture: linux-any" on binary packages in debian/control, but I would love confirmation on that. B) Someone who cares about HURD figures out how much of this package can reasonably be expected to work and submits a patch. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058511: ntpsec: FTBFS: mv: cannot stat 'debian/tmp/lib/systemd/system/ntpd.service': No such file or directory
Control: fixed 1.2.2+dfsg1-3 This looks to be the same as #1052664. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058961: ntpsec: postinst should check for user:group before adding them
On 2023-12-18 16:15, Bob Proulx wrote: Package: ntpsec Version: 1.2.2+dfsg1-3 Severity: normal Tags: patch Every time the ntpsec package upgrades it attempts to unconditionally add the ntpsec user and group as per the following postinst snippet. addgroup --system --quiet ntpsec adduser --system --quiet --ingroup ntpsec \ --no-create-home --home /nonexistent ntpsec This logs errors because the user and group already exists. For the record, the "logs" here is critical. These errors show up in the logs, not on stdout. This is why I have never noticed this behavior until now (whether in ntpsec or just generally, having used adduser for years). Please test for the existence of those groups before creating them as other packages such as apt and others do. Adding the following "if" and "getent" checking fixes this using the same method the apt package and others do. if ! getent passwd ntpsec > /dev/null; then addgroup --system --quiet ntpsec fi if ! getent group ntpsec > /dev/null; then adduser --system --quiet --ingroup ntpsec \ --no-create-home --home /nonexistent ntpsec fi Those getent checks have passwd & group swapped, but otherwise, yes, that's what we want. I'll upload a fix shortly. Thanks! -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059273: missing path /var/lib/ntp/drift-tmp in apparmor.d/usr.sbin.ntpd
On 2023-12-22 05:32, Stefan Bauer wrote: Apparmor denies creation of /var/lib/ntp/drift-tmp. Where are you getting /var/lib/ntp/drift from? The ntpsec package in Debian has (from when both ntp and ntpsec existed in Debian) everything namespaced under "ntpsec". It uses /var/lib/ntpsec/ntp.drift in the default config file. Maybe you have something different set. What does "grep driftfile /etc/ntpsec/ntp.conf" say? -- Richard
Bug#1057570: libgnt: FTBFS: error: invalid use of incomplete typedef ‘PANEL’ {aka ‘struct panel’}
On 2023-12-20 09:57, Sven Joachim wrote: I have not tested it myself, but these errors should be fixed in libgnt 2.14.4 which has been released upstream the other day. See https://keep.imfreedom.org/libgnt/libgnt/rev/2da723f790d6, which explicitly mentions this bug. Thanks for letting me know! -- Richard
Bug#1057966: ntpsec-ntpdate not fully compatible with ntpdate, causes adjtimex --host breakage
From ntpdate (the wrapper): # Known bugs: # * The -e and -p options of ntpdate are not yet implemented. # * ntpdate took 4 samples and chose the best (shortest trip time). # This takes the first. I suppose there are maybe 4 options here: A) Do nothing. B) Change adjtimex to not pass -p. C) Change ntpdate to accept -p but ignore it. Currently, it gives an error message of "-p is no longer supported." as you saw. D) Have the wrapper repeatedly calling ntpdig and... then what? E) Actually implement support for this in ntpdig and pass the flag through. Obviously A is the null option, and we are looking for something better. I don't love C, as that silently eats an option rather than being explicit that it doesn't do anything. D is terrible, so I'm going to veto that one. I'm not personally interested in implementing E, but I don't see why I'd reject a patch if someone else was interested. Regarding B, it turns out that -p4 is being _added_ in adjtimex as a Debian patch: debian/patches/11-Fix-ntpdate-command.patch That references this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987625 That is for the ntp ntpdate, not ntpsec-ntpdate. @rosh, what do you think? Could you just remove 11-Fix-ntpdate-command.patch? That would fix adjtimex. -- Richard
Bug#1049424: ntpsec: Missing /var/log/ntpsec is logged as an error
On 2023-08-15 10:35, Santiago Vila wrote: Either a missing /var/log/ntpsec directory is considered a "supported configuration" or it's not. I agree with you on the general point. I'll process this bug in more detail when time allows, in the relatively near future. I currently expect the answer will be to accept the patch as written. Thanks for the bug report and patch. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1043145: Upgraded ntpsec to 1.2.2+dfsg1-1+deb12u1: fewer servers remain
The "pool" directive spins up more associations than it needs and then prunes them back (which takes a while). https://docs.ntpsec.org/latest/quick.html#pool https://docs.ntpsec.org/latest/discover.html#assoc With 4 pool servers each returning 4 A records and one of them returning 4 records, it seems to me you could end up with potentially 20 servers initially, which will then be pruned back to 7 (per tos maxclock*). * Note that tos maxclock is 11 in the Debian default, as pool entries themselves count. I personally think that's wrong, but changing it creates a compatibility concern. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1040355: ntpdate: obsolete conffiles
Fix pending as: https://salsa.debian.org/debian/ntpsec/-/commit/ed7cf69b3c7ec6cc21a604e47fbf6ee9a9966117 Feedback welcome! 1. I brought back some of the (manual) postrm bits for the ntp & ntpdate packages. This was something I should have preserved when making the transitional packages. ntpsec.service has ntp.service as an alias, so we do not mask ntp.service. I did not bring back the apparmor bits, as the apparmor profile still exists in the ntpsec package. I did not bring back the /etc/network/if-up.d/ntpdate removal in ntpdate, as that was conditionalized on 1:4.2.8p12+dfsg-2~, so that transition was completed in buster. 2. sntp needs to cleanup /var/lib/sntp because of /var/lib/sntp/kod. This seems to be a pre-existing bug in the ntp package. (Though, if it wasn't, I still would have missed it with everything else.) 3. The obsolete ntp & ntpdate conffiles need to be cleaned up. For most, this is accomplished by listing them in PACKAGE.conffiles with the "remove-on-upgrade" flag. 4. For /etc/default/ntp and /etc/ntp.conf, which are handled special in ntpsec.preinst, I'm not sure if the "remove-on-upgrade" functionality would even work; it seems like it would remove them too soon. The dpkg-maintscript-helper rm_conffile support seemed problematic too... If I run that in the ntpsec scripts (so I can get it to happen after the special handling), I don't think it would work, as it checks that the package in question owns the files, and in the ntp -> ntpsec case, it does not. If I run that in the ntp scripts, then it would run too early, so I'd need to make ntpsec.preinst look at some backup file. I'm not sure how much ordering is guaranteed between the ntp and ntpsec maintainer scripts, so I might have to look at both the .dpkg-backup and .dpkg-bak versions. It's also not clear to me whether I should care about the original name. Given that this already released in this state and I'm going to need a stable release update to fix this, it seems I should be conservative. Policy 10.7.3 says I "should" remove these during upgrade, not that I "must". Ultimately, I am leaving these two files alone during the upgrade and removing them on purge of the ntp transitional package. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1036443: ntpsec: leftover files on purge
Fix pending as: https://salsa.debian.org/debian/ntpsec/-/commit/ed7cf69b3c7ec6cc21a604e47fbf6ee9a9966117 Feedback welcome! 1. I brought back some of the (manual) postrm bits for the ntp & ntpdate packages. This was something I should have preserved when making the transitional packages. ntpsec.service has ntp.service as an alias, so we do not mask ntp.service. I did not bring back the apparmor bits, as the apparmor profile still exists in the ntpsec package. I did not bring back the /etc/network/if-up.d/ntpdate removal in ntpdate, as that was conditionalized on 1:4.2.8p12+dfsg-2~, so that transition was completed in buster. 2. sntp needs to cleanup /var/lib/sntp because of /var/lib/sntp/kod. This seems to be a pre-existing bug in the ntp package. (Though, if it wasn't, I still would have missed it with everything else.) 3. The obsolete ntp & ntpdate conffiles need to be cleaned up. For most, this is accomplished by listing them in PACKAGE.conffiles with the "remove-on-upgrade" flag. 4. For /etc/default/ntp and /etc/ntp.conf, which are handled special in ntpsec.preinst, I'm not sure if the "remove-on-upgrade" functionality would even work; it seems like it would remove them too soon. The dpkg-maintscript-helper rm_conffile support seemed problematic too... If I run that in the ntpsec scripts (so I can get it to happen after the special handling), I don't think it would work, as it checks that the package in question owns the files, and in the ntp -> ntpsec case, it does not. If I run that in the ntp scripts, then it would run too early, so I'd need to make ntpsec.preinst look at some backup file. I'm not sure how much ordering is guaranteed between the ntp and ntpsec maintainer scripts, so I might have to look at both the .dpkg-backup and .dpkg-bak versions. It's also not clear to me whether I should care about the original name. Given that this already released in this state and I'm going to need a stable release update to fix this, it seems I should be conservative. Policy 10.7.3 says I "should" remove these during upgrade, not that I "must". Ultimately, I am leaving these two files alone during the upgrade and removing them on purge of the ntp transitional package. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1040354: ntp: obsolete conffiles
Fix pending as: https://salsa.debian.org/debian/ntpsec/-/commit/ed7cf69b3c7ec6cc21a604e47fbf6ee9a9966117 Feedback welcome! 1. I brought back some of the (manual) postrm bits for the ntp & ntpdate packages. This was something I should have preserved when making the transitional packages. ntpsec.service has ntp.service as an alias, so we do not mask ntp.service. I did not bring back the apparmor bits, as the apparmor profile still exists in the ntpsec package. I did not bring back the /etc/network/if-up.d/ntpdate removal in ntpdate, as that was conditionalized on 1:4.2.8p12+dfsg-2~, so that transition was completed in buster. 2. sntp needs to cleanup /var/lib/sntp because of /var/lib/sntp/kod. This seems to be a pre-existing bug in the ntp package. (Though, if it wasn't, I still would have missed it with everything else.) 3. The obsolete ntp & ntpdate conffiles need to be cleaned up. For most, this is accomplished by listing them in PACKAGE.conffiles with the "remove-on-upgrade" flag. 4. For /etc/default/ntp and /etc/ntp.conf, which are handled special in ntpsec.preinst, I'm not sure if the "remove-on-upgrade" functionality would even work; it seems like it would remove them too soon. The dpkg-maintscript-helper rm_conffile support seemed problematic too... If I run that in the ntpsec scripts (so I can get it to happen after the special handling), I don't think it would work, as it checks that the package in question owns the files, and in the ntp -> ntpsec case, it does not. If I run that in the ntp scripts, then it would run too early, so I'd need to make ntpsec.preinst look at some backup file. I'm not sure how much ordering is guaranteed between the ntp and ntpsec maintainer scripts, so I might have to look at both the .dpkg-backup and .dpkg-bak versions. It's also not clear to me whether I should care about the original name. Given that this already released in this state and I'm going to need a stable release update to fix this, it seems I should be conservative. Policy 10.7.3 says I "should" remove these during upgrade, not that I "must". Ultimately, I am leaving these two files alone during the upgrade and removing them on purge of the ntp transitional package. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]
Is this reproducible for you? If you have experience with building from source, upstream has proposed the following patch. Otherwise, I could build a test package for you. diff --git a/ntpd/nts_cookie.c b/ntpd/nts_cookie.c index 166d0230f..a73955fb7 100644 --- a/ntpd/nts_cookie.c +++ b/ntpd/nts_cookie.c @@ -382,6 +382,9 @@ bool nts_unpack_cookie(uint8_t cookie, int cookielen, if (NULL == cookie_ctx) return false; /* We aren't initialized yet. */ + + if (0 == nts_nKeys) + return false; /* No cookies. We are not an NTS server. */ /* We may get garbage from the net */ if (cookielen > NTS_MAX_COOKIELEN) return false; -- Richard
Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]
Some questions from upstream, with my commentary added... How busy is this sustem? Is it just a simple client or also a server? If server, how busy? From the stack trace, the server side is trying to decode a NTS cookie. Is this box setup as a NTS server? That needs a certificate and key so it takes more than just upgrading from bullseye to bookworm. It's not, right? We previously established that this is using the stock ntp.conf? What are the chances that a valid NTP request with NTS arrived at this system? ntpq -c ntsinfo will show counters. It would be good if you could check this. But if an NTS request is crashing ntpd, you might never see non-zero counters. The log file from starting up might be helpful. -- Richard
Bug#1038876: ntpq: missing empty lines between command outputs
I forwarded this upstream. I'm not sure how much upstream will care. But hopefully I can get a firm answer either way. -- Richard
Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]
On 2023-06-28 20:14, forest.ow...@riseup.net wrote: On 2023-06-28 02:39, Richard Laager wrote: The original submitter replied off the tracker (probably by accident). I'll summarize here. The ntp.conf he included is the stock ntp.conf. He indicated he will try to get a backtrace. I'm trying to setup ntpsec to get a backtrace. I installed the ntpsec-dbgsym package, but I'm not sure that I did it correctly. Shouldn't the output from this file command include the text "no stripped". I don't think it should change that. I think the debug symbols end up somewhere else. -- Richard
Bug#1036113: libpurple0: license conflict with libsasl2
On 2023-06-27 17:35, Bastian Germann wrote: Am 28.06.23 um 00:13 schrieb Richard Laager: The last bugfix release took them more than 3 years and when #767 is released is unknown. When a release happens is irrelevant, as you can carry #767 as a patch in the Debian package until then. Even when that happens, upstream still has to eliminate the last instance of the RSA-MD license. What is the remaining instance of RSA-MD licensed code after #767? License compliance will not just magically happen by ignoring the problematic parts in Debian. I didn't suggest it would, nor am I ignoring anything. My point is that, in this particular case, it seems that you have everything solved or close to solved by yourself. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]
The original submitter replied off the tracker (probably by accident). I'll summarize here. The ntp.conf he included is the stock ntp.conf. He indicated he will try to get a backtrace. -- Richard
Bug#1036113: libpurple0: license conflict with libsasl2
Wait a minute... You are a maintainer for cyrus-sasl. You have already addressed the BSD-4-clause-KTH in the latest upload. You also fixed debian/copyright to reference BSD-3-Clause-Attribution in the latest upload. That license is fine for the reasons I mentioned. That just leaves the MD5 stuff, right? You have authored a fix for that, which it looks like will be merged shortly: https://github.com/cyrusimap/cyrus-sasl/pull/767 It seems like you can have this fixed any time (by merging in upstream #767) and will have it fixed shortly. So why do I need to do anything? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#996892: cyrus-sasl2: consider handling as system library
On 2023-06-27 16:19, Richard Laager wrote: For BSD-3-Clause-Attribution BTW, my suggestion of asking CMU to drop the clause should not be read as taking or agreeing to the position that it is GPL-incompatible. I don't actually see an incompatibility with BSD-3-Clause-Attribution. The original BSD license, which the FSF says is GPL-incompatible, said: All advertising materials mentioning features or use of this software must display the following acknowledgement: ... BSD-3-Clause-Attribution is different: Redistributions of any form whatsoever must retain the following acknowledgment: ... The "bad" clause requires you to put something in "advertising materials". The actual effect of BSD-3-Clause-Attribution is that you need to retain the license grant block itself, which is already required by the 1st (for source) and 2nd (for binaries) clauses anyway, is always done by Debian, and is fine. There is no practical difference between retaining (or being forced to retain) the following in a license block: "This product includes software developed by ." vs "Copyright " They mean literally the same thing! -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1036113: libpurple0: license conflict with libsasl2
Bastian, I see you have raised the severity on this bug again. What is your goal here? Cyrus SASL has reverse (binary) dependencies in the ballpark of 7,500. Quickly taking that list through UDD gives me just over 4,500 source packages. Surely, a large number of those are going to be GPL licensed. Is your plan to file Severity: serious bugs against all of them? If so, isn't that an MBF that needs discussion on debian-devel first? If not, then why are you singling out Pidgin, a project that is struggling to stay alive right now? Your position in bug #996892 is that cyrus-sasl2 / libsasl2 should be considered a system library. If libsasl2 can be considered a system library, then by your own position, there is no bug in libpurple0. I don't see how you can have it both ways. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#996892: cyrus-sasl2: consider handling as system library
On 2023-06-27 16:19, Richard Laager wrote: For RSA-MD, I'd imagine there are other MD5 implementations that could be dropped in relatively easily. Also, Bastian Germann mentioned in bug #1036113: "See https://github.com/cyrusimap/cyrus-sasl/issues/513 for an implementation that leaves only one RSA-MD licensed file." -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#996892: cyrus-sasl2: consider handling as system library
On Thu, 13 Apr 2023 14:36:12 +0200 Bastian Germann wrote: Hi Philipp, Thanks for clarifying that. There is one file in cyrus-sasl2 that is licensed under BSD-4-clause-KTH (which really has an advertisement clause), which we can get rid of; see https://github.com/cyrusimap/cyrus-sasl/pull/724. The OpenSSL license can be eliminated by repackaging. This leaves us with the two supposedly GPL-incompatible licenses BSD-3-Clause-Attribution and RSA-MD. For RSA-MD, I'd imagine there are other MD5 implementations that could be dropped in relatively easily. For BSD-3-Clause-Attribution, as anyone reached out to CMU (e.g. at tech-trans...@andrew.cmu.edu) to ask them to remove clause 3, like the University of California, Berkeley did in 1999: https://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_(%22BSD_License_2.0%22,_%22Revised_BSD_License%22,_%22New_BSD_License%22,_or_%22Modified_BSD_License%22) https://www.freebsd.org/copyright/license/ -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]
I'm not sure if you saw this, as he didn't send it directly to you, but Matt Selsky asked: > Can you please share your ntp.conf or if there's a particular server > that seems to cause this segfault so that we can try to reproduce it? Also, can you get a stack trace? There are some instructions in the Debian wiki: https://wiki.debian.org/HowToGetABacktrace -- Richard
Bug#1036821: NTP does not keep accurate time on bookworm
I've made a suggestion upstream of how we could do better here by making this either a fatal error or at least a warning. If it was a fatal error with a good error message, you would have figured it out immediately. Let's see what people think of that. -- Richard
Bug#1036821: Acknowledgement (NTP does not keep accurate time on bookworm)
On 2023-06-07 03:22, Rob Janssen wrote: On 6/7/23 10:13, Richard Laager wrote: On 2023-06-07 02:37, Rob Janssen wrote: Yes I was using the "ntp" package before. I have upgraded and it installed "ntpsec". I tried to remove it as I have no need for the "security" part but it removed "ntp" as well. And then you presumably reinstalled it. Did this result in you starting over with a default ntp.conf, where you then manually removed (or commented out) the pool lines and added your server lines? No, then I removed everything and installed chrony. I thought the sequences of events was this: 0. You are running ntp on bullseye. 1. You upgrade to bookworm. This results in ntpsec being installed. 2. You removed ntpsec. 3. [The part I was asking about.] You reinstalled ntpsec. 4. You found that ntpd was not syncing the clock. 5. You switched to chrony. Was it this instead? 0. You are running ntp on bullseye. 1. You upgrade to bookworm. This results in ntpsec being installed. 2. You found that ntpd was not syncing the clock. 3. You removed ntpsec. 4. You switched to chrony. I'm trying to understand what happened with your ntp.conf. Upgrading from ntp to ntpsec should result in your existing /etc/ntp.conf being copied to /etc/ntpsec/ntp.conf by ntpsec.preinst. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1036821: Acknowledgement (NTP does not keep accurate time on bookworm)
On 2023-06-07 02:37, Rob Janssen wrote: Yes I was using the "ntp" package before. I have upgraded and it installed "ntpsec". I tried to remove it as I have no need for the "security" part but it removed "ntp" as well. And then you presumably reinstalled it. Did this result in you starting over with a default ntp.conf, where you then manually removed (or commented out) the pool lines and added your server lines? Please don't fall in the common trap of trying to make everything "top secure" and then making it unusable or causing problems for people that do not require that. NTPsec is a fork of NTP. Most of the security benefit of NTPsec comes from NTPsec simply removing and cleaning up decades of code cruft in NTP. NTPsec is a drop-in replacement for NTP. > It looks like "ntp" is only a dummy package. In Debian, NTPsec was packaged alongside NTP for some time. This release cycle, the Debian ntp maintainer suggested it was time to retire ntp, and the consensus was to do so and migrate existing ntp installs to ntpsec: https://lists.debian.org/debian-devel/2022/01/msg00172.html > Probably you should put that > config line commented in the default config so people who like it can > easily enable it. This configuration exists for correctness. If a given system has two time sources and they disagree, which one is correct? There is no way to be sure. If you have three sources, then you take whichever two agree. "A man with a watch knows what time it is. A man with two watches is never sure." https://en.wikipedia.org/wiki/Segal%27s_law If you're only running your own servers, then the best practice is to run 3 (or more) servers. (Some sources say 4, so if one server is down, you can still detect a falseticker.) And I say that as someone who runs two. But my clients use my two servers plus the pool. https://access.redhat.com/solutions/58025 https://www.tenable.com/audits/items/CIS_Cisco_NX-OS-v1.0.0_Level_2.audit:6a5be86b59dc9342bd22dfc2b7c70cb4 https://insights.sei.cmu.edu/blog/best-practices-for-ntp-services/ https://labs.ripe.net/author/christer-weinigel/best-practices-for-connecting-to-ntp-servers/ -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1036821: Acknowledgement (NTP does not keep accurate time on bookworm)
The answer is so obvious as soon as someone said it! The default "minsane" is "3" (see "tos minclock 4 minsane 3" in /etc/ntpsec/ntp.conf). Try commenting out that line, or if that doesn't work, set both to "1". -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1036821: Acknowledgement (NTP does not keep accurate time on bookworm)
Since you've moved to chrony, this is probably moot for you. But in case it affects anyone else, I forwarded this upstream: https://gitlab.com/NTPsec/ntpsec/-/issues/790 Can you confirm you were running the "ntp" package on bullseye, not "ntpsec"? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1036443: ntpsec: leftover files on purge
At first glance, I agree that these should be cleaned up. I just need to actually do the work on this, ASAP, of course. On 2023-05-22 08:40, Christoph Anton Mitterer wrote: Oh and I've just noticed that I've had accidentally reported the bug against ntpsec, not ntp. That is correct, I believe. The ntpsec source package has taken over the ntp binary packages. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1036113: libpurple0: license conflict with libsasl2
First, I've downgraded the severity on this to "important". We are currently in a freeze with a release imminent. Removing pidgin from the next Debian release is a significant step that we should not undertake lightly. The issue at hand has existed for years, possibly a decade or even two, without complaints, so I think we can afford some time here. Second, looking at #996892, Philipp Hahn already made some points about what is and isn't an advertising clause. There is no "BSD-3-Clause-Attribution" license in the copyright file that I can see. Please identify specifically which license(s) you are talking about, using names as they appear in the copyright file for the cyrus-sasl2 package. Third, if a system-library exemption is reasonable (or even possible), then there isn't actually an incompatibility in the first place. On 2023-05-15 12:32, Bastian Germann wrote: Package: libpurple0 Version: 2.14.12-1 Severity: serious Hi, libirc.so and libjabber.so.0.0.0 depend on libsasl2-2, which is licensed under CMU's BSD-3-Clause-Attribution license and covered by the RSA-MD license. They have clauses in place, which are known to be incompatible with GPL-2+ (as far as I can see the mentioned libraries' license). There are several possible solutions to this problem: 1) Build with --disable-cyrus-sasl configuration and get rid of the libsasl2 (Build-)Dependencies. Then users lose SASL support, which is not great. 2) Support my request at #996892. If we are going to treat OpenSSL as a system library, then I think cyrus-sasl is a reasonable contender for the same treatment. 3) Ask upstream to add a license exception for libsasl2-2, similar to the one that was required by Debian for OpenSSL for a long time. 3 is not viable due to too many copyright holders. 4) Pidgin could switch SASL implementations. This will be happening for Pidgin 3 anyway. Are the problems just limited to MD5? If so: 5) Replace the MD5 implementation in Cyrus SASL with a different one. 6) Cyrus SASL uses OpenSSL for MD5 instead of its built-in MD5 code. 7) Cyrus SASL just drops MD5. (That might actually be reasonable post-bookworm.) -- Richard
Bug#1033088: ntpsec: mssntp in ntp.conf breaks time service to all clients
On 4/29/23 21:54, Steven Monai wrote:
I downloaded and unpacked this source on a Bookworm host. The build
system bundled with the source ("waf") seems to assume python 2.x, but,
unfortunately, Bookworm provides only python3. Any hints?
Quick approach is try this:
python3 waf configure ...
python3 waf build
A longer, but possibly better, approach might be something like:
git clone g...@salsa.debian.org:debian/ntpsec.git
cd ntpsec
git checkout debian/1.1.3+dfsg1-1
debuild -uc -us
An intermediate approach might be to test with the binary package from
buster. You can get download links here, by architecture, plus there are
links to related packages, some of which (like python3-ntp) you might need:
https://packages.debian.org/buster/ntpsec
Hopefully this will turn out to be something broken during code
cleanups/refactorings in NTPsec that you can bisect (at least somewhat).
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1033088: ntpsec: mssntp in ntp.conf breaks time service to all clients
forwarded 1033088 https://gitlab.com/NTPsec/ntpsec/-/issues/785 thanks Sorry for the delay in responding. I had hoped to try to reproduce this myself. But I need to be honest with myself that it's simply not going to happen. Can you confirm whether you get either of these messages to stderr on startup: A) MS-SNTP signd operations currently block ntpd degrading service to all clients. B) mssntp restrict bit ignored, this ntpd was configured without --enable-mssntp. I would expect "A". If you are getting "B", that is bad (and makes no sense, as the Debian ntpsec package is built with --enable-mssntp). Is there any chance you could test with ntpsec 1.1.3? You'd have to build from source (and note that upstream stores the config file in /etc/ntp, not /etc/ntpsec). It is available here: https://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz If ntpsec 1.1.3 works and 1.1.4 does not, then I'm wondering if commit ee7677d0cff27c9e208cc3716db41f51bf29c1fb would be to blame. That said, I don't see anything wrong with that change. It's just that there aren't many other changes to mssntp code in ntpsec. Other than that, I don't have any ideas. I've forwarded the bug upstream. You can see the URL in the control commands at the top of this message. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1020865: ntpsec-ntpdate: ntpdate-debian doesn't work due to missing dependency
On 9/27/22 14:00, Dima Kogan wrote:
root@shorty:/home/dima# ntpdate-debian
sed: can't read /etc/ntpsec/ntp.conf: No such file or directory
Yep, I see the issue. I'll upload a fix.
The missing file is in the "ntpsec" package, which is not in the
Depends, and maybe should be there. If I install this package I see
this:
root@shorty:/home/dima# ntpdate-debian
ntpdig: socket error on transmission: [Errno 99] Cannot assign requested
address
ntpdig: socket error on transmission: [Errno 99] Cannot assign requested
address
ntpdig: socket error on transmission: [Errno 99] Cannot assign requested
address
ntpdig: socket error on transmission: [Errno 99] Cannot assign requested
address
{"time":"2022-09-27T11:54:36.227571-0700","offset":-0.001772,"precision":0.073811,"host":"0.debian.pool.ntp.org","ip":"79.133.44.139","stratum":1,"leap":"no-leap","adjusted":false}
This is probably the ipv6 bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971523
The console output doesn't tell me if the errors were fatal or not. Were
they actually warnings? It should tell me.
These are not fatal. I've submitted a patch upstream to suppress those
messages except in debug mode, since they are clearly confusing:
https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1288
Debian bug #971523 probably should have been marked fixed already once
the upstream change to make them non-fatal was uploaded to Debian. But
given I'm submitting another patch, I'll leave it open.
If you have further commentary on this part, let's discuss in 971523.
Also, the output is qualitatively different from what it used to be not
very long ago. It used to be human-readable text
...
Now it's JSON
Yeah, I'll disable that JSON.
--
Richard
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Bug#971523: ntpsec-ntpdate: ntpdate fail if DNS name for server resolve to IPv6
I've submitted a patch upstream to suppress those messages except in debug mode, since they are clearly confusing: https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1288 This bug probably should have been marked fixed already once the upstream change to make them non-fatal was uploaded to Debian. But given I'm submitting another patch, I'll leave it open. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1013867: Don't use user ntpsec if package ntp is installed
On 6/26/22 02:18, Klaus Ethgen wrote: When package ntp is installed (from long history), the ntp daemon is started by this /etc/init.d/ntp which uses user ntp:ntp. So all auxiliary directories and files are owned by ntp:ntp. I agree this is the expected "before" state. When ntpsec starts to start the same daemon with ntpsec:ntpsec (which is counter expected) the ntp daemon is not running properly and more over, it is creating/changing some file rights so neither daemon is running properly afterwards. The expected transition behavior is: - /etc/default/ntp is copied to /etc/default/ntpsec if and only if it was modified. - /etc/ntp.conf is copied to /etc/ntpsec/ntp.conf, with ntp.drift and ntpstats paths updated. - /etc/init.d/ntp should be renamed too, though that uses dpkg-maintscript-helper mv_conffile, which means I might be missing something (vs custom code that I can easily see what it is doing). Also, I can't recall if I've even tested this. Debian's default is systemd. You'll have to be more specific about what's broken. A reproducible test case would be ideal. If the problem is specific to sysvinit, your best bet is to submit a patch (to the ntpsec package). Even better would be to drop that ntpsec:ntpsec user fully and use ntp:ntp as this would be the expected user a ntp is running under. And please, don't conflict for ntp package as usually ntp is managed by configuration management which is depending on ntp init script named ntp. Nobody would expect init script ntpsec! The ntpsec package uses "ntpsec" all over the place because that was the decision made at the time that it was introduced to Debian, when both packages existed. I actually tried to use /etc/init.d/ntp for ntpsec. That turns out to not work, even in some cases contrary to documented behavior. Ultimately, other developers said that was a bad idea, and said I should namespace things separately. So that's what I did, for better and worse (and yes, it's some of each). Even if the long term plan were to eliminate the "ntpsec" namespacing (e.g. match upstream ntpsec more closely)*, I don't think it's a good idea to attempt that now. That increases the number of transitions. * I'm not even sure that we have a consensus that it is a good idea to do this rename at all, at least while the upstream "ntp" project still exists. -- -- Richard
Bug#1012600: [Pkg-zfsonlinux-devel] Bug#1012600:
I think this is because it Depends: a kernel << 5.18 and not Conflicts/Breaks a kernel >= 5.18. Since you can install multiple kernel packages, your existing kernel package is satisfying the dependency. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1012699: ntpleapfetch broken
[Responding on mobile.] I’ll take a look at it, as obviously it should be made to work. But on Debian, there shouldn’t be a need for ntpleapfetch, as the tzdata package ships the leap second file. -- Richard > On Jun 11, 2022, at 22:33, Martin Maney wrote: > > > Correction: does not apply to ntp package. I seem to have looked for > it on the wrong machine (one that was in fact using ntpsec). > > And apologies for the link munging - I've been forced to route through > sendgrid ever since the connection here was upgraded to fiber, and > despite repeated claims to the contrary, it does block outbound SMTP. > The fix is in commit a0e5e050dfbdb672459f74bf52562bc8fc50c3b9 in > ntpsec's github repo. > > -- > The only non-renewable resource you truly have > is your time. -- Clay Johnson
Bug#1011526: pidgin: fails to start on sway
On 5/25/22 02:05, Samtinel wrote: Are other GTK apps working? Yes, dino-im starts successfully. GTK 2 Uh, this I did not check. I will do that when I get to my terminal later. So you happen to know a simple GTK 2 package I can test on? I don't. So much stuff has moved to GTK 3 (or now GTK 4), of course. -- Richard
Bug#1011526: pidgin: fails to start on sway
I really don't know. Are other GTK apps working? If so, GTK 2 apps specifically? -- Richard
Bug#1011166: [Debian-on-mobile-maintainers] Bug#1011166: Bug#1011166: pidgin breaks chatty autopkgtest: error while loading shared libraries: libjabber.so.0
On 5/20/22 01:56, Evangelos Ribeiro Tzaras wrote: Hi, On Thu, 2022-05-19 at 22:23 -0500, Richard Laager wrote: On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote: Thanks for the patch! I'll upload a fixed version soon. If you upload a new version, you (or I) can then close the binNMU request, bug #1011201. I have prepared an update on salsa [0]. I was wondering one thing though: The packaging used to have override dh_shlibdeps: dh_shlibdeps -l/usr/lib/purple-2 which I stripped, because a) the path is now wrong b) it doesn't seem to get used at all, judging by compairing packages built with an updated path and without the override Since I'm not 100% sure if this was ever actually needed, I was curious if you could potentially shed some light ;) No idea. Judging from the description in the man page, it's probably not necessary. And your testing seemingly confirms that. I think you're right to strip it. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1011166: [Debian-on-mobile-maintainers] Bug#1011166: pidgin breaks chatty autopkgtest: error while loading shared libraries: libjabber.so.0
On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote: Thanks for the patch! I'll upload a fixed version soon. If you upload a new version, you (or I) can then close the binNMU request, bug #1011201. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1011166: pidgin breaks chatty autopkgtest: error while loading shared libraries: libjabber.so.0
Control: notfound 1011166 pidgin/2.14.9-2
Control: tags 1011166 patch
On 5/17/22 15:34, Paul Gevers wrote:
I note that
the library moved location from /usr/lib/purple-2/libjabber.so.0.0.0 to
/usr/lib/x86_64-linux-gnu/purple-2/libjabber.so.0.0.0.
I converted from an ancient compat version to modern debhelper. This
brought in multiarch support. Rather than fight it, I just went with
that, since the problem looked tractable.
Naively I would
have expected it to be picked up, but maybe the /purple-2 in the middle
of the path is preventing that.
-- BEGIN RED HERRING --
I would expect it to be picked up.
libpurple/plugin.c sets up the search path for that purple-2 directory
(which is where all libpurple plugins are installed):
purple_plugins_add_search_path(LIBDIR);
In libpurple/Makefile.am, AM_CPPFLAGS has:
-DLIBDIR=\"$(libdir)/purple-$(PURPLE_MAJOR_VERSION)/\"
This should cause us to find libxmpp.so, the protocol plugin. It then
needs to bring in libjabber.so, an internal library. It should be
finding this with RUNPATH, I believe:
$ readelf -a /usr/lib/x86_64-linux-gnu/purple-2/libxmpp.so | grep -i path
0x001d (RUNPATH)Library runpath:
[/usr/lib/x86_64-linux-gnu/purple-2]
If I run: LD_DEBUG=libs pidgin -n
That is indeed what happens:
43864: find library=libjabber.so.0 [0]; searching
43864: search
path=/usr/lib/x86_64-linux-gnu/purple-2/glibc-hwcaps/x86-64-v3:/usr/lib/x86_64-linux-gnu/purple-2/glibc-hwcaps/x86-64-v2:/usr/lib/x86_64-linux-gnu/purple-2/tls/haswell/x86_64:/usr/lib/x86_64-linux-gnu/purple-2/tls/haswell:/usr/lib/x86_64-linux-gnu/purple-2/tls/x86_64:/usr/lib/x86_64-linux-gnu/purple-2/tls:/usr/lib/x86_64-linux-gnu/purple-2/haswell/x86_64:/usr/lib/x86_64-linux-gnu/purple-2/haswell:/usr/lib/x86_64-linux-gnu/purple-2/x86_64:/usr/lib/x86_64-linux-gnu/purple-2
(RUNPATH from file
/usr/lib/x86_64-linux-gnu/purple-2/libxmpp.so)
If I run: LD_DEBUG=libs chatty
It fails:
43926: find library=libjabber.so.0 [0]; searching
43926: search path=/usr/lib/purple-2 (RUNPATH from file
chatty)
43926: trying file=/usr/lib/purple-2/libjabber.so.0
43926: search cache=/etc/ld.so.cache
43926: search
path=/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v3:/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2:/lib/x86_64-linux-gnu/tls/haswell/x86_64:/lib/x86_64-linux-gnu/tls/haswell:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/haswell/x86_64:/lib/x86_64-linux-gnu/haswell:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v3:/usr/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2:/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64:/usr/lib/x86_64-linux-gnu/tls/haswell:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/haswell/x86_64:/usr/lib/x86_64-linux-gnu/haswell:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/glibc-hwcaps/x86-64-v3:/lib/glibc-hwcaps/x86-64-v2:/lib/tls/haswell/x86_64:/lib/tls/haswell:/lib/tls/x86_64:/lib/tls:/lib/haswell/x86_64:/lib/haswell:/lib/x86_64:/lib:/usr/lib/glibc-hwcaps/x86-64-v3:/usr/lib/glibc-hwcaps/x86-64-v2:/usr/lib/tls/haswell/x86_64:/usr/lib/tls/haswell:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/haswell/x86_64:/usr/lib/haswell:/usr/lib/x86_64:/usr/lib
(system search path)
At first glance, it felt like the RUNPATH from chatty was winning over
that from libxmpp.so.
-- END RED HERRING --
Upon further investigation, the real issue is that chatty is directly
linking to libjabber.so, and they're setting a RUNPATH to do it.
chatty's src/meson.build has:
executable('chatty', chatty_sources, resources,
include_directories: src_inc,
dependencies: chatty_deps,
link_with: libchatty.get_static_lib(),
install: true,
install_rpath: purple_plugdir,
)
Note the install_rpath.
and src/purple/meson.build has (manual wrapping added for email):
purple_plugdir = purple_dep.get_pkgconfig_variable('plugindir')
jabber = meson.get_compiler('c').find_library(
'jabber', dirs: purple_plugdir)
In terms of "Who is at fault?", I blame chatty for explicitly linking to
an internal library. However, in fairness, I understand that they have
their reasons and a better solution was never found with upstream (at
least in part because no significant changes are going to go into purple
2 at this point):
https://source.puri.sm/Librem5/chatty/-/issues/266
The good news here is that a rebuild of chatty is all that's necessary.
A binNMU should be sufficient to fix the bug. I've submitted a request
for one, but this was my first time, so I might have done something wrong.
To fix it fully correctly, though, I think we want a versioned
Build-Depends to ensure it cannot be built against an old libpurple0
(not that such a thing should happen). And a lintian override needs
updating. Here is a MR for that:
Bug#1011201: nmu: chatty_0.6.3-1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: normal chatty directly links against an internal library (libjabber.so.0) in libpurple0. This is technically wrong, but at the moment, it is what it is. I converted libpurple0 to multiarch, which caused libjabber.so.0 to move from /usr/lib/purple-2/ to /usr/lib//purple-2. As a result, chatty will not run; see bug #1011166. A no-change rebuild of chatty fixes this. I think a binNMU is thus the appropriate action, but this is my first time with one. Please rebuild chatty against libpurple0 2.14.9-2 so chatty gains an appropriate runpath. nmu chatty_0.6.3-1 . ANY -m 'Rebuild against libpurple0 2.14.9-2 to correct runpath' -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1006350: pidgin: crashes when typing past visible number of lines
This has hopefully been fully fixed now (upstream). It will land in the 2.14.9 release, which should be coming next week. However, I've uploaded a backport of it now. -- Richard
Bug#1001610: Gbonds
On 1/31/22 19:37, Trey Glover wrote: I had no idea that the treasury was doing this. Is there a code fix in place yet? In unstable, yes; it's fixed in 2.0.3-17. I wrote code to use the Treasury API to generate old-style sbMM.asc files which are stored (as always) in ~/.gbonds/ In stable, no; see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002563 -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1004709: update-ieee-data URLs need updating
Package: ieee-data Version: 20210605.1 I ran into this on 20180805.1 on Ubuntu 20.04, but I verified that the same URLs are present in Debian's 20210605.1. update-ieee-data references URLs (see the files_to_get variable near the top) which which no longer work. For example, this 404s: https://standards.ieee.org/develop/regauth/oui/oui.txt I found Ubuntu's bug on this: https://bugs.launchpad.net/ubuntu/+source/ieee-data/+bug/1796047 That suggests this URL, which works (note http only; https hangs): http://standards-oui.ieee.org/oui/oui.txt -- Richard
Bug#1003956: ntpsec: security settings
On 1/25/22 17:08, Christoph Anton Mitterer wrote: On Tue, 2022-01-25 at 16:34 -0600, Richard Laager wrote: Consider a powerful attacker who a) runs a clocksource one trusts and b) can block traffic to any other sources in the pool one uses? Does NTP(sec) complain eventually (like too many sources not answering, something is fishy)... or would it just happily continue with the one (then evil) source? With the Debian-default of "tos minsane 3", it's not going to follow a single source, period. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1003956: ntpsec: security settings
On 1/25/22 10:45, Christoph Anton Mitterer wrote: On Tue, 2022-01-25 at 00:54 -0600, Richard Laager wrote: There are two potential issues: A) the server serves bogus/malicious time B) a MITM messes with the time. (A) is kinda what I'd want to prevent by having -g removed... at least it shouldn't be "so easy" anymore for a rogue server (NTS or not) to quickly change the time by amounts that really matter. The primary protection for A is consensus (see specifically minsane). A single bogus/malicious clock can't do anything. At least not quickly... AFAIU it should still be able to slowly change my time, over time. I don't see how that's possible. Eventually that single server will tick too far outside of the consensus window and be excluded as a falseticker. To give you a real example of this... At $DAYJOB a week ago, one of my NTP servers has a PPS input from a telecom GPS clock. This clock failed; specifically it started outputting bad time (ticking at the wrong rate, as opposed to stopping outputting time entirely). ntpd followed this for a bit, making it look like the other sources all went insane simultaneously. After a few minutes (of elapsed time, not of time drift!), the error was bad enough that ntpd realized the PPS was insane, stopped following it, and followed the consensus of the other sources back to sanity. And this was with the PPS source marked "prefer". I'm not sure if anyone kept the graphs, but the error was us or ms, not even seconds, much less your example of 3 minutes. With -g, and even despite NTS, they could send me malicious time, every time I boot (or (re)start the service manually). Yes, they could. And someone (USNO, I think) had a bug a couple years ago where they did serve bad time. But if you have multiple sources, as you should, then you have protection against this. For example, I get my time from 8 sources, two with old style authentication and 1 with NTS. So even on boot, even with -g, a single source can't cause one to accept bad time. The default configuration uses the pool, so there too, a single source cannot cause one to accept bad time at boot even with -g. Back to scenario B, the network MITM: Now, given NTS's current limited deployment, I have limited protections against a network MITM. Only 3 of my 8 sources have any protection at all, so a MITM could change the other 5 and I'd follow that. My choices are: reduce the number of non-authenticated sources, raise minsane, and/or run without -g (which only matters at boot). In the default configuration, a MITM could slowly change your clock over time by changing all of the times you see. But -g or no -g is irrelevant to that. The _only_ real answer to the MITM is NTS. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1003966: ntpsec: split out ntpdig?
I'm relatively set on the idea of breaking out ntpdig, since it's the renamed replacement for sntp which is broken out in src:ntp, which we are talking (on debian-devel) about ntpsec replacing. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1003956: ntpsec: security settings
Control: reopen -1 On 1/24/22 13:25, Christoph Anton Mitterer wrote: On Tue, 2022-01-18 at 21:52 -0600, Richard Laager wrote: Shouldn't -g be removed? First off, note that the stock ntpsec.service has Restart=no, not Restart=yes. So in the malicious/broken server scenario described, ntpd will die, but not restart. Isn't it still, that if one e.g. reboots and ntpd starts the first time Yes, -g is only applicable at boot (or first install). then an attacker could basically set any time? There are two potential issues: A) the server serves bogus/malicious time B) a MITM messes with the time. The primary protection for A is consensus (see specifically minsane). A single bogus/malicious clock can't do anything. Of course, in scenario B, the MITM can mess with all of the clocks you're talking to. NTS is the best protection. The older style fixed secret hash-based (e.g. MD5/SHA) authentication is better than nothing. But yes, without NTS and with -g (both being the defaults in Debian), ultimately a MITM could adjust all of the times you're seeing and set any time, but only once upon boot. Eliminating -g would improve security in this situation. But there are trade-offs. One could argue here, that most "normal" systems (desktops, servers) have usually rather well working clocks... an so they wouldn't be likely affected by what you describe. That's true until it isn't: one day your motherboard's battery dies and now your clock is wrong, despite running ntpd. OTOH, embedded systems are "special" and if someone uses a system with no clock at all, than IMO it's rather his duty to take necessary steps so that it works (e.g. by installing ntpdate). I'm not sure how installing ntpdate is different from installing ntpsec in that regard. Let's say I remove -g by default. (Then I can safely set Restart=on-failure by default.) I could address some/all of the trade-offs: I'd imagine I could script up something to add -g on the first run of ntpd on initial install, to address that case. For example, I could detect the first run scenario as there being no drift file. I could use hwclock(1) to determine if there is an RTC. If not, add -g. That would make the Raspberry Pi case work out-of-the-box without decreasing security for regular systems. That still leaves the case of "my RTC battery died". I could probably detect that too, by checking to see if the current time is older than the drift file, and again add -g. The only problem I see with this is that if I'm adding -g under various circumstances, there's then no way for the administrator to prohibit -g. Another option would be to remove -g from $NTPD_OPTS if none of those conditions apply. If I'm only removing -g, the admin can still ensure -g is not used by removing it. This creates the opposite problem: there's no way for an admin to add -g if they want it always. (Unless my -g removal only removes one and they set NTPD_OPTS="-g -g" but that seems like a hack.) But, removing options is itself tricky (e.g. NTPD_OPTS="-gN" or NTPD_OPTS="-Ng") and that feels like asking for trouble. 2) Also in /etc/default/ntpsec, per default IGNORE_DHCP is "". Shouldn't that be set to yes, so that per default a malicious DHCP server couldn't add it's own possible rogue servers? Maybe. But ntpsec-ntpdate isn't installed by default and even installing ntpsec doesn't pull it in. If you choose to install that package, you (arguably) are expressing a desire to use its features, and the DHCP integration is a big part of that. I didn't realise that /etc/default/ntpsec's IGNORE_DHCP actually affects only ntpsec-ntpdate (or at least that's how I understand you)... which however has it's own /etc/default file with it's own IGNORE_DHCP?? Yeah, in looking at this more, this is different / more complicated than I remember, and arguably messy. So both ntpsec and ntpsec-ntpdate have DHCP support, which is enabled by default (IGNORE_DHCP=""). /etc/default/ntpsec's IGNORE_DHCP affects ntpd from ntpsec. /etc/default/ntpsec-ntpdate affects ntpdate-debian (note the -debian there) from ntpsec-ntpdate. It's technically possible to have both installed, but generally one is either using ntpd or ntpdate-debian, not both. The only documentation for this is README.Debian, which only references /etc/default/ntpsec. In fairness, lots of that file is talking only about ntpd from the ntpsec package, which ntpsec-ntpdate being a bit of a separate thing / an afterthought. Really, ntpsec-ntpdate should just die and this gets simpler. As far as DHCP goes, though... the DHCP server controls my address and my gateway. It can trivially MITM me. It could serve me DNS that redirects the pool servers somewhere. Or even without DNS being involved, it could simply serve me a gateway IP that forwards all NTP traffic somewhere. That said, if I'm using NTS
Bug#1003966: ntpsec: split out ntpdig?
I have a few questions: 1. What is your use case for ntpdig and/or ntpdate (please be specific which) if not for the hooks? Note that ntpdate is a wrapper script around ntpdig that upstream does not install by default. And then there's ntpdate-debian wrapping ntpdate. 2. My recollection is that there was some talk about removing ntpdate from Debian's src:ntp. I don't know if that's already happened. I ended up implementing all that in Debian's src:ntpsec for compatibility with ntp, but I intended on removing it once ntp did. The network hooks do a couple of different things. First, if you're using ifupdown, then when an interface comes up, ntpsec is stopped, ntpdate is run, and ntpsec is started. This is arguably* desirable if the system is not always connected to the Internet. If you're running both ntpsec and these hooks (why?), this is harmful if interfaces come and go while the system remains connected to the Internet. Off the top of my head, I can't remember whether this behavior happens with NetworkManager or networkd. The hooks also take the NTP server(s) given by the DHCP server and write them to a configuration file to be used by ntpdate/ntpsec. I believe this works with dhclient, NetworkManager, and networkd. * But why not either: A) run systemd-timesyncd (the default anyway) or B) just run ntpsec and let it figure out when the network is up (which it's probably "good enough" at). Is any of this a use case you care about? 3. The DHCP bit can be turned off in /etc/default/ntpsec-ntpdate. Disabling running ntpdate on ifup would require deleting the hook script. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1002563: bullseye-pu: package gbonds/2.0.3-16+deb11u1
A couple more things: This seems like it would qualify for the stable-updates special case to be pushed out before the next point release. Granted, this is not a popular package, so I'm not sure if that affects the decision. I don't immediately have plans to make updates for buster or stretch, but if anyone feels like I should, I could do that (or at least try; I haven't checked dependency versions, etc.). -- Richard
Bug#1002563: bullseye-pu: package gbonds/2.0.3-16+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: rlaa...@debian.org [ Reason ] gbonds is a program to track U.S. Savings Bonds and show their current redemption value. To do so, it needs updated valuation data from the U.S. Treasury twice a year. For nearly 30 years, Treasury has released this data in flat file format. These were recently discontinued in favor of an HTTP JSON API. The old files were removed from Treasury's FTP site and I have it on good authority that they are not coming back. This is Debian bug #1001610. [ Impact ] gbonds cannot provide current redemption values. The version in bullseye shipped with redemption data through May 2021 and, if its update code ran before Treasury deleted the files from the FTP site, could have downloaded one more file with redemption data through December 2021. [ Tests ] The new updater code writes out files in the traditional flat file format. I downloaded data for the previous period and compared it to the last official flat file. The results are the same, except: - The order of the lines in the file differs, which does not affect the data. - The API returns "null" (which maps to " ") instead of "NO PAY". This seems to be a bug, as the API is documented to return "NO PAY". I reported this to Treasury via their contact form, but who know if/when this might be fixed. This does not affect the values calculated, though it does mean bonds will not properly show as "Not yet eligible for payment". [ Risks ] The core of the update code has been completely rewritten (by me, as gbonds is long dead upstream). It uses libsoup to download data and json-glib to parse it. If the new update code is non-functional, it's no worse than the old code now. Since Treasury has removed the files from its FTP site and is not publishing new ones in that format, the old update code no longer does anything useful. If the new update code produces bad output, users would see incorrect valuations. The transformation is straightforward, and I did compare to the old data, as noted above. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] 1. I added the last official Treasury data file (sb202106.asc). I wouldn't normally include one of these in a stable update because the update code would download them anyway. But in this case, the file is no longer available from Treasury. It seems correct to ship the last official file since it's possible to do so. 2. I added a patch (which I wrote) that rewrites the core of the update code. Instead of downloading flat files from Treasury's FTP site, it accesses Treasury's HTTP JSON API. It writes out files in the traditional format, so none of the rest of the application changed. 3. I modified debian/gbp.conf to reference the debian/bullseye branch I created as part of this update. 4. I updated debian/changelog, of course. diff -Nru gbonds-2.0.3/debian/changelog gbonds-2.0.3/debian/changelog --- gbonds-2.0.3/debian/changelog 2021-02-04 02:23:39.0 -0600 +++ gbonds-2.0.3/debian/changelog 2021-12-23 21:24:14.0 -0600 @@ -1,3 +1,10 @@ +gbonds (2.0.3-16+deb11u1) bullseye; urgency=high + + * Add redemption data through 11/2021 (sb202106.asc) + * Use Treasury API for redemption data (Closes: 1001610) + + -- Richard Laager Thu, 23 Dec 2021 21:24:14 -0600 + gbonds (2.0.3-16) unstable; urgency=medium * Add redemption data through 05/2021 (sb202012.asc) diff -Nru gbonds-2.0.3/debian/control gbonds-2.0.3/debian/control --- gbonds-2.0.3/debian/control 2021-02-04 02:22:30.0 -0600 +++ gbonds-2.0.3/debian/control 2021-12-23 21:23:46.0 -0600 @@ -6,6 +6,8 @@ dpkg-dev (>= 1.16.1), intltool, libgtk-3-dev, + libjson-glib-dev, + libsoup2.4-dev, libtool, libxml2-dev (>= 2.4.23), Standards-Version: 4.5.1 diff -Nru gbonds-2.0.3/debian/gbp.conf gbonds-2.0.3/debian/gbp.conf --- gbonds-2.0.3/debian/gbp.conf2020-02-19 18:18:42.0 -0600 +++ gbonds-2.0.3/debian/gbp.conf2021-12-23 21:24:11.0 -0600 @@ -1,5 +1,5 @@ [DEFAULT] -debian-branch = debian/unstable +debian-branch = debian/bullseye pristine-tar = True upstream-branch = upstream/latest diff -Nru gbonds-2.0.3/debian/patches/download-sites gbonds-2.0.3/debian/patches/download-sites --- gbonds-2.0.3/debian/patches/download-sites 2020-08-15 17:41:52.0 -0500 +++ gbonds-2.0.3/debian/patches/download-sites 1969-12-31 18:00:00.0 -0600 @@ -1,15 +0,0 @@ -Description: Remove snaught.com from the download list - It d
Bug#1001610: GBonds Unable to Update Redemption Tables
Package: gbonds Version: 2.0.3-8 Severity: grave The U.S. Treasury has discontinued publishing the sbMM.asc files on its FTP site. Unfortunately, this means that GBonds is unable to update its redemption tables. Given that a, if not the, major reason to use GBonds is to track the current redemption value of one's U.S. Savings Bonds, this renders the application mostly broken as of December 1, 2021. The good news is that Savings Bond value data is available at the FiscalData site as a JSON-based RESTful API. I have ported GBonds to use this API and will be making an upload shortly. -- Richard
Bug#999375: rsyslog randomly exits, possibly caused by imrelp
FWIW, you can force OpenSSL with this, which is what I do: module(load="omrelp" tls.tlslib="openssl") -- Richard
Bug#996699: [Debian-on-mobile-maintainers] Bug#996699: chatty: Cross-building fails to resolve libpurple-dev
On a related note, I still need to bring this package's debehlper compat level current. That would hopefully address these: W: finch-dev: pkg-config-unavailable-for-cross-compilation usr/lib/pkgconfig/finch.pc W: libpurple-dev: pkg-config-unavailable-for-cross-compilation usr/lib/pkgconfig/purple.pc W: pidgin-dev: pkg-config-unavailable-for-cross-compilation usr/lib/pkgconfig/pidgin.pc -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#995370: pidgin: segmentation fault on malloc/free
I've uploaded a 2.14.7-2 with the upstream patch that should fix the issue. If it doesn't, please let me know. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#995370: pidgin: segmentation fault on malloc/free
On 10/1/21 7:11 AM, Václav Ovsík wrote: This is the changeset causing segfaults. Thanks! That's excellent that you bisected it all the way to a commit (not just a release). I've copied this to the upstream bug report. -- Richard
Bug#995370: pidgin: segmentation fault on malloc/free
On 9/30/21 7:16 AM, Vaclav Ovsik wrote: after ugprade of pidgin:amd64 to 2.14.7-1 from 2.14.1-1+b1 Are you in any position to bisect this by building the intermediate 2.14.x versions of Pidgin? -- Richard
Bug#995042: pidgin: new upstream releases 2.14.2 to 2.14.7
Thanks for your report. I was finally able to find some time today for Debian work. I've updated to the latest Pidgin release. I do have a lot more work to do on modernizing the packaging, but at least we're shipping the latest upstream release now. -- Richard
Bug#995090: systemd_system_unit_dir should be /usr/lib/systemd/system
Package: systemd Version: 247.9-2+b1 Severity: normal $ pkg-config --variable systemd_system_unit_dir systemd /lib/systemd/system This should be /usr/lib/systemd/system instead. debhelper and lintian now use/expect this path. See: lintian-explain-tags systemd-service-in-odd-location which references: * Bug#992465 * Bug#987989 * https://salsa.debian.org/debian/debhelper/-/commit/d70caa69c64b124e3611c967cfab93aef48346d8 * https://lists.debian.org/debian-devel/2021/08/msg00275.html I am the maintainer for ntpsec. Upstream ntpsec uses pkg-config to determine the proper path for unit files, because historically RedHat and Debian differed. If Debian now wants to prefer /usr/lib/systemd/system over /lib/systemd/system, then the installed systemd.pc file should be adjusted accordingly. -- Richard
Bug#989976: unblock: ntpsec/1.2.0+dfsg1-4
Subject: unblock: ntpsec/1.2.0+dfsg1-4
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package ntpsec
[ Reason ]
This is a targetted fix (specifically a backport of the upstream fix)
for Debian bug #989847 / CVE-2021-22212.
[ Impact ]
ntpkeygen can generate keys using the # character, which is then parsed
as a comment by ntpd, truncating the key. This weakens security for
anyone generating keys using ntpkeygen. In the worst case that would
still function, the key could be effectively truncated to a single
character (e.g. "X#...").
[ Tests ]
There are no automated tests covering this functionality. I manually
tested ntpkeygen to ensure it still functions. (Also, I'm not getting
any keys with # in them, but even with the bug it wouldn't be guaranteed
to happen every time.)
[ Risks ]
The targetted fix touches only ntpkeygen. If the change caused an
unforseen problem, it would be limited to ntpkeygen, not the core ntpd
functionality.
The specific change is trivial, changing the starting point of the range
from 0x21 (!) to 0x24 ($). This avoids 0x23 (#). However, it differs
from the pre-bug version of this code in that it will not output
0x21 (!) or 0x22 (") either.
In the course of investigating this, I see that the pre-bug version used
random.randint(0x21, 0x7e) which is inclusive on the upper end, while
the new code uses 0x2[14] + secrets.randbelow(0x5d) which is exclusive
on the upper end. Thus, the new code (both prior to and after the fix
for this CVE) will no longer use 0x7e (~). This is arguably another
bug.
Both of these slightly reduce the entropy, but I'm not sure how much it
matters:
Pre-bug: [0x21, 0x7e] excluding 0x23 => 0x5d choices per char
Bug: [0x21, 0x7e) aka=> 0x5d choices per char
[0x21, 0x7d]
Now: [0x24, 0x7e) aka=> 0x5a choices per char
[0x24, 0x7d]
I have emailed upstreams with these notes. But, even if one considers
this small reduction in entropy a problem, having the current fix is
still much better than not having it.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
Upstream issue:
https://gitlab.com/NTPsec/ntpsec/-/issues/699
Upstream fix:
https://gitlab.com/NTPsec/ntpsec/-/commit/fc50a701faafe60f117473016868770df54a6444
Bug introduced:
https://gitlab.com/NTPsec/ntpsec/-/commit/974bcf02108f94a23eb619619e706b720aeb2ddd
unblock ntpsec/1.2.0+dfsg1-4
--
Richard
diff -Nru ntpsec-1.2.0+dfsg1/debian/changelog
ntpsec-1.2.0+dfsg1/debian/changelog
--- ntpsec-1.2.0+dfsg1/debian/changelog 2021-01-20 20:36:38.0 -0600
+++ ntpsec-1.2.0+dfsg1/debian/changelog 2021-06-17 00:15:04.0 -0500
@@ -1,3 +1,9 @@
+ntpsec (1.2.0+dfsg1-4) unstable; urgency=medium
+
+ * ntpkeygen: Stop using # character: CVE-2021-22212 (Closes: 989847)
+
+ -- Richard Laager Thu, 17 Jun 2021 00:15:04 -0500
+
ntpsec (1.2.0+dfsg1-3) unstable; urgency=medium
* apparmor: allow openssl.cnf (Closes: 980508)
diff -Nru
ntpsec-1.2.0+dfsg1/debian/patches/0001-Don-t-generate-into-ASCIIfied-keys.patch
ntpsec-1.2.0+dfsg1/debian/patches/0001-Don-t-generate-into-ASCIIfied-keys.patch
---
ntpsec-1.2.0+dfsg1/debian/patches/0001-Don-t-generate-into-ASCIIfied-keys.patch
1969-12-31 18:00:00.0 -0600
+++
ntpsec-1.2.0+dfsg1/debian/patches/0001-Don-t-generate-into-ASCIIfied-keys.patch
2021-06-16 23:50:03.0 -0500
@@ -0,0 +1,36 @@
+From fc50a701faafe60f117473016868770df54a6444 Mon Sep 17 00:00:00 2001
+From: "Eric S. Raymond"
+Date: Tue, 11 May 2021 08:10:10 -0400
+Subject: [PATCH] Don't generate # into ASCIIfied keys.
+
+---
+ ntpclients/ntpkeygen.py | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/ntpclients/ntpkeygen.py b/ntpclients/ntpkeygen.py
+index 969be76a6..10d220f43 100644
+--- a/ntpclients/ntpkeygen.py
b/ntpclients/ntpkeygen.py
+@@ -33,7 +33,8 @@ try:
+ if asciified:
+ result = ''
+ for index in range(bytes):
+-result += chr(0x21 + secrets.randbelow(0x5d))
++# Start ASCII characters with 0x24 so as not to include
comment-beginning #
++result += chr(0x24 + secrets.randbelow(0x5a))
+ return result
+ else:
+ return secrets.token_hex(bytes)
+@@ -43,7 +44,8 @@ except ImportError:
+ result = ''
+ if asciified:
+ for index in range(bytes):
+-result += chr(random.randint(0x21, 0x7e))
++# Start ASCII characters with 0x24 so as not to include
comment-beginning #
++result += chr(random.randint(0x24, 0x7e))
+ else:
+ for index in range(bytes):
+ result += "%02x" % random.randint(0x0, 0xff)
+--
+2.25.1
+
diff -Nru ntps
Bug#989847: CVE-2021-22212
I've uploaded a targeted fix to unstable and requested an unblock. -- Richard
Bug#989847: CVE-2021-22212
On 6/14/21 1:59 PM, Moritz Muehlenhoff wrote: Package: ntpsec Severity: important Tags: security X-Debbugs-Cc: Debian Security Team This was assigned CVE-2021-22212: https://gitlab.com/NTPsec/ntpsec/-/issues/699 Patch: https://gitlab.com/NTPsec/ntpsec/-/commit/b09be47d650280cc7ebdcd45dfa07eca4b9a52f8 Can you please upload a targeted fix to unstable and ask the release team for an unblock? Yes, I will prepare one very soon (tonight or tomorrow). -- Richard
Bug#983095: pidgin: 5353/udp probe every 2 sec
Unfortunately, I don't see any references to 5353 in any of that. However, I do see a mention of libgstmicrodns.so. I wonder if that's related. Could you run: dpkg -S /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstmicrodns.so Then remove whatever package ships that library? You can reinstall it again after running the test. Or, if you're worried about removing it (e.g. if it's something you can't reinstall easily), maybe you can just rename libgstmicrodns.so out of the way and test? -- Richard
Bug#983095: pidgin: 5353/udp probe every 2 sec
On 5/16/21 7:50 PM, Richard Laager wrote: So it's happening in a child process. Gary had an idea here... Pidgin generally only uses child processes for DNS. Is it possible that you have some NSS plugin that is doing this? Specifically, do you have libnss-mdns installed? I do, and I still can't reproduce the problem. But maybe you can try removing it to see if that fixes it? (Obviously, you can reinstall it either way.) -- Richard
Bug#988819: libgnt-doc: broken symlinks: /usr/share/doc/libgnt-doc/* -> ../../gtk-doc/html/*
On 5/19/21 3:31 PM, Andreas Beckmann wrote: Should libgnt-doc have a Depends/Recommends/Suggests: libglib2.0-doc ? Yes. Thanks! In the course of investigating this, I found that I also need libglib2.0-doc as a Build-Depends. I've made both fixes, but intend to wait to upload until after the freeze. If that's wrong, please let me know. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#983095: pidgin: 5353/udp probe every 2 sec
On 5/16/21 3:21 AM, Slavko wrote: I didn't see it, pidgin.log attached, but tcpdump shows them. Then i tried it with -f option to strace: Good thinking. So it's happening in a child process. A good next step is to use gdb, but the fork will complicate things. I think you can do "set detach-on-fork off", but I'm not sure. If that doesn't work, then you probably need to figure out how many child processes it forks off before the child that we are interested in. From the strace, it looks like it's the second child that we care about. So try this: gdb pidgin set args -c pidgin-test set pagination off set logging file pidgin-gdb.txt set logging on watch fork run # When it forks the first time: continue # When it forks the second time, set it to follow the child: set follow-fork-mode child break socket commands bt continue end break sendto commands bt continue end continue The goal here is to get a backtrace of it opening the socket() and/or sendto() on the socket. Since you're on sid, you should be able to use debuginfod (though I have never used it personally): I am on testing, are the instructions still relevant? I think debuginfod will work. If not you can follow the instructions to install dbgsym packages for pidgin & libpurple0. -- Richard
Bug#983095: pidgin: 5353/udp probe every 2 sec
Can you try this: rm -rf pidgin-test mkdir pidgin-test strace -e trace=socket,sendto pidgin -c pidgin-test 2>&1 | \ tee pidgin.log Hopefully you'll see some socket() call for 5353 and some sendto() calls as it sends the packets. If so, then let's try to find out what is opening that socket. We will do that by using gdb to get a backtrace from every call to socket. You will need gdb installed: sudo apt install gdb Since you're on sid, you should be able to use debuginfod (though I have never used it personally): export DEBUGINFOD_URLS="https://debuginfod.debian.net; More instructions here if debuginfod does not work: https://wiki.debian.org/HowToGetABacktrace Then run like this: gdb pidgin set args -c pidgin-test set pagination off set logging file pidgin-gdb.txt set logging on break socket # say yes to the prompt commands bt continue end run Once it sends some packets, kill it with Ctrl-C, type quit, and confirm you are okay with gdb killing pidgin. Send me the pidgin.log and the pidgin-gdb.txt. Hopefully I can then determine which backtrace corresponds to the socket that sends the packets. If not, then you'll have to do the gdb thing again but breaking on both socket and sendto. -- Richard
Bug#983095: pidgin: 5353/udp probe every 2 sec
I was never able to reproduce this, nor was Gary (Pidgin lead developer). Are you able to narrow this down at all? For example, if you run: mkdir pidgin-test pidgin -c pidgin-test that will start with a blank config. Does it happen then? If not, try adding accounts and/or enabling plugins until you reproduce it. Or, alternatively, work from the opposite direction by copying your config: cp -a ~/.purple pidgin-test2 pidgin -c pidgin-test2 That should reproduce it. Then remove things from your config until it stops. Or, do both and diff the two configs to know what to tweak. -- Richard
Bug#983095: pidgin: 5353/udp probe every 2 sec
I am not able to reproduce this. Do you have a packet capture? Specifically, I'd like to know what sort of request it is. -- Richard
Bug#949977: ITP: libgnt -- GLib Ncurses Toolkit
This obviously took me a long time to get to, but I finally have. 1. As discussed with Ari, I have adopted the Pidgin package. I also made a few cleanups at the same time. More extensive updating (e.g. to modern debhelper compat) will probably have to wait until after bullseye, given the impending freeze. 2. I have uploaded libgnt, which should hit the NEW queue. 3. I have a Pidgin 2.14.1 package prepared, which uses the libgnt package. As soon as libgnt clears NEW, I can upload pidgin. -- Richard
Bug#980508: ntpsec: apparmor="DENIED" while trying to read /etc/ssl/openssl.cnf
On 1/19/21 6:09 PM, Diederik de Haas wrote: # journalctl -kaf --no-hostname | grep -w 'apparmor="DENIED"' jan 20 00:45:32 kernel: audit: type=1400 audit(1611099932.689:41): apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" name="/etc/ssl/openssl.cnf" pid=43157 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Thanks for your report! I've uploaded a new version which includes the openssl abstraction and thus fixes this. -- Richard
Bug#980464: [Pkg-zfsonlinux-devel] Bug#980464: zfs-dracut: dracut+ZFS-on-root systems rendered unbootable
FWIW, I gave the patch a review and it seems sane to me. I also looked at the package in unstable and confirmed that zgenhostid is being installed to /sbin, not /bin. -- Richard
Bug#977794: marked as done (ntpsec: Stops after seeing an old version of openssl is used)
On 12/21/20 2:51 AM, Debian Bug Tracking System wrote: I'd expect the update of ntpsec triggers too the update of libssl1.1 to a compatible version. I ended up taking the opposite approach. I patched out the OpenSSL build vs install version check from upstream NTPsec. While I definitely think one should stay current on (packaged versions of) OpenSSL, there is no good reason to force the upgrade in this scenario. We should be able to assume that dpkg-shlibdeps is generating correct dependencies. In this case, it would have been just fine for ntpd to run. This version check is arguably somewhat useful in the general case, but I believe it largely exists as part of an effort to avoid 1.1.1a which is buggy and/or to ensure that a new enough version is present for NTS. I've added an explicit dependency on >= 1.1.1b. Note that this fix is only in unstable at the moment. I will update buster-backports once the fixed version migrates to testing, as required by backports policy. -- Richard
Bug#971523: ntpsec-ntpdate: ntpdate fail if DNS name for server resolve to IPv6
tags 971523 upstream forwarded 971523 https://gitlab.com/NTPsec/ntpsec/-/issues/680 On 10/1/20 4:13 AM, Petter Reinholdtsen wrote: > ntpdig: socket error on transmission: [Errno 101] Network is unreachable > > My guess is that you have working IPv6, while I do not. > > root@devuan-n900:~# ping6 2001:67c:558::43 > connect: Network is unreachable > root@devuan-n900:~# I previously had IPv6 enabled, but no (non-link-local) IPv6 address. If I disable IPv6 entirely, I get: [Errno 99] Cannot assign requested address That's slightly different than your error, but the principle of the failure is the same. -- Richard signature.asc Description: OpenPGP digital signature
Bug#972132: [Pkg-zfsonlinux-devel] Bug#972132: zfs-initramfs: Fails to boot when / is on zfs encryption=on dataset
On 10/12/20 9:29 PM, John Goerzen wrote: > I have set up this system to use ZFS crypto rather than my more conventional > zfs-atop-LUKS. Can you explain a little bit more about how you setup your system? This (root-on-ZFS with native encryption) already works for me on Buster (with ZFS from buster-backports) using the upstream HOWTO (that I maintain): https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html -- Richard signature.asc Description: OpenPGP digital signature
Bug#971523: ntpsec-ntpdate: ntpdate fail if DNS name for server resolve to IPv6
On 10/1/20 3:19 AM, Petter Reinholdtsen wrote: > root@devuan-n900:~# /usr/sbin/ntpdate -b 0.debian.pool.ntp.org > 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org > ntpdig: socket error on transmission: [Errno 101] Network is unreachable NTPsec's ntpdate is just a thin wrapper around ntpdig. I think ntpdig is the NTPsec name for sntp, but like all the client utilities, it has been completely rewritten from C into Python. What does this output: ntpdig -d 0.debian.pool.ntp.org 1.debian.pool.ntp.org \ 2.debian.pool.ntp.org 3.debian.pool.ntp.org I get a different error, which might be related, with: ntpdig -d 2.debian.pool.ntp.org That seems to timeout (the default being 5 seconds) and then return: ntpdig: no eligible servers How does that behave for you? For me, this works, albeit still with a 5 second delay: ntpdig -dc 2.debian.pool.ntp.org -- Richard signature.asc Description: OpenPGP digital signature
Bug#960132: mdadm: mdcheck_start.service trying to start unexisting file
found 960132 4.1-1 severity 960132 serious Justification for "serious": This bug causes a shipped service (mdcheck_start.service) to completely fail to start, due to the fact that its script (/usr/share/mdadm/mdcheck) does not exist. A package should not release in that state. I considered going up or down a level, but ultimately landed on "serious". Argument for increasing to "grave": For someone expecting/needing this service to work, this could lead to data loss. The entire point of MD's "check" functionality is to make sure that all the blocks are readable. In e.g. a two-disk mirror, if one disk ends up with an unreadable block and then the other disk fails, data loss occurs. If the check script runs as intended and catches this before the second failure, the unreadable block will be detected and then rewritten (from the good copy on the other disk). Argument for decreasing to "important": mdcheck_start.timer is disabled by default and /etc/cron.d/mdadm still exists. Regardless of the particular severity (>= important), I think this is a good candidate for a stable update. Here is an example debdiff (sub in your name): --- mdadm-4.1/debian/changelog 2019-01-15 12:23:53.0 -0600 +++ mdadm-4.1/debian/changelog 2020-09-18 02:09:41.0 -0500 @@ -1,3 +1,9 @@ +mdadm (4.1-1+deb10u1) buster; urgency=medium + + * Install misc/mdcheck (Closes: #960132) + + -- Richard Laager Fri, 18 Sep 2020 02:09:41 -0500 + mdadm (4.1-1) unstable; urgency=medium * New upstream release. diff -Nru mdadm-4.1/debian/rules mdadm-4.1/debian/rules --- mdadm-4.1/debian/rules 2019-01-15 12:23:53.0 -0600 +++ mdadm-4.1/debian/rules 2020-09-18 02:08:04.0 -0500 @@ -64,6 +64,7 @@ install -Dm0755 debian/mkconf $(DESTDIR)/usr/share/mdadm/mkconf install -Dm0755 debian/checkarray $(DESTDIR)/usr/share/mdadm/checkarray install -Dm0755 debian/bugscript $(DESTDIR)/usr/share/bug/mdadm/script + install -Dm0755 misc/mdcheck $(DESTDIR)/usr/share/mdadm/mdcheck install -Dm0755 udeb/mdadm $(DESTDIR_UDEB)/sbin/mdadm install -Dm0755 udeb/mdmon $(DESTDIR_UDEB)/sbin/mdmon install -Dm0644 $(DESTDIR)/lib/udev/rules.d/63-md-raid-arrays.rules $(DESTDIR_UDEB)/lib/udev/rules.d/63-md-raid-arrays.rules -- Richard signature.asc Description: OpenPGP digital signature
Bug#959013: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME
FWIW, this looks good to me. This is a new upstream release, but it's a bug-fix only (adding a translation update at the same time seems fine). Is there a particular reason this should NOT be uploaded? -- Richard signature.asc Description: OpenPGP digital signature
Bug#960132: mdadm: mdcheck_start.service trying to start unexisting file
On Sun, 10 May 2020 02:16:57 +0700 Павел Мотырев wrote: > There is a patch in attachment, that adds missed scripts into the > package during build process. syslog-events is already installed by a dh_installexamples call. Also, I'm not sure why this would need to install the mdcheck script into the udeb. So I end up with this (sorry for my mail client line wrapping the context lines): diff -Nru mdadm-4.1/debian/rules mdadm-4.1/debian/rules --- mdadm-4.1/debian/rules 2019-03-11 22:58:03.0 -0500 +++ mdadm-4.1/debian/rules 2020-09-11 17:08:40.0 -0500 @@ -63,6 +63,7 @@ install -Dm0755 debian/mkconf $(DESTDIR)/usr/share/mdadm/mkconf install -Dm0755 debian/checkarray $(DESTDIR)/usr/share/mdadm/checkarray + install -Dm0755 misc/mdcheck $(DESTDIR)/usr/share/mdadm/mdcheck install -Dm0755 debian/bugscript $(DESTDIR)/usr/share/bug/mdadm/script install -Dm0755 udeb/mdadm $(DESTDIR_UDEB)/sbin/mdadm install -Dm0755 udeb/mdmon $(DESTDIR_UDEB)/sbin/mdmon -- Richard signature.asc Description: OpenPGP digital signature
Bug#962509: Not always boot arguments must include a root= parameter
On 9/7/20 4:00 AM, kvaps wrote: > Thanks for your intention to help. > It seems I already found the correct solution for my case, > > The problem persists only for the scripts/local, which is set by > default (BOOT=local) > We can review two cases where it might be caused: > > 1. LTSP and booting over the network > >I implemented option to boot rootfs image over HTTP and it is > conflicting with scripts/local >https://github.com/ltsp/ltsp/pull/90 > >The solution was to implement another boot script > (scripts/ltsp-http) with empty functions >and call it by setting BOOT=ltsp-http Your bug was reassigned from initramfs-tools to zfs-initramfs. Are you not using ZFS? zfs-initramfs already sets BOOT=zfs. -- Richard signature.asc Description: OpenPGP digital signature
Bug#962509: Not always boot arguments must include a root= parameter
On Tue, 9 Jun 2020 01:25:58 +0200 kvaps wrote: > Package: initramfs-tools > Version: 0.133+deb10u1 > > Hi, after the change introduced in f8ceeb90 both zfs and http booting > methods are not working anymore, it stops on the message: > > No root device specified. Boot arguments must include a root= parameter. Please add "debug" to your kernel command line*, reboot, and send me a copy of /run/initramfs/initramfs.debug. * If you're not sure how to do this: When you see GRUB, hit "e" to stop the timer and go into edit mode. Use the arrow keys to find the line starting with "linux" and navigate to the end of it. Add "debug" (no quotes). Press Ctrl-x or F10 to boot. -- Richard signature.asc Description: OpenPGP digital signature
Bug#656060: logrotate: drop compress option
retitle Move de facto "compress" default into logrotate.conf submitter 656060 ! On Wed, 22 Aug 2018 15:24:18 +0200 Christian Göttsche wrote: > I think extX is still the default for filesystems. So the compress > option makes sense in the general case. The request here is to: 1. Enable "compress" in logrotate.conf. 2. (Request that maintainers and/or NMU to) Drop "compress" in package's /etc/logrotate.d/* files. Thus, compression would still be enabled by default. But this gives users a _single_ place to toggle this globally, rather than needing to toggle it in every package's /etc/logrotate.d/* configuration file. The user might want to disable log compression for any number of reasons; some examples being: A) They have a filesystem doing copy-on-write snapshots. B) They have tons of disk space and don't need the compression. C) They want to make it easier to grep the files. In the Root-on-ZFS HOWTOs that I maintain, I recommend people turn it off for reason A. At $DAYJOB, we use ext4 but turn off log compression for reason C (and the implied B). > p.s.: @Richard Laager: I quite did not get the point with the snapshots. 1. Write a log file to disk. Let's say that's 10 MB. It takes up 10 MB on disk. 2. Take a snapshot. With copy-on-write, this takes no new space. 3. Compress the log file. Let's say the compressed version takes 1 MB. On a traditional filesystem, step 3 wrote 1 MB but freed 10 MB, for a net savings of 9 MB. On a copy-on-write filesystem with snapshots, step 3 wrote 1 MB and freed 0 MB (as the original uncompressed file exists in one or more snapshots), for a net _cost_ of 1 MB. This is the exact opposite of the goal of enabling compression. -- Richard
Bug#968329: gbp import-orig should strip +dfsg, etc. for upstream-vcs-tag
Package: src:git-buildpackage
Version: 0.9.20
Severity: wishlist
Tags: patch
Feature request:
`gbp import-orig` should strip [~+](dfsg|ds).* or even [~+].* from the
upstream version (only) when calculating the upstream-vcs-tag.
Details:
I'm trying to get `gbp import-orig --uscan` working with a variant of
the repack-waf script from: https://wiki.debian.org/UnpackWaf
The example here is NTPsec 1.1.9.
The stock repack-waf script takes an input orig tarball of "1.1.9" and
outputs an orig tarball of "1.1.9+dfsg1". Unfortunately, in this state,
uscan is not aware that the tarball was repacked, so neither is `gbp
import-orig`. gbp gets the version from the tarball name, which it gets
from the element in the `uscan --dehs` output.
If I add oversionmangle=s/$/+dfsg1/ to the opts in debian/watch, then
uscan is aware that the output will be 1.1.9+dfsg1. This seems like the
correct thing to do from uscan's perspective, as its man page says
oversionmangle "should be used to add a suffix such as +dfsg1".
However, uscan will also symlink the upstream orig tarball with that
name, so the stock repack-waf script breaks. That can easily be
addressed by changing repack-waf to use the 1.1.9+dfsg1 name as both
input and output, which I have done.
In that configuration, gbp gets the upstream version of 1.1.9+dfsg1.
This leads to tag names like upstream/1.1.9+dfsg1, which is what I have
been using so far. DEP-14 isn't clear whether it should be
upstream/1.1.9+dfsg1 or upstream/1.1.9. However, DEP-14 does
contemplate that "The upstream/ tag would be created by the
package maintainer when needed: for example when
it does a release based on a Git snapshot". So those tags are not
expected to correspond exactly with upstream's tags. I think they
should be the "Debian upstream version", so 1.1.9+dfsg1 is correct.
Further, in bug #546598, Charles Plessy suggested
that `gbp import-orig --filter` should automatically add "~dfsg":
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546598 That bug was
from 2009. Today, plessy seems to use +dfsg.1, +ds-1, and +dfsg-1
suffixes. More importantly than those minor differences in suffix
style, some of those packages currently have numbers greater than 1.
That to me shows that stripping the +dfsg1 to get just upstream/1.1.9
would be inappropriate, as that would not scale to +dfsg2 and beyond.
This is further evidence that upstream/1.1.9+dfsg1 is correct.
However, that still leaves one problem. The --upstream-vcs-tag tag
format only allows for one substitution which has to be a single
character substitution. There is no way to strip the +dfsg1. In my
case, I want to get to the NTPsec_1_1_9 format that upstream uses by
using: upstream-vcs-tag = NTPsec_%(version%.%_)s
I ran some queries against UDD to find various patterns. Based on that,
the attached patch series implements this and a bunch more. With this
change, I was able to import version 1.1.9 of NTPsec using:
gbp import-orig --uscan --upstream-vcs-tag="NTPsec_%(version%.%_)s"
The first patch is just a typo fix to a comment nearby. It's unrelated
to this change.
The second two patches are refactoring changes. Those can be squashed
together or into the last change, if you prefer. I included them to show
the refactoring steps individually, in case that helps you review this.
The third change is the meat of this. I have doctests, but I'm not sure
if those are automatically run or how I integrate them into the
git-buildpackage tests. I'm also not sure about the function name for
_upstream_version_from_debian_upstream(). In a previous version, I
called it _mangle_upstream_version().
--
Richard
From 7cc1195bac48833fa551102a114d943be2cc006b Mon Sep 17 00:00:00 2001
From: Richard Laager
Date: Wed, 12 Aug 2020 21:54:06 -0500
Subject: [PATCH 1/4] import-orig: Fix a comment typo
---
gbp/deb/git.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gbp/deb/git.py b/gbp/deb/git.py
index 596c9ff..4b52122 100644
--- a/gbp/deb/git.py
+++ b/gbp/deb/git.py
@@ -171,7 +171,7 @@ class DebianGitRepository(PkgGitRepository):
@classmethod
def _mangle_version(cls, format, version):
"""
-Basic version mangling to replce single characters
+Basic version mangling to replace single characters
>>> DebianGitRepository._mangle_version(r'%(version%-%\\%)s', "0-1.2.3")
('%(version)s', '0%1.2.3')
--
2.28.0
From 37904cdda6d4b1de4602bbf3e98baa8bb5ace42d Mon Sep 17 00:00:00 2001
From: Richard Laager
Date: Wed, 12 Aug 2020 21:58:31 -0500
Subject: [PATCH 2/4] import-orig: Refactor vcs_tag_parent
This eliminates an indentation level.
---
gbp/deb/git.py | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/gbp/deb/git.py b/gbp/deb/git.py
index 4b52122..a701589 100644
--- a/gbp/deb/git.py
+++ b/gbp/deb/git.py
@@ -375,14 +375,13
Bug#966565: [zfsutils-linux] zfs-mount-generator broken by git_fix_dependency_loop_encryption1.patch
On 7/30/20 1:58 PM, Antonio Russo wrote: > Changing this line to > > pools=$(zpool list -H -o name | true) This should be || true (two pipes, not one). -- Richard signature.asc Description: OpenPGP digital signature
Bug#957616: ntpsec: ftbfs with GCC-10
On 7/25/20 5:27 PM, Reiner Herrmann wrote: > this has been fixed in version 1.1.9. > The relevant commit is this one: > > https://gitlab.com/NTPsec/ntpsec/-/commit/ccdd9d4b941b30fc44b301595e42809dbe48628d Thanks for that information! That saves me investigating. I need to get 1.1.9 packaged anyway, so I'll proceed straight to that. -- Richard signature.asc Description: OpenPGP digital signature
Bug#962424: [Pkg-zfsonlinux-devel] Bug#962424: zfsutils-linux: systemd zfs-mount-generator breaks boot if multiple datasets have the same mountpoint
On 6/9/20 7:02 PM, Wxcafé wrote: > I don't use zfs-import-cache since it's a single pool that contains the > root so it's in the kernel cmdline and imported at that point. I wasn't asking about the pool cache, but the filesystem cache file used by zfs-mount-generator. That would show all the datasets involved and their properties and would allow testing the generator to see what units it is producing for you. -- Richard signature.asc Description: OpenPGP digital signature
Bug#962424: [Pkg-zfsonlinux-devel] Bug#962424: zfsutils-linux: systemd zfs-mount-generator breaks boot if multiple datasets have the same mountpoint
On 6/7/20 3:12 PM, wxcafe wrote: > The systemd zfs-mount-generator script > (/lib/systemd/system-generators/zfs-mount-generator) can break system > boot if there are multiple datasets with the same mountpoint, because it > ignores the zfs property canmount=noauto. It certainly does not "ignore" canmount=noauto. There's all kinds of logic in the generator to deal with canmount=noauto. > I store backups on my system and after upgrading the system wouldn't > boot anymore because while my backups are canmount=noauto, the generator > was trying to mount multiple datasets to the same mountpoints (/, /usr/, > ...) which obviously breaks... everything. If you have datasets marked as canmount=on, they should take precedence over any marked canmount=noauto for the same mountpoint. Are there multiple pools involved here, or just one? Can you provide a copy of your cache file(s) from /etc/zfs/zfs-list.cache? -- Richard signature.asc Description: OpenPGP digital signature
Bug#961748: Does CVE-2018-8956 affect ntpsec?
On 5/28/20 1:39 PM, Moritz Muehlenhoff wrote: > Source: ntpsec > Severity: normal > Tags: security > > There was a "new" CVE assignment for ntp (2018 ID, but appeared today): > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8956 > > Does this affect ntpsec? Almost certainly not. NTPsec removed the broadcast mode stuff. I've emailed upstream to confirm. > And congrats to becoming a DD :-) Thanks! -- Richard signature.asc Description: OpenPGP digital signature
Bug#961094: [Pkg-zfsonlinux-devel] Bug#961094: zfsutils-linux: Hostid is not regenerated on a clone/copy/restore of the underlying OS
On 5/19/20 7:34 PM, Real Carbonneau wrote: > For example, every clone of a Debian system has a UUID (eg command "dmidecode > -t 1"), thus it would be simple to generate a new hostid (possibly keeping the > old one backed up) when the system uuid has been observed to have changed. The BIOS UUID is not reliable. I have a bunch of SuperMicro systems with the same UUID. I suggest using /etc/machine-id when present (i.e. systemd systems). See also: https://github.com/openzfs/zfs/issues/9367 -- Richard signature.asc Description: OpenPGP digital signature
