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: Odd typing (Julien ?LIE)
2. Discussion about Cancel-Lock support (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Sun, 8 Nov 2020 10:10:58 +0100
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: Odd typing
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Bo,
> Why does the overview interface use int rather than ARTNUM
> for article number and count parameters of some methods
> (groupstats, opensearch, expiregroup)?
I bet the answer is just for historical reasons, code was just initially
written with int instead of ARTNUM.
From time to time, improvements are done. For instance:
https://inn.eyrie.org/trac/changeset/7540
"Article numbers should be stored in variables of type ARTNUM rather
than ints. Article numbers are unsigned, so print them appropriately.
Work around the broken overview API for right now."
At some point, INN should also handle 64-bit article numbers.
Supporting that requires a bit of work...
--
Julien ?LIE
??Ce vieux forban d'Asthmatix, il ne manquait pas d'air?!?? (Ast?rix)
------------------------------
Message: 2
Date: Sun, 8 Nov 2020 12:29:14 +0100
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all,
Now that Cancel-Lock has been standardized in RFC 8315, maybe it is a
good time to integrate its support in INN. At last!
We already have an old ticket about that, with patches against INN 2.3.5
(that need being rewritten):
https://inn.eyrie.org/trac/ticket/33
I've just had a deeper look.
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?
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.
- 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?
or just ship and build with INN the few files of libcanlock (under
MIT-like and BSD-3-clause for SHA algorithms)
=> different APIs of libcanlock are in the wide (API v3 is the latest
one and certainly the preferred to support; see later for possible
legacy APIs)
- 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
- 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)?
Other things?
--
Julien ?LIE
??Sol lucet omnibus.??
------------------------------
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 2
*******************************************
