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: QIO_BUFFERSIZE (Bo Lindbergh)
2. Re: QIO_BUFFERSIZE (Russ Allbery)
3. Re: Hardening flags (Julien ?LIE)
4. Re: Hardening flags (Russ Allbery)
5. Re: QIO_BUFFERSIZE (Julien ?LIE)
6. Re: Hardening flags (Julien ?LIE)
7. Re: Hardening flags (Russ Allbery)
8. Re: Discussion about Cancel-Lock support (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Mon, 7 Dec 2020 13:04:52 +0100
From: Bo Lindbergh <[email protected]>
To: [email protected]
Subject: Re: QIO_BUFFERSIZE
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Quoth Russ Allbery <[email protected]>:
>
> This is supposed to only be a fallback, and the actual buffer size is
> determined based on st_blksize of the fstat data structure for a file
> (which, at least on the ext3 system I'm currently looking at, is 4KB and
> thus even smaller). That means that changing this require more than just
> changing that #define, so I'm moderately surprised that changing the
> #define did anything on your system. That implies to me that either
> st_blksize isn't working on your system or something else weird is going
> on. What operating system and underlying file system is this?
It works because the buffer_size function never returns a value smaller than
QIO_BUFFERSIZE.
On both Linux and macOS I'm getting st_blksize == 4096 everywhere
except for a 56 GB exFAT partition on an external disk, where it's 131072.
It seems filesystem code writers have repurposed st_blksize to mean
the allocation block size.
/Bo Lindbergh
------------------------------
Message: 2
Date: Mon, 07 Dec 2020 09:44:09 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: QIO_BUFFERSIZE
Message-ID: <[email protected]>
Content-Type: text/plain
Bo Lindbergh <[email protected]> writes:
> Quoth Russ Allbery <[email protected]>:
>> This is supposed to only be a fallback, and the actual buffer size is
>> determined based on st_blksize of the fstat data structure for a file
>> (which, at least on the ext3 system I'm currently looking at, is 4KB
>> and thus even smaller). That means that changing this require more
>> than just changing that #define, so I'm moderately surprised that
>> changing the #define did anything on your system. That implies to me
>> that either st_blksize isn't working on your system or something else
>> weird is going on. What operating system and underlying file system is
>> this?
> It works because the buffer_size function never returns a value smaller
> than QIO_BUFFERSIZE.
Oh, I see now. Wow, I didn't write that code in a very straightforward
way and didn't do myself any favors with the comment.
> On both Linux and macOS I'm getting st_blksize == 4096 everywhere except
> for a 56 GB exFAT partition on an external disk, where it's 131072. It
> seems filesystem code writers have repurposed st_blksize to mean the
> allocation block size.
Yeah, I think the probe that code is doing is mostly meaningless and
there's no downside to always using a predictable, larger buffer.
--
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, 7 Dec 2020 20:30:51 +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,
>> With libperl.a built without -fPIC, linking with -pie fails for innd.
>> Should we care for that?
>
> My initial feeling is no mostly because I don't expect many users of INN
> to be building their own Perl or Python (generally they come with whatever
> distribution they're using), and if they do build them, I think most
> people will build them shared rather than static
Noted, thanks for your answer.
> (although I admit I don't know what the default is)
As for Perl, default is static.
One needs to run "./Configure -Duseshrplib" so as to have a shared library.
Quoting INSTALL:
"""
On systems that support dynamic loading, it may be possible to replace
libperl.a with a shared libperl.so.
[...]
The disadvantages are that there may be a significant performance
penalty associated with the shared libperl.so, and that the overall
mechanism is still rather fragile with respect to different versions and
upgrades. In terms of performance, on my test system (Solaris 2.5_x86)
the perl test suite took roughly 15% longer to run with the shared
libperl.so. Your system and typical applications may well give quite
different results.
"""
That's probably why the default is still to generate a static library,
unless explicitly asked otherwise.
> If it turns out that this is more common than we thought, we can always
> do something about that later.
Sure!
--
Julien ?LIE
??Il ne faut jamais gifler un sourd?: il perd la moiti? du plaisir. Il
sent la gifle mais il ne l'entend pas.?? (Georges Courteline)
------------------------------
Message: 4
Date: Mon, 07 Dec 2020 11:34:16 -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:
>> My initial feeling is no mostly because I don't expect many users of
>> INN to be building their own Perl or Python (generally they come with
>> whatever distribution they're using), and if they do build them, I
>> think most people will build them shared rather than static
> Noted, thanks for your answer.
>> (although I admit I don't know what the default is)
> As for Perl, default is static.
> One needs to run "./Configure -Duseshrplib" so as to have a shared library.
Oh, huh. Okay, yes, that does push me a bit more towards saying it
wouldn't be a horrible idea to document this somewhere (although I still
suspect most people aren't building Perl themselves).
--
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, 7 Dec 2020 20:43:36 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: QIO_BUFFERSIZE
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
>> It works because the buffer_size function never returns a value smaller
>> than QIO_BUFFERSIZE.
>
> Oh, I see now. Wow, I didn't write that code in a very straightforward
> way and didn't do myself any favors with the comment.
Suprising of you :-)
Oh, well, your initial commit in year 2000 had the right comment:
https://inn.eyrie.org/trac/changeset/3655/trunk/lib/qio.c
You can be relieved! :-)
The intent of a subsequent commit in 2004 was also to ensure that
buffer_size was a multiple of st_blksize.
>> On both Linux and macOS I'm getting st_blksize == 4096 everywhere except
>> for a 56 GB exFAT partition on an external disk, where it's 131072.
Still works: 131 072 = 4*(the new QIO_BUFFERSIZE value of 32*1024)
--
Julien ?LIE
??Il ne faut jamais gifler un sourd?: il perd la moiti? du plaisir. Il
sent la gifle mais il ne l'entend pas.?? (Georges Courteline)
------------------------------
Message: 6
Date: Mon, 7 Dec 2020 20:49:24 +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,
>> As for Perl, default is static.
>> One needs to run "./Configure -Duseshrplib" so as to have a shared library.
>
> Oh, huh. Okay, yes, that does push me a bit more towards saying it
> wouldn't be a horrible idea to document this somewhere (although I still
> suspect most people aren't building Perl themselves).
I suggest to add a sentence in INSTALL, where we speak of configure
options like --with-perl.
--
Julien ?LIE
??Il ne faut jamais gifler un sourd?: il perd la moiti? du plaisir. Il
sent la gifle mais il ne l'entend pas.?? (Georges Courteline)
------------------------------
Message: 7
Date: Mon, 07 Dec 2020 12:06:37 -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:
> I suggest to add a sentence in INSTALL, where we speak of configure
> options like --with-perl.
Sounds great to me.
--
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: 8
Date: Mon, 7 Dec 2020 21:07:15 +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,
>>> 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.
>
> On the generate side, I think it only matters what other servers support,
> and I have no feel for what server support is out there and thus whether
> we need a transition period for that part.
When Michael wrote RFC 8315 (Cancel-Key), he did the analysis and found
out that not all servers know other algorithms than sha1.
The previous draft (from the USEFOR WG), written two decades ago, only
defined sha1; so implementations only used that.
Implementations of earlier draft versions of this specification
defined a different value for <scheme> than this version. The
following value for <scheme> is now deprecated and SHOULD NOT be
generated anymore. Serving agents SHOULD still accept it for a
transition period as long as the corresponding hash function is not
considered unsafe (see Section 7 for details) or already marked as
OBSOLETE in the "Netnews Cancel-Lock Hash Algorithms" registry
(Section 8.3).
obs-scheme = "sha1"
It is important for backward compatibility that the deprecated value
for <scheme> is not phased out too early. Security and compatibility
concerns should be carefully weighed before choosing to remove
<obs-scheme> from existing implementations (or not implementing it in
new ones).
=> in the IANA registry related to Cancel-Lock, sha1 is of LIMITED USE
(still not OBSOLETE)
=> SHA-1 is still not deprecated (unless for signature hashes in TLS 1.2
through draft-ietf-tls-md5-sha1-deprecate-04 in the process of becoming
a proposed standard)
> (What we generate won't matter
> for Gnus, since it won't have the secret keys for those hashes anyway.)
Yes, exactly! A posting agent does not verify these keys.
--
Julien ?LIE
??La femme est beaucoup plus port?e que l'homme aux actes imprudents et
irr?fl?chis.?? (D?mocrite)
------------------------------
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 5
*******************************************
