help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Eli Schwartz <eschwartz@archlinux.org>
Cc: discuss@mandoc.bsd.lv
Subject: Re: Compiling and packaging mandoc for Arch Linux
Date: Sat, 14 Aug 2021 16:50:00 +0200	[thread overview]
Message-ID: <20210814145000.GC88512@athene.usta.de> (raw)
In-Reply-To: <6fc50edc-3d53-1d9b-4123-8d29728671ed@archlinux.org>

Hi Eli,

Eli Schwartz wrote on Sun, Nov 01, 2020 at 01:32:26PM -0500:

> While investigating the possibility of adding a mandoc package to the
> official repositories for Arch Linux, I noticed that it doesn't
> currently compile without patches, which are fixed in CVS but not
> released. Any chance of an official release?

i'm currently working through forgotten feedback since i'm trying again
to prepare the next mandoc release; package maintainers will be asked
for testing once we are ready for that.

> Particularly:
> - https://cvsweb.bsd.lv/mandoc/configure.diff?r1=1.71&r2=1.72
> - various changes for compat_*.c
> compile correctly with gcc -fno-common (default in gcc 10)
> ...

Everything already committed to CVS HEAD will automatically be in the
upcoming release.

> I'm also wondering about this patch:
> https://aur.archlinux.org/cgit/aur.git/tree/fix-tbl-segfault.patch?h=mandoc
> Fixed a different way in
> https://cvsweb.bsd.lv/mandoc/tbl_term.c.diff?r1=1.69&r2=1.70
> The current maintainer of the unofficial package mentions:
> "right... IIRC these two behave exactly the same (at least for the
> inputs I tried) so it can be changed to match upstream"
> but I don't know which approach you'd consider "more correct", thought
> I'd mention it anyway.

The bsd.lv fix is more robust.

> Unfixed in the latest development source...
> [ -z "${INSTALL_LIB}"     ] && INSTALL_LIB="${INSTALL} -m 0444"
> [ -z "${INSTALL_MAN}"     ] && INSTALL_MAN="${INSTALL} -m 0444"
> [ -z "${INSTALL_DATA}"    ] && INSTALL_DATA="${INSTALL} -m 0444"
> What is the purpose of installing these files as non-writable by the
> *owner*?

Protection against accidental damage that might occur when an
administrator does some work as root.  It is standard practice in
*BSD to install system-installed files that are not supposed to be
changed at run time as non-writeable.  Just because an administrator
uses a root shell for some work does not imply they want to change
the content of system binaries.

> By definition, the owner may always achieve write access by a
> simple chmod, and the owner permission bits do not affect whether other
> users may modify the file... I don't see the point of this restriction
> except to inconvenience legitimate uses.

Needless to say, this is not a security feature, but part of a
defence-in-depth strategy against accidental mistakes.

Changing the content of installed system binaries almost never makes
sense even for a system administrator, and in the rare cases where
it is attempted, i believe it is almost invariably unintentional.

> Unfortunately, it is very problematic for creating an official package,
> as this prevents stripping the executables or generating debuginfo
> packages if the files are not writable during the packaging step.

I regularly use the OpenBSD packaging system but never encountered
such a problem while porting any software.  I'm not too familiar
with the internals of packaging systems, though.

> If it turns out there's no good purpose here, then I can locally hack
> around this, but then equally it seems like the defaults should be made
> a bit saner.

I think installing system binaries non-writeable is quite sane,
and i have no intention of changing that.

 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

      reply	other threads:[~2021-08-14 14:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-01 18:32 Eli Schwartz
2021-08-14 14:50 ` Ingo Schwarze [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210814145000.GC88512@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=discuss@mandoc.bsd.lv \
    --cc=eschwartz@archlinux.org \
    --subject='Re: Compiling and packaging mandoc for Arch Linux' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).