Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Build failure on macOS 10.15 (Julien ?LIE)
2. Re: Build failure on macOS 10.15 (Bo Lindbergh)
3. Re: systemd hardening for INN (Russ Allbery)
4. Re: Hardening flags (Russ Allbery)
5. Re: Hardening flags (Russ Allbery)
6. Re: Static builds & snapshots (Russ Allbery)
7. Re: Discussion about Cancel-Lock support (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Sun, 29 Nov 2020 22:25:20 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Build failure on macOS 10.15
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Bo,
Suggested fix:
--- m4/cc-flags.m4 (r?vision 10422)
+++ m4/cc-flags.m4 (copie de travail)
@@ -1,9 +1,10 @@
dnl Check whether the compiler supports particular flags.
dnl $Id$
dnl
-dnl Provides INN_PROG_CC_FLAG, which checks whether a compiler supports a
-dnl given flag. If it does, the commands in the second argument are
run. If
-dnl not, the commands in the third argument are run.
+dnl Provides INN_PROG_CC_FLAG and INN_PROG_LD_FLAG, which check whether
+dnl a compiler supports a given flag, respectively in CFLAGS and LDFLAGS
+dnl when invoking the linker. If it does, the commands in the second
+dnl argument are run. If not, the commands in the third argument are run.
dnl
dnl The canonical version of this file is maintained in the rra-c-util
dnl package, available at
<https://www.eyrie.org/~eagle/software/rra-c-util/>.
@@ -29,6 +30,8 @@
dnl Used to build the result cache name.
AC_DEFUN([_INN_PROG_CC_FLAG_CACHE],
[translit([inn_cv_compiler_c_$1], [-=+,], [____])])
+AC_DEFUN([_INN_PROG_LD_FLAG_CACHE],
+[translit([inn_cv_linker_c_$1], [-=+,], [____])])
dnl Check whether a given flag is supported by the compiler.
AC_DEFUN([INN_PROG_CC_FLAG],
@@ -46,3 +49,16 @@
AC_MSG_RESULT([$_INN_PROG_CC_FLAG_CACHE([$1])])
AS_IF([test x"$_INN_PROG_CC_FLAG_CACHE([$1])" = xyes], [$2], [$3])])
+dnl Check whether a given flag is supported by the linker.
+AC_DEFUN([INN_PROG_LD_FLAG],
+[AC_REQUIRE([AC_PROG_CC])
+ AC_MSG_CHECKING([if $LD supports $1])
+ AC_CACHE_VAL([_INN_PROG_LD_FLAG_CACHE([$1])],
+ [save_LDFLAGS=$LDFLAGS
+ LDFLAGS="$LDFLAGS $1"
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([], [int foo = 0;])],
+ [_INN_PROG_LD_FLAG_CACHE([$1])=yes],
+ [_INN_PROG_LD_FLAG_CACHE([$1])=no])
+ LDFLAGS=$save_LDFLAGS])
+ AC_MSG_RESULT([$_INN_PROG_LD_FLAG_CACHE([$1])])
+ AS_IF([test x"$_INN_PROG_LD_FLAG_CACHE([$1])" = xyes], [$2], [$3])])
--- configure.ac (r?vision 10422)
+++ configure.ac (copie de travail)
@@ -686,14 +686,14 @@
AS_IF([test x"$inn_enable_hardening_flags" = xyes],
[INN_PROG_CC_FLAG([-fPIE], [CFLAGS="${CFLAGS} -fPIE"
CC_WARNINGS="${CC_WARNINGS} -fPIE"
- LDFLAGS="${LDFLAGS} -fPIE -pie"], [])
+ LDFLAGS="${LDFLAGS} -pie"], [])
INN_PROG_CC_FLAG([-fstack-protector-strong],
[CFLAGS="${CFLAGS} -fstack-protector-strong"
CC_WARNINGS="${CC_WARNINGS}
-fstack-protector-strong"],
[])
- INN_PROG_CC_FLAG([-Wl,-z,relro],
+ INN_PROG_LD_FLAG([-Wl,-z,relro],
[LDFLAGS="${LDFLAGS} -Wl,-z,relro"], [])
- INN_PROG_CC_FLAG([-Wl,-z,now],
+ INN_PROG_LD_FLAG([-Wl,-z,now],
[LDFLAGS="${LDFLAGS} -Wl,-z,now"], [])])
dnl Clean up our LIBS, just for grins.
> config.log contains:
>> configure:30703: checking if gcc supports -Wl,-z,relro
>> configure:30728: gcc -c -Wno-error=all -Os -g -fPIE -fstack-protector-strong
>> -Wl,-z,relro conftest.c >&5
>> clang: warning: -Wl,-z,relro: 'linker' input unused
>> [-Wunused-command-line-argument]
>> configure:30728: $? = 0
>> configure:30737: result: yes
>> configure:30743: checking if gcc supports -Wl,-z,now
>> configure:30768: gcc -c -Wno-error=all -Os -g -fPIE -fstack-protector-strong
>> -Wl,-z,now conftest.c >&5
>> clang: warning: -Wl,-z,now: 'linker' input unused
>> [-Wunused-command-line-argument]
>> configure:30768: $? = 0
>> configure:30777: result: yes
With the above patch, the result seems the expected one with macOS 11.0:
configure:30423: checking if
/Library/Developer/CommandLineTools/usr/bin/ld supports -Wl,-z,relro
configure:30441: gcc -o conftest -g -O2 -fPIE -fstack-protector-strong
-pie -Wl,-z,relro conftest.c >&5
clang: warning: argument unused during compilation: '-pie'
[-Wunused-command-line-argument]
ld: unknown option: -z
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
configure:30441: $? = 1
configure:30451: result: no
configure:30457: checking if
/Library/Developer/CommandLineTools/usr/bin/ld supports -Wl,-z,now
configure:30475: gcc -o conftest -g -O2 -fPIE -fstack-protector-strong
-pie -Wl,-z,now conftest.c >&5
clang: warning: argument unused during compilation: '-pie'
[-Wunused-command-line-argument]
ld: unknown option: -z
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
configure:30475: $? = 1
configure:30485: result: no
Is it OK for you too?
--
Julien ?LIE
??Pourquoi les programmeurs confondent-ils Halloween et No?l??
Parce que OCT 31 == DEC 25.??
------------------------------
Message: 2
Date: Mon, 30 Nov 2020 00:23:55 +0100
From: Bo Lindbergh <[email protected]>
To: [email protected]
Subject: Re: Build failure on macOS 10.15
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
./configure now says this:
> checking if /Library/Developer/CommandLineTools/usr/bin/ld supports
> -Wl,-z,relro... no
> checking if /Library/Developer/CommandLineTools/usr/bin/ld supports
> -Wl,-z,now... no
... and everything builds. Looks good.
I think the description is a bit off, though: the "-Wl,-z,relro" option
is passed to the C compiler, not to the linker.
/Bo Lindbergh
------------------------------
Message: 3
Date: Sun, 29 Nov 2020 17:48:05 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: systemd hardening for INN
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
>> I'm still testing, but in early experiments the following systemd service
>> unit seems to work for starting INN while applying considerably more
>> protections than the sample one included in the source tree. (This is
>> using Debian package paths.)
> [...]
>> AmbientCapabilities=CAP_NET_BIND_SERVICE
>> NoNewPrivileges=true
>> PrivateDevices=true
>> PrivateTmp=true
>> ProtectControlGroups=true
>> ProtectHome=true
>> ProtectKernelModules=true
>> ProtectKernelTunables=true
>> ProtectSystem=full
>> RuntimeDirectory=news
> [...]
> Any improvement since your last mail in August?
Nope, it seems to be working well on Debian stable.
>> Setting NoNewPrivileges will break most local sendmail implementations
>> because they're setuid or setgid to drop off mail in the mail queue.
>> With this configuration, I'm using mSMTP as the configured mta, set to
>> forward mail via SMTP to localhost.
> So maybe this setting should be commented out in the sample.
Yes, what you committed looks great to me. Thanks!
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 4
Date: Sun, 29 Nov 2020 17:51:19 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Hardening flags
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Also, FYI, automake has just included upstream our local changes to
> install-sh:
> https://lists.gnu.org/archive/html/automake-patches/2020-11/index.html
Oh, excellent!
> Only the Cygwin part has not:
> + # For Cygwin compatibility.
> + if [ -x "$src".exe ]; then
> + src=${src}.exe
> + fi
> I think this change is too dangerous. It would make it impossible to
> install foo if foo.exe exists, regardless of what was intended.
> I think Cygwin support has to be handled at a different level,
> like EXEEXT in Autoconf.
> Well, we're not impacted so it's fine for this local change to install-sh.
Yes, I'm fairly sure the Cygwin support in INN doesn't currently work
(that's the sort of thing that will break quickly without someone actively
looking out for it, and I don't think anyone has been interested since
Greg Andruk).
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 5
Date: Sun, 29 Nov 2020 17:56:08 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Hardening flags
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Hi all,
>> A remaining issue is a build with "--with-pic=no".
> I would finally just suggest to disable the generation of shared
> libraries when PIC mode is disabled.
> --with-pic=no -> call to AC_DISABLE_SHARED
This seems fine to me, although I'll also say that I think it's fine not
to put too much maintenance effort into accomodating odd combinations of
flags. Shared libraries are by definition position-independent (at least
on basically all modern platforms), so if one wants non-PIC code,
disabling shared libraries is the right approach. (It's not the sort of
thing that I think it's likely anyone would turn off.)
> I'm also wondering whether a --with-pie configure option wouldn't be
> useful to have. It would be on by default, and would permit to easily
> disable a PIE build when needed (for instance in architectures that do
> not support it correctly).
I have no objections, but we could also wait to see if anyone cares and
save the maintenance effort if no one asks for it.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 6
Date: Sun, 29 Nov 2020 18:00:25 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Static builds & snapshots
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Linking with static libraries now work fine again!
> Fix will be present in upcoming INN 2.6.4:
> https://inn.eyrie.org/trac/changeset/10406/ (issue with circular
> dependencies + Libtool bug)
> https://inn.eyrie.org/trac/changeset/10412/ (issue with expire.c)
> Patch submitted to improve --preserve-dup-deps in Libtool Debian package.
Great, thank you for fixing this!
> Incidentally, would it be possible to add a few configure flags to INN
> during the dailing generation of snapshots? It would regularly test
> that some options are still working fine.
> For instance :
> - on Monday: ./configure --enable-shared=no
> - on Tuesday: ./configure --enable-tagged-hash
> - on Wednesday: ./configure --enable-keywords
> - on Thursday: ./configure --enable-largefiles
> - on Friday: ./configure --enable-reduced-depends
> - on the other days: ./configure
We could just build with all variations every snapshot run with a make
distclean between them. CPU is cheap. The cron job that does that just
runs support/mksnapshot, so feel free to commit whatever iteration of
options you think would be good to test to that script.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 7
Date: Sun, 29 Nov 2020 18:09:19 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> First: do you all agree that support for Cancel-Lock/Key should be
> natively integrated in both innd and nnrpd? (in C source code) or do you
> prefer only an update to Perl filter hook samples to add an example of
> code to deal with that feature?
I think it's fine to integrate it directly since it will be an inn.conf
option. It may be worth considering getting rid of verifycancels while
we're at it to reduce some complexity, since the check it enables is
essentially meaningless and RFC 5537 actively recommends against this.
Cancel-Lock support is the correct approach to achieve the same ends
(although of course most people don't generate Cancel-Lock headers).
> General features:
> - comply with RFC 8315 (Cancel-Lock)
> - when an article is posted, a user cancel lock is added (unless
> existing), and always an admin cancel lock is added
> - when a cancel (or supersedes) is posted, a user cancel key is always added
> - when a cancel (or supersedes) is received, it is checked, whether one of
> the keys matches one of the locks. If yes, the cancel is
> honoured. Otherwise, it has no effect, but is still accepted and relayed
> - no check at injection time by nnrpd of the validity of a provided cancel
> key. Indeed, we may no longer have the original article in the spool to
> check that. If the cancel key is wrong, or the original article had no
> lock, the cancel will just not be honoured.
This all sounds good.
> - rely on libcanlock (check for presence at configure time)
> => OK with that? new --with-canlock option (like --with-perl) and the
> functionality is not available if libcanlock is not installed?
Yes, I think this is the right approach. libcanlock is already packaged
for Debian, and I'm not a fan of including copies of code that someone
else is already maintaining when we can avoid it.
> - new inn.conf parameters:
> * canlockuser (default to <pathetc>/canlock.usr) to store the secret
> passphrase used for the user lock (uid+secret)
> * canlockadmin (default to <pathetc>/canlock.adm) to store the secret
> passphrase used for the news administrator lock
Yeah, this is probably fine. It would be nice if we had a general secrets
configuration for INN, but we don't, and this is probably the easiest way
to go forward.
> - which hash algorithm to support? and how?
> I suggest not to generate nor honour md5 hashes.
> But what for sha1, sha224, sha256, sha384 and sha512? Honour all of them
> but generate only sha256 and/or sha512?
> Force for instance the generation of sha256 (the only MANDATORY algorithm
> in RFC 8315)? or parameter the one to use? or parameter all that should
> be used (multiple locks and keys to add)?
My inclination would be to support all of the non-MD5 algorithms for
verification but only generate SHA-256. I don't think there's much gained
by using the other algorithms.
It looks like Gnus still only supports SHA-1.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 125, Issue 12
********************************************
