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 (Russ Allbery)
3. Re: Build failure on macOS 10.15 (Julien ?LIE)
4. Re: Build failure on macOS 10.15 (Russ Allbery)
5. Re: Build failure on macOS 10.15 (Julien ?LIE)
6. Re: Discussion about Cancel-Lock support (Julien ?LIE)
7. Re: Static builds & snapshots (Julien ?LIE)
8. Re: Static builds & snapshots (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Nov 2020 18:58:52 +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 Russ,
>> Suggested fix:
>
> I've applied the relevant part of this to rra-c-util as well, with a minor
> tweak to the comment and to the configure output (because so far as I can
> tell Autoconf doesn't promise to always set $LD).
Oh, thanks!
I'm wondering whether RRA_PROG_LD_FLAG should not take 2 arguments into
account ($1 for CFLAGS, and $2 for LDFLAGS).
Use case would be to improve the current chek for PIE to:
RRA_PROG_LD_FLAG([-fPIE], [-pie],
[CFLAGS="${CFLAGS} -fPIE"
LDFLAGS="${LDFLAGS} -pie"], [])
instead of only using RRA_PROG_CC_FLAG, checking that the compiler
supports -fPIE, and assuming (without testing it) that the linker will
accept -pie.
--
Julien ?LIE
??Pourquoi les programmeurs confondent-ils Halloween et No?l??
Parce que OCT 31 == DEC 25.??
------------------------------
Message: 2
Date: Mon, 30 Nov 2020 10:36:04 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Build failure on macOS 10.15
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Oh, thanks!
> I'm wondering whether RRA_PROG_LD_FLAG should not take 2 arguments into
> account ($1 for CFLAGS, and $2 for LDFLAGS).
> Use case would be to improve the current chek for PIE to:
> RRA_PROG_LD_FLAG([-fPIE], [-pie],
> [CFLAGS="${CFLAGS} -fPIE"
> LDFLAGS="${LDFLAGS} -pie"], [])
> instead of only using RRA_PROG_CC_FLAG, checking that the compiler
> supports -fPIE, and assuming (without testing it) that the linker will
> accept -pie.
Don't you want something like this?
RRA_PROG_CC_FLAG([-fPIE],
[CFLAGS="$CFLAGS -fPIE"
RRA_PROG_LD_FLAG([-pie], [LDFLAGS="$LDFLAGS -pie"])])
I could support checking both at the same time, but I think the above is
equivalent for all systems I'm aware of and makes it fairly clear what's
going on.
--
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: Mon, 30 Nov 2020 20:00:58 +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 Russ,
>> RRA_PROG_LD_FLAG([-fPIE], [-pie],
>> [CFLAGS="${CFLAGS} -fPIE"
>> LDFLAGS="${LDFLAGS} -pie"], [])
>
> Don't you want something like this?
>
> RRA_PROG_CC_FLAG([-fPIE],
> [CFLAGS="$CFLAGS -fPIE"
> RRA_PROG_LD_FLAG([-pie], [LDFLAGS="$LDFLAGS -pie"])])
>
> I could support checking both at the same time, but I think the above is
> equivalent for all systems I'm aware of and makes it fairly clear what's
> going on.
Couldn't we have linkers that do not know how to link PIE executables?
The compiler would support PIE but the linker would not, so we would not
want to have CFLAGS with -fPIE if RRA_PROG_LD_FLAG([-pie]) failed.
That's why I thought setting both CFLAGS and LDFLAGS at the same time
would be better to handle that case (which maybe does not exist in
practice).
OK otherwise with your suggestion.
--
Julien ?LIE
??Pour se marier, il faut un t?moin comme pour un accident ou un duel.??
(Sacha Guitry)
------------------------------
Message: 4
Date: Mon, 30 Nov 2020 11:17:00 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Build failure on macOS 10.15
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
>> Don't you want something like this?
>> RRA_PROG_CC_FLAG([-fPIE],
>> [CFLAGS="$CFLAGS -fPIE"
>> RRA_PROG_LD_FLAG([-pie], [LDFLAGS="$LDFLAGS -pie"])])
>> I could support checking both at the same time, but I think the above
>> is equivalent for all systems I'm aware of and makes it fairly clear
>> what's going on.
> Couldn't we have linkers that do not know how to link PIE executables?
> The compiler would support PIE but the linker would not, so we would not
> want to have CFLAGS with -fPIE if RRA_PROG_LD_FLAG([-pie]) failed.
> That's why I thought setting both CFLAGS and LDFLAGS at the same time
> would be better to handle that case (which maybe does not exist in
> practice).
Oh, I see, and it's otherwise a bit awkward because you have to write:
RRA_PROG_CC_FLAG([-fPIE],
[save_CFLAGS=$CFLAGS
CFLAGS="$CFLAGS -fPIE"
RRA_PROG_LD_FLAG([-pie],
[LDFLAGS="$LDFLAGS -pie"],
[CFLAGS=$save_CFLAGS])])
That said, I haven't seen that combination, and I also don't think it's
harmful to have the compiler generate PIE code even if the linker doesn't
create PIE executables. (There's a minor performance penalty, but I'm not
sure it's worth worrying about for this edge case.)
The main reason why I'm reluctant is that I think it makes the macro a bit
hard to understand when it takes both compiler and linker flags. Hm, if
we go that route, I think I'd want to make a third macro called
RRA_PROG_CC_LD_FLAGS to make it explicit and separate from the macros to
probe compiler and linker flags independently.
--
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: Mon, 30 Nov 2020 21:44:23 +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 Russ,
>> Couldn't we have linkers that do not know how to link PIE executables?
>> The compiler would support PIE but the linker would not, so we would not
>> want to have CFLAGS with -fPIE if RRA_PROG_LD_FLAG([-pie]) failed.
>> That's why I thought setting both CFLAGS and LDFLAGS at the same time
>> would be better to handle that case (which maybe does not exist in
>> practice).
>
> Oh, I see, and it's otherwise a bit awkward because you have to write:
>
> RRA_PROG_CC_FLAG([-fPIE],
> [save_CFLAGS=$CFLAGS
> CFLAGS="$CFLAGS -fPIE"
> RRA_PROG_LD_FLAG([-pie],
> [LDFLAGS="$LDFLAGS -pie"],
> [CFLAGS=$save_CFLAGS])])
>
> That said, I haven't seen that combination, and I also don't think it's
> harmful to have the compiler generate PIE code even if the linker doesn't
> create PIE executables. (There's a minor performance penalty, but I'm not
> sure it's worth worrying about for this edge case.)
All right, adopted then!
Thanks,
--
Julien ?LIE
??Avec toutes les salet?s que les gens jettent dans le fleuve, il n'y a
plus de poissons?! Tout ce que je p?che depuis ce matin sont des
amphores vides?!?? (Ast?rix)
------------------------------
Message: 6
Date: Mon, 30 Nov 2020 21:51:08 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
>> 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).
Noted.
I'll have a look next year. It will permit to have time to properly
implement and test it, before eventually integrating it into a stable
release.
Thanks for all your comments.
>> - 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.
For interoperability reasons, it seems that we'll have to handle a
transition period, and generate two hashes for each message (SHA-1 and
SHA-256). And support all of the non-MD5 algorithms to verify cancel keys.
--
Julien ?LIE
??Avec toutes les salet?s que les gens jettent dans le fleuve, il n'y a
plus de poissons?! Tout ce que je p?che depuis ce matin sont des
amphores vides?!?? (Ast?rix)
------------------------------
Message: 7
Date: Mon, 30 Nov 2020 22:51:14 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Static builds & snapshots
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
>> Incidentally, would it be possible to add a few configure flags to INN
>> during the dailing generation of snapshots?
>
> 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.
OK, I've just committed to CURRENT the following variations:
./configure --with-perl --with-python
./configure --disable-shared
./configure --enable-tagged-hash
./configure --enable-keywords --without-bdb --without-krb5 \
--without-openssl --without-sasl --without-zlib
./configure --enable-largefiles
(Perl and Python are the only optional packages that need being
explicitly passed to configure so as to be used, even though libraries
are installed on the system.)
Let's see if tomorrow's snapshot generation will work fine.
--
Julien ?LIE
??Avec toutes les salet?s que les gens jettent dans le fleuve, il n'y a
plus de poissons?! Tout ce que je p?che depuis ce matin sont des
amphores vides?!?? (Ast?rix)
------------------------------
Message: 8
Date: Tue, 1 Dec 2020 12:22:44 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Static builds & snapshots
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
>> 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.
>
> OK, I've just committed to CURRENT the following variations:
>
> ??? ./configure --with-perl --with-python
> ??? ./configure --disable-shared
> ??? ./configure --enable-tagged-hash
> ??? ./configure --enable-keywords --without-bdb --without-krb5 \
> ??????? --without-openssl --without-sasl --without-zlib
> ??? ./configure --enable-largefiles
>
> (Perl and Python are the only optional packages that need being
> explicitly passed to configure so as to be used, even though libraries
> are installed on the system.)
>
> Let's see if tomorrow's snapshot generation will work fine.
Seems like it worked fine, though generation takes 25mn more.
inn-CURRENT-20201129.tar.gz 2020-11-29 02:08 2.5M
inn-CURRENT-20201130.tar.gz 2020-11-30 02:09 2.5M
inn-CURRENT-20201201.tar.gz 2020-12-01 02:35 2.5M
--
Julien ?LIE
??C'est la goutte d'eau qui fait d?border le vase et qui met le feu aux
poudres.??
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 126, Issue 1
*******************************************
