Bug#1068951: new upstream (6.x)
Hey Daniel, I did a spring cleaning in upstream debian packaging (distro/pkg/deb), merging -core and -manager into knot-resolver6, porting most of your debian/experimental patches, and removing many lintian warnings. This was done in upstream MRs now merged into `master` branch (which is now v6, `master-5` is for v5). For your convenience, here's a link to upstream debian dir distro/pkg/deb: https://gitlab.nic.cz/knot/knot-resolver/-/tree/master/distro/pkg/deb The upstream package was renamed to knot-resolver6 in order to prevent unwanted upgrades as there is sadly no upgrade path from v5 to v6. Users were already complaining about such issues with shared v5 & v6 upstream repos and the situation will be equivalent on bookworm -> trixie update so I suggest using that (knot-resolver6) in Debian packaging as well. Debian in particual is expected not to break working systems on upgrade and I don't see a way to ensure that without knot-resolver6 rename. Remaining issues: * debian: adduser -> useradd patch doesn't create knot-resolver group as it should * debian: package should be renamed to knot-resolver6 (?) * debian: python modules must be properly installed (see upstream d/rules) * upstream: meson / ninja is invoked manually as opposed to dh_auto_* because I don't know how to properly refernce meson build dir I did what I could with the upstream packaging, so now it's your turn with debian/experimental, Daniel, if you have the time :) Feel free to sync what you think is good, do the knot-resolver6 rename (or not, I'm still not 100 % decided there), properly use dh_auto_* (if you know how to reference meson builddir in d/rules) or whatever you see fit. After that I'll go one more round of upstream <-> debian sync, hunt some more lintian warnings, and finally release the debian/experimental package. Cheers, Jakub signature.asc Description: PGP signature
Bug#1068951: new upstream (6.x)
Yo Santiago (CC'd), could you please drop your opinion on this for extra reference? On 4/30/24 18:34, Daniel Baumann wrote: Hi, On 4/30/24 18:12, Jakub Ružička wrote: Secondary reason for that was that there is no upgrade path from 5.x to 6.x so it's unwanted for knot-resolver 5 packages to auto-update to 6. For that, the package probably needs a different name (like knot-resolver6) imho this should be handled in the package (e.g. by showing a debconf note or so) and be included in the trixie release notes. renaming the binary package doesn't really solve much and is more suited for (library) transitions, i.e. if there were several knot-resolver-module-* packages or so. We currently have v5 and v6 packages in a single knot-resolver repo on pkg.labs.nic.cz and v5 users are safe to `apt update` from the repo without breaking their setup or they can `apt install knot-resolver6` to upgrade. This would apply to Bookworm -> Trixie transition as well. If there was no distinction between v5 and v6 packages, unwanted updates leading into broken setups are bound to happen, that's not very user friendly. I could split the upstream repos (knot-resolver5, knot-resolver6), but that won't solve Bookworm -> Trixie case. OTOH knot-resolver6 fork is extra maintenance (new source package & Salsa repo...) and an unwanted irregularity although it gets the job done. This was the case for bird2 and upcoming bird3 for example, which also isn't a library. also (I haven't looked at it), is it worthwile to (with users consent) to "try" to guess with (some parts of) the old config to generate the new config from? I don't think that's worthwhile, that's why it's not officially supported. So what do you suggest? generally, the amount of binary packages should be limited to a minimum - oiow there needs to be a reason why an additional binary package is added. some of them are: * saving relative excessive amount of diskspace (e.g. large documentation can be split into a -doc package) * different parts have different dependencies and/or particulary long dependency chains (e.g. gtk parts of a cli tool) therefore, imho the following binary packages make sense here: * knot-resolver * knot-resolver-doc * knot-resolver-module-dnstap * knot-resolver-module-http Consulting with upstream, there doesn't seem to be a strong reason not to merge like that. Separating the python module(s) in a sub-package could be useful in some (official unsupported edge) cases like containers where pulling the extra python deps might increase the image size significantly. I believe vast majority of users will use the manager so it's desirable to install it by default, which would be 100 % ensured by having it a part of knot-resolver package, so that's a plus. Those who want to use kresd without manager can simply disable manager and do what they want at the cost of some unused python deps. I don't think that's too bad of a compromise. So I'm generally in favor of merging the -manager package, I'm just worried about unwanted upgrades if we don't change the name (knot-resolver6) as there isn't really an upgrade path. Such is the price of progress. Note that Fedora policies/customs are strongly in favor of not forking per-version - in line of what you suggest. Note that -dbg packages are generated automatically and don't need to be specified in control (I'll provide a commit for that). Oh, right :) Cheers, Jakub
Bug#1068951: new upstream (6.x)
On 4/29/24 21:13, Daniel Baumann wrote: On 4/29/24 19:50, Daniel Baumann wrote: pushing to the repo requires me to be added to the salsa project.. would you mind adding me? in the meantime, I've pushed to here: https://git.progress-linux.org/users/daniel.baumann/debian/todo/knot-resolver/log/ Nice! before I'll continue: what's the idea of adding knot-resolver-manager binary package? I can't think of a reason why one would use kresd (knot-resolver-core) without the manager, and thus, would fold knot-resolver-manager and knot-resolver-core (back) into knot-resolver. But probably I'm missing something.. That is a great question and in fact the primary topic I wanted some other DD to review. You basically answered that already, but let me elaborate why it's like this. Manager was initially developed in a separate repo imported into kresd as a git submodule and it wasn't clear back then how integrated / optional / required it will be. Manager is now quite integrated in kresd and while it's theoretically possible to use knot-resolver-core without knot-resolver-manager, this isn't officially supported and generally a use case probably not worth supporting. Secondary reason for that was that there is no upgrade path from 5.x to 6.x so it's unwanted for knot-resolver 5 packages to auto-update to 6. For that, the package probably needs a different name (like knot-resolver6) so I made this little trick of moving knot-resolver to knot-resolver-core and added manager to knot-resolver-manager with Provides: knot-resolver6. That way no upgrade is triggered as there is no knot-resolver package in 6.0. However, this is probably just unneeded complexity - I guess the packages could or even should be merged. So what do you suggest? Merging -manager and -core into knot-resolver6? Or is there a way to prevent upgrade without changing package name? Cheers, Jakub OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068951: new upstream (6.x)
On 4/23/24 14:05, Daniel Baumann wrote: Hi, On 4/23/24 13:58, Jakub Ružička wrote: but we've agreed the time has come to get extra testing & feedback through Debian experimental. yay, thanks! [ we use knot-resolver at work for the central resolvers for the university, and we love it. kresd 6 offers some nice improvements for us, so looking forward testing it (via local bookworm-backports we maintain) ] Awesome, I've forwarded your words of praise to the hard-working Knot Resolver team :) The only blocker for that is missing python3-json-schema-for-humans needed for docs build which I intend to package later - for now I guess I'll just disable the docs build. (just as an offer) I'll maintain a bunch of python modules already and don't mind another, so I can upload that later today if this is any help. Thanks, but I'm part of PythonTeam so I can do that myself and I'm actually quite interested in (the nightmares of) python packaging in general so it's a welcome opportunity to have some real world experience plus I think it will be a trivial package. I'm hitting boundaries of my Debian knowledge so it's slow. I'm happy to help if you want. Cool, I've already mental-marked you as a person I'm gonna bother with reviewing my v6 changes even before your willing reply :) For example, upstream package uses meson directly and builds in meson_deb dir, but debian package uses debhelper with obj-x86_64-linux-gnu dir and I don't know howto properly reference it from d/rules without relying on shady strings. I didn't find a branch on the salsa repo, where would I find the current 6.x state to send patches against? I don't like pushing broken/incomplete branches but yeah this is gonna take a while so I pushed my Draft to debian/experimental salsa branch (also pristine-tar and new upstream-6). The upstream package is well tested, but it diverged quite far from debian package and syncing them is non-trivial - my mission is to fix that. git clone -b 6.0 https://gitlab.nic.cz/knot/knot-resolver meld knot-resolver/distro/pkg/deb ~/debian/knot-resolver/debian IOW ~/src/knot-resolver/distro/pkg/deb and ~/debian/knot-resolver/debian should be as close as possible. Of course the changes can flow both ways - I'm happy to update the upstream packaging as well. Feel free to push your changes (if any) to debian/experimental or use your branch as you prefer, I'm always eager to learn how other DDs do things. I'd be especially interested about how you translate the distro/pkg/deb/rules to debian/rules without using the static build_deb dir 樂 There might be variable already defined for this purpose, but I just don't know how to find it. Regards, Daniel Cheers, Jakub OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068951: new upstream (6.x)
Hello, we have a working upstream packages for knot-resolver 6.x alpha at https://pkg.labs.nic.cz/doc/?project=knot-resolver but we've agreed the time has come to get extra testing & feedback through Debian experimental. The only blocker for that is missing python3-json-schema-for-humans needed for docs build which I intend to package later - for now I guess I'll just disable the docs build. I'm working on deep-cleaning the knot-resolver package (silencing the many cries of lintian and such) and syncing it closer with upstream but I'm hitting boundaries of my Debian knowledge so it's slow. For example, upstream package uses meson directly and builds in meson_deb dir, but debian package uses debhelper with obj-x86_64-linux-gnu dir and I don't know howto properly reference it from d/rules without relying on shady strings. I'll take some more time to clean the package properly so that it starts its 6.x life with a clean slate but it's going to hit experimental in upcoming weeks :) Thanks for indicating interest, I'll get it done. Cheers, Jakub Ružička On 4/14/24 08:39, Daniel Baumann wrote: Package: knot-resolver Severity: wishlist Hi, it would be nice if you could upload knot-resolver 6.x to experimental. Regards, Daniel OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1012289: Bug #1012289: Following up on Lintian
Hello, On Wed, 27 Dec 2023 18:54:14 + Simon Quigley wrote: > In most recent Ubuntu cycles, I've taken on the "archive bootstrapping" > responsibility of adding the new Ubuntu codename to Lintian. I remember > having some deeper conversations with the former Lintian maintainer > regarding further contributions and maintenance, but I also recall some > politics, and quite frankly, *I don't care*. Regardless, Lintian is > something I look at every cycle. Same. > I'm writing today to express my concern about the current state of > Lintian maintenance. I already understand that there is an RFH filed > against Lintian, but that has not received any sort of followup since > 2022. The most recent Lintian upload is from March 2023, and as of the > time of writing, there are 26 open merge requests[1]. Currently, there are quite a few merged patches ready in VCS as well, including the one I'm interested in (added support for loong64). Just being able to actually release new version of lintian would be nice. > I also understand that this is a volunteer team. My goal here is not to > diminish the work of the current maintainers in any way, quite the > opposite. I would simply like to ask, "do you need help?" I'm pretty sure we need hands on lintian and I'm willing to help as well. > I'm not volunteering to take over Lintian entirely, nor do I want to. > That being said, I would be motivated to sort through the current MR > list and at least shave off some technical debt. If this is something > you are open to, or if anyone else would be open to this as well, I > think it is a worthwhile effort. Same. My perl-fu isn't strong enough to take over maintainership of core package in perl. > Lintian is crucially important for Debian development as it stands > today. Before sponsoring a package, before uploading our own packages, > and even once in the archive, we run Lintian all the time. I do not > believe it is too late to put some additional minds behind this, to > ensure Lintian survives for years to come. I simply feel as if *someone* > should bump this thread, so we do not lose sight of it. Agreed, lintian is crucially important. What we need is a perl magician willing and able to do the actual lintian release. Who wants to get blamed for breaking a core tool? :) Then folks like you and me can help with fixing individual issues and/or merging MRs. > Thank you for your time. Please do let me know if you have any > questions, or if I can do anything else to help. Thank you for bumping this, we need to get this sorted one way or another. Cheers, Jakub Ružička signature.asc Description: PGP signature
Bug#1054236: ITP: python-nvchecker -- new version checker
Package: wnpp Severity: wishlist Owner: Jakub Ružička X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-nvchecker Version : 2.12 Upstream Contact: lilydjwg * URL : https://github.com/lilydjwg/nvchecker * License : Expat Programming Lang: Python Description : new version checker nvchekcer (short for new version checker) is a Python library and CLI for checking if a new version of some software has been released. It's a handy tool for querying various sources (such as deb/rpm repos or repology) for software versions. Individual version sources are modular and can be easily reused from python code, making nvchecker useful both as a CLI and as a reusable library. Upstream is friendly and active. I plan to maintain this as a part of PythonTeam.
Bug#1043360: Any progress on ITP: python-poetry-dynamic-versioning?
Hi Roland, in the end, I've replaced poetry by hatchling due to various issues and/or I use dunamai manually in affected projects so I no longer have an incentive/opportunity to package and test poetry-dynamic-versioning. Sorry for not following up on my intent, I'm not sure how to properly indicate this on the wnpp bug I haven't really started with the packaging so feel free to start from scratch. At least python-dunamai made it to testing and I've uploaded latest 1.19.0 to sid today so that you can work with the latest and greatest version. If you need an extra pair of eyes for review or something, let me know. Cheers, Jakub Ružička On 10/10/23 15:09, Roland Mas wrote: Hi Jakub, Is there any progress on the package? A package of mine (dioptas) has started depending on it, so it would be nice to have in Debian. Can I help somehow? Is there any beta code somewhere that I could test and help with? Thanks, Roland. OpenPGP_signature Description: OpenPGP digital signature
Bug#1043360: ITP: python-poetry-dynamic-versioning -- dynamic versioning plugin for Poetry
On 23-08-09 15:08, Colin Watson wrote: > How will this sort of thing work when a git tree isn't necessarily > available at binary package build time, since buildds build binary > packages from a source package rather than directly from git and the > source package doesn't usually include a git tree? Is it just a matter > of causing the plugin to exist so that pybuild doesn't fail, but in > practice the version is still going to be set by something that's > actually in the source package? A primary objective is to provide the plugin so that python3 -m build works in general, not limited to package builds. Supporting pybuild correctly out of the box for projects using the plugin is a next step. I'm not sure how it will behave when no VCS is available as in source package. IIRC it replaces version in pyproject.toml during build. So possibly a mechanism that does the same during package build but from d/changelog version might solve this... Hmmm, sounds non-trivial. This will certainly require some testing.
Bug#1043360: ITP: python-poetry-dynamic-versioning -- dynamic versioning plugin for Poetry
Package: wnpp Severity: wishlist Owner: Jakub Ružička X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-poetry-dynamic-versioning Version : 0.25.0 Upstream Contact: Matthew T. Kennerly * URL : https://github.com/mtkennerly/poetry-dynamic-versioning * License : Expat Programming Lang: Python Description : dynamic versioning plugin for Poetry This is a Python plugin for Poetry and Poetry Core to enable dynamic versioning based on tags in your version control system, powered by Dunamai. Many different version control systems are supported, including Git and Mercurial. Poetry is very popular in the Python world and this plugin makes it easy to use dynamic versioning in Poetry-managed projects. Having this in Debian is a prerequisite for packaging of any projects using poetry-dynamic-versioning. Some of existing packages require this in order to update to latest upstream version which started using the plugin. I plan to maintain the package as a part of the PythonTeam alongside its requirement python-dunamai by the same upstream author. I don't expect this package to be maintenance heavy. signature.asc Description: PGP signature
Bug#992341: Acknowledgement (bird2: does not properly take over /etc/bird/bird.conf)
Hello, I'm the new bird2 maintainer and I'm happy to help with this. On 23-08-04 11:08, Jonathan Wiltshire wrote: > Control: retitle -1 bird2: does not properly take over from bird package > Control: severity -1 serious This results in Version 2.0.12-7 of bird2 is marked for autoremoval from testing on Sat 19 Aug 2023. I think this help noone. If any of the two packages should be dropped from testing, it's bird as it's nearing upstream EOL at the end of 2023. > Control: affects -1 + src:bird > > Hi, > > I have just run into this again on the upgrade from bullseye to bookworm. bullseye contains bird_1.6.8-2.1 which is the same as bookworm, so I tested on bookworm as it should be equivalent. > In fact it's worse than just the config files now: bird in its postrm does > things like disabling and masking the systemd units bird2 uses, and attempts > to remove the 'bird' user. I'm unable to reproduce the error on purge after upgrade on my machine, in VM, or in a container: $ apt install bird Setting up bird (1.6.8-2.1+b1) ... $ apt install bird2 Removing bird (1.6.8-2.1+b1) ... Setting up bird2 (2.0.12-7) ... $ apt purge bird Purging configuration files for bird (1.6.8-2.1+b1) ... $ grep bird /etc/passwd bird:x:105:110::/run/bird:/usr/sbin/nologin $ ls /etc/bird bird.conf envvars $ ls /run/bird bird.ctl $ systemctl status bird ● bird.service - BIRD Internet Routing Daemon Loaded: loaded (/lib/systemd/system/bird.service; disabled; preset: enabled) Active: active (running) since Mon 2023-08-07 12:29:43 UTC; 3min 45s ago On further investigation, the collision you describe is fixed by a patch included in bird_1.6.7-1 (2019): https://salsa.debian.org/debian/bird/-/commit/7738791be2 It checks for the ownership of /etc/bird/bird.conf using ucf and only performs actual purging (including the removal of bird user) when it should. > disabling and masking the systemd units bird2 uses I don't see such thing happening in current bird/bird2 package sources: https://salsa.debian.org/debian/bird/-/blob/master/debian/bird.postrm The problems you describe imply upgrading from older bird package than 1.6.7, for example buster 1.6.6-1 but that that's old-old-stable now. This seems fixed both in bookworm and bullseye. IOW upgrading from a fully upgraded bullseye system bird_1.6.8 to bookworm bird2_2.0.12 seems to work. Are you sure you upgraded from latest bullseye bird package? If so, I'm afraid you might be a victim of a fallout from previous package versions. > Please work together to make these two packages cooperate better. They cooperated just fine in my testing with current bullseye/bookworm versions and the above-described patch seems to have addressed exactly this issue. Please provide a reproducer with current (bookworm/bullseye) packages, otherwise I think this was fixed in bird_1.6.7-1. Cheers, Jakub Ružička signature.asc Description: PGP signature
Bug#1033361: ITP: dunamai -- dynamic versioning library and CLI
Package: wnpp Severity: wishlist Owner: Jakub Ružička X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: dunamai Version : 1.16.0 Upstream Contact: Matthew T. Kennerly * URL : https://github.com/mtkennerly/dunamai * License : MIT Programming Lang: Python Description : dynamic versioning library and CLI Dunamai is a Python library and command line tool for producing dynamic, standards-compliant version strings, derived from tags in your version control system. This facilitates uniquely identifying nightly or per-commit builds in continuous integration and releasing new versions of your software simply by creating a tag. I plan to maintain this nice tool along with poetry-dynamic-versioning from the same author which integrates Dunamai into Poetry as a plugin. I have the packaging ready for review in Salsa repo: https://salsa.debian.org/jruzicka/dunamai Salsa CI is green including lintian and simple autopkgtest. I've wrote a manpage as well. Note that this is the first time I've used poetry-core with pyproject pybuild system and it seems to work, awesome stuff! I'd like to join PythonTeam and maintain this alongside other python projects. FYI at the time of writing, Dunamai is packaged for: * Arch/Manjaro * Fedora >= 36 * nixpkgs >= 22.05 signature.asc Description: PGP signature
Bug#993796: bullseye-pu: package knot-resolver/5.3.1-1
On 7/1/22 19:57, Adam D. Barratt wrote: On Fri, 2021-12-03 at 16:59 +0100, Julien Cristau wrote: Control: tag -1 confirmed On Mon, Sep 06, 2021 at 04:21:15PM +, Jakub Ružička wrote: [ Reason ] Fixing bug #991463 (CVE-2021-40083) - potential DoS. [...] Feel free to go ahead and upload, thank you. Ping? Hello, thanks for the ping, the previous mail got lost in my endless inbox and this bug isn't shown in the bug list available from knot-resolver package tracker so I completely lost track. Better late than never, I've uploaded knot-resolver_5.3.1-1+deb11u1 into proposed-updates. Cheers, Jakub Ružička
Bug#993796: bullseye-pu: package knot-resolver/5.3.1-1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jakub.ruzi...@nic.cz
[ Reason ]
Fixing bug #991463 (CVE-2021-40083) - potential DoS.
[ Impact ]
Vulnerability to DoS attack.
[ Tests ]
I've tested the fix manually by running the deckard (DNS test harness)
test sets/resolver/val_iter_high.rpl supplied with the upstream fix.
It's not trivial to setup system for deckard so I've used upstream
Debian bullseye docker image from Knot CI:
docker run -it --privileged
registry.nic.cz/knot/knot-resolver/ci/debian-11:knot-3.0
With current knot-resolver-5.3.1-1 the test failed.
With suggested knot-resolver-5.3.1-1+deb11u1 the test passed.
[ Risks ]
This is a simple backport of upstream fix.
Upstream tests run during package build so chances of something
breaking are small.
[ Checklist ]
[*] *all* changes are documented in the d/changelog
[*] I reviewed all changes and I approve them
[*] attach debdiff against the package in (old)stable
[*] the issue is verified as fixed in unstable
[ Changes ]
Backport of upstream fix for #991463:
https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1169/diffs#c22c39e3a02cdfb0d3d47b16ff46e65d196df19d
diff -Nru knot-resolver-5.3.1/debian/changelog
knot-resolver-5.3.1/debian/changelog
--- knot-resolver-5.3.1/debian/changelog2021-04-12 05:59:28.0
+
+++ knot-resolver-5.3.1/debian/changelog2021-08-31 16:20:00.0
+
@@ -1,3 +1,10 @@
+knot-resolver (5.3.1-1+deb11u1) bullseye; urgency=medium
+
+ * Fix possible assertion failure in NSEC3 edge-case (CVE-2021-40083)
+(Closes: #991463)
+
+ -- Jakub Ružička Tue, 31 Aug 2021 16:20:00 +
+
knot-resolver (5.3.1-1) unstable; urgency=medium
[ Jakub Ružička ]
diff -Nru knot-resolver-5.3.1/debian/gbp.conf
knot-resolver-5.3.1/debian/gbp.conf
--- knot-resolver-5.3.1/debian/gbp.conf 2021-04-12 05:59:28.0 +
+++ knot-resolver-5.3.1/debian/gbp.conf 2021-08-31 16:20:00.0 +
@@ -1,5 +1,5 @@
[DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/bullseye
debian-tag = debian/%(version)s
upstream-branch = upstream
upstream-tag = upstream/%(version)s
diff -Nru
knot-resolver-5.3.1/debian/patches/0002-validator-avoid-assertion-in-an-edge-case.patch
knot-resolver-5.3.1/debian/patches/0002-validator-avoid-assertion-in-an-edge-case.patch
---
knot-resolver-5.3.1/debian/patches/0002-validator-avoid-assertion-in-an-edge-case.patch
1970-01-01 00:00:00.0 +
+++
knot-resolver-5.3.1/debian/patches/0002-validator-avoid-assertion-in-an-edge-case.patch
2021-08-31 16:20:00.0 +
@@ -0,0 +1,58 @@
+From: =?utf-8?b?VmxhZGltw61yIMSMdW7DoXQ=?=
+Date: Mon, 12 Apr 2021 15:23:02 +0200
+Subject: [PATCH] validator: avoid assertion in an edge-case
+
+Case: NSEC3 with too many iterations used for a positive wildcard proof.
+
+To really fix the answers, this also needed fixing the `any_rank` part
+which I somehow forgot in commit 7107faebc :-(
+---
+ lib/dnssec/nsec3.c | 7 +++
+ lib/dnssec/nsec3.h | 1 +
+ lib/layer/validate.c | 3 ++-
+ 3 files changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/lib/dnssec/nsec3.c b/lib/dnssec/nsec3.c
+index e9e536a..f3a48c0 100644
+--- a/lib/dnssec/nsec3.c
b/lib/dnssec/nsec3.c
+@@ -596,6 +596,13 @@ int kr_nsec3_wildcard_answer_response_check(const
knot_pkt_t *pkt, knot_section_
+ if (rrset->type != KNOT_RRTYPE_NSEC3) {
+ continue;
+ }
++ if (knot_nsec3_iters(rrset->rrs.rdata) >
KR_NSEC3_MAX_ITERATIONS) {
++ /* Avoid hashing with too many iterations.
++ * If we get here, the `sname` wildcard probably ends
up bogus,
++ * but it gets downgraded to KR_RANK_INSECURE when
validator
++ * gets to verifying one of these over-limit NSEC3 RRs.
*/
++ continue;
++ }
+ int ret = covers_name(, rrset, sname);
+ if (ret != 0) {
+ return ret;
+diff --git a/lib/dnssec/nsec3.h b/lib/dnssec/nsec3.h
+index 1e316f5..0fdbfce 100644
+--- a/lib/dnssec/nsec3.h
b/lib/dnssec/nsec3.h
+@@ -39,6 +39,7 @@ int kr_nsec3_name_error_response_check(const knot_pkt_t
*pkt, knot_section_t sec
+ * KNOT_ERANGE - NSEC3 RR that covers a wildcard
+ * has been found, but has opt-out flag set;
+ * otherwise - error.
++ * Records over KR_NSEC3_MAX_ITERATIONS are skipped, so you probably get
kr_error(ENOENT).
+ */
+ int kr_nsec3_wildcard_answer_response_check(const knot_pkt_t *pkt,
knot_section_t section_id,
+ const knot_dname_t *sname, int
trim_to_next);
+diff --git a/lib/layer/validate.c b/lib/layer/validate.c
+index cf5dda2..cf5c88a 100644
+--- a/lib/layer/validate.c
b/lib/layer/validate.c
+
Bug#991463: fixed in knot-resolver 5.4.1-1
> I've opened transition bug #993027 Got ack from RT, I've uploaded knot-3.1.1-4 into unstable to start the transition. Do I need to wait until the new knot built on all archs before uploading depending knot-resolver-5.4.1-2 or is there a smart mechanism ensuring build against correct/latest version? > Yes, that I should fix the issue with the next (first) bullseye-point > release after it's been fixed in unstable. I've prepared knot-resolver-5.3.1-2+deb11u1 with the backport of upstream fix in new debian/bullseye salsa branch: https://salsa.debian.org/dns-team/knot-resolver/-/commits/debian/bullseye Please review my changes before I attempt the bullseye upload as I'm new to this process. , Jakub OpenPGP_0xA4254072E373042C.asc Description: OpenPGP public key
Bug#991463: fixed in knot-resolver 5.4.1-1
On 8/26/21 10:42 PM, Santiago Ruano Rincón wrote: > El 26/08/21 a las 14:45, Jakub Ružička escribió: >>> - Includes fix for CVE-2021-40083 (Closes: #991463) >> I've used this magic syntax found throughout the changelog and it closed >> the bug upon experimental upload, which isn't what I expected. Please >> reopen as needed, I'm not yet familiar with handling bugs wrt different >> Debian branches. >> > Why would you like to reopen the bug? The BTS knows it is still to be > fixed in unstable. Take a look at the image at the top right of the bug > report page: > https://bugs.debian.org/cgi-bin/version.cgi?absolute=0;found=knot-resolver%2F5.3.1-1;info=1;fixed=knot-resolver%2F5.4.1-1;collapse=1;package=knot-resolver Aha! I didn't notice that all-important image at all, thanks. So BTS is as smart as I hoped 拾 Please disregard my prior confusion. > >> Regardless, experimental knot-resolver-5.4.1-1 built against >> experimental knot-3.1.1-3 so I'll try to proceed with the transition >> which should fix the bug for sid. > Awesome, thanks! My pleasure! I've opened transition bug #993027 > >> After that I plan to cherry-pick the fix for next bullseye-point release. > Did you have any feedback from the security team? Yes, that I should fix the issue with the next (first) bullseye-point release after it's been fixed in unstable. As the sid fix is in progress, I'll prepare the bullseye release (at debian/bullseye Salsa branch I think) and follow instructions at https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable , Jakub OpenPGP_signature Description: OpenPGP digital signature
Bug#993027: transition: knot 3.0 to 3.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, in order to update knot to latest 3.1.1, its only reverse dependency knot-resolver needs to be updated to >= 5.4 which supports new knot 3.1 API/ABI. I've tested this in experimental - knot-resolver-5.4.1-1 built against knot-3.1.1-3. Both packages have autopkgtests as well upstream tests enabled. Ben file: title = "knot"; is_affected = .depends ~ /\b(libknot12|libzscanner4|libknot11|libzscanner3)\b/; is_good = .depends ~ /\b(libknot12|libzscanner4)\b/; is_bad = .depends ~ /\b(libknot11|libzscanner3)\b/; Thank you. Cheers, Jakub
Bug#991463: fixed in knot-resolver 5.4.1-1
> - Includes fix for CVE-2021-40083 (Closes: #991463) I've used this magic syntax found throughout the changelog and it closed the bug upon experimental upload, which isn't what I expected. Please reopen as needed, I'm not yet familiar with handling bugs wrt different Debian branches. Regardless, experimental knot-resolver-5.4.1-1 built against experimental knot-3.1.1-3 so I'll try to proceed with the transition which should fix the bug for sid. After that I plan to cherry-pick the fix for next bullseye-point release. Cheers, Jakub OpenPGP_signature Description: OpenPGP digital signature
Bug#932087: knot-host: Add to update-alternatives
Hello, thanks for handling the bind9 side of things! I'm happy to update the knot source package with update-alternatives functionality as soon as it's implemented in bind9 package which is a necessary prerequisite to avoid package file conflicts if I understand correctly. Cheers, Jakub On Wed, 28 Apr 2021 00:15:39 +0200 Daniel Baumann wrote: > tag 932087 patch > thanks > > Hi, > > I've attached patches that we're using in our Debian derrivate for this. > I've also send the required patches to a bugreport against src:bind9 > (will add a "block by" to this bug after having recieved the bugnumber). > > Regards, > Daniel > OpenPGP_signature Description: OpenPGP digital signature
Bug#900374: updated knot.service file available since knot-3.0.1-1
I've updated debian/knot.service file from upstream which already addressed described issues. It's been synced in knot-3.0.1-1 debian package release and it remains in sync as of 3.0.4. You can look at commit cc65f515c1: https://salsa.debian.org/dns-team/knot-dns/-/commit/cc65f515c1 I believe this issue is solved and can be closed. Cheers, Jakub Ružička
Bug#974080: ITP: lua-binaryheap -- Binary heap implementation in lua
On 11/20/20 10:34 AM, Santiago Ruano Rincón wrote: > El 19/11/20 a las 22:04, Santiago Ruano Rincón escribió: >> El 19/11/20 a las 17:56, Santiago Ruano Rincón escribió: >> Before uploading a wanted to take a look at the debian/watch file. >> Attached you can find a work-in-progress version. I cannot work more on >> it today. There is still an error after downloading the file. Would you >> like to fix it? (c.f. man uscan) >> >> Cheers, >> >> -- S >> version=4 >> opts="filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/-$1\.tar\.gz/,uversionmangle=s/v/./" >> \ >> https://github.com/Tieske/binaryheap.lua/tags .*/version_?(\d\S*)\.tar\.gz > Somehow I messed up my working files (*). The attached (simpler) d/watch > seems to work. Could you please test it? Thanks, it works for me too so I added this to salsa and CI confirms we're free of lintian warnings/infos ᕕ( ᐛ )ᕗ https://salsa.debian.org/jruzicka/lua-binaryheap/-/jobs/1178434#L27 I also signed all commits in debian/master as you suggested elsewhere. > Cheers, > > -- Santiago > > (*) I need to stop working late. I concur, workaholism is dangerous you know... Cheers, Jakub signature.asc Description: OpenPGP digital signature
Bug#974080: ITP: lua-binaryheap -- Binary heap implementation in lua
On 11/17/20 4:41 PM, Santiago Ruano Rincón wrote: > El 09/11/20 a las 13:31, Jakub Ružička escribió: >> Package: wnpp >> Severity: wishlist >> Owner: Jakub Ružička >> >> * Package name: lua-binaryheap >> Version : 0.4 >> Upstream Author : Thijs Schreijer >> * URL : https://github.com/Tieske/binaryheap.lua >> * License : MIT >> Programming Lang: lua >> Description : binary heap implementation in lua >> >> binaryheap.lua is a binary heap (binary tree) implementaion in lua. >> > ... > > Jakub, thanks for packaging lua-binaryheap. Thanks for fast respone, Santiago :) > > Two lintian "major" comments from your current repo: > > W: lua-binaryheap source: ancient-standards-version 3.9.8 (released > 2016-04-06) (current is 4.5.0) > W: lua-binaryheap source: package-uses-deprecated-debhelper-compat-version 9 > > Do you have any reason for that standards-version and > debhelper-compat-version? Upstream packages support older distros including ubuntu xenial so it's just a leftover - I've updated these to current. > > These other lintian minor warnings could be easily fixed: > > I: lua-binaryheap: capitalization-error-in-description lua Lua > I: lua-binaryheap source: debian-watch-file-is-missing > I: lua-binaryheap source: vcs-field-not-canonical Vcs-Git > > Could you please consider them? I've fixed all of them except debian-watch-file-is-missing because upstream is using one the weirdest version tag scheme I've witnessed (version_0v4) and I'm not familiar with watch files enough to solve this efficiently. I've pushed fixed debian/master and you can see lintian output in CI: https://salsa.debian.org/jruzicka/lua-binaryheap/-/jobs/1176088#L27 Thank you for Salsa CI suggestion and help with enabling it. I like it and I'll probably use it for other packages too. Cheers, Jakub signature.asc Description: OpenPGP digital signature
Bug#974080: ITP: lua-binaryheap -- Binary heap implementation in lua
Package: wnpp Severity: wishlist Owner: Jakub Ružička * Package name: lua-binaryheap Version : 0.4 Upstream Author : Thijs Schreijer * URL : https://github.com/Tieske/binaryheap.lua * License : MIT Programming Lang: lua Description : binary heap implementation in lua binaryheap.lua is a binary heap (binary tree) implementaion in lua. - lua-binaryheap package is a missing requirement of lua-http package which is already included in Debian as described in bug #958665 - this package is an indirect requirement of Knot Resolver which I intend to package for Debian. upstream Knot Resolver package repos currntly use custom lua-binaryheap package which I use as a base for the Debian package. - binaryheap.lua is a small and focused project which started in 2015 with last activity in 2019 so I assume it's stable/mature with changes unlikely thus it should be easy to maintain. - I'm not a debian Dev but I try to become Maintainer with active sponsor as a part of Debian DNS team. I'm willing to maintain the package in forseeable future, especially as I expect minimal or no changes.
Bug#587976: fails to open image from URI
Anything including file:/// doesn't work. For example: http://www.debian.org/Pics/openlogo-50.png -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524630: fixed
Adding forgotten Screen 0 Screen 0 0 to ServerLayout solves the problem, but this behaviour(crash on missing option in config file) is not nice. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
