Bug#1065247: new lighttpd servers mangled file names
FYI, I submitted a patch to Debian on 19 March, over two months ago. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067126 It has taken Debian developers (volunteers) over 10 weeks (!!!) to pick up a simple patch that I packaged for them and signed on salsa.debian.org. :(
Bug#1067126: RFS: lighttpd/1.4.76-3 -- light, fast, functional web server
Gianfranco, thank you for sponsoring this upload. > Please some nitpicks for a future upload > 1) wait for the sponsor upload before tagging, >many of your entries were never uploaded ack. Still, this seems like unnecessary latency between humans once a Debian developer volunteer picks up the sponsorship-request. This sponsorship-request bug was filed March 19 and as I write this, today is May 29, over two months later. > 2) don't create new entries if the previous ones are not yet in the archive Should the now-incorrect tags in the repository be deleted and re-tagged? I prefer not to move tags once the tag matches code on the master branch, hence why I created new entries in the changelog and new tags. Also, this sounds like a fragile limitation for which a bug should be filed. When uploading, it should be possible to programmatically query the current version in the archive, find that changelog entry, and then process the newer entries with versions between the current version in the archive and the new version being submitted. Cheers, Glenn
Bug#1067126: RFS: lighttpd/1.4.76-3 -- light, fast, functional web server
lighttpd-1.4.76-3 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.76-3 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 lighttpd (1.4.76-3) unstable; urgency=medium * Patch to fix graceful shutdown timeout
Bug#1067126: RFS: lighttpd/1.4.76-2 -- light, fast, functional web server
lighttpd-1.4.76-2 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.76-2 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 lighttpd (1.4.76-2) unstable; urgency=medium * Fix FTBFS Linux on SPARC * Declare compliance with policy 4.7.0 - no changes needed.
Bug#1067126: RFS: lighttpd/1.4.76-1 -- light, fast, functional web server
lighttpd-1.4.76-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.76-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 lighttpd (1.4.76-1) unstable; urgency=medium * New upstream version 1.4.76 * Detect VU#421644 HTTP/2 CONTINUATION Flood * Avoid CVE-2024-3094 xz supply chain attack
Bug#1067126: RFS: lighttpd/1.4.75-1 -- light, fast, functional web server
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear mentors, I am looking for a DD sponsor for my package "lighttpd": https://salsa.debian.org/debian/lighttpd/ I am an upstream lighttpd developer and have participated in maintaining lighttpd on Debian for a number of years. I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd lighttpd-1.4.75-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.75-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Thank you. Glenn P.S. There is a regression in lighttpd 1.4.74 that is fixed with a patch in tag lighttpd-1.4.74-3 on salsa.d.o. Does that need to go through the release process for the changelog entries to automatically close bugs? If so, please upload 1.4.74-3 to Unstable, and in a few days 1.4.75-1. With the time64 migration, everything is stuck in Unstable, anyway. Note: with lighttpd 1.4.74-3, lighttpd is time64 agnostic and so this package could safely go to Testing, and will work properly (with 64-bit time_t) on 32-bit platforms even without the rest of the time64 libs.
Bug#1067053: qa.debian.org: Documented policy needed for bug archival + archival transparency needed
Package: qa.debian.org Severity: normal X-Debbugs-Cc: debbug.qa.debian@sideload.33mail.com Control: affects -1 +www.debian.org There are essentially no documented policies or procedures for bug report archival. The only disclosure on the website is here: https://www.debian.org/Bugs/server-control#unarchive It’s so minimal I will just copy it here: > archive bugnumber > > Archives a bug that had been archived at some point in the past but > is currently not archived if the bug fulfills the requirements for > archival, ignoring time. > > unarchive bugnumber > > Unarchives a bug that was previously archived. Unarchival should > generally be coupled with reopen and found/fixed as > appropriate. Bugs that have been unarchived can be archived using > archive assuming the non-time based archival requirements are > met. You should not be using unarchive to make trivial changes to > archived bugs, such as changing the submitter; its primary purpose > is to allow for the reopening of bugs which have been archived > without the intervention of BTS administrators. That’s it. There is no further guidance in the www.debian.org/Bugs/* tree. It seems to say artificial archival can only be requested on bugs that were previously archived. Yet there are bugs that have been archived just 1 month after opening. This indicates undisclosed / non-transparent procedures are in play. Then it says unarchival should only be requested on naturally archived bugs (due to aging). Should that “policy” be revisited? Is archival a synonym for bug closure? What are the reasons a bug report can or should be artificially archived by intervention? The Debian Social Contract (DSC) has a transparency clause: > 3. We will not hide problems > >We will keep our entire bug report database open for public view >at all times. Reports that people file online will promptly >become visible to others. That’s a good start but IMO it would improve quality if that were to go a step further and (by extension) state that open public /discussion/ of problems will also be facilitated. The archival of a bug report has the speech/idea-chilling effect of closing it and blocking further discussion. This bug report is motivated by another. I thought of a new feature that would improve the reportbug application. A search of bug reports showed that someone already put forward the same idea (bug 1002906). There’s more to say on that, so I responded. My contribution was suppressed because the bug was archived. In fact it was archived just a month or so after it was opened. Big transparency problem: even the verbose view of the bug report showing extraneous control messages gives no indication of /how/ or /why/ the bug was archived, or /who/ initiated it. We can only guess that based on the very short timeframe open that it was archived by intervention. Which means requesting unarchival goes against what I quoted from the server control page. I don’t imagine that whoever initiated the archival actually intended to suppress the discussion. It was likely maintainers looking to get the bug report out of their view (out of sight, out of mind) for organizational reasons. But since archival has the effect of suppressing discussion, it’s not a proper mechanism for that. ** Proposal ** I propose several actions to remedy all this. ① Revision to the DSC to include public discourse w.r.t bug reports. ② Drafting a clear and comprehensive policy informing everyone as to proper and improper usage of bug archival and unarchival. Adapt Bugs/server-control#unarchive as needed. ③ Modify the BTS as needed to include basic archival information in the public views of bug reports, such as: * who initiated the archival * why it was archived (age or intervention; and if intervention then the rationale for the intervention) ④ Reopen bug 1002906 if it’s deemed to have been archived without good cause.
Bug#1064572: RFS: lighttpd/1.4.74-1 -- light, fast, functional web server
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear mentors, I am looking for a DD sponsor for my package "lighttpd": https://salsa.debian.org/debian/lighttpd/ I am an upstream lighttpd developer and have participated in maintaining lighttpd on Debian for a number of years. I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd lighttpd-1.4.74-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.74-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Thank you. Glenn
Bug#1061602: vmtouch invalid option parsing
Package: vmtouch Version: 1.3.1-2 Severity: important looking at the cmdline arguments the service actually provides to vmtouch it is mangling the provided ones and thereby creates invalid arguments. esp. for "-p 0-50k" which becomes "-p 0 50" and "-P /run/vmtouch" which somehow gets joined together with the first provided item to cache. `cat /etc/default/vmtouch`: ``` # Change to yes to enable running vmtouch as a daemon ENABLE_VMTOUCH=yes # User and group to run as VMTOUCH_USER_GROUP=root:root # Whitespace separated list of files and directories for vmtouch to operate on VMTOUCH_FILES="/folder001/ /folder002/ /folder003/ /folder004/ /folder005/ /folder006/" # Options to pass to vmtouch itself. See vmtouch(8). VMTOUCH_OPTIONS="-d -L -p 0-50k -f -P /run/vmtouch.pid" ``` `systemctl status vmtouch.service | grep CGroup -A1`: ``` CGroup: /system.slice/vmtouch.service └─10341 /usr/bin/vmtouch -d -L -p 0 50 "" -f -P /run/vmtouch.pid /folder001 "" /folder002 "" /folder003 "" /folder004 /folder005 /folder006 ``` `dpkg --search vmtouch` ``` vmtouch: /etc/init.d/vmtouch vmtouch: /usr/share/doc/vmtouch/TODO vmtouch: /usr/share/doc/vmtouch/TUNING.md vmtouch: /etc/default/vmtouch vmtouch: /usr/share/doc/vmtouch/changelog.gz vmtouch: /usr/share/doc/vmtouch/changelog.Debian.gz vmtouch: /usr/share/doc/vmtouch vmtouch: /usr/share/doc/vmtouch/copyright vmtouch: /usr/bin/vmtouch vmtouch: /usr/share/doc/vmtouch/README.md vmtouch: /usr/share/man/man8/vmtouch.8.gz ``` `dpkg --list vmtouch`: ``` Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---== ii vmtouch1.3.1-2 amd64Portable file system cache diagnostics and control ``` `dpkg --status vmtouch` ``` Package: vmtouch Status: install ok installed Priority: optional Section: admin Installed-Size: 68 Maintainer: Lucas Nussbaum Architecture: amd64 Version: 1.3.1-2 Depends: lsb-base (>= 3.0-6), libc6 (>= 2.15) Pre-Depends: init-system-helpers (>= 1.54~) Conffiles: /etc/default/vmtouch ed573c189b71c232b5fcd2057b634b51 /etc/init.d/vmtouch 45af12b8bbff820fbbe73145fce96c19 Description: Portable file system cache diagnostics and control vmtouch is a tool for learning about and controlling the file system cache of unix and unix-like systems. It can discover which files the OS is caching, tell the OS to cache or evict some files or regions of files, lock files into memory so the OS won't evict them, and more. Homepage: https://hoytech.com/vmtouch/ ```
Bug#1057385: lighttpd FTCBFS: host CFLAGS leak into build compiler invocation
On Mon, Dec 04, 2023 at 11:49:30AM +0100, Emanuele Rocca wrote: > With the attached patch lighttpd cleanly cross-builds from source. Thanks, Emanuele. A slightly different patch: https://salsa.debian.org/debian/lighttpd/-/commit/a7d695d59c9a8bffe154aae29e335102beaaf3f2 was committed a few weeks ago to salsa.debian.org, which I based off comments in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021292? Is your suggested approach (above) preferred to this patch (below)? @@ -50,9 +50,9 @@ override_dh_auto_configure: --with-xxhash \ --with-zstd \ $(if $(filter pkg.lighttpd.libunwind,$(DEB_BUILD_PROFILES)),--with-libunwind) \ - CFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get CFLAGS)" \ - LDFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get LDFLAGS)" \ - CPPFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get CPPFLAGS)" \ + CFLAGS_FOR_BUILD="$$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dpkg-buildflags --get CFLAGS)" \ + LDFLAGS_FOR_BUILD="$$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dpkg-buildflags --get LDFLAGS)" \ + CPPFLAGS_FOR_BUILD="$$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dpkg-buildflags --get CPPFLAGS)" \ override_dh_install: cp NEWS debian/tmp/changelog
Bug#1055131: RFS: lighttpd/1.4.73-1 -- light, fast, functional web server
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear mentors, I am looking for a DD sponsor for my package "lighttpd": https://salsa.debian.org/debian/lighttpd/ I am an upstream lighttpd developer and have participated in maintaining lighttpd on Debian for a number of years. I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd lighttpd-1.4.73-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.73-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Important changes in lighttpd 1.4.73: * HTTP/2 detect and log rapid reset attack While lighttpd is not affected by HTTP/2 rapid reset attacks any more than by other DoS attacks, changes have been made to lighttpd to detect and log when a rapid reset attack occurs, and to close the HTTP/2 connection. Log watchers might subsequently use the trace to block IPs. The goal is to make lightpd 1.4.73 available in unstable, testing, and then backports (or sloppy-backports) to maintained Debian versions. Please advise next steps. Thank you. Glenn P.S. The version of lighttpd in Debian Experimental is 1.4.71-1+exp1 and can be retired.
Bug#1040525: Lighttpd disregards ssl.dh-file setting
Repeating: lighttpd TLS configuration recommendations supercede the issue reported here. (https://wiki.lighttpd.net/Docs_SSL) > I now removed that cipher list (falling back to the default), and this > disabled the 2 remaining ciphers (DHE-RSA-AES256-GCM-SHA384 and > DHE-RSA-AES128-GCM-SHA256) that used Diffie Hellman :-) As you noticed, using the lighttpd TLS configuration recommendations does not include the ciphers using the finite field Diffie-Hellman parameters which caused Nexpose to generate warnings. --- Regarding the DH parameters used by default by lighttpd when finite field Diffie-Hellman parameters are used: > > Please clarify why you think this is insecure. > I trust Nexpose on this one. The theory goes that any "standard" > parameter is insecure, as a would be attacker would only need to "crack" > it once, and then be able to use it against a huge number of sites. I trust the published RFCs by experts more than I trust Nexpose. > I'm not really sure that it is a good idea to rely on *any* standard > Diffie-Hellman parameters :-( I'm not familiar with your expertise in this security area. What are your credentials that would give weight to your opinion? On the contrary: While there is the theoretical possibility of the well-known standard parameters being cracked, there are different potential pitfalls for generating custom parameters and then not cryptographically analyzing those custom parameters for weaknesses. It does not appear that you are performing that analysis on your custom parameters, and so my recommendation is to use the standard parameters which have been analyzed by experts for weaknesses. That does not guarantee safety, but does add more confidence to safety of the standard parameters when compared to custom parameters lacking expert analysis for weaknesses. As you have outsourced your security analysis to Nexpose, I recommend you follow up with Nexpose for more detailed guidance. I suggest that removing those ciphers is best practices at this point, unless you must support older clients which do not support more modern ciphers. If you still trust Nexpose more than other experts, I urge you to reconsider. Do you think Nexpose knows better than the OpenSSL developers? `man SSL_CTX_set_dh_auto` ``` Typically applications should use well know DH parameters that have built-in support in OpenSSL. The macros SSL_CTX_set_dh_auto() and SSL_set_dh_auto() configure OpenSSL to use the default built-in DH parameters for the SSL_CTX and SSL objects respectively. Passing a value of 1 in the onoff parameter switches the feature on, and passing a value of 0 switches it off. The default setting is off. If "auto" DH parameters are switched on then the parameters will be selected to be consistent with the size of the key associated with the server's certificate. If there is no certificate (e.g. for PSK ciphersuites), then it it will be consistent with the size of the negotiated symmetric cipher key. Applications may supply their own DH parameters instead of using the built-in values. This approach is discouraged and applications should in preference use the built-in parameter support described above. ``` Note: other TLS libraries such as GnuTLS use the expert-recommended standard parameters and no longer provide an option to set custom DH parameters. ``` Prior to GnuTLS 3.6.0 for the ephemeral or anonymous Diffie-Hellman (DH) TLS ciphersuites the application was required to generate or provide DH parameters. That is no longer necessary as GnuTLS utilizes DH parameters and negotiation from [RFC7919]. ``` --- Issue resolution: Since lighttpd 1.4.60, lighttpd switches on SSL_CTX_set_dh_auto() in lighttpd mod_openssl, and this causes openssl to ignore "DHParameters" even when explicitly set. This will be fixed in lighttpd 1.4.72. In lighttpd 1.4.72, if you explicitly set "DHParameters", lighttpd will switch off SSL_CTX_set_dh_auto() so that openssl will honor the user-supplied parameters. Even so, the expert recommendation is to allow openssl 3.0.0 and later to select the DH parameters (which lighttpd does by enabling SSL_CTX_set_dh_auto()).
Bug#1034586: always reports inactive/expired certificate on armhf
Marco, please review my previous messages and try to help provide additional information. Thank you. Glenn
Bug#1031046: Unacceptable - Asterisk is too popular to exclude
Hello Moritz, I've read your bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031046 I believe it to be unacceptable to exclude Asterisk from Bookworm. Asterisk is used by a LOT of users worldwide and, as you've noted, is frequently the subject of security concerns. The VoIP Team is currently working on a plan to resolve your concerns. If we don't provide Debian users with secure packages, they will use packages from less reputable sources and chaos will ensue. I believe the VoIP team can deliver on the commitments you are asking for, we are working on raising a bigger team of volunteers so we can more effectively address CVEs. Stay tuned. David
Bug#1050625: asterisk: Downgrade to lua5.1
On 2023-08-27 12:14, Jonas Smedegaard wrote: Hi David, Quoting debian@spam.lublink.net (2023-08-27 16:04:20) I wrote and applied the required patch ( see attached ). I built the asterisk package 1:20.4.0~dfsg+~cs6.13.40431414-2 and signed it successfully. I installed the new package on my local machine and tested a lua dialplan. I connected using chan_sip+baresip, and setup a new lua context in extensions.lua. I called this context and listened to some menus. ( I had audio ). Thanks a lot for the thorough testing! I am now building the package and (unless something surprising happens) will release it within an hour. Since the patch only affects lua integration, I saw no reason to do further testing. Agreed. Since I am a new contributor, I'll need help actually pushing this patch into Salsa and Debian master. For a change this tiny there is really no need to make a formal patch - simply posting here on the list that you've succesfully tested a build with build-dependency changed from liblua5.2-dev to liblua5.1-dev is fine. @jonas can you grant me salsa access and/or review my patch and integrate it into salsa? Please don't use the merge-request feature: I am not comfortable using that, but more importantly I find it better to keep conversation about the packaging in bugreports, not some parts in gitlab. (In addition to concerete discussions about bugs I am happy to have casual conversations as well, at our irc channel that we don't need to keep track of - I just currently have trouble reaching it from matrix). In future, please make simple git commits pushed directly to the branch debian/latest where first line of your commit message is sensible to list in Debian changelog - and please *don't* edit debian/changelog. This approach makes it easier to revert or cherry-pick e.g. for a stable backport, and debian/changelog is easily populated using "gpb dch" just before building the package. In bug #1023306 I am looking at version bumping to 3.4.0. Should I also commit this directly to debian/latest or should I use a branch? Please request membership at https://salsa.debian.org/pkg-voip-team/asterisk/-/project_members to gain write access to the git repo. I've sent my request. I'm waiting for approval. (I have now disabled the MR feature for this package, which also killed the conversation you started there - I forgot to take note of your account so cannot invite you into the group myself). ...and while writing this the build finished and I have now pushed it to Debian :-) Nice! Also, I ran dput, but got no response from debian masters ( probably because I am not authorized to build the asterisk package ) . Correct: dput works but the resulting uploaded source package gets silently dropped because a) your OpenPGP signature is not in the list of trusted Debian Developers, and b) because it was uploaded by someone not trusted that someone could have forged a bogus contact address so it won't be contacted to avoid backscatter. thank you for the explanation. How can I learn more about the VoIP Team workflow so that I can contribute more effectively ? - Jonas - David
Bug#1050625: asterisk: Downgrade to lua5.1
Merge request is in Salsa : https://salsa.debian.org/pkg-voip-team/asterisk/-/merge_requests/4 On 2023-08-27 10:04, debian@spam.lublink.net wrote: I wrote and applied the required patch ( see attached ). I built the asterisk package 1:20.4.0~dfsg+~cs6.13.40431414-2 and signed it successfully. I installed the new package on my local machine and tested a lua dialplan. I connected using chan_sip+baresip, and setup a new lua context in extensions.lua. I called this context and listened to some menus. ( I had audio ). Since the patch only affects lua integration, I saw no reason to do further testing. Since I am a new contributor, I'll need help actually pushing this patch into Salsa and Debian master. @jonas can you grant me salsa access and/or review my patch and integrate it into salsa? Also, I ran dput, but got no response from debian masters ( probably because I am not authorized to build the asterisk package ) . Thank you, David
Bug#1050625: asterisk: Downgrade to lua5.1
I wrote and applied the required patch ( see attached ). I built the asterisk package 1:20.4.0~dfsg+~cs6.13.40431414-2 and signed it successfully. I installed the new package on my local machine and tested a lua dialplan. I connected using chan_sip+baresip, and setup a new lua context in extensions.lua. I called this context and listened to some menus. ( I had audio ). Since the patch only affects lua integration, I saw no reason to do further testing. Since I am a new contributor, I'll need help actually pushing this patch into Salsa and Debian master. @jonas can you grant me salsa access and/or review my patch and integrate it into salsa? Also, I ran dput, but got no response from debian masters ( probably because I am not authorized to build the asterisk package ) . Thank you, David-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - From 1bb7f853f963a05846f4994b0737657e2e9754d3 Mon Sep 17 00:00:00 2001 From: david Date: Sun, 27 Aug 2023 08:56:30 -0400 Subject: [PATCH] * downgrade liblua dependency to 5.1 closes bug #1050625 - --- debian/changelog | 10 ++ debian/control | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 3c752b06..d36f5e39 100644 - --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +asterisk (1:20.4.0~dfsg+~cs6.13.40431414-2) unstable; urgency=medium + + [ upstream ] + * no change + + [ David Lublink ] + * downgrade liblua dependency to 5.1 closes bug #1050625 + + -- David Lublink Sun, 27 Aug 2023 08:54:59 -0400 + asterisk (1:20.4.0~dfsg+~cs6.13.40431414-1) unstable; urgency=medium [ upstream ] diff --git a/debian/control b/debian/control index 1e56e578..ade1e090 100644 - --- a/debian/control +++ b/debian/control @@ -34,7 +34,7 @@ Build-Depends: libjack-dev, libjansson-dev, libldap-dev, - - liblua5.2-dev, + liblua5.1-dev, libncurses-dev, libneon27-dev, libnewt-dev, - -- 2.39.2 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmsrHNiyThbxy/27E6Uk97Y34rXwFAmTrU9cACgkQ6Uk97Y34 rXx+8g/9HD3KBpIvsLgUUUrQWX7beGdt6rIzP6+v2Tjpj6tGQBvnQ3PzR24CWTSp /68D1d0udxo+wNnglC5bNsl7GZ5qUILamefMcgq5kPHT5JT1okhRuoaRc0J7qDes ZUtEypdshfNrJ7jnyS/in+o3EPhw3OB9tzZaOJLvs8JhJM4+UavRmr3gR5eBwExV 16QWPlKje9wuuhhvkl8YJBw+IejtYCWOOilxaEJezpL/fuWAt+BPODf9v5hsicEJ ldQuAPd35uz238ZJhczmR2LoiY4R5PRXsjqQzNp4CZUrcVzOAXTq4FLyvL3BVgbk X2iObdEnEEC7WRW2yCsZSP8mjY1IBuoQFhby8Lvc3IVbAtvTAACyypreP+2UVvOr FE/lrgRj1tKOIM420jK1vfAnyRwcPiRQHfwoDOMob3o/bzrVJ2WoQc0SjIV/+yoU zGTUs+354tnC2oFPFlS975cZ+Qx2gN0IbrY57ukuJdkKjydXmz/OSTVwgqbcLnqC Lu6HsKb3v/V8epo7WDV2x5Kg19trvbLHDjzHA4oPwnvbJKlUmpO6E69reC103VGq mzn0jMgK5+ITfiMJlYUp0pyXK2IgFn6Ft3aQR5+uq+BbSgbdy7spRpQIrBc5Zf5T figB7HwRIx/ELALvKt8r3yAdGqs8X3gm2kKYekSI+pCbpnv5Wg0= =0WlF -END PGP SIGNATURE-
Bug#1023306: Version 3.4.0
It would seem there is now a release 3.4.0. https://github.com/baresip/baresip/tree/v3.4.0
Bug#1040525: Lighttpd disregards ssl.dh-file setting
On Fri, Jul 07, 2023 at 09:28:24AM +, Alain Knaff wrote: > Package: lighttpd > Version: 1.4.69-1 > > Since our upgrade to Debian 12, lighttpd now uses insecure > Diffie-Hellman parameters > c90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63 > b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d5 > 1c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899f > a5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39 > a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d6 > 70c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b > 2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2 > 261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb8 > 50458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94 > e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18 > 177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce > 0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186 > af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fb > ecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2 > d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c0 > 8f4df435c934063199 What are you sharing? What command did you use to obtain this info? Please clarify why you think this is insecure. This does not look like lighttpd mod_openssl default DH parameters used since lighttpd 1.4.56. Since lighttpd 1.4.56, lighttpd mod_openssl configures default DH parameters to use RFC 7919 FFDHE2048 2048-bit group https://git.lighttpd.net/lighttpd/lighttpd1.4/commit/10c65e88f773d361db48e0135e1f4be3a932bf83 RFC 7919: https://datatracker.ietf.org/doc/html/rfc7919#appendix-A.1 Nowadays, FFDHE3072 is preferred, and a future version of lighttpd may change lighttpd mod_openssl to use FFDHE3072 by default in the future. Please note: if using GnuTLS (with lighttpd mod_gnutls) or using mbedTLS (with lighttpd mod_mbedtls), the Diffie-Hellman group is chosen to be secure according to RFC7919 DH parameter negotiation, and there is no default set by lighttpd. > And this despite having pointed ssl.dh-file to a self generated dh param > file, as described in https://weakdh.org/sysadmin.html That page is out-dated, at least for lighttpd. Since lighttpd 1.4.68, if you are using ssl.cipher-list specified in https://weakdh.org/sysadmin.html, then you are WEAKENING the cipher list now used by default since lighttpd 1.4.68. https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68 > In Debian 11, an identical configuration was using our locally generated > secure dh parameters. Since lighttpd 1.4.65 (released Jun 2022), lighttpd has been announcing the future scheduled removal of ssl.dh-file. https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_65 https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_66 https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_67 The removal of ssl.dh-file occurred in lighttpd 1.4.68 (Jan 2023) https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68 As linked in the lighttpd release notes: See https://wiki.lighttpd.net/Docs_SSL for replacements with `ssl.openssl.ssl-conf-cmd`, but prefer lighttpd defaults instead. Since lighttpd 1.4.68, use ssl.openssl.ssl-conf-cmd "DHParameters" to specify your own DH parameters file, as ssl.dh-file has been removed. If you have custom DH parameters, then please review RFC7919 and modern security papers to make sure what you think is secure is still considered secure by experts, as the use of parameters derived from "safe" primes is strongly recommended. It is my understanding that FFDHE3072 is the current recommendation if you are going to set explicit DH parameters. Cheers, Glenn
Bug#1037099: RFS: lighttpd/1.4.71-1 -- light, fast, functional web server
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear mentors, I am looking for a DD sponsor for my package "lighttpd": https://salsa.debian.org/debian/lighttpd/ I am an upstream lighttpd developer and have participated in maintaining lighttpd on Debian for a number of years. I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd lighttpd-1.4.71-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.71-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036020 for lighttpd 1.4.70, this currently targets experimental, though I would like to get this into testing and into Bookworm in due time. Please advise. Thank you. Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
Macro, please review my previous messages and try to help provide additional information. Thank you. Glenn
Bug#1035926: lighttpd conf-enabled files cannot override IPV6 port number
On Thu, May 11, 2023 at 11:49:21AM +0200, Michael Moore wrote: ... > Issue and suggested fix: > === > In lighttpd.conf the includes for conf-enabled/*.conf happens after passing > server.port to the use-ipv6.pl script. Re-ordering these lines so that the > conf files are included first allows the server.port value to be > overridden. > > include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port > include_shell "/usr/share/lighttpd/create-mime.conf.pl" > include "/etc/lighttpd/conf-enabled/*.conf" Thank you for the thorough description. Yes, I agree with your suggestion. use-ipv6.pl is simple and its output can be placed anywhere in lighttpd.conf. Therefore, it should be safe to move to follow conf-enabled/*.conf I'll mark this fixed once the change is included in a release. Cheers, Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
On Tue, May 02, 2023 at 02:35:05AM -0400, gs-debian@gluelogic.com wrote: > On Fri, Apr 21, 2023 at 01:47:22PM -0400, gs-debian@gluelogic.com wrote: > > On Fri, Apr 21, 2023 at 06:14:25PM +0200, Marco d'Itri wrote: > > > On Apr 21, gs-debian@gluelogic.com wrote: > > > > > > > I probably should have started with the most basic thing: > > > > > > > > What is the date on your device? > > > NTP-accurate. > > > > Perhaps there is something amiss in the Debian 32-bit build of lighttpd > > or openssl for aarch64. (Is there any particular reason that you are > > running 32-bit lighttpd on aarch64 rather than running 64-bit lighttpd?) > > Apologies for the delay. I installed Debian Bookworm onto a QEMU > aarch64 VM and the (64-bit!) lighttpd package for Debian aarch64 works > as expected when I tested with an expired LE cert (warning issued), and > when I tested with a current LE cert (no warning issued). > > From where did you obtain a 32-bit build of lighttpd for aarch64? > If you know, how was that 32-bit lighttpd built? I would like to try to > reproduce (as closely as possible) the 32-bit build. Is your system based on raspbian? My understanding is that a while back, raspbian was using a 32-bit kernel and 32-bit userland, even on aarch64-capable ARM chips. Then, they upgraded the kernel to be 64-bit on aarch64-capable ARM chips, but userland may still be 32-bit. In any case, I have tested that things work as expected for me on a physical 32-bit ARM processor running 32-bit lighttpd, and on a 64-bit ARM VM running 64-bit lighttpd. I'll need more info to get any further. You might try testing using lighttpd mod_gnutls instead of mod_openssl to see if that makes a difference. If it does, then the issue might be in the 32-bit armhf build of openssl that you are running under your aarch64 kernel. Cheers, Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 01:47:22PM -0400, gs-debian@gluelogic.com wrote: > On Fri, Apr 21, 2023 at 06:14:25PM +0200, Marco d'Itri wrote: > > On Apr 21, gs-debian@gluelogic.com wrote: > > > > > I probably should have started with the most basic thing: > > > > > > What is the date on your device? > > NTP-accurate. > > Perhaps there is something amiss in the Debian 32-bit build of lighttpd > or openssl for aarch64. (Is there any particular reason that you are > running 32-bit lighttpd on aarch64 rather than running 64-bit lighttpd?) Apologies for the delay. I installed Debian Bookworm onto a QEMU aarch64 VM and the (64-bit!) lighttpd package for Debian aarch64 works as expected when I tested with an expired LE cert (warning issued), and when I tested with a current LE cert (no warning issued). >From where did you obtain a 32-bit build of lighttpd for aarch64? If you know, how was that 32-bit lighttpd built? I would like to try to reproduce (as closely as possible) the 32-bit build. Cheers, Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 06:14:25PM +0200, Marco d'Itri wrote:
> On Apr 21, gs-debian@gluelogic.com wrote:
>
> > I probably should have started with the most basic thing:
> >
> > What is the date on your device?
> NTP-accurate.
Perhaps there is something amiss in the Debian 32-bit build of lighttpd
or openssl for aarch64. (Is there any particular reason that you are
running 32-bit lighttpd on aarch64 rather than running 64-bit lighttpd?)
If you are able to build lighttpd on your aarch64, you can use my
local (internal) code to parse ASN1_TIME, rather than the openssl
ASN1_TIME_cmp_time_t() routine to parse and compare. (Be sure to build
32-bit for testing to better match your current system configuration.)
For *testing only*, the following patch "disables" the check for openssl
1.1.1, which added ASN1_TIME_cmp_time_t(), so that the local (internal)
ASN1_TIME parsing is used.
--- a/src/mod_openssl.c
+++ b/src/mod_openssl.c
@@ -1272,7 +1272,7 @@ network_ssl_servername_callback (SSL *ssl, int *al, void
*srv)
#endif
-#if OPENSSL_VERSION_NUMBER < 0x10101000L \
+#if OPENSSL_VERSION_NUMBER < 0xL \
|| defined(BORINGSSL_API_VERSION) \
||(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x306fL)
static unix_time64_t
@@ -1291,7 +1291,7 @@ mod_openssl_cert_is_active (const X509 *crt)
{
const ASN1_TIME *notBefore = X509_get0_notBefore(crt);
const ASN1_TIME *notAfter = X509_get0_notAfter(crt);
- #if OPENSSL_VERSION_NUMBER < 0x10101000L \
+ #if OPENSSL_VERSION_NUMBER < 0xL \
|| defined(BORINGSSL_API_VERSION) \
||(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER <
0x306fL)
const unix_time64_t before = mod_openssl_asn1_time_to_posix(notBefore);
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 09:38:31AM +0200, Marco d'Itri wrote: > On Apr 21, gs-debian@gluelogic.com wrote: > > > What your `uname -a` ? > Linux omitted.mi.bofh.it 6.1.0-7-arm64 #1 SMP Debian 6.1.20-2 (2023-04-08) > aarch64 GNU/Linux > > > What is the output of the following for you? > > $ lighttpd -V | grep "Y2038 support" > > + Y2038 support > Same. I probably should have started with the most basic thing: What is the date on your device? If the `date` is incorrect, e.g. starts at 1970 after reboot, then that might explain lighttpd's trace when starting lighttpd.
Bug#1034586: always reports inactive/expired certificate on armhf
On Fri, Apr 21, 2023 at 07:41:13AM +0200, Marco d'Itri wrote: > On Apr 21, gs-debian@gluelogic.com wrote: > > > Please confirm you are running an arm64 kernel, as you posted above. > Confirmed. What your `uname -a` ? What is the output of the following for you? $ lighttpd -V | grep "Y2038 support" + Y2038 support I'll build a Debian VM image this weekend to try to repro with the Debian packages. Cheers, Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
On Wed, Apr 19, 2023 at 01:39:02AM +0200, Marco d'Itri wrote: > Package: lighttpd > Version: 1.4.69-1 > Severity: normal > > I am using the latest openssl and lighttpd packages on an armhf (with an > arm64 kernel) and an amd64 system, and only on the armhf system I always > get this warning at startup even just after having created a Let's > Encrypt certificate. > > Apr 19 01:23:31 omitted.mi.bofh.it lighttpd[8876]: 2023-04-19 01:23:30: > (mod_openssl.c.1335) SSL: inactive/expired X509 certificate > '/var/lib/dehydrated/certs/omitted.mi.bofh.it/fullchain.pem' > > # openssl x509 -noout -text -in > /var/lib/dehydrated/certs/bokassa.mi.bofh.it/fullchain.pem | grep -A2 Validity > Validity > Not Before: Apr 18 22:13:45 2023 GMT > Not After : Jul 17 22:13:44 2023 GMT > > After looking at > https://github.com/lighttpd/lighttpd1.4/blob/fdb7ffed88b9dfe09a51e7fb58e5ddfe938c1ec9/src/mod_openssl.c#L1284 > > I wonder if this is common on all 32 bit systems instead. No, this is not common on all 32-bit systems, though I am curious as to why you are seeing that warning with a valid certificate. To try to reproduce this, I took some LE certs and put them on a 32-bit ARM system I have (which is running openwrt, not Debian) $ uname -m armv7l $ cat /proc/cpuinfo | egrep "model|Features" model name : ARMv7 Processor rev 1 (v7l) Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 $ file /usr/sbin/lighttpd /usr/sbin/lighttpd: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, no section header The vfpv3 and /lib/ld-musl-armhf.so.1 confirms to me this is an armhf. See also: https://www.baeldung.com/linux/arm64-armel-armhf-overview My cert: $ openssl x509 -noout -text -in /tmp/x.com/fullchain.pem | grep -A2 Validity Validity Not Before: Apr 10 22:15:43 2023 GMT Not After : Jul 9 22:15:42 2023 GMT ==> I did not get any warning trace on that system with: $ lighttpd -f test.conf -tt using my LE certificates, though that test system has only lighttpd 1.4.67 at the moment. My test system is running a 32-bit kernel. Please confirm you are running an arm64 kernel, as you posted above. What lighttpd package (from which architecture) do you have installed? $ file /usr/sbin/lighttpd might be useful. Please ensure that you have installed the proper package for your architecture. Is your system openssl-based or libressl-based? The only changes between lighttpd 1.4.67 and lighttpd 1.4.69 in lighttpd mod_openssl that seemed to be related to this issue is that lighttpd mod_openssl started using libressl ASN1_TIME_cmp_time_t() when LIBRESSL_VERSION_NUMBER >= 0x306fL and this also requires that lighttpd mod_openssl was built with libressl. The standard Debian package for lighttpd mod_openssl is built with openssl.
Bug#979308: This Bug is already fixed in Ubuntu
Ubuntu fixed this bug with jq (1.6-2.1ubuntu1) hirsute; urgency=medium [ Alex Murray ] * Fix fromdate when local time is during daylight savings (LP: #1910162) - d/p/fix-ftbfs-when-localtime-is-dst.patch: Backport upstream patch which ensures fromdate uses the correct time during daylight savings -- Christian Ehrhardt Tue, 05 Jan 2021 08:03:50 +0100
Bug#1023697: can wolfssl bug be closed?
Can this be closed? Are there any action items remaining for this bug? I am still getting messages that packages depending on wolfssl are "marked for autoremoval from testing on 2023-01-27" Thank you. Glenn
Bug#1028284: [Pkg-zfsonlinux-devel] Bug#1028284: zfs-dkms: build fails for linux-headers-6.1.0-1-amd64
Thanks. Re-install helped. Achim On 09.01.23 15:03, Antonio Russo wrote: On 1/9/23 01:48, Achim Schaefer wrote: Package: zfs-dkms Version: 2.1.7-1 Severity: important X-Debbugs-Cc: bts.debian@schaefer-home.eu When installing the new 6.1 kernel headers, dkms starts to build the zfs module, but fails: configure: creating ./config.status config.status: creating Makefile config.status: creating include/Makefile config.status: creating include/os/Makefile config.status: creating include/os/linux/Makefile config.status: creating include/os/linux/kernel/Makefile config.status: creating include/os/linux/kernel/linux/Makefile config.status: creating include/os/linux/spl/Makefile config.status: creating include/os/linux/spl/rpc/Makefile config.status: error: cannot find input file: `include/os/linux/spl/sys/Makefile.in' Hello, Can you please check that /usr/src/zfs-2.1.7/include/os/linux/spl/sys/Makefile.in actually exists on your installation? I.e., run ls -l /usr/src/zfs-2.1.7/include/os/linux/spl/sys/Makefile.in If that does not exist, please reinstall zfs-dkms; the file was somehow deleted. On an unrelated note: BTS 1028242 means that some temporary files on ZFS with Linux 6.1 will not work. (This should not be related to your compiling issue at all, though). Best, Antonio Russo
Bug#1021021: wolfssl: CVE-2022-38152 CVE-2022-38153 CVE-2022-39173
> I plan to upload version 5.5.1 in the near future. Felix, a month has passed and we are still waiting for an upload. Failure to upload a version with security fixes within the next few days will result in wolfssl and packages which depend on wolfssl to be removed from Debian Testing. Please act accordingly and please look to engage others to help you to maintain wolfssl in Debian. Security fixes should not be unduly delayed. Thank you. Glenn
Bug#981347: [debian-mysql] Bug#981347: Bug#981347: Bug#981347: mariadb-10.5 FTBFS on kfreebsd
On Mon, May 10, 2021 at 08:00:00AM -0700, Otto Kekäläinen wrote: > Hello! > > If you want to help improve MariaDB in Debian in the open source way, > you could for example: > > - submit your suggestion for a fix as a Merge Request at > https://salsa.debian.org/mariadb-team/mariadb-10.5 > - help with documentation/testing to improve our understanding on what > exactly the bug is about I diagnosed and submitted a patch, which was merged a couple months ago. https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/3
Bug#983478: FAM and other arch/kernels
On Wed, Mar 31, 2021 at 08:30:24AM -0400, PICCORO McKAY Lenz wrote: > linux is so popular (wh ugh) today.. but only for enterprices.. i do > not see any help for normal users that wants more freedom .. sad and > oscure! Please go away troll. Your language is inappropriate and you are clearly uninformed on this topic. gamin supports kqueue on FreeBSD and inotify on Linux. For cross-platform servers such as lighttpd, multiple file system monitoring alternatives are implemented for portability. The default stat cache in lighttpd does not use FAM or gamin or inotify or kqueue, and in the most common use-case of infrequently-modified files, the default in lighttpd is often faster than with the added overhead of file system monitoring. Please go away troll. I will not respond to you further here. This is not an invitation to defend your gross hyperbole. Just go away.
Bug#938987: Overly restrictive CapabilityBoundingSet
Thank you very much! Adding CAP_DAC_OVERRIDE solved it for me as well. Not sure how many hours it would have taken for me to figure it out. Does systemd or the linux kernel log capability violations somewhere? (is it even possible) smime.p7s Description: S/MIME Cryptographic Signature
Bug#592834: grub-efi-amd64: File descriptor leaked on lvs invocation
Hey there, got this warning, dunno why, never read this before. Here's what I did before I got this warning. Be aware that I use parrot 4.6, which is based on debian but is a rolling distribution. The not upgraded (helt back) packages are some nvidia packages, not needed on my system (no nvidia card installed). They has nothing to do with grub. Maybe this helps you to recreate this issue. grub-efi-amd64 2.04-1parrot1 ┌─[anonymous@parrot]─[~] └──╼$ apt search grub | grep installed WARNING: apt does not have a stable CLI interface. Use with caution in scripts. grub-common/rolling,now 2.04-1parrot1 amd64 [installed] grub-efi-amd64/rolling,now 2.04-1parrot1 amd64 [installed] grub-efi-amd64-bin/rolling,now 2.04-1parrot1 amd64 [installed,automatic] grub-imageboot/rolling,rolling,now 0.6 all [installed] grub2-common/rolling,now 2.04-1parrot1 amd64 [installed,automatic] hashcat/rolling,now 5.1.0+ds1-1 amd64 [installed,automatic] ┌─[anonymous@parrot]─[~] └──╼$ sudo apt install grub-imageboot [sudo] password for anonymous: Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: syslinux-common The following NEW packages will be installed: grub-imageboot syslinux-common 0 upgraded, 2 newly installed, 0 to remove and 16 not upgraded. Need to get 1,242 kB of archives. After this operation, 3,619 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 https://ftp.halifax.rwth-aachen.de/parrotsec rolling/main amd64 syslinux-common all 3:6.04~git20190206.bf6db5b4+dfsg1-1 [1,237 kB] Get:2 https://ftp.halifax.rwth-aachen.de/parrotsec rolling/main amd64 grub-imageboot all 0.6 [4,354 B] Fetched 1,242 kB in 2s (710 kB/s) Selecting previously unselected package syslinux-common. (Reading database ... 333752 files and directories currently installed.) Preparing to unpack .../syslinux-common_3%3a6.04~git20190206.bf6db5b4+dfsg1-1_all.deb ... Unpacking syslinux-common (3:6.04~git20190206.bf6db5b4+dfsg1-1) ... Selecting previously unselected package grub-imageboot. Preparing to unpack .../grub-imageboot_0.6_all.deb ... Unpacking grub-imageboot (0.6) ... Setting up syslinux-common (3:6.04~git20190206.bf6db5b4+dfsg1-1) ... Setting up grub-imageboot (0.6) ... Copy syslinux memdisk to /boot/memdisk Scanning application launchers Updating active launchers Done ┌─[anonymous@parrot]─[~] └──╼$ sudo apt purge memtest86+ Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: memtest86+* 0 upgraded, 0 newly installed, 1 to remove and 16 not upgraded. After this operation, 2,449 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 333972 files and directories currently installed.) Removing memtest86+ (5.01-3+b1) ... Generating grub configuration file ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-5.1.0-parrot1-3t-amd64 Found initrd image: /boot/initrd.img-5.1.0-parrot1-3t-amd64 Found linux image: /boot/vmlinuz-4.19.37-6parrot2-amd64 Found initrd image: /boot/initrd.img-4.19.37-6parrot2-amd64 Adding boot menu entry for EFI firmware configuration Found memdisk: /memdisk Imagepath /boot/images not found done (Reading database ... 333955 files and directories currently installed.) Purging configuration files for memtest86+ (5.01-3+b1) ... Generating grub configuration file ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-5.1.0-parrot1-3t-amd64 Found initrd image: /boot/initrd.img-5.1.0-parrot1-3t-amd64 Found linux image: /boot/vmlinuz-4.19.37-6parrot2-amd64 Found initrd image: /boot/initrd.img-4.19.37-6parrot2-amd64 Adding boot menu entry for EFI firmware configuration Found memdisk: /memdisk Imagepath /boot/images not found done Generating grub configuration file ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-5.1.0-parrot1-3t-amd64 Found initrd image: /boot/initrd.img-5.1.0-parrot1-3t-amd64 Found linux image: /boot/vmlinuz-4.19.37-6parrot2-amd64 Found initrd image: /boot/initrd.img-4.19.37-6parrot2-amd64 Adding boot menu entry for EFI firmware configuration Found memdisk: /memdisk Imagepath /boot/images not found done Scanning application launchers Updating active launchers Done ┌─[✗]─[anonymous@parrot]─[~] └──╼$ sudo apt install memtest86+ Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: hwtools memtester kernel-patch-badram memtest86 grub-pc | grub-legacy The following NEW packages will be installed: memtest86+ 0 upgraded, 1 newly installed, 0 to remove and 16 not upgraded. Need to get 78.1 kB of archives. After this operation, 2,449 kB of additional disk space will be used. Get:1 https://mirror.yandex.ru/mirrors/parrot rolling/main amd64 memtest86+ amd64 5.01-3+b1 [78.1 kB]
Bug#840850: [Mutt] #3896: smime secret key not found
On Wed, Nov 16, 2016 at 03:18:04PM -, Mutt wrote: > Debian changed the default to use GPGME for GPG and S/MIME encryption. > > Please try putting "unset crypt_use_gpgme" in your .muttrc and restart > mutt. (You must restart mutt for this option to have any effect). > > Let me know if that solves the problem. This indeed solves the problem, thanks for your quick answer!
Bug#840850: mutt: Mutt can't find S/MIME key to sign messages
I'm having the exact same issue
Bug#825748: (no subject)
Additionnal informations:
python
Python 2.7.11+ (default, May 9 2016, 15:54:33)
[GCC 5.3.1 20160429] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests; requests.__version__.split('.')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line
61, in
from .packages.urllib3.exceptions import DependencyWarning
ImportError: cannot import name DependencyWarning
Bug#775612: Bug is in Perl
Tie/StdHash.pm is missing from Perl 5.20.1 It is there. You have unreadable paths in your @INC and perl complains. See the above bug log for more information. sh dpkg -L perl-base | grep Tie /usr/share/perl/5.20.2/Tie /usr/share/perl/5.20.2/Tie/Hash.pm Same issue with amanda looking for StdHash on Jessie. There is NO StdHash.pm in perl-base. After some investigation, StdHash is defined within Hash.pm: sh grep StdHash /usr/share/perl/5.20.2/Tie/Hash.pm # The Tie::StdHash package implements standard perl hash behaviour. package Tie::StdHash; Which means that it seems to be necessary to import Tie::Hash to find it, but amanda probably only imports Tie::StdHash. -- Fabien. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515835: /var/log/messages
After having the problem again, I went back and checked /var/log/messages. This turned up: May 17 15:26:47 hostname kernel: [815860.826184] flickrfs[21821]: segfault at 0 ip b7deb0bf sp b4f0eca8 error 4 in libc-2.7.so[b7d85000+155000] I hope this sheds further light on what is causing this problem. Please let me know if you have any questions or need any further information. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#323032: Same problem two years later with the last upgrade
Hello, right after this morning last upgrade, my proftp server and my webmin stopped to work throwing out these errors : /var/log/webmin/miniserv.error:/usr/bin/perl: relocation error: /lib/libresolv.so.2: symbol __res_iclose, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference And (accepting connections): relocation error: /lib/libresolv.so.2: symbol __res_iclose, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference I just had to restart those services then everything worked well... Perhaps the upgrade script for libc6 should look which running services are using libc6 and restart them ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
