discuss@mandoc.bsd.lv
 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
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_PROGRAM}" ] && INSTALL_PROGRAM="${INSTALL} -m 0555"
> [ -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.

Yours,
  Ingo
--
 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* 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 \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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

discuss@mandoc.bsd.lv

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/mandoc-discuss

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 mandoc-discuss mandoc-discuss/ https://inbox.vuxu.org/mandoc-discuss \
		discuss@mandoc.bsd.lv
	public-inbox-index mandoc-discuss

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.mandoc.discuss


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git