Hi,

To be honest, I was never really that much interested in how cancel locks
work, so forgive me if my questions are naive.

I want to use the newly added cancel-lock feature to inn 2.7.0, but it's
not entirely clear to me from the documentation if my intended
configuration is correct.

From what I understand:

- canlockadmin is used when generating cancels from hand by gencancel

- cancel generated by gencancel should just be posted to the server, by
any user, authenticated or not

- canlockuser is used when authenticated user generates cancels

- authenticated user's name is taken from the "user:" field in "access"
section of readers.conf

- if canlockuser is set and not disabled in readers.conf, and posting is
allowed for users without "user:" field in "access" section of
readers.conf, then they will be able to cancel posts made by other
non-authenticated users (but not those made by authenticated ones)

- if the posting agent doesn't support cancel locks, then it's enough for
it to generate a normal cancel and as long as the authenticated user
matches, the hash will match and the cancel will be honored by other
servers using this feature

- if the posting agent supports cancel locks, then it generates its own
Cancel-Lock header and the user possessing the key can cancel the
article even if he changes the identity or server

- the feature doesn't interfere with cancel locks supported by posting
agents, it just adds more possibilities to generate a honored cancel

- INN servers starting with 2.7.0 will refuse to honor cancels without
correct Cancel-Lock headers (I'm not sure about this)

Is my understanding of this mechanism correct?

Now, from theory to practice.

- I set canlockadmin (during testing I kept canlockuser empty)

- I posted a message to my local group (kept in timehash, if that matters)

- I generated two cancels with gencancel

- I altered one of them so the hashes won't match

- I posted the altered one

- I posted the unaltered one

I expected to have the post available after posting the altered cancel,
but gone after posting the unaltered cancel. But the post is still on the group. Why didn't it work?

I also posted the unauthenticated cancel (without Cancel-Lock header), but
it didn't change anything. The article is still there.

All three cancels landed properly in control.cancel group.

I also expected to have something logged about incorrect cancel hash, but
I can't find anything. Should there be some log line about it?

Also, can I control if my server accepts cancels or not (even better, by matching the pattern)? It would be best if there were three settings:
never accept, always accept (even unauthenticated), or accept only if cancel-lock matches.

Thank you!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Adam W. <gof-cut-this-news@cut-this-chmurka.net.invalid> wrote:

- INN servers starting with 2.7.0 will refuse to honor cancels without
correct Cancel-Lock headers (I'm not sure about this)

Cancel-Key, I meant.

Also, will they honor cancels without Cancel-Key if the cancelled post
doesn't have a Cancel-Lock?

Adding this made me wonder how it fits into the superseding (Supersedes) mechanism...

I also posted the unauthenticated cancel (without Cancel-Lock header), but

Without Cancel-Key header, I meant.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Adam,

Also, will they honor cancels without Cancel-Key if the cancelled post doesn't have a Cancel-Lock?

It depends on the setting of the "docancels" parameter in inn.conf.

Adding this made me wonder how it fits into the superseding (Supersedes) mechanism...

It also fits in; a Cancel-Key hash is expected along with the superseding.

--
Julien ÉLIE

« La grandeur d'un métier, c'est peut-être avant tout d'unir les
hommes. » (Saint-Exupéry)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Adam,

- authenticated user's name is taken from the "user:" field in "access"
section of readers.conf

The authenticated user's name is the identity assigned by the matching
auth group. This identity matches the "users" field pattern in access
group.

- INN servers starting with 2.7.0 will refuse to honor cancels without
correct Cancel-Lock headers (I'm not sure about this)

Yes, because it is the default value of "docancels" in inn.conf. It's
the safest configuration.

Now, from theory to practice.

- I set canlockadmin (during testing I kept canlockuser empty)

- I posted a message to my local group (kept in timehash, if that matters)

- I generated two cancels with gencancel

- I altered one of them so the hashes won't match

- I posted the altered one

- I posted the unaltered one

I expected to have the post available after posting the altered cancel,
but gone after posting the unaltered cancel. But the post is still on the group. Why didn't it work?

I don't know.

I also expected to have something logged about incorrect cancel hash, but
I can't find anything. Should there be some log line about it?

This mismatch is not logged.

Also, can I control if my server accepts cancels or not (even better, by matching the pattern)? It would be best if there were three settings:
never accept, always accept (even unauthenticated), or accept only if cancel-lock matches.

It is the "docancels" parameter in inn.conf.

--
Julien ÉLIE

« Ira furor breuis est. » (Horace)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)