From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3432 invoked from network); 14 Aug 2021 14:50:07 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 14 Aug 2021 14:50:07 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id cbe6ced7 for ; Sat, 14 Aug 2021 09:50:05 -0500 (EST) Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 1c73a07c for ; Sat, 14 Aug 2021 09:50:04 -0500 (EST) Received: from hekate.asta.kit.edu ([141.3.145.153] helo=hekate.usta.de) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1mEuz4-0003J3-KR; Sat, 14 Aug 2021 16:50:03 +0200 Received: from donnerwolke.asta.kit.edu ([141.3.145.61] helo=donnerwolke.usta.de) by hekate.usta.de with esmtp (Exim 4.92.2) (envelope-from ) id 1mEuz2-0005IS-JK; Sat, 14 Aug 2021 16:50:00 +0200 Received: from athene.asta.kit.edu ([141.3.145.60] helo=athene.usta.de) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1mEuz2-0007ce-DC; Sat, 14 Aug 2021 16:50:00 +0200 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id dd7e22a2; Sat, 14 Aug 2021 16:50:00 +0200 (CEST) Date: Sat, 14 Aug 2021 16:50:00 +0200 From: Ingo Schwarze To: Eli Schwartz Cc: discuss@mandoc.bsd.lv Subject: Re: Compiling and packaging mandoc for Arch Linux Message-ID: <20210814145000.GC88512@athene.usta.de> References: <6fc50edc-3d53-1d9b-4123-8d29728671ed@archlinux.org> X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6fc50edc-3d53-1d9b-4123-8d29728671ed@archlinux.org> User-Agent: Mutt/1.12.2 (2019-09-21) 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