Bug#1034586: always reports inactive/expired certificate on armhf
tobias.jakobi.compleo added more details in https://redmine.lighttpd.net/issues/3244 The issue appears to be lighttpd being built with 64-bit time_t, but the underlying openssl library being built with 32-bit time_t *and* exposing an API interface using time_t. The result is that lighttpd might issue error trace that a certificate is expired when the certificate is not expired. There should be no other ill-effect besides the error trace at startup. However, some distros have startup scripts which check config syntax, and will treat `lighttpd -f /etc/lighttpd/lighttpd.conf -tt` as an error if there is error trace, even if the lighttpd command exits 0 (success) that the syntax is valid. --- Most OS distros have migrated or are in the process of migrating to 64-bit time_t. However, lighttpd 1.4.75 will contain a workaround for older systems to address this issue with older libraries on armhf.
Bug#1065247: new lighttpd serves mangled file names
> I have noticed something odd though. I created a directory which when > served by lighttpd in Firefox looks like: > > Index of /test/ > ../ - Directory > This is just a test.mkv/ 2024-Mar-03 13:22:24583.7M video/x-matroska > This is just a test.txt/ 2024-Mar-03 13:05:210.1K > text/plain;charset=utf-8 There is a regression in lighttpd 1.4.74 and will be fixed in lighttpd 1.4.75 released later this month (Mar). The regression causes the display of filenames in mod_dirlisting to end in '/'. https://redmine.lighttpd.net/issues/3242 > In Firefox, if I click on the text file it works just as expected and FF shows > the contents of the text file. > > For the video file however it starts a download, but renames the file to > `6GQOZxf0.mpv` (an MS-DOS like 8.3 filename). > > If I use wget to retrieve the file I get this: > > > wget -S http://white:8080/test/This%20is%20just%20a%20test.mkv/ > --2024-03-03 13:38:41-- > http://white:8080/test/This%20is%20just%20a%20test.mkv/ > Resolving white (white)... 192.168.1.8 > Connecting to white (white)|192.168.1.8|:8080... connected. > HTTP request sent, awaiting response... > HTTP/1.1 200 OK > Content-Type: video/x-matroska > ETag: "72386044" > Last-Modified: Sun, 03 Mar 2024 02:22:24 GMT > Content-Length: 612101519 > Accept-Ranges: bytes > Date: Sun, 03 Mar 2024 02:38:41 GMT > Server: lighttpd/1.4.74 > Length: 612101519 (584M) [video/x-matroska] > Saving to: ‘index.html.1’ > > However, if I drop the trailing `/` from the filename it works as expected: > > > > wget -S http://white:8080/test/This%20is%20just%20a%20test.mkv > --2024-03-03 13:40:38-- > http://white:8080/test/This%20is%20just%20a%20test.mkv > Resolving white (white)... 192.168.1.8 > Connecting to white (white)|192.168.1.8|:8080... connected. > HTTP request sent, awaiting response... > HTTP/1.1 200 OK > Content-Type: video/x-matroska > ETag: "72386044" > Last-Modified: Sun, 03 Mar 2024 02:22:24 GMT > Content-Length: 612101519 > Accept-Ranges: bytes > Date: Sun, 03 Mar 2024 02:40:38 GMT > Server: lighttpd/1.4.74 > Length: 612101519 (584M) [video/x-matroska] > Saving to: ‘This is just a test.mkv’ > > My guess is that that problem is in the module that generates the listing > for a directory and that the problem is that it puts a trailing `/` on > file as well as just directories. > > I use lighttpd to serve viedo files for a kodi.tv box, so I cannot maually > correct the generated directory listings that lighttpd gives me. Ok, so it sounds to me like the client is renaming the downloaded file, not lighttpd, due to the bug in lighttpd 1.4.74 mod_dirlisting erroneously adding a trailing '/' to the filename. This will be fixed in the next version of lighttpd, and I'll probably submit a patch to Debian sooner. Cheers, Glenn
Bug#1065247: new lighttpd servers mangled file names
Hi Erik. Please provide more details. lighttpd config can be printed with lighttpd -f /etc/lighttpd/lighttpd.conf -p Including only the literal contents of lighttpd.conf in your bug report is less useful than the full config. For more details, please see "How to get support - please read" https://redmine.lighttpd.net/boards/2/topics/5 If you are suggesting that you are getting > as short (seemingly MS-DOS) 8.3 file names. then perhaps you might also share the filesystem type from which you are serving files. Do you know what lighttpd module is producing the response? Your description of the issue is somewhat vague. Perhaps you can share a sample request and response including a sample of the response HTML to show what you are describing as an issue? https://wiki.lighttpd.net/DebugVariables debug.log-request-header = "enable" debug.log-response-header = "enable" Thanks.
Bug#1064572: RFS: lighttpd/1.4.74-1 / usrmerge
On Tue, Feb 27, 2024 at 08:47:22AM +0100, Alexandre Detiste wrote: > 9e6532694efb91a5da9d39acee0c9a6ce43eb180 > > Hi, > > I uploaded 1.4.74-1 but I noticed just now > that this would create a UsrMerge regression. > > If the .timer & .service are correctly named (too early in the morning > for me to think) > then the two lines in lighttpd.install are not needed at all. > > @Helmut: you can correct us directly on Salsa, > no need to file a bug. https://salsa.debian.org/debian/lighttpd/-/merge_requests/46 from Helmut has been merged. Would you like me to tag and sign lighttpd-1.4.74-2 with these changes? I'll do so later today unless I hear otherwise. Cheers, Glenn
Bug#1036020: RFS: lighttpd/1.4.70-1 -- light, fast, functional web server
On Sat, May 13, 2023 at 02:23:13PM +0200, Andrey Rakhmatullin wrote: > Control: retitle -1 RFS: lighttpd/1.4.70-1 -- light, fast, functional web > server > > On Sat, May 13, 2023 at 04:27:36AM -0400, Glenn Strauss wrote: > > (This is not actually an NMU, but a non-DD maintainer upload.) > If it's not a NMU it shouldn't be tagged as a NMU. > > > Please help me to get lighttpd 1.4.70 into Debian Bookworm. > The time to get new upstream versions into Debian Bookworm ended 3 months > ago. Please check the freeze policy every time there is a freeze if you > maintain packages in testing. > If you want you can change this upload to target experimental instead, or > just postpone it until the Bookworm release. You can make a backport for > bookworm-backports after that. As suggested, I have modified the debian/changelog to target "experimental" on salsa.d.o debian/lighttpd. Is there anything else that I need to do for "experimental"? I am a lighttpd developer. I help maintain lighttpd packages in multiple distros, and lighttpd 1.4.70 has been in production and stable for about a week now. lighttpd 1.4.70 is the best available version of lighttpd currently available. Cheers, Glenn
Bug#1036020: RFS: lighttpd/1.4.70-1 [NMU] -- 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.70-1 is passes autopkgtests and CI, and is tagged. (This is not actually an NMU, but a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.70-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Please help me to get lighttpd 1.4.70 into Debian Bookworm. Thank you. Glenn
Bug#1031669: lintian: [false positive] shared-library-lacks-prerequisites
Package: lintian Version: 2.116.3 Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear Maintainer, Problem: lintian: [false positive] shared-library-lacks-prerequisites lighttpd is a modular application which dynamically loads (dlopen) optional modules (.so) depending on user lighttpd.conf configuration. On platforms which require shared libraries to resolve all symbols at link time, lighttpd compiles a shared library against which each lighttpd module (.so) is linked. On platforms which allow shared libraries to access (exported) global symbols from the base executable, lighttpd does not create a separate shared library for these shared symbols; the symbols are in the base exe shared-library-lacks-prerequisites is falsely reported for one lighttpd shared module (mod_sockproxy.so) which has no dependencies besides the symbols in the base executable. (shared-library-lacks-prerequisites fails to catch the same is true for mod_access.so and mod_staticfile.so) **What is the goal of shared-library-lacks-prerequisites lintian tag?** https://lintian.debian.org/tags/shared-library-lacks-prerequisites Why does this lintian tag exist? What does it identify and why? Should it be applied only to packages which are marked as libraries? Maybe it should be applied only to packages which have a -devel package? Should it *not be applied* to applications? If this lintian tag intends to catch errors on certain platforms, then these lintian tests should be run only on those platforms. My personal opinion is that shared-library-lacks-prerequisites should be removed. At a mimimum, shared-library-lacks-prerequisites and other lintian tags should attempt to explain *why* they exist and what problem(s) they are trying to identify, rather than only giving a terse technical explanation of *what* they check. https://lintian.debian.org/tags/shared-library-lacks-prerequisites suggests linking with -lc. This workaround is unnecessary make-work. lintian could already use `file` to detect a dynamically linked, shared object, if lintian does not already know this by the extension (.so). What does explicit -lc do besides tell lintian to stfu? Why should an upstream project make such changes to their build system? Please help me to understand why I should not simply ignore the lintian warning for shared-library-lacks-prerequisites. Thank you. Glenn -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.40-2 ii bzip2 1.0.8-5+b1 ii diffstat1.65-1 ii dpkg1.21.19 ii dpkg-dev1.21.19 ii file1:5.44-3 ii gettext 0.21-11 ii gpg 2.2.40-1 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.12.0-1 ii libapt-pkg-perl 0.1.40+b2 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-2+b1 ii libcapture-tiny-perl0.48-2 ii libclass-xsaccessor-perl1.19-4+b1 ii libclone-perl 0.46-1 ii libconfig-tiny-perl 2.28-2 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.32-1+b1 ii libdata-dpath-perl 0.58-2 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-2+b1 pn libdigest-sha-perl ii libdpkg-perl1.21.19 ii libemail-address-xs-perl1.05-1+b1 ii libfile-basedir-perl0.09-2 ii libfile-find-rule-perl 0.34-3 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-3 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-2 ii libipc-run3-perl0.048-3 ii libjson-maybexs-perl1.004004-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.144-1 ii libperlio-gzip-perl 0.20-1+b1 ii libperlio-utf8-strict-perl 0.010-1 ii libproc-processtable-perl 0.634-1+b2 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.002+ds-1 ii libsereal-encoder-perl 5.002+ds-1 ii libsort-versions-perl 1.62-3 ii
Bug#1031146: RFS: lighttpd/1.4.69-1 [NMU] -- light, fast, functional web server
Control: tags -1 - moreinfo On Fri, Feb 17, 2023 at 09:57:17AM +0100, Santiago Ruano Rincón wrote: > > > Do you think NEWS could be updated? > > > > Updated to 1.4.69-1, as this will be the release that contains the > > change. > > Great, thanks! However, just a is a minor typo: > > +++ lighttpd-1.4.69/debian/lighttpd.NEWS2023-02-11 04:34:51.0 > +0100 > @@ -1,3 +1,18 @@ > +lighttpd (1.4.69-1) experimental; urgency=medium > + > > You are uploading to unstable, not experimental. And lintian still > complains about that. Sorry, I missed that. fixed. > Once you have fixed that, could you please push a signed git tag, and > remove the moreinfo tag of this bug? done. Thanks! Glenn
Bug#1031146: RFS: lighttpd/1.4.69-1 [NMU] -- light, fast, functional web server
On Tue, Feb 14, 2023 at 05:50:12PM +0100, Santiago Ruano Rincón wrote: > Hello Glenn, > > El 12/02/23 a las 08:54, Glenn Strauss escribió: > > > Since you are listed in Uploaders:, this shouldn't be a NMU. I don't > > > understand why lintian doesn't complain about this in this job: > > > https://salsa.debian.org/debian/lighttpd/-/jobs/3931309 > > > but don't have the time to investigate that right now. > > > > > > Please, fix the changelog. > > > > changelog updated. Thanks for your guidance. > > Cheers, Glenn > > > > Sorry I was unable to give you more feedback the first time. So I am > iterating. ENOTIME… Iterating makes progress! Thank you! > I am afraid I cannot parse that entry. What are the changes related to > 1.4.68? I had prepared a release for 1.4.68, and earlier for 1.4.67-2. It was a separate changelog entry, but nmudiff did not work since it detected 1.4.68 (not released) as a prior version. Therefore, I had merged the changelog entries. I've now edited that entry to simply be the combination, without reference to 1.4.68. > * Remove deprecated lighttpd modules. > * Skip installing modules now built into lighttpd. > * Add to not-installed mods now built into lighttpd. > > Is it worth to list those modules? > Is there any impact for the uses to they should be warned via e.g. > debian/NEWS too? There should be no impact for end users. The change impacts packaging. > 2. d/lighttpd.NEWS: > > As lintian complains, this entry relates a release not known by debian: > > lighttpd (1.4.67-2) experimental; urgency=medium > > Do you think NEWS could be updated? Updated to 1.4.69-1, as this will be the release that contains the change. Cheers, Glenn
Bug#1031146: RFS: lighttpd/1.4.69-1 [NMU] -- light, fast, functional web server
> Since you are listed in Uploaders:, this shouldn't be a NMU. I don't > understand why lintian doesn't complain about this in this job: > https://salsa.debian.org/debian/lighttpd/-/jobs/3931309 > but don't have the time to investigate that right now. > > Please, fix the changelog. changelog updated. Thanks for your guidance. Cheers, Glenn
Bug#1031146: RFS: lighttpd/1.4.69-1 [NMU] -- 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 I put together a new package for lighttpd 1.4.69 and filed an NMU bug, but that got routed to lighttpd maintainers, which currently has no DD. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031069 The previous DD maintainer had to step away and there is currently no DD part of the Debian lighttpd package maintainers. * Package name : lighttpd Version : 1.4.69-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Please help me to get lighttpd 1.4.69 into Debian Bookworm. Thank you. Glenn
Bug#1031068: media-types 9.0.0 duplicates .aml, breaking lighttpd autopkgtest
Package: media-types Version: 8.0.0 Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear Maintainer, media-types 9.0.0 duplicates .aml, breaking lighttpd autopkgtest Regression is currently reported on https://tracker.debian.org/pkg/media-types and blocking media-types 9.0.0 for Bookworm. media-types 9.0.0 is blocking lighttpd 1.4.69 for Bookworm since lighttpd autopkgtest fails. If you have the lighttpd package installed, you can test with: $ /usr/share/lighttpd/create-mime.conf.pl -v >/dev/null There should be no trace to stderr. Current trace to stderr from lighttpd autopkgtest defconfig looks like: autopkgtest [03:50:43]: summary defconfigFAIL stderr: Duplicate mimetype: '.aml' => 'application/automationml-aml+xml' (already have 'application/AML'), merging to 'application/octet-stream' Please remove duplication of .aml extension. Thank you. Glenn -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1012555: lighttpd: starte takes over an minute (php.socket-0 load: 1)
On Thu, Jun 09, 2022 at 08:01:58AM +, nico wrote: > Dear Maintainer, > we use an faster sd-card in our embedded system, nothing else. > Now the start from the lighttpd server takes often over an minute. > we use debian 10, for the bug submit i upgrade to bullseye, but the behaviour > is the same. > Without fastcgi/php lighttpd start fast, only some second. > > I can send some error.log from the debian 10 system, if needed, but it seems > to identical > > Sometimes we got the following error: > 2022-06-09 06:26:17: gw_backend.c.238) establishing connection failed: > socket: unix:/run/lighttpd/php.socket-0: Resource temporarily unavailable > 2022-06-09 06:26:17: gw_backend.c.255) backend error; we'll disable for 1secs > and send the request to another backend instead:load: 130 > 2022-06-09 06:26:17: gw_backend.c.262) If this happened on Linux: You have > run out of local ports. Check the manual, section Performance how to handle > this. This sounds more like an issue with your backend, not with lighttpd. If the load is 130, that is more than the default socket backlog of 128, so it sounds like your backend is overloaded and not responding quickly enough. Try replacing your PHP with something trivial -- e.g. something which returns a simple "Hello World" -- and test if that works better. Try replacing your lighttpd fastcgi config with one which uses PHP-FPM to manage the PHP processes, rather than having lighttpd start the PHP. Configuring PHP-FPM to manage the PHP and tuning the number of PHP instances there is the recommended approach to managing your PHP FastCGI servers independently from lighttpd. Do not forget to tune the number of PHP backends started by PHP-FPM. Depending on the resources available on your embedded system, you may want to reduce the number of connections allowed by lighttpd by setting lighttpd.conf: server.max-connections = 64 or whatever number is appropriate for the max number of clients you expect simultaneously connecting to lighttpd. On a resource constrained embedded system, limiting the number of connections which lighttpd accepts can help you limit the load on your backend.
Bug#1000310: lighttpd: logrotate fails if service is not running
> This also fails, the following works: > > systemctl reload lighttpd.service > /dev/null 2>&1; That will start lighttpd if it is not running, which might not be desirable. I think that a different solution is warranted. /etc/logrotate.d/lighttpd is doing the correct thing, calling /etc/init.d/lighttpd reopen-logs However, perhaps /etc/init.d/lighttpd should avoid sending a signal to lighttpd to reopen logs if lighttpd is not running. /etc/init.d/lighttpd might check using pidofproc, even though running start-stop-daemon --oknodo --quiet should have exited 0 if nothing was running. Does the following work for you? @@ -92,6 +92,7 @@ case "$1" in fi ;; reopen-logs) +pidofproc -p "$PIDFILE" "$DAEMON" >/dev/null 2>&1 || exit 0 log_daemon_msg "Reopening $DESC logs" $NAME if start-stop-daemon --stop --signal HUP --oknodo --quiet \ --pidfile $PIDFILE --exec $DAEMON
Bug#997039: lighttpd segfaults every few minutes
"lighttpd.conf" is not the whole lighttpd configuration. Print the config with: lighttpd -f /etc/lighttpd/lighttpd.conf -p Your probable error is well-documented as user misconfiguration: $SERVER["socket"] must not be nested in other lighttpd config conditions https://wiki.lighttpd.net/Docs_SSL#Configuration https://wiki.lighttpd.net/Docs_Configuration#Conditional-Configuration
Bug#981347: [debian-mysql] Bug#981347: mariadb-10.5 FTBFS on kfreebsd
I believe this bug was addressed in https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/2 Cheers, Glenn
Bug#981515: kcoreaddons: please replace fam with gamin
On Fri, Mar 05, 2021 at 05:12:17PM +0100, Pino Toscano wrote: > Personally, I'd argue that switching the FAM implementation across the > distribution _is_ a "transition", and as such it ought to have been > requested (if not even started) two months ago. In July 2020, #966273 was filed: RFA: fam -- File Alteration Monitor I posted in October 2020 on that bug where FAM was abandoned. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273#15 Debian developers did not suggest "next steps" for over 3 months, until the freeze occurred. The bug was not touched by a Debian Developer until 31 Jan 2021. All this reflects poorly on Debian Developers, who we all understand are volunteers. I am not questioning the skills of Debian Developers. I am criticizing the execution. The failure to triage bugs in a timely fashion, the failure to encourage outside contributions, and the failure to recruit and nurture additional help all reflect poorly on Debian as a project, as does the 12+ year old bug which is being deferred, yet again. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510368 The solution is to remove FAM. It just FUD that is delaying action. (It is FUD hiding behind policy, since FAM package removal was a blocking bug for Bullseye.) Back on topic: If you take a moment to look in the kcoreaddons code, you can see that kcoreaddons has multiple mechanisms for filesystem notification. If FAM interfaces fail for any reason, kcoreaddons switches to an alternative mechanism. https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/io/kdirwatch.cpp#L1611 Therefore, your FUD is unsubstantiated. Changing kcoreaddons to use gamin, or to not use FAM or gamin, are both reasonable options. As I posted in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#49 gamin can be configured to poll NFS locations and so is a reasonable substitution for FAM, not limited to inotify() as Sune suggested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#39 It is true that this relatively safe change is being requested during the soft freeze and so should be scrutinized. However, that does not make the requested change any more or less dangerous. It does mean less time to test by people who, in your own words, might not be using this feature: > and these FAM/gamin bits do not get much of use these days I posit that the code in upstream kcoreaddons is already better tested than would be Debian "testing" (existence in tree?) of an additional month or two or three of the Debian kcoreaddons package configured to use gamin (or to use neither FAM nor gamin). With that, I've said my piece. I shall not argue further.
Bug#981515: kcoreaddons: please replace fam with gamin
In #981513, courier changed to use libgamin-dev, so kcoreaddons is now the *only* remaining package using FAM. As such, there is considerably more risk to doing nothing than there is to migrating to gamin. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510368 is over 12 years old. It's time to get it fixed by removing FAM instead of going through another cycle where end-users continue to run into unnecessary conflicts. There are a large number of issues that go away when FAM gets dropped. I listed some of them in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981513 If you search bugs.debian.org, or Ubuntu forums, or the internet, the general solution to conflicts in between FAM and gamin is to remove FAM, e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599682 (from 2011!) (solution: replace FAM with gamin) On the other hand, a search of bugs.debian.org did not turn up any bugs with kcoreaddons and gamin, besides this one (#981515). Why are you suggesting "there might be issues with kcoreaddons using gamin", when no such issues have been reported thus far? ==> Please change kcoreaddons to use libgamin-dev for Bullseye. https://salsa.debian.org/qt-kde-team/kde/kcoreaddons/-/merge_requests/3 Thank you. Glenn
Bug#981515: kcoreaddons: please replace fam with gamin
On Wed, Mar 03, 2021 at 02:54:58PM -0500, Nicholas D Steeves wrote: > Hi, > > Glenn Strauss writes: > > > gamin provides libfam0. > > > > kcoreaddons should load just fine with libfam0 from gamin. > > > > I did the research in #510368 and #966273, reviewing the actual code > > and confidentally concluded that FAM can be removed from Bullseye. > > > > The safest choice is to have a single library (gamin) used in the > > distro, rather than having both FAM and gamin. > > > > I don't think the removal of FAM is as clear-cut as it has been > presented to be. > > AFAIK the following is still current: Gamin provides "No NFS support > based on specific RPC and server, instead gamin monitors only the state > as reported locally by the kernel, not that locally done changes on NFS > or AFS filesystems are reported on Linux which is the main criteria when > having user home directories on such filesystems." > > https://people.gnome.org/~veillard/gamin/differences.html > > thus FAM covers a use case that gamin does not, and this case is: users > who want to receive inotify style events for files that have been > remotely created or modified on NFS mounts. > > I can't speak to how widespread the need for this feature is, but if it > is non-zero then it seems to me that FAM should not be removed this late > in the Bullseye cycle. > > Also, IIRC gamin depends on Linux-specific features such as inotify > where FAM provides fallbacks (eg: IIRC FAM is required on kfreebsd and > hurd); this might not be significant, but I felt it was worth mentioning > :-) > > FreeBSD doesn't have inotify, so there is a need for FAM, and maybe > someone from their community has become the defacto upstream (via their > "ports" packaging system)? Or maybe someone from their community would > be willing to officially become FAM's new upstream? Nicholas: gamin can be configured to use different mechanisms for different filesystems, so gamin can be configured to poll an NFS filesystem instead of using inotify(). Also, gamin supports kqueue() on *BSD. https://people.gnome.org/~veillard/gamin/config.html Cheers, Glenn
Bug#983478: Bug#981513: courier: please replace fam with gamin
On Wed, Mar 03, 2021 at 11:23:41AM +0100, Markus Wanner wrote: > On 03.03.21 09:21, Glenn Strauss wrote: > > If there is any remaining concern about upgrade compatibility, > > ..none from my side. Courier would simply depend on gamin only. I don't > see why that would cause issues during upgrades. > > > In Bullseye, change the fam package to import the gamin source, and > > then bump the fam package version number. The fam package would > > actually be the same as gamin, and upgrades would avoid any packaging > > system deficiencies in choosing between gamin and fam for upgrade. > > That sounds very confusing and outright wrong, IMO. What's wrong with just > dropping fam? (Whether right now for Bullseye or at any later point in > time...) Almost as wrong as leaving a bug like #510368 open for 12 years? /s https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510368 Yes, I agree that FAM should be dropped. Markus, I do not understand why you were asked to revert the change from gamin back to FAM. If courier and kcoreaddons change to use gamin, then FAM will not be used and 12-year-old bug #510368 gets fixed. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981513 courier https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515 kcoreaddons Adrian: is there a known issue that you are trying to address by asking courier to revert to use FAM (#983478)? Or is that theoretical? OTOH, there are many real bugs regarding FAM / gamin conflicts which get resolved when FAM gets dropped. Was #983478 filed before it was clear that remaining packages could convert to use gamin? (incomplete list of FAM and gamin conflicts) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348563 (from 2006!) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510368 (from 2009!) courier: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599682 (from 2011!) (solution: replace FAM with gamin) lighttpd conflicts with FAM and gamin https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521274 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539962 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545576 I am an upstream developer of lighttpd and the conflicts were reported to me last Aug 2020. I posted a patch with a solution 4 days later. https://salsa.debian.org/debian/lighttpd/-/merge_requests/18 As an upstream developer, I am absolutely appalled at how long the FAM/gamin conflict has remained in Debian, and subsequently Ubuntu and derivatives. Last Oct, I did the research for Debian in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273 which, of course, was ignored until Bullseye went to start freeze. ==> Markus, I ask that we give Adrian a chance to respond, but I see no good reason to keep courier depending on FAM. On the contrary, using FAM is MORE LIKELY to lead to conflicts with other packages that are using gamin (instead of FAM), which is now all of them other than courier and kcoreaddons (#981515). Cheers, Glenn
Bug#981515: kcoreaddons: please replace fam with gamin
On Thu, Mar 04, 2021 at 08:23:44AM +0100, Sune Stolborg Vuorela wrote: > > On 3/3/21 8:54 PM, Nicholas D Steeves wrote: > > > > thus FAM covers a use case that gamin does not, and this case is: users > > who want to receive inotify style events for files that have been > > remotely created or modified on NFS mounts. > > > > Also, IIRC gamin depends on Linux-specific features such as inotify > > where FAM provides fallbacks (eg: IIRC FAM is required on kfreebsd and > > hurd); this might not be significant, but I felt it was worth mentioning > > :-) > > > Please note that these features are what KCoreAddons (or more specifically > KDirWatch) uses FAM for. > > KDirWatch hooks up to inotify directly and prefers that if possible. FAM is > only used for fallback codepath for e.g. nfs-mounts, before KDirWatch > resorts to the last fallback; polling. > > Replacing with libgamin is basically making the inotify-free codepath depend > on inotify, so either keep using FAM, or skip both of them. > > > /Sune > > - who has been debugging KDirWatch and other parts of KCoreAddons over the > years. Sune, thanks for chiming in as someone using and debugging KCoreAddons! It bears repeating that KCoreAddons using FAM is ineffective over NFS unless the NFS server is also running and insecurely exposing FAM, which is hopefully not widely used on the open internet today. Sune, do you know if you were using KCoreAddons on networks that had FAM running on the NFS server? If so, would you recommend those configurations today (versus 20 years ago)? (Yes, it is possible to better secure with firewall rules and tunnels, but takes more effort and is still less appropriate for a multi-user system on which the users have shell access and are using KCoreAddons.) > Replacing with libgamin is basically making the inotify-free codepath depend > on inotify, so either keep using FAM, or skip both of them. I suggest the latter. I think removal of FAM and gamin from KCoreAddons is preferred. As a lighttpd developer, I replaced both FAM and gamin with inotify() on Linux and kqueue() on *BSD. There is a reasonable fallback in lighttpd when neither are available. Cheers, Glenn
Bug#981515: kcoreaddons: please replace fam with gamin
On Wed, Mar 03, 2021 at 02:54:58PM -0500, Nicholas D Steeves wrote: > I don't think the removal of FAM is as clear-cut as it has been > presented to be. > > AFAIK the following is still current: Gamin provides "No NFS support > based on specific RPC and server, instead gamin monitors only the state > as reported locally by the kernel, not that locally done changes on NFS > or AFS filesystems are reported on Linux which is the main criteria when > having user home directories on such filesystems." > > https://people.gnome.org/~veillard/gamin/differences.html > > thus FAM covers a use case that gamin does not, and this case is: users > who want to receive inotify style events for files that have been > remotely created or modified on NFS mounts. > > I can't speak to how widespread the need for this feature is, but if it > is non-zero then it seems to me that FAM should not be removed this late > in the Bullseye cycle. FAM attempts to get notifications for NFS by requiring that a remote FAM server is running on the NFS server. No encryption is used. I hope this is not widely used. FAM code was last modified circa 2003 in the tar ball I downloaded from debian and predates inotify(). However, using FAM or gamin in kcoreaddons is not necessary. Quoting from kcoreaddons src/lib/io/kdirwatch.h: https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/io/kdirwatch.h#L44 * The implementation uses the INOTIFY functionality on LINUX. * Otherwise the FAM service is used, when available. * As a last resort, a regular polling for change of modification times * is done; the polling interval is a global config option: * DirWatch/PollInterval and DirWatch/NFSPollInterval for NFS mounted * directories. Please consider removing kcoreaddons dependency on FAM and on gamin in the Debian package. kcoreaddons has its own fallbacks. Also, kcoreaddons is not using FAM or gamin on Linux. > FreeBSD doesn't have inotify, so there is a need for FAM, and maybe > someone from their community has become the defacto upstream (via their > "ports" packaging system)? Or maybe someone from their community would > be willing to officially become FAM's new upstream? FYI: *BSD has kqueue() with EVFILT_VNODE. Please consider removing FAM and gamin from the Debian package for kcoreaddons by removing libfam-dev and libgamin-dev from debian/control, or at least changing it to libgamin-dev. https://salsa.debian.org/qt-kde-team/kde/kcoreaddons/-/merge_requests/3 Cheers, Glenn
Bug#981513: Bug#983478: Bug#981513: courier: please replace fam with gamin
If there is any remaining concern about upgrade compatibility, how about this: In Bullseye, change the fam package to import the gamin source, and then bump the fam package version number. The fam package would actually be the same as gamin, and upgrades would avoid any packaging system deficiencies in choosing between gamin and fam for upgrade.
Bug#981515: kcoreaddons: please replace fam with gamin
gamin provides libfam0. kcoreaddons should load just fine with libfam0 from gamin. I did the research in #510368 and #966273, reviewing the actual code and confidentally concluded that FAM can be removed from Bullseye. The safest choice is to have a single library (gamin) used in the distro, rather than having both FAM and gamin. Please pick up the trivial change in https://salsa.debian.org/qt-kde-team/kde/kcoreaddons/-/merge_requests/3 so that kcoreaddons is not blocking progress. Thank you. Glenn
Bug#981513: Bug#983478: Bug#981513: courier: please replace fam with gamin
On Wed, Mar 03, 2021 at 08:06:57AM +0100, Markus Wanner wrote: > On 03.03.21 07:02, Glenn Strauss wrote: > > Please replace "libfam-dev" with "libgamin-dev" in debian/control > > > > Also, please replace "gamin | fam" with simply "gamin" for Bullseye. > > I just changed it forth and back. To change it again, we need some deeper > reasoning than just "please do". Are you claiming the initial information > given by Adrian Bunk in #983478 (which you're responding to) is wrong? I did the research in #510368 and #966273, reviewing the actual code and confidentally concluded that FAM can be removed from Bullseye. I am one of the developers of lighttpd and am intimately aware of the issues caused to end-users due to #510368 and symbol conflicts that it caused in lighttpd. The safest choice is to have a single library (gamin) used in the distro, rather than having both FAM and gamin. Two packages remaining in Bullseye with unnecessary dependencies on FAM: kcoreaddons and courier. Fixing them requires trivial substitutions in debian/control For kcoreaddons, I submitted: https://salsa.debian.org/qt-kde-team/kde/kcoreaddons/-/merge_requests/3 To Adrian: if courier and kcoreaddons s/libfam-dev/libgamin-dev/ and depend on gamin instead of on fam, then fam can be removed from Bullseye. For upgrades, fam should be removed, replaced by gamin since packages no longer declare dependencies on fam. Cheers, Glenn
Bug#981513: courier: please replace fam with gamin
Markus, Please replace "libfam-dev" with "libgamin-dev" in debian/control Also, please replace "gamin | fam" with simply "gamin" for Bullseye. Cheers, Glenn
Bug#971393: mbedtls: please update to mbedtls 2.25.0 in sid
Please upgrade to 2.25.0 in Debian testing. Thank you. mbedtls 2.25.0 was released almost 3 months ago. mbedtls 2.24.0 was 6 months ago. Since mbedtls 2.24.0, mbedtls supports TLSv1.3. https://github.com/ARMmbed/mbedtls/releases
Bug#979232: lighttpd: does not start with media-types 1.1.0
On Thu, Jan 07, 2021 at 02:53:17PM +0100, Alexandre Duret-Lutz wrote: > FWIW more uppercase variants are now present in media-types 2.0.0 > > audio/AMR amr AMR > audio/AMR-WBawb AWB > audio/EVRC-QCP qcp QCP > image/t38 t38 T38 > image/vnd.globalgraphics.pgbPGB pgb I maintain that providing multiple case-differing variants is wasteful and unnecessary. Up to this point, such was not done so for any existing entries in /etc/mime.types (until these were added). The person(s) introducing this unnessary duplication should be clued in. They should provide justification for the duplication or should stop introducing such inconsistency in /etc/mime.types. Is there a bug being solved by adding this duplication? If so, why does the solution not apply to many/all entries in /etc/mime.types? Have the maintainers looked at /etc/mime.types in other Linux distributions? Other unix distributions?
Bug#979232: lighttpd: does not start with media-types 1.1.0
On Mon, Jan 04, 2021 at 11:23:48AM -0300, Antonio Terceiro wrote: > Package: lighttpd > Version: 1.4.57-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > After media-types has been upgraded to 1.1.0, lighttpd fails to start, > complaining about duplicated media types. > > jan 04 11:17:27 lemur systemd[1]: Starting Lighttpd Daemon... > jan 04 11:17:27 lemur lighttpd[22434]: Duplicate mimetype: '.png' => > 'image/vnd.mozilla.apng' (already have 'image/png'), merging to > 'application/octet-stream' > jan 04 11:17:27 lemur lighttpd[22434]: Duplicate mimetype: '.pcx' => > 'image/vnd.zbrush.pcx' (already have 'image/pcx'), merging to > 'application/octet-stream' > jan 04 11:17:28 lemur lighttpd[22430]: Error: duplicate array-key: .pgb. > Please get rid of the duplicate entry. > jan 04 11:17:28 lemur lighttpd[22430]: 2021-01-04 11:17:27: > (configfile.c.1966) source: /usr/share/lighttpd/create-mime.conf.pl line: 495 > pos: 8 parser failed somehow near here: (COMMA) > jan 04 11:17:28 lemur lighttpd[22430]: 2021-01-04 11:17:27: > (configfile.c.1966) source: /etc/lighttpd/lighttpd.conf line: 48 pos: 8 > parser failed somehow near here: (EOL) [...] > The new /etc/mime.types has both lowercase and uppercase file extensions > for the same mime type: > > $ grep pgb /etc/mime.types > image/vnd.globalgraphics.pgb PGB pgb > > I'm copying the media-types maintainers just so that they know about > this, but it seems to me that this should be handled properly in > lighttpd. Thank you for reporting this. Yes, lighttpd could handle this better and I have just pushed a patch to salsa.debian.org/debian/lighttpd master branch. An update to lighttpd is scheduled to be released to testing some time later next week. However, I also urge the media-types maintainers to review their change. Of the 800+ lines in /etc/mime.types, only this new addition lists both uppercase and lowercase for the same extension. It is unnecessary and wasteful. If they are going to duplicate uppercase and lowercase for pgb, then they should do so for all extensions, e.g. jpg and JPG, png and PNG, etc One quickly realizes that this is excessive and wasteful and not the convention in /etc/mime.types. Therefore 'image/vnd.globalgraphics.pgb PGB pgb' is the outlier that should be changed to conform to the existing conventions. Cheers, Glenn
Bug#979159: nss: pkg build fails on m68k due to insufficient LD_LIBRARY_PATH
Source: nss Severity: important Tags: ftbfs patch X-Debbugs-Cc: gs-debian@gluelogic.com, debian-m...@lists.debian.org Dear Maintainer, On m68k on the Debian build farm, nss fails to build. Patch to fix issue is provided at: https://salsa.debian.org/mozilla-team/nss/-/merge_requests/3 I tested the patch on m68k. @glaubitz has tested the patch and doesn't see any regressions on amd64/powerpc/ppc64/s390x (see comments in salsa.d.o merge request) The build error on m68k is "loading softokn3 failed" for the command umask 022; LD_LIBRARY_PATH=debian/libnss3/usr/lib/m68k-linux-gnu debian/libnss3-tools/usr/bin/shlibsign -v -i debian/libnss3/usr/lib/m68k-linux-gnu/nss/libsoftokn3.so since shlibsign itself depends on libsoftokn3.so and the LD_LIBRARY_PATH does not include the path to libsoftokn3.so. (Don't be misled because the argument to shlibsign is libsoftokn3.so) If libsoftokn3.so is not already installed in the standard system library paths, shlibsign fails to run and the build fails. Cheers, Glenn -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: m68k Kernel: Linux 5.9.0-4-m68k (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#975064: Changing server.username causes lighttpd to fail to start
> Changing the value of 'server.username' in lighttpd.conf causes the > server to fail to start. In my particular configuration, with webdav > enabled, I get the following error: > > Starting Lighttpd Daemon... > (mod_webdav.c.1153) sqlite3_open() > '/var/cache/lighttpd/lighttpd.webdav.db': unable to open database file > (server.c.1496) Configuration of plugins failed. Going down. > lighttpd.service: Control process exited, code=exited, status=255/EXCEPTION > lighttpd.service: Failed with result 'exit-code'. > Failed to start Lighttpd Daemon. > > > This happens because the user/group of 'www-data' is hard-coded in > /usr/lib/tmpfiles.d/lighttpd.tmpfile.conf Perhaps you should not change server.username unless you are also prepared to change other scripts and filesystem ownership as appropriate? What are you suggesting that lighttpd do in response to your *manual* modification? The Debian installation provides a working set of defaults, which includes running lighttpd under user www-data, and includes scripts which manage temporary files, upload directories, databases and cache locations, such as the mod_webdav sqlite database. If you have different needs, there is nothing that requires you to use the lighttpd service provided by Debian. You can create your own service with your own configuration, and can run it under a different user account. This custom service can run independently and concurrently with the Debian-provided /etc/lighttpd/lighttpd.conf (as long as each instance used different IP's and ports) Case in point, I often recommend spinning a test environment up as a non-privileged, non-production user with lighttpd listening on localhost (i.e. not a public IP and port).
Bug#971393: mbedtls: New upstream version (2.24.0) with TLS 1.3 support
mbedTLS 2.24.0 also addresses recent mbedTLS security advisories https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972806 Please upgrade to 2.24.0 in Debian testing. Thank you.
Bug#972806: mbedtls security advisories: local side channel attacks
Earlier this year, an issue was filed for security advisories in April: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963159
Bug#972806: mbedtls security advisories: local side channel attacks
Source: mbedtls Version: 2.16.0-1 Severity: serious Tags: security Justification: security Dear Maintainer, Mbed TLS 2.16.8 released 1 Sep 2020 addresses 3 security advisories ==> Please update mbedtls in all active Debian releases. Thank you. https://github.com/ARMmbed/mbedtls/releases https://tls.mbed.org/tech-updates/security-advisories Local side channel attack on classical CBC decryption in (D)TLS https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2020-09-1 CVE-2020-16150 Severity: High Local side channel attack on RSA and static Diffie-Hellman https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2020-09-2 Severity: High Protocol weakness in DHE-PSK key exchange https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2020-09-3 Severity: Low -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-12-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#510368: libgamin0: libfam shlib dependency wrongly set to libfam0
cross-posting to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510368 stbuehler wrote: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273 > Is there any reason to keep FAM around any longer in your opinion, > given upstream is dead and there is gamin? > > Or, in other words, why didn't you file a package removal request? > > Imho providing a package that runs a (even if just local) service as > root doesn't combine well with a dead upstream with regards to > security. > > I see the following reverse dependencies in aptitude: > > fam: (recommends) gnubiff > > libfam0: (depends) > courier-base > courier-imap > doodled > gnubiff > libkf5coreaddons5 > lighttpd > omake > sqwebmail > > Is any of these known to actually need fam instead of gamin? Negative. I just scanned the source code and *none* require FAM. gamin limitations according to https://people.gnome.org/~veillard/gamin/differences.html "The functions FAMSuspendMonitor(), FAMResumeMonitor() and FAMMonitorCollection() are not implemented. They all raise problem of accumulating unbounded state on the server side and better handled at the client level if needed." A simple egrep "FAMMonitorCollection|FAMSuspendMonitor|FAMResumeMonitor" through source code finds that none of the above packages use those APIs except omake. omake provides its own implementation of the FAM APIs, and on Linux, uses its own implementation employing inotify(). omake provides a kqueue implementation for *BSD, and a Win32 implementation for Windows. On other platforms, it uses FAM. To repeat, on Linux, omake uses its own implementation of FAM APIs employing inotify(). See omake source code lib/configure/fam.install None of the other packages reference the APIs in FAM missing in gamin. doodle and omake reference FamErrlist[FAMErrno], but if FAM is removed, building and depending on gamin has consistent behavior. ==> Therefore, it should be possible to remove FAM from Bullseye, and to change package dependencies from libfam-dev to libgamin-dev in Bullseye. ==> What are the next steps to remove FAM from Bullseye? Can the following be turned into a package removal request? RFA: fam -- File Alteration Monitor https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273 Cheers, Glenn https://tracker.debian.org/pkg/courier http://www.courier-mta.org/repo.html https://github.com/svarshavchik/courier https://github.com/svarshavchik/courier-libs Debian packages: courier-base courier-imap sqwebmail https://tracker.debian.org/pkg/doodle http://http.us.debian.org/debian/pool/main/d/doodle/ https://tracker.debian.org/pkg/gnubiff http://gnubiff.sourceforge.net/ https://tracker.debian.org/pkg/kcoreaddons https://invent.kde.org/frameworks/kcoreaddons https://tracker.debian.org/pkg/lighttpd https://salsa.debian.org/debian/lighttpd https://tracker.debian.org/pkg/omake https://salsa.debian.org/ocaml-team/omake
Bug#970803: lighttpd: appliation segfaults on start
Did you have a prior version of lighttpd running successfully? Which version? Please share your current lighttpd config $ lighttpd -f /etc/lighttpd/lighttpd.conf -p $ lighttpd -f /etc/lighttpd/lighttpd.conf -tt If you have strace installed: $ strace -s 1024 lighttpd -f /etc/lighttpd/lighttpd.conf -D
Bug#958520: lighttpd: remove usage of 'su' in crontab
Thanks for the report and suggestion. As you know, a patch has been pending since May https://salsa.debian.org/debian/lighttpd/-/commit/744b38fd5c4c4c11123733d1a5f1239a5a9b5a0d
Bug#961843: tags
tags 961843 - moreinfo
Bug#961843: buster-pu: package lighttpd/1.4.53-4
reattaching debdiff diff -Nru lighttpd-1.4.53/debian/changelog lighttpd-1.4.53/debian/changelog --- lighttpd-1.4.53/debian/changelog2019-04-13 00:00:00.0 -0400 +++ lighttpd-1.4.53/debian/changelog2020-03-21 19:30:00.0 -0400 @@ -1,11 +1,67 @@ +lighttpd (1.4.53-4+deb10u1) UNRELEASED; urgency=high + + * QA upload. + * backport security, bug, portability fixes from lighttpd 1.4.54, 1.4.55 + * mod_evhost, mod_flv_streaming: +[regression] %0 pattern does not match hostnames without the domain part +https://redmine.lighttpd.net/issues/2932 + * mod_magnet: Lighttpd crashes on wrong return type in lua script +https://redmine.lighttpd.net/issues/2938 + * failed assertion on incoming bad request with server.error-handler +https://redmine.lighttpd.net/issues/2941 + * mod_wstunnel: fix wstunnel.ping-interval for big-endian architectures +https://redmine.lighttpd.net/issues/2944 + * fix abort in server.http-parseopts with url-path-2f-decode enabled +https://redmine.lighttpd.net/issues/2945 + * remove repeated slashes in server.http-parseopts with url-path-dotseg-remove, including leading "//" + * [regression][Bisected] lighttpd uses way more memory with POST since 1.4.52 +https://redmine.lighttpd.net/issues/2948 + * OPTIONS should return 2xx status for non-existent resources if Allow is set +https://redmine.lighttpd.net/issues/2939 + * use high precision stat timestamp (on systems where available) in etag + * mod_authn_ldap/mod_cgi race condition, "Can't contact LDAP server" +https://redmine.lighttpd.net/issues/2940 + * SUN_LEN in sock_addr.c (1.4.53, 1.4.54) +https://redmine.lighttpd.net/issues/2962 + * Embedded vim command line in conf file with no comment (#) hangs server +https://redmine.lighttpd.net/issues/2980 + * mod_authn_gssapi: 500 if fail to delegate creds +https://redmine.lighttpd.net/issues/2967 + * mod_authn_gssapi: option to store delegated creds +https://redmine.lighttpd.net/issues/2967 + * mod_auth: require digest uri= match original URI +HTTP digest authentication not compatible with some clients +https://redmine.lighttpd.net/issues/2974 + * mod_auth: send Authentication-Info nextnonce when nonce is approaching expiration + * mod_auth: http_auth_const_time_memeq improvement + * mod_auth: http_auth_const_time_memeq_pad() + * mod_auth: use constant time comparison when comparing digests + * stricter request header parsing: reject WS following header field-name +https://redmine.lighttpd.net/issues/2985 + * stricter request header parsing: reject Transfer-Encoding + Content-Length +https://redmine.lighttpd.net/issues/2985 + * mod_openssl: reject invalid ALPN + * mod_accesslog: parse multiple cookies +https://redmine.lighttpd.net/issues/2986 + * preserve %2b and %2B in query string +https://redmine.lighttpd.net/issues/2999 + * mod_auth: close connection after bad password +mitigation slows down brute force password attacks +https://redmine.lighttpd.net/boards/3/topics/8885 + * do not accept() > server.max-connections + * update /var/run -> /run for systemd (closes: #929203) + + -- Glenn Strauss Sat, 21 Mar 2020 18:30:00 -0500 + lighttpd (1.4.53-4) unstable; urgency=high + * QA upload. * fix mixed use of srv->split_vals array (regression) * mod_magnet:fix invalid script return-type crash * fix assertion with server.error-handler * mod_wstunnel:fix wstunnel.ping-interval for big-endian architectures * fix abort in server.http-parseopts with url-path-2f-decode enabled -CVE-2019-11072 (closes #926885) +CVE-2019-11072 (closes: #926885) -- Glenn Strauss Sat, 13 Apr 2019 00:00:00 -0400 diff -Nru lighttpd-1.4.53/debian/.gitlab-ci.yml lighttpd-1.4.53/debian/.gitlab-ci.yml --- lighttpd-1.4.53/debian/.gitlab-ci.yml 2019-04-13 00:00:00.0 -0400 +++ lighttpd-1.4.53/debian/.gitlab-ci.yml 2020-03-21 19:30:00.0 -0400 @@ -1,13 +1,7 @@ -include: https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml +include: + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml -build: -extends: .build-unstable - -lintian: -extends: .test-lintian - -autopkgtest: -extends: .test-autopkgtest - -piuparts: -extends: .test-piuparts +variables: + # Disable reprotest until salsa-ci-team/pipeline#26 is resolved. + SALSA_CI_DISABLE_REPROTEST: 1 diff -Nru lighttpd-1.4.53/debian/patches/config-update-var-run-run-for-systemd.patch lighttpd-1.4.53/debian/patches/config-update-var-run-run-for-systemd.patch --- lighttpd-1.4.53/debian/patches/config-update-var-run-run-for-systemd.patch 1969-12-31 19:00:00.0 -0500 +++ lighttpd-1.4.53/debian/patches/config-update-var-run-run-for-systemd.patch 2020-03-21 19:30:00.0 -0400 @@ -0,0 +1,67 @@ +From 15cdc313b500e2473de
Bug#961843: buster-pu: package lighttpd/1.4.53-4
> > I'm attaching the correct debdiff now. > > There doesn't appear to have actually been an attachment here. I believe that the original debdiff attachment is correct. Please advise if that is not the case. Cheers, Glenn
Bug#961843: buster-pu: package lighttpd/1.4.53-4
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Dear Maintainer, Greetings! I am an upstream maintainer of lighttpd. Please accept this backport of important patches from lighttpd 1.4.54 (released 2019.05.27) lighttpd 1.4.55 (released 2020.01.31) The patches to backport have been hand-selected from the release available in buster-backports lighttpd 1.4.55-1~bpo10+1 since 2020.03.06 These patches fix important bugs from upstream lighttpd issue tracker https://redmine.lighttpd.net/issues (direct links below) including a couple in the Debian Bug Tracker https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954759 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929203 >From the debian/changelog: * backport security, bug, portability fixes from lighttpd 1.4.54, 1.4.55 + mod_evhost, mod_flv_streaming: [regression] %0 pattern does not match hostnames without the domain part https://redmine.lighttpd.net/issues/2932 + mod_magnet: Lighttpd crashes on wrong return type in lua script https://redmine.lighttpd.net/issues/2938 + failed assertion on incoming bad request with server.error-handler https://redmine.lighttpd.net/issues/2941 + mod_wstunnel: fix wstunnel.ping-interval for big-endian architectures https://redmine.lighttpd.net/issues/2944 + fix abort in server.http-parseopts with url-path-2f-decode enabled https://redmine.lighttpd.net/issues/2945 + remove repeated slashes in server.http-parseopts with url-path-dotseg-remove, including leading "//" + [regression][Bisected] lighttpd uses way more memory with POST since 1.4.52 https://redmine.lighttpd.net/issues/2948 (closes: #954759) + OPTIONS should return 2xx status for non-existent resources if Allow is set https://redmine.lighttpd.net/issues/2939 + use high precision stat timestamp (on systems where available) in etag + mod_authn_ldap/mod_cgi race condition, "Can't contact LDAP server" https://redmine.lighttpd.net/issues/2940 + SUN_LEN in sock_addr.c (1.4.53, 1.4.54) https://redmine.lighttpd.net/issues/2962 + Embedded vim command line in conf file with no comment (#) hangs server https://redmine.lighttpd.net/issues/2980 + mod_authn_gssapi: 500 if fail to delegate creds https://redmine.lighttpd.net/issues/2967 + mod_authn_gssapi: option to store delegated creds https://redmine.lighttpd.net/issues/2967 + mod_auth: require digest uri= match original URI HTTP digest authentication not compatible with some clients https://redmine.lighttpd.net/issues/2974 + mod_auth: send Authentication-Info nextnonce when nonce is approaching expiration + mod_auth: http_auth_const_time_memeq improvement + mod_auth: http_auth_const_time_memeq_pad() + mod_auth: use constant time comparison when comparing digests + stricter request header parsing: reject WS following header field-name https://redmine.lighttpd.net/issues/2985 + stricter request header parsing: reject Transfer-Encoding + Content-Length https://redmine.lighttpd.net/issues/2985 + mod_openssl: reject invalid ALPN + mod_accesslog: parse multiple cookies https://redmine.lighttpd.net/issues/2986 + preserve %2b and %2B in query string https://redmine.lighttpd.net/issues/2999 + mod_auth: close connection after bad password mitigation slows down brute force password attacks https://redmine.lighttpd.net/boards/3/topics/8885 + do not accept() > server.max-connections + update /var/run -> /run for systemd (closes: #929203) debdiff attached. I think it may be easier to review the contents of the files in debian/patches to see that the patches are generally small. Please advise how best to proceed. Thank you! Glenn -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled lighttpd-1.4.53-4+deb10u1.diff.xz Description: application/xz
Bug#961842: lighttpd: backport security, bug, portability fixes from lighttpd upstream
Source: lighttpd Version: 1.4.53-4 Severity: normal Tags: buster, patch Dear Maintainer, Greetings! I am an upstream maintainer of lighttpd. Please accept this backport of important patches from lighttpd 1.4.54 (released 2019.05.27) lighttpd 1.4.55 (released 2020.01.31) The patches to backport have been hand-selected from the release available in buster-backports lighttpd 1.4.55-1~bpo10+1 since 2020.03.06 These patches fix important bugs from upstream lighttpd issue tracker https://redmine.lighttpd.net/issues (direct links below) including a couple in the Debian Bug Tracker https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954759 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929203 >From the debian/changelog: * backport security, bug, portability fixes from lighttpd 1.4.54, 1.4.55 + mod_evhost, mod_flv_streaming: [regression] %0 pattern does not match hostnames without the domain part https://redmine.lighttpd.net/issues/2932 + mod_magnet: Lighttpd crashes on wrong return type in lua script https://redmine.lighttpd.net/issues/2938 + failed assertion on incoming bad request with server.error-handler https://redmine.lighttpd.net/issues/2941 + mod_wstunnel: fix wstunnel.ping-interval for big-endian architectures https://redmine.lighttpd.net/issues/2944 + fix abort in server.http-parseopts with url-path-2f-decode enabled https://redmine.lighttpd.net/issues/2945 + remove repeated slashes in server.http-parseopts with url-path-dotseg-remove, including leading "//" + [regression][Bisected] lighttpd uses way more memory with POST since 1.4.52 https://redmine.lighttpd.net/issues/2948 (closes: #954759) + OPTIONS should return 2xx status for non-existent resources if Allow is set https://redmine.lighttpd.net/issues/2939 + use high precision stat timestamp (on systems where available) in etag + mod_authn_ldap/mod_cgi race condition, "Can't contact LDAP server" https://redmine.lighttpd.net/issues/2940 + SUN_LEN in sock_addr.c (1.4.53, 1.4.54) https://redmine.lighttpd.net/issues/2962 + Embedded vim command line in conf file with no comment (#) hangs server https://redmine.lighttpd.net/issues/2980 + mod_authn_gssapi: 500 if fail to delegate creds https://redmine.lighttpd.net/issues/2967 + mod_authn_gssapi: option to store delegated creds https://redmine.lighttpd.net/issues/2967 + mod_auth: require digest uri= match original URI HTTP digest authentication not compatible with some clients https://redmine.lighttpd.net/issues/2974 + mod_auth: send Authentication-Info nextnonce when nonce is approaching expiration + mod_auth: http_auth_const_time_memeq improvement + mod_auth: http_auth_const_time_memeq_pad() + mod_auth: use constant time comparison when comparing digests + stricter request header parsing: reject WS following header field-name https://redmine.lighttpd.net/issues/2985 + stricter request header parsing: reject Transfer-Encoding + Content-Length https://redmine.lighttpd.net/issues/2985 + mod_openssl: reject invalid ALPN + mod_accesslog: parse multiple cookies https://redmine.lighttpd.net/issues/2986 + preserve %2b and %2B in query string https://redmine.lighttpd.net/issues/2999 + mod_auth: close connection after bad password mitigation slows down brute force password attacks https://redmine.lighttpd.net/boards/3/topics/8885 + do not accept() > server.max-connections + update /var/run -> /run for systemd (closes: #929203) debdiff attached. I think it may be easier to review the contents of the files in debian/patches to see that the patches are generally small. Please advise how best to proceed. Thank you! Glenn -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled lighttpd-1.4.53-4+deb10u1.diff.xz Description: application/xz
Bug#955833: please describe your "invalid data"
> GET requests send invalid data for files above 30kB when connecting to the
> server over http. But GET requests send good data when connecing over https.
What do you mean by "invalid data"? Please be more specific.
What kind of requests? Please be more specific.
It would be hightly unlikely that lighttpd would pass its unit tests and
yet be unable to server a static file.
Your minimal configuration is missing a basic mimetypes config which
would inform your browser of the Content-Type of the responses.
> include_shell "/usr/share/lighttpd/create-mime.conf.pl"
or, for testing purposes:
> mimetype.assign = (".html" => "text/html", ".png => "image/png" )
Bug#954864: RFS: lighttpd/1.4.53-5 [SPU, RC] -- backport security, bug fixes from upstream
Package: sponsorship-requests Severity: important Dear mentors, Please release lighttpd 1.4.53-5 as a stable-update to Buster. I am a lighttpd developer (upstream) and have prepared lighttpd 1.4.53-5 on the 'buster' branch at https://salsa.debian.org/debian/lighttpd/-/tree/buster The debian/changelog entry for 1.4.53-5 is currently marked UNRELEASED. The patches added to debian/patches do the following: * backport security, bug, portability fixes from lighttpd 1.4.54, 1.4.55 Numerous important fixes have been backported to Debian Buster package for lighttpd 1.4.53, including: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954759 This is my first submission to sponsorship-requests, so your guidance is appreciated. Cheers, Glenn -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#954760: RFS: lighttpd/1.4.53-5 {SPU, RC] -- backport security, bug fixes from upstream
Package: sponsorship-requests Severity: important Dear mentors, Please release lighttpd 1.4.53-5 as a stable-update to Buster. I am a lighttpd developer (upstream) and have prepared lighttpd 1.4.53-5 on the 'buster' branch at https://salsa.debian.org/debian/lighttpd/-/tree/buster The debian/changelog entry for 1.4.53-5 is currently marked UNRELEASED. The patches added to debian/patches do the following: * backport security, bug, portability fixes from lighttpd 1.4.54, 1.4.55 Numerous important fixes have been backported to Debian Buster package for lighttpd 1.4.53, including: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954759 This is my first submission to sponsorship-requests, so your guidance is appreciated. Cheers, Glenn -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#954759: lighttpd: streaming POST request uses way more memory since 1.4.51
Source: lighttpd Version: 1.4.53 Severity: important Tags: upstream Dear Maintainer, POST requests use way more memory than in lighttpd 1.4.51 when lighttpd is configured with: server.stream-request-body = 2 Upstream bug report: https://redmine.lighttpd.net/issues/2948 The excessive memory use was fixed in upstream lighttpd 1.4.54 and a patch is available -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#952541: patch proposed
lighttpd ssl.* directives can be inherited from the global scope
(without needing to be repeated in each condition) if the only ssl.*
directive in a socket condition is
$SERVER["socket"] == "..." { ssl.engine = "enable" }
conf-available/10-ssl.conf and use-ipv6.pl can be modifed to achieve
the behavior requested in this bug.
Proposed patch:
https://salsa.debian.org/debian/lighttpd/-/commit/3487cb5dbf39a588af2134822c64fdcae197a523
Bug#931827: lighttpd: server returnd 400, if %C0 is included in the URL
On Fri, Jul 12, 2019 at 02:13:00PM +0200, Helmut Grohne wrote: > Hi, > > On Thu, Jul 11, 2019 at 02:38:19AM +0200, OHNO Tetsuji wrote: > > lighttpd server is returnd ???400 Bad Request", if %C0 (or any other > > char.) is included in the URL. > > > > for example, > > http://localhost/index.lighttpd.html : return OK (display index page) > > http://localhost/index.lighttpd.html?%C0 : 400 Bad Request > > http://localhost/index.lighttpd.html?%C1 : 400 Bad Request > > http://localhost/index.lighttpd.html?%C2 : OK > > > > I can't understand this behavior. > > Thank you for the detailed report. I don't fully understand this either > and am thus Ccing Glenn Strauss (upstream). https://en.wikipedia.org/wiki/UTF-8#Overlong_encodings " The standard specifies that the correct encoding of a code point use only the minimum number of bytes required to hold the significant bits of the code point. Longer encodings are called overlong and are not valid UTF-8 representations of the code point. This rule maintains a one-to-one correspondence between code points and their valid encodings, so that there is a unique valid encoding for each code point. This ensures that string comparisons and searches are well-defined. " https://tools.ietf.org/html/rfc3986#section-2.5 " When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent- encoded. " tl;dr: URIs must contain valid UTF-8, including percent-encoded bytes of UTF-8 chars, as required above. C0 might be part of the byte sequence C0 80, which is an overlong UTF-8 encoding of the NUL character. In the wrong contexts, this might be abused in a truncation attack if C0 80 in the middle of a string were interpreted as '\0'. Both C0 and C1 bytes are part of overlong UTF-8 encodings, and are not part of any UTF-8 encodings using the minimum number of bytes, as required by the standard. Therefore, lighttpd rejects those percent-encoded bytes when looking for potentially malicious bytes in URLs. If you are storing binary data in a URL and naively percent-encode the bytes, doing so is not guaranteed to produce valid UTF-8. Please consider a different encoding for your binary data, such as base64 modified to use URL-safe chars. Cheers, Glenn
Bug#920915: outdated docs
Yes, you are right that the doc is outdated. The debian package installs docs from the lighttpd source tree path doc/outdated/*.txt We are aware of this issue, but it is non-trivial to correct. Updated lighttpd SSL doc can be found at: https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL Updated lighttpd doc in general can be found at: https://redmine.lighttpd.net/projects/lighttpd/wiki
Bug#916750:
> Problem #2: > > lighttpd presently produces 11 binary packages. That's quite many for an > otherwise small package. Adding binary packages has a metadata cost to > the Debian archive that affects everyone (not just lighttpd users). We > should seek to reduce the package count. IMHO, it appears that the origin of these issues is the metadata cost, and not that lighttpd is modular. It appears the metadata costs are the tail wagging the dog for package design decisions. That is most unfortunate. > How bad would it be to simply not ship these four packages in buster (as > is presently the case) and add them for bullseye? Which ones do we > really need for buster? Did I miss anything? The previous Debian lighttpd maintainers did a pretty poor job following upstream. Just about everything that you're doing is an improvement, so thank you. Perhaps for Buster, all the new packages should be removed, except those split from existing lighttpd core (mod_openssl) and from mod_auth (mod_authn_file, mod_authn_ldap). Hopefully, Debian will address the metadata cost scaling issue in a future Debian release. I still think it reflects poorly on Debian that lighttpd in Debian will be crippled due to Debian packaging scaling limitations. While I would like to see mod_openssl as its own package for the future, no such requirement exists at the moment, and other parts of lighttpd link against libcrypto (not libssl). The lighttpd build would have to be modified if lighttpd were to provide some algorithms with the core (e.g. SHA1), rather than obtaining them from libcrypto, and then mod_openssl built separately. So for now, let's not do mod_openssl as a separate package. As you proposed, we might proceed with creating lighttpd-modules-mysql and lighttpd-modules-ldap to start the transition, as that makes sense to group the modules depending on the database so that a future Debian release can remove those dependencies from the core. tl;dr: I agree with your proposal for lighttpd-modules-mysql and lighttpd-modules-ldap, though I might suggest lighttpd-modules-mariadb instead of lighttpd-modules-mysql. I agree with your proposal to avoid adding new modules to the lighttpd base package which would increase the dependency footprint of the lighttpd base package. I propose leaving the -dev build dependencies in debian/rules so that others could more easily build dpkgs of the additional modules, and install those modules themselves.
Bug#916786: 916750
Source: lighttpd Version: 1.4.52-1 > Problem #2: > > lighttpd presently produces 11 binary packages. That's quite many for an > otherwise small package. Adding binary packages has a metadata cost to > the Debian archive that affects everyone (not just lighttpd users). We > should seek to reduce the package count. IMHO, it appears that the origin of these issues is the metadata cost, and not that lighttpd is modular. It appears the metadata costs are the tail wagging the dog for package design decisions. That is most unfortunate. > How bad would it be to simply not ship these four packages in buster (as > is presently the case) and add them for bullseye? Which ones do we > really need for buster? Did I miss anything? The previous Debian lighttpd maintainers did a pretty poor job following upstream. Just about everything that you're doing is an improvement, so thank you. Perhaps for Buster, all the new packages should be removed, except those split from existing lighttpd core (mod_openssl) and from mod_auth (mod_authn_file, mod_authn_ldap). Hopefully, Debian will address the metadata cost scaling issue in a future Debian release. I still think it reflects poorly on Debian that lighttpd in Debian will be crippled due to Debian packaging scaling limitations. While I would like to see mod_openssl as its own package for the future, no such requirement exists at the moment, and other parts of lighttpd link against libcrypto (not libssl). The lighttpd build would have to be modified if lighttpd were to provide some algorithms with the core (e.g. SHA1), rather than obtaining them from libcrypto, and then mod_openssl built separately. So for now, let's not do mod_openssl as a separate package. As you proposed, we might proceed with creating lighttpd-modules-mysql and lighttpd-modules-ldap to start the transition, as that makes sense to group the modules depending on the database so that a future Debian release can remove those dependencies from the core. . tl;dr: I agree with your proposal for lighttpd-modules-mysql and lighttpd-modules-ldap, though I might suggest lighttpd-modules-mariadb instead of lighttpd-modules-mysql. I agree with your proposal to avoid adding new modules to the lighttpd base package which would increase the dependency footprint of the lighttpd base package. I propose leaving the -dev build dependencies in debian/rules so that others could more easily build dpkgs of the additional modules, and install those modules themselves.
Bug#850061: lighttpd graceful restart
lighttpd systemd service can be improved (related bug #856001, bug #838473, and bug #877870) Changes in recent versions of lighttpd allow graceful restart and other features Since lighttpd 1.4.46: https://git.lighttpd.net/lighttpd/lighttpd1.4.git/commit/?h=0ae6bab4a97f12a0c93200df36ac1741696eeed5 https://git.lighttpd.net/lighttpd/lighttpd1.4.git/diff/doc/systemd/lighttpd.service?h=0ae6bab4a97f12a0c93200df36ac1741696eeed5
Bug#879496: lighttpd 1.4.50 released
lighttpd 1.4.50 released https://www.lighttpd.net/2018/8/13/1.4.50/
