https://code.th-h.de/?p=usenet/INN.git;a=tree;f=filter
I think I've succeffuly rewrited those hooks to be RFC 8315 compliant.
If that works and looks good, tell me how to (and where) submit these.
As Thomas reads this newsgroup, just provide a link to your patch.
Thanks for it!
Julien ÉLIE wrote:
When this feature will be natively integrated into INN, it will be even easier.
Theres is the libcanlock that could be used.
Not avaialable yet on FreeBSD ports, but available on Linux Debian
based : https://micha.freeshell.org/libcanlock/
Unfortunatly the v3 doesn't works yet with slrn (on client side).
libcanlock V3 can be configured to emulate the V2 API (with the option "--enable-legacy-api", which is used by default). This is sufficient
for slrn, but the V2 API has no support for SHA2.
There are patches for slrn to use the V3 API: <https://micha.freeshell.org/libcanlock/#patches>
The hash algorithm can then be configured via "canlock_algo".
I've put the files on a webpage here:
https://home.gegeweb.org/rfc8315.html
Patch files:
https://home.gegeweb.org/files/filter_nnrpd.pl.patch https://home.gegeweb.org/files/cleanfeed.local.patch
And also (article in French) on my Gemini capsule: gemini://home.gegeweb.org/rfc8315-inn.gmi
I use these patch on my two servers.
Works fine, and tested a posting with slrn an libcanclock (sha-1) from another server and the cancel from mine. Cancel wath accepted for the
sha-1 lock/key added on client side. Not tested with a MD5 key/lock,
Michael Bäuerle écrivait sur news.software.nntp:
libcanlock V3 can be configured to emulate the V2 API (with the option "--enable-legacy-api", which is used by default). This is sufficient
for slrn, but the V2 API has no support for SHA2.
There are patches for slrn to use the V3 API: <https://micha.freeshell.org/libcanlock/#patches>
The hash algorithm can then be configured via "canlock_algo".
Thanks for the information.
I would test on MacOS (Big Sur) but I can't compile slrn.
HEAD from git or latest stable, with or without libcanlock.
I've succefully compiled libcanclock (not yet in Homebrew).
Don't know how to fix that! :(
And I'm not sure if it is an issue from slrn code.
(Darwin Kernel Version 20.3.0: Thu Jan 21 00:07:06 PST 2021; root:xnu-7195.81.3~1/RELEASE_X86_64 x86_64)
slrn/src/misc.c:376:4: error: implicit declaration of function 'VA_COPY'
is invalid in C99 [-Werror,-Wimplicit-function-declaration]
VA_COPY(ap1, ap);
^
1 error generated.
AFAIK the Perl based server implementations do not create MD5 based locks/keys too.
What does the "configure" script prints for this check on your machine?
|
| checking for an implementation of va_copy()... yes
On my machine the configure script writes this into "src/sysconf.h":
|
| /* define if you have va_copy() in stdarg.h */
| #define VA_COPY va_copy
Michael Bäuerle écrivait sur news.software.nntp :
AFAIK the Perl based server implementations do not create MD5 based locks/keys too.
Yes right, I've adapted the code to use sha256 instead of sha1 for the Cancel-Lock/Key as the RFC8315 specification.
But in cleanfeed.local it take care about sha256, sha1 or md5 for the verification.
I've only added the sha256, sha1 and md5 verifications was already in
the original code.
I use libcanlock with slrn on linux (Debian buster) and it use sha1.
Capability to verify SHA512 would be nice to have too.
It is registered with "COMMON" for "Intended Usage": <https://www.iana.org/assignments/netnews-parameters/netnews-parameters.xhtml#cancel-lock-hash-algorithms>
This is the expected behaviour without patches (via the V2 API emulation
of libcanlock).
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 307 |
Nodes: | 16 (2 / 14) |
Uptime: | 67:51:05 |
Calls: | 6,915 |
Files: | 12,379 |
Messages: | 5,431,814 |