Hi Alexandru, thanks for the reply! Will the binary package from testing work as-is on stable/oldstable? I am usually careful about pulling packages forward that didn't get a backport build because I assumed there were other dependencies that would break, perhaps on OpenSSL versions and other such things, but from your note it sounds like that may not be an issue after all?
Building from source is another option. I fully understand on the time commitment. Thanks for stepping in as maintainer. Regards Lloyd Alexandru Mihail wrote: > Hi, > Thanks for using mini-httpd ! > > Indeed, not logging CGI has security implications, for sure. However, > the version of mini-httpd in buster/bullseye has a LOAD of other issues > as well (multihosting bugs, a buffer overflow I believe, no systemd > service, etc). > That version predates me as a maintainer of this package. > If I were to release a backport of mini-httpd to stable and/or > oldstable, I would have to port all new patches and retest, since it > would be of little help to create a whole release just for CGI logging. > Sadly, I currently lack the manpower for this. > > I have to ask, is there any reason at all for you to not just use the > current testing (12) release on stable/oldstable ? You would get lots > of other benefits in addition to fixing your CGI issue (systemd with > hardening, better logging in general, etc) That's what I already do in > production with my setup. As Salvo said, this is not RC for trixie as > these changes are already applied in time for the trixie freeze. > > I'll close this in a few days if nothing happens > > > Have a good one, > Alexandru
