Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1245509 > unrolled thread

Bug#1104616: Backporting trixie mini-httpd

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1104616: Backporting trixie mini-httpd Lloyd <ng2d68@proton.me> - 2025-05-10 18:50 +0200
    Bug#1104616: Backporting trixie mini-httpd Alexandru Mihail <alexandru.mihail2897@gmail.com> - 2025-05-10 19:50 +0200
      Bug#1104616: Backporting trixie mini-httpd Lloyd <ng2d68@proton.me> - 2025-05-11 08:10 +0200
        Bug#1104616: Backporting trixie mini-httpd Alexandru Mihail <alexandru.mihail2897@gmail.com> - 2025-05-11 11:50 +0200
          Bug#1104616: Backporting trixie mini-httpd Alexandru Mihail <alexandru.mihail2897@gmail.com> - 2025-05-11 12:00 +0200
            Bug#1104616: Backporting trixie mini-httpd Lloyd <ng2d68@proton.me> - 2025-05-11 23:30 +0200

#1245509 — Bug#1104616: Backporting trixie mini-httpd

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

[toc] | [next] | [standalone]

#1245520

Hi,
It should work, let me try it on a stable VM I have and I'll get back to you. The source build from the src package will 100% work.

Alex

[toc] | [prev] | [next] | [standalone]

#1245562

Alexandru Mihail wrote:

> Therefore, I recommend the source route and I'll give you all
> instructions, works on a fresh stable VM. Hope this solves your issue
> Lloyd :D (until perhaps you update to trixie when it comes out)

Hi Alex - thanks for the helpful info and detailed instructions!

I was able to easily build the package; but, the service would not
start. Several hours later I was able to identify the root cause.

Unfortunately, it appears I uncovered a new bug. :(

I run mini-httpd in chroot mode. The new systemd unit file in the
latest release explicitly blacklists chroot syscall via the @mount
syscall filter group. I've provided a patch below. However, for
clarity's sake I think it's best I resolve this bug and open a new
one.

Regards
Lloyd

--- mini-httpd.service.default
+++ mini-httpd.service.modified
@@ -14,7 +14,7 @@
 ProtectSystem=full
 CapabilityBoundingSet=~CAP_BPF CAP_LINUX_IMMUTABLE CAP_IPC_LOCK CAP_SYS_TTY_CONFIG \
                        CAP_SYS_BOOT CAP_MAC_* CAP_SYS_NICE CAP_SYS_RESOURCE CAP_SYS_PTRACE
-SystemCallFilter=~@clock @cpu-emulation @debug @module @mount @obsolete @reboot @raw-io
+SystemCallFilter=~@clock @cpu-emulation @debug @module @obsolete @reboot @raw-io
 RestrictNamespaces=~uts ipc pid user cgroup
 ProtectKernelTunables=yes
 ProtectKernelModules=yes
@@ -27,4 +27,4 @@
 LockPersonality=yes

[toc] | [prev] | [next] | [standalone]

#1245572

[Multipart message — attachments visible in raw view] — view raw

Hi,
Thanks for the help !
Yes, indeed, the chroot functionality you discussed doest not properly work with the service, I retested. Thanks for providing the patch, I will produce a release in a few days which will incorporate the fix.
I see you already created a bug, that's very good. Please, adjust the severity to NORMAL from serious again.We're in the middle of the trixie freeze and serious should only be release critical things now.(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105097)

Thanks for your contribution to Debian!

Alexandru

[toc] | [prev] | [next] | [standalone]

#1245576

[Multipart message — attachments visible in raw view] — view raw

P.S: Please rush to change bug severity to normal or Salvo will scream here again, justly :) I'm not home right now.
P.P.S I think you're lucky with the backport request, there is another bug in stable which apparently prevents starting with initscripts. The user didn't provide very clean logs. 
(Perhaps if you have a bit of time you can help me confirm his problem too granted you're also on stable ? -https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101557) If I confirm that bug too, I'll make a backport too, I don't like bugs piling up, especially since upstream is gone and I'm in effect the sole upstream of mini-httpd in all Linux land.

[toc] | [prev] | [next] | [standalone]

#1245641

Hi Alex

> P.S: Please rush to change bug severity to normal

done

> (Perhaps if you have a bit of time you can help me
> confirm his problem too granted you're also on stable

I don't think it's a bug, he forgot to enable the service.

mini-httpd ships disabled by default, no? Seems like a good
plan for security and consistent with other Debian packages.

I just wanted to mention the patch provided in the new bug
report is updated (and improved) than the one I posted here.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web