Bug#1034361: haveged: autopkgtest fails on bookworm kernel: service fails to start
Hi, I looked into haveged a while back because I ran into some issue. (Don't remember exactly what.) Apparently, the upstream systemd-service contains a conditional to only start on old kernels. The strategies that haveged performed are apparently incorporated into the kernel. That makes haveged an optional "extra" contribution to entropy, but no longer necessary. A issue on either haveged's github or Qubes-OS's discussed pros/cons for use in VMs and IIRC the benefits are doubtful due to depending on healthy input entropy and characteristics of VMs (as opposed to actual machines). Running haveged as userspace tool only has uses because applications/scripts can use it as an API to randomness. However, the issue for running haveged userspace while the systemd-service is running, was broken for a while. (Not sure what the status is now.) You would need to investigate in detail, as I am not knowledgeable on this subject, but from my understanding one would run haveged service on newer kernels solely for an overabundance of caution, rather than a necessity to seed the entropy pool. There is an explanation with references on the haveged homepage. The issue should be that *if* the service is running, *then* userspace cannot start. Original Message On Apr 14, 2023, 9:47 PM, Cyril Brulebois < k...@debian.org> wrote: Paul Gevers (2023-04-13): > The release team has announced [1] that failing autopkgtest on amd64 and > arm64 are considered RC in testing. [Release Team member hat on] Because > we're currently in the hard freeze for bookworm, I have marked this bug as > bookworm-ignore, however, I have a strong suspicion that it points out that > the package is broken. Targeted fixes are still welcome. The daemon starts just fine in d-i. The daemon starts just fine from the service unit on baremetal. I'd like extreme caution to be used before considering removing this package. After the 5.4 announce, trying to drop it from the installer didn't go quite well[1]. Maybe that's indeed better after 5.6, but I really don't want to investigate dropping it from the installer for Bookworm. 1. https://lists.debian.org/debian-boot/2020/03/msg00182.html and replies. Cheers, -- Cyril Brulebois (k...@debian.org) D-I release manager -- Release team member -- Freelance Consultant
Bug#1033144: [Firewalld] exit with status-code cleaned up rules in firewall
Package: firewalld Version: 1.3.0-1~bpo11+1 I do not know exactly how to reproduce, so I will describe my facts and suspicions best I can. I checked current status of the firewall on my system (`firewalld`) and discovered it was not running and in addition, the rules were not present in nftables (`sudo nft list ruleset`). Manually restarting the service restored operation. There were no changes to the firewall configuration involved. (that I can recall) Journald showed an entry: ``` systemd[1]: firewalld.service: Main process exited, code=exited, status=3/NOTIMPLEMENTED systemd[1]: firewalld.service: Failed with result 'exit-code'. ``` I do not know what caused the error with this exit-code, so I am not sure how to reproduce. I am using some software that creates a separate network-namespace which includes firewall rules, so there may be exceptional circumstances it cannot handle. Regardless, I suspect there is an error in handling this use case. There are three factors at play: 1.) firewalld exited suddenly. 2.) systemd service configuration did not properly restart it. 3.) configuration: the firewall rules were cleaned up (I suspect due to default config to clean up rules at exit.) I would expect either: a) immediate restart by systemd to ensure the firewall is operational. Or b) the firewall-rules not being cleaned up as to not drop protection of the system if an error occurs. So one solution *may be* to have the configuration *not* clean up firewall rules on exit. Another may be to configure the systemd service file to force restarts on certain exit codes, or rather everything but the expected success exit code. A quick check showed that you can configure broadly to restart on anything but success, or you can configure specific actions on specific exit codes. Regards, Danny
Bug#1001039: panfrost: missing dependency in modinfo causes issues during early loading (dmesg)
Package: linux-signed-arm64 Version: 5.10.70+1 Version: 5.14.9+2~bpo11+1 The 'panfrost' driver for the variety of Mali graphics devices requires a GPU scaling governor to be available. Either this version of the source has not yet been patched, or the patch only affects a statically bound governor. In any case, In the above versions, I've had to define the dependency myself. (governor_simpleondemand <- gpu_sched <- panfrost, but neither panfrost or gpu_sched explicitly depends on governor_simpleondemand) In the original case -- the device is Pinebook Pro -- initialization of 'panfrost' would fail repeatedly, causing Xorg to fail to detect the panfrost device and start with LLVMpipe graphics device. Only after reloading panfrost (remove + install) and restarting the desktop manager, would panfrost be detected. A (temporary) fix would be a 'modprobe.d' config file with the line: `softdep panfrost pre: governor_simpleondemand`. This ensures that panfrost initializes successfully on early init. I'm not sure if this is the appropriate package to report this bug on. So please correct if necessary. Kind regards PS: I had to type the 'softdep' line from memory, so please read over it once to check for silly typos.
Bug#999811: HAVEGED is obsolete starting from linux kernel 5.6
Package: haveged Version: 1.9.14-1 HAVEGED is no longer considered necessary on any linux kernel 5.6 and greater. The site itself recommends[1] not using it as kernel random support is sufficiently improved, making haveged obsolete. Upstream uses a systemd service file with starting conditions[2] for exactly this reason. Incidentally, issue 998382 notes issues with running haveged both as service and as userspace application. For recent kernels (e.g. Debian bullseye) this does not need to be an issue per se. I want to point this out to ensure it is on the radar. I can imagine such a change might be too invasive on stable. [1]: https://github.com/jirka-h/haveged/blob/master/README.md [2]: https://raw.githubusercontent.com/jirka-h/haveged/master/contrib/Fedora/haveged.service
Bug#993949: dnscrypt-proxy fails to use address from DoH servers on start-up, resorts to system resolver
Hi Eric, It has been quiet for a while. I'd like to hear what your thoughts are on this. Kind regards, Danny ‐‐‐ Original Message ‐‐‐ On Friday, September 10th, 2021 at 5:54 PM, Danny van Heumen wrote: > Hi Eric, > > Indeed, a fix was implemented. > > Yes. I think that the address from the public-resolvers document should take > precedence over the address from an arbitrary resolver. > > Kind regards, > > Danny > > ‐‐‐ Original Message ‐‐‐ > > On Friday, September 10th, 2021 at 7:40 AM, Eric Dorland e...@debian.org > wrote: > > > Control: forwarded -1 https://github.com/DNSCrypt/dnscrypt-proxy/issues/1861 > > > > Thanks for the report. I've marked it forwarded upstream, and the fix > > > > appears to be in > > > > https://github.com/DNSCrypt/dnscrypt-proxy/commit/0f00cd27f92cee434336c6d6cde9df26286d8dbe. > > Do > > > > you think this is serious enough to warrant cherrypicking into the > > > > package or should we just wait for the next upstream release? > > > > - Danny van Heumen (da...@dannyvanheumen.nl) wrote: > > > > > Package: dnscrypt-proxy > > > > > > Version: 2.0.45+ds1-1+b5 > > > > > > Severity: normal > > > > > > X-Debbugs-Cc: da...@dannyvanheumen.nl > > > > > > Dear Maintainer, > > > > > > A bug was recently found where DNS stamp information is used > > > > > > incorrectly to fill the resolver cache on initialization. > > > > > > In short, DNS stamps of the various DNSCrypt/DoH/etc. resolvers include > > > > > > hostname and port information for finding the server. Additionally, it > > > > > > (optionally) includes an IPv4/IPv6 address to find the server without > > > > > > nameserver resolution for bootstrapping/initialization purposes, in such > > > > > > cases where it is unreliable or unavailable. > > > > > > dnscrypt-proxy intends to use this address in all cases - caching the > > > > > > address with unlimited lifetime, but accidentally stored it with incorrect > > > > > > key "hostname with optional port number". Subsequently loading from a key > > > > > > "hostname" will fail to load the address from the cache. > > > > > > Consequently, in all cases of DoH servers that include a port number, > > > > > > the bootstrapping address could not be loaded and dnscrypt-proxy needs to > > > > > > rely on the system resolver to look up the address anyways. > > > > > > The details can be found in > > > > > > https://github.com/DNSCrypt/dnscrypt-proxy/issues/1861 > > > > > > and a side-effect was under discussion at > > > > > > https://github.com/DNSCrypt/dnscrypt-proxy/discussions/1828 > > > > > > It is beneficial to use the DNS stamp information both for speed and > > > > > > reliability of resolution. > > > > > > Kind regards, > > > > > > Danny > > > > > > PS: I am not familiar with bug reporting or bug handling in Debian. Please > > > > > > let me know if I should do things differently. I may be able to help if > > > > > > you want to cherry-pick the bugfix from upstream. (Although I am not > > > > > > affiliated with the project in any way.) > > > > > > -- System Information: > > > > > > Debian Release: 11.0 > > > > > > APT prefers stable-security > > > > > > APT policy: (500, 'stable-security'), (500, 'stable') > > > > > > Architecture: amd64 (x86_64) > > > > > > Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) > > > > > > Kernel taint flags: TAINT_USER > > > > > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > > > LANGUAGE=en_US:en > > > > > > Shell: /bin/sh linked to /usr/bin/dash > > > > > > Init: systemd (via /run/systemd/system) > > > > > > LSM: AppArmor: enabled > > > > > > Versions of packages dnscrypt-proxy depends on: > > > > > > ii adduser 3.118 > > > > > > ii libc6 2.31-13 > > > > > > ii lsb-base 11.1.0 > > > > > > dnscrypt-proxy recommends no packages. > > > > > > Versions of packages dnscrypt-proxy suggests: > > > > > > pn resolvconf > > > > > > -- Configuration Files: > > > > > > /etc/dnscrypt-proxy/dnscrypt-proxy.toml changed [not included] > > > > > > -- no debconf information > > > > Eric Dorland e...@kuroneko.ca > > > > 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
Bug#993949: dnscrypt-proxy fails to use address from DoH servers on start-up, resorts to system resolver
Actually, what I said below is meaningless. The fact is, that precedence was chosen by design. The fix we're talking about here merely ensures consistent behavior under all circumstances. (Correcting mainly because I'm annoyed by my own inaccurate response.) ‐‐‐ Original Message ‐‐‐ On Friday, September 10th, 2021 at 5:54 PM, Danny van Heumen wrote: > Hi Eric, > > Indeed, a fix was implemented. > > Yes. I think that the address from the public-resolvers document should take > precedence over the address from an arbitrary resolver. > > Kind regards, > > Danny > > ‐‐‐ Original Message ‐‐‐ > > On Friday, September 10th, 2021 at 7:40 AM, Eric Dorland e...@debian.org > wrote: > > > Control: forwarded -1 https://github.com/DNSCrypt/dnscrypt-proxy/issues/1861 > > > > Thanks for the report. I've marked it forwarded upstream, and the fix > > > > appears to be in > > > > https://github.com/DNSCrypt/dnscrypt-proxy/commit/0f00cd27f92cee434336c6d6cde9df26286d8dbe. > > Do > > > > you think this is serious enough to warrant cherrypicking into the > > > > package or should we just wait for the next upstream release? > > > > - Danny van Heumen (da...@dannyvanheumen.nl) wrote: > > > > > Package: dnscrypt-proxy > > > > > > Version: 2.0.45+ds1-1+b5 > > > > > > Severity: normal > > > > > > X-Debbugs-Cc: da...@dannyvanheumen.nl > > > > > > Dear Maintainer, > > > > > > A bug was recently found where DNS stamp information is used > > > > > > incorrectly to fill the resolver cache on initialization. > > > > > > In short, DNS stamps of the various DNSCrypt/DoH/etc. resolvers include > > > > > > hostname and port information for finding the server. Additionally, it > > > > > > (optionally) includes an IPv4/IPv6 address to find the server without > > > > > > nameserver resolution for bootstrapping/initialization purposes, in such > > > > > > cases where it is unreliable or unavailable. > > > > > > dnscrypt-proxy intends to use this address in all cases - caching the > > > > > > address with unlimited lifetime, but accidentally stored it with incorrect > > > > > > key "hostname with optional port number". Subsequently loading from a key > > > > > > "hostname" will fail to load the address from the cache. > > > > > > Consequently, in all cases of DoH servers that include a port number, > > > > > > the bootstrapping address could not be loaded and dnscrypt-proxy needs to > > > > > > rely on the system resolver to look up the address anyways. > > > > > > The details can be found in > > > > > > https://github.com/DNSCrypt/dnscrypt-proxy/issues/1861 > > > > > > and a side-effect was under discussion at > > > > > > https://github.com/DNSCrypt/dnscrypt-proxy/discussions/1828 > > > > > > It is beneficial to use the DNS stamp information both for speed and > > > > > > reliability of resolution. > > > > > > Kind regards, > > > > > > Danny > > > > > > PS: I am not familiar with bug reporting or bug handling in Debian. Please > > > > > > let me know if I should do things differently. I may be able to help if > > > > > > you want to cherry-pick the bugfix from upstream. (Although I am not > > > > > > affiliated with the project in any way.) > > > > > > -- System Information: > > > > > > Debian Release: 11.0 > > > > > > APT prefers stable-security > > > > > > APT policy: (500, 'stable-security'), (500, 'stable') > > > > > > Architecture: amd64 (x86_64) > > > > > > Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) > > > > > > Kernel taint flags: TAINT_USER > > > > > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > > > LANGUAGE=en_US:en > > > > > > Shell: /bin/sh linked to /usr/bin/dash > > > > > > Init: systemd (via /run/systemd/system) > > > > > > LSM: AppArmor: enabled > > > > > > Versions of packages dnscrypt-proxy depends on: > > > > > > ii adduser 3.118 > > > > > > ii libc6 2.31-13 > > > > > > ii lsb-base 11.1.0 > > > > > > dnscrypt-proxy recommends no packages. > > > > > > Versions of packages dnscrypt-proxy suggests: > > > > > > pn resolvconf > > > > > > -- Configuration Files: > > > > > > /etc/dnscrypt-proxy/dnscrypt-proxy.toml changed [not included] > > > > > > -- no debconf information > > > > Eric Dorland e...@kuroneko.ca > > > > 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
Bug#993949: dnscrypt-proxy fails to use address from DoH servers on start-up, resorts to system resolver
Hi Eric, Indeed, a fix was implemented. Yes. I think that the address from the public-resolvers document should take precedence over the address from an arbitrary resolver. Kind regards, Danny ‐‐‐ Original Message ‐‐‐ On Friday, September 10th, 2021 at 7:40 AM, Eric Dorland wrote: > Control: forwarded -1 https://github.com/DNSCrypt/dnscrypt-proxy/issues/1861 > > Thanks for the report. I've marked it forwarded upstream, and the fix > > appears to be in > > https://github.com/DNSCrypt/dnscrypt-proxy/commit/0f00cd27f92cee434336c6d6cde9df26286d8dbe. > Do > > you think this is serious enough to warrant cherrypicking into the > > package or should we just wait for the next upstream release? > > - Danny van Heumen (da...@dannyvanheumen.nl) wrote: > > > Package: dnscrypt-proxy > > > > Version: 2.0.45+ds1-1+b5 > > > > Severity: normal > > > > X-Debbugs-Cc: da...@dannyvanheumen.nl > > > > Dear Maintainer, > > > > A bug was recently found where DNS stamp information is used > > > > incorrectly to fill the resolver cache on initialization. > > > > In short, DNS stamps of the various DNSCrypt/DoH/etc. resolvers include > > > > hostname and port information for finding the server. Additionally, it > > > > (optionally) includes an IPv4/IPv6 address to find the server without > > > > nameserver resolution for bootstrapping/initialization purposes, in such > > > > cases where it is unreliable or unavailable. > > > > dnscrypt-proxy intends to use this address in all cases - caching the > > > > address with unlimited lifetime, but accidentally stored it with incorrect > > > > key "hostname with optional port number". Subsequently loading from a key > > > > "hostname" will fail to load the address from the cache. > > > > Consequently, in all cases of DoH servers that include a port number, > > > > the bootstrapping address could not be loaded and dnscrypt-proxy needs to > > > > rely on the system resolver to look up the address anyways. > > > > The details can be found in > > > > https://github.com/DNSCrypt/dnscrypt-proxy/issues/1861 > > > > and a side-effect was under discussion at > > > > https://github.com/DNSCrypt/dnscrypt-proxy/discussions/1828 > > > > It is beneficial to use the DNS stamp information both for speed and > > > > reliability of resolution. > > > > Kind regards, > > > > Danny > > > > PS: I am not familiar with bug reporting or bug handling in Debian. Please > > > > let me know if I should do things differently. I may be able to help if > > > > you want to cherry-pick the bugfix from upstream. (Although I am not > > > > affiliated with the project in any way.) > > > > -- System Information: > > > > Debian Release: 11.0 > > > > APT prefers stable-security > > > > APT policy: (500, 'stable-security'), (500, 'stable') > > > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) > > > > Kernel taint flags: TAINT_USER > > > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > > LANGUAGE=en_US:en > > > > Shell: /bin/sh linked to /usr/bin/dash > > > > Init: systemd (via /run/systemd/system) > > > > LSM: AppArmor: enabled > > > > Versions of packages dnscrypt-proxy depends on: > > > > ii adduser 3.118 > > > > ii libc6 2.31-13 > > > > ii lsb-base 11.1.0 > > > > dnscrypt-proxy recommends no packages. > > > > Versions of packages dnscrypt-proxy suggests: > > > > pn resolvconf > > > > -- Configuration Files: > > > > /etc/dnscrypt-proxy/dnscrypt-proxy.toml changed [not included] > > > > -- no debconf information > > Eric Dorland e...@kuroneko.ca > > 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
Bug#993949: dnscrypt-proxy fails to use address from DoH servers on start-up, resorts to system resolver
Package: dnscrypt-proxy Version: 2.0.45+ds1-1+b5 Severity: normal X-Debbugs-Cc: da...@dannyvanheumen.nl Dear Maintainer, A bug was recently found where DNS stamp information is used incorrectly to fill the resolver cache on initialization. In short, DNS stamps of the various DNSCrypt/DoH/etc. resolvers include hostname and port information for finding the server. Additionally, it (optionally) includes an IPv4/IPv6 address to find the server without nameserver resolution for bootstrapping/initialization purposes, in such cases where it is unreliable or unavailable. dnscrypt-proxy intends to use this address in all cases - caching the address with unlimited lifetime, but accidentally stored it with incorrect key "hostname with optional port number". Subsequently loading from a key "hostname" will fail to load the address from the cache. Consequently, in all cases of DoH servers that include a port number, the bootstrapping address could not be loaded and dnscrypt-proxy needs to rely on the system resolver to look up the address anyways. The details can be found in https://github.com/DNSCrypt/dnscrypt-proxy/issues/1861 and a side-effect was under discussion at https://github.com/DNSCrypt/dnscrypt-proxy/discussions/1828 It is beneficial to use the DNS stamp information both for speed and reliability of resolution. Kind regards, Danny PS: I am not familiar with bug reporting or bug handling in Debian. Please let me know if I should do things differently. I may be able to help if you want to cherry-pick the bugfix from upstream. (Although I am not affiliated with the project in any way.) -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dnscrypt-proxy depends on: ii adduser 3.118 ii libc6 2.31-13 ii lsb-base 11.1.0 dnscrypt-proxy recommends no packages. Versions of packages dnscrypt-proxy suggests: pn resolvconf -- Configuration Files: /etc/dnscrypt-proxy/dnscrypt-proxy.toml changed [not included] -- no debconf information
