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: Hardening flags (Julien ?LIE)
2. Re: Hardening flags (Russ Allbery)
3. Re: Hardening flags (Julien ?LIE)
4. Re: Hardening flags (Julien ?LIE)
5. Re: Hardening flags (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Thu, 12 Nov 2020 19:36:32 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Hardening flags
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
> Syncing rra-c-util will also pick up the fix for Debian bug #974024.
Did you commit the fix for #974024? (build issue on IPV6-only builds)
I do not see it.
In NEWS:
Include string.h in the probe for AI_ADDRCONFIG support to avoid
problems on macOS X. Thanks, Julien ?LIE.
Thanks should be for Bo Lindbergh regarding this patch!
--
Julien ?LIE
??Sum, ergo bibo?; bibo, ergo sum.??
------------------------------
Message: 2
Date: Thu, 12 Nov 2020 11:18:26 -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 Russ,
>> Syncing rra-c-util will also pick up the fix for Debian bug #974024.
> Did you commit the fix for #974024? (build issue on IPV6-only builds)
> I do not see it.
It's commit b7d8ecafc9d5a7a8e3d37128640061e1ad0eb9da which I think hasn't
been synced to INN yet (although I have used Git so much that I've
forgotten how to use Subversion, so maybe I'm missing it)... oh, yes, I
did miss it. I think you already synced this as r10388, so I think the
Debian bug will be fixed by updating to code later than that. (Obviously
a release is a great idea.)
> In NEWS:
> Include string.h in the probe for AI_ADDRCONFIG support to avoid
> problems on macOS X. Thanks, Julien ?LIE.
> Thanks should be for Bo Lindbergh regarding this patch!
Oh, yes, sorry Bo. Will fix. Thanks for the correction!
--
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: 3
Date: Thu, 12 Nov 2020 20:58:04 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Hardening flags
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
>>> Syncing rra-c-util will also pick up the fix for Debian bug #974024.
>
>> Did you commit the fix for #974024? (build issue on IPV6-only builds)
>> I do not see it.
>
> It's commit b7d8ecafc9d5a7a8e3d37128640061e1ad0eb9da which I think hasn't
> been synced to INN yet (although I have used Git so much that I've
> forgotten how to use Subversion, so maybe I'm missing it)... oh, yes, I
> did miss it. I think you already synced this as r10388
Yes, exactly, it is r10388 in CURRENT.
Yet not committed to STABLE, but will do soon.
> so I think the Debian bug will be fixed by updating to code later
> than that. (Obviously a release is a great idea.)
Seems like a yearly or every two years release (like this one) is a good
idea. There are always little fixes or improvements that could benefit
to some people.
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
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.
--
Julien ?LIE
??? Nous parlerons quand l'interpr?te dormira. [Bong?!]
? Il dort. On peut parler.?? (Ast?rix)
------------------------------
Message: 4
Date: Thu, 12 Nov 2020 23:55:37 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Hardening flags
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
>> Suggested addition in configure.ac:
>
>> dnl Add hardening flags, if supported by the compiler.
>> INN_PROG_CC_FLAG([-fPIE], [CFLAGS="${CFLAGS} -fPIE"
>> LDFLAGS="${LDFLAGS} -fPIE -pie"], [])
>> INN_PROG_CC_FLAG([-fstack-protector-strong],
>> [CFLAGS="${CFLAGS} -fstack-protector-strong"], [])
>
> This looks fine for the stack protector flag. I'm not sure about PIE; it
> seems to be rather complicated. The dpkg-buildflags documentation says:
>
> If there is a need to set these flags manually, bypassing the gcc
> specs injection, there are several things to take into account.
> Unconditionally and explicitly passing -fPIE, -fpie or -pie to a
> build-system using libtool is safe as these flags will get stripped
> when building shared libraries. Otherwise on projects that build
> both programs and shared libraries you might need to make sure that
> when building the shared libraries -fPIC is always passed last (so
> that it overrides any previous -PIE) to compilation flags such as
> CFLAGS, and -shared is passed last (so that it overrides any
> previous -pie) to linking flags such as LDFLAGS. Note: This should
> not be needed with the default gcc specs machinery.
Indeed, in the libtool script, these rules are correctly enforced.
>> ../libtool --mode=link gcc -fPIE -pie
>> -L/home/iulius/work/cyrus-install/lib -o authprogs/ident.t
>> authprogs/ident-t.o tap/basic.o /home/iulius/work/inn/trunk/lib/libinn.la
>> libtool: link: gcc -fPIE -pie -o authprogs/.libs/ident.t
>> authprogs/ident-t.o tap/basic.o -L/home/iulius/work/cyrus-install/lib
>> /home/iulius/work/inn/trunk/lib/.libs/libinn.so -Wl,-rpath
>> -Wl,/home/iulius/work/test-inn-bdb/lib
>> /usr/bin/ld: authprogs/ident-t.o: relocation R_X86_64_32 against
>> `.rodata.str1.1' can not be used when making a shared object; recompile
>> with -fPIC
>
> I think the problem is that the tests Makefile doesn't use libtool to
> compile the individual objects. It just uses CC. Therefore, it doesn't
> get the -fPIE flag and therefore doesn't create position-independent
> objects. That's how I'd interpret that error.
Exact, the -fPIE flag was not set. Problem spotted: build flags were
inconsistent when using "make warnings". Another variable (CC_WARNINGS)
should have been set:
INN_PROG_CC_FLAG([-fPIE], [CFLAGS="${CFLAGS} -fPIE"
CC_WARNINGS="${CC_WARNINGS} -fPIE"
LDFLAGS="${LDFLAGS} -fPIE -pie"], [])
Now builds fine!
> However, I don't know why --with-pic=yes would fix this problem.
Because I ran "make" without warnings on that time, to have less output
on the screen...
So, no, it does not fix the problem.
> I'm also not sure why the same problem doesn't happen when building other
> executables like innd, although I'll note those Makefiles don't seem to
> specify a .c.o rule, whereas the tests Makefile does. (But perl.o and
> python.o are built with just CC, so... I'm confused.)
Seems like only lib, storage and history directories use libtool for
compiling (the 3 libraries we generate). All the other directories use
CC directly for compiling.
For linking, libtool is always use.
Hmm, the rule for lib/perl.c differs from the others in lib/Makefile:
.c.o .c.lo:
$(LIBCC) $(CFLAGS) -c $*.c
perl.o: perl.c
$(CC) $(CFLAGS) $(PERL_CPPFLAGS) $(LDFLAGS) -c perl.c
Maybe it should also use LIBCC (with its specific PERL_CPPFLAGS).
> Honestly, a lot of things would be easier if we used Automake. There's a
> lot of very INN-specific Makefile machinery and I suspect that's breaking
> somewhere. But that's a whole other project.
A remaining issue is a build with "--with-pic=no".
It fails with "can not be used when making a shared object; recompile
with -fPIC".
So I try "--with-pic=no --enable-shared=no" and there are a few things
to investigate further (multiple definitions, undefined references...).
Well, it seems that INN does not currently build with static libraries!
As a matter of fact, we have in nnrpd.h and ovinterface.h:
extern char *ACTIVE;
So the one in nnrpd should be renamed.
ovdb does not build:
/home/iulius/work/gcc/gcc-10.1.0/bin/gcc -fPIE -pie -o ovdb_init
ovdb_init.o /home/iulius/work/inn/trunk/history/.libs/libinnhist.a
/home/iulius/work/inn/trunk/storage/.libs/libstorage.a
/home/iulius/work/inn/trunk/lib/.libs/libinn.a -ldb -lz
/home/iulius/work/inn/trunk/storage/.libs/libstorage.a(expire.o): dans
la fonction ? OVhisthasmsgid ?:
/home/iulius/work/inn/trunk/storage/expire.c:804: r?f?rence ind?finie
vers ? HISlookup ?
I'll go on fixing that tomorrow.
As for now, it seems that the following lines are enough to correctly
build INN with PIE support and libtool.
INN_PROG_CC_FLAG([-fPIE], [CFLAGS="${CFLAGS} -fPIE"
CC_WARNINGS="${CC_WARNINGS} -fPIE"
LDFLAGS="${LDFLAGS} -fPIE -pie"], [])
--
Julien ?LIE
??? Nous parlerons quand l'interpr?te dormira. [Bong?!]
? Il dort. On peut parler.?? (Ast?rix)
------------------------------
Message: 5
Date: Fri, 13 Nov 2020 11:33:31 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Hardening flags
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
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
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).
> ovdb does not build:
> /home/iulius/work/gcc/gcc-10.1.0/bin/gcc -fPIE -pie -o ovdb_init
> ovdb_init.o? /home/iulius/work/inn/trunk/history/.libs/libinnhist.a
> /home/iulius/work/inn/trunk/storage/.libs/libstorage.a
> /home/iulius/work/inn/trunk/lib/.libs/libinn.a -ldb -lz
> /home/iulius/work/inn/trunk/storage/.libs/libstorage.a(expire.o): dans
> la fonction ? OVhisthasmsgid ?:
> /home/iulius/work/inn/trunk/storage/expire.c:804: r?f?rence ind?finie
> vers ? HISlookup ?
>
> I'll go on fixing that tomorrow.
I believe it is the same sort of issue we once had:
https://inn.eyrie.org/trac/changeset/9720/
"Backend commands (such as nntpget) linked with both history
and storage libraries list $(LIBSTORAGE) in the link line twice.
This isn't a mistake; there are some unfortunate circular
dependencies that require listing $(LIBSTORAGE) both before
and after $(LIBINNHIST) in the link line or static linking will
fail.
This time, it happens to frontends (ovdb) and we have libtool...
I've seen that a special flag --preserve-dup-deps can be used. But
unfortunately, it does not work (stripping the duplicate libstorage.la):
../libtool --preserve-dup-deps --mode=link
/home/iulius/work/gcc/gcc-10.1.0/bin/gcc -o ovdb_monitor ovdb_monitor.o
/home/iulius/work/inn/trunk/storage/libstorage.la
/home/iulius/work/inn/trunk/history/libinnhist.la
/home/iulius/work/inn/trunk/storage/libstorage.la
/home/iulius/work/inn/trunk/lib/libinn.la -ldb -lz
libtool: link: /home/iulius/work/gcc/gcc-10.1.0/bin/gcc -o ovdb_monitor
ovdb_monitor.o /home/iulius/work/inn/trunk/history/.libs/libinnhist.a
/home/iulius/work/inn/trunk/storage/.libs/libstorage.a
/home/iulius/work/inn/trunk/lib/.libs/libinn.a -ldb -lz
Still an open bug (from 2008):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508658
Hopefully a working patch is given.
=> Just uncommenting the new_libs assignment line, and remove the rest
of the for loop. Well, we are in the case of the "very few problems in
practice"!
In support/ltmain.sh:
for deplib in $tmp_libs; do
# FIXME: Pedantically, this is the right thing to do, so
# that some nasty dependency loop isn't accidentally
# broken:
#new_libs="$deplib $new_libs"
# Pragmatically, this seems to cause very few problems in
# practice:
It fixes the build with static libraries (which has not been working
since a few releases).
--
Julien ?LIE
??? Nous parlerons quand l'interpr?te dormira. [Bong?!]
? Il dort. On peut parler.?? (Ast?rix)
------------------------------
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 6
*******************************************
