Re: usage de cancel-clock

Bonjour l'ami,

l'en-tête de ton message et, qui plus est, en sha256 !

Ce qui est totalement conforme à la RFC 8315 puisque SHA256 est ce qui DOIT être utilisé (MANDATORY = OBLIGATOIRE).
RFC 8315 : Netnews Cancel-Lock hash algorithm name: sha256
Intended usage: COMMON
Note: This algorithm is mandatory to implement
Mais comme les auteurs de serveurs prennent aussi en considération l'intégralité des RFC (qu'ils ne font pas que survoler), ils savent qu'un serveur DEVRAIT aussi ajouter un SHA1 pour permettre aux anciens serveurs d'annuler les articles, le temps qu'ils soient capables de prendre en charge SHA256.
Cela s'appelle la transition, mon ami.
RFC 8315 : Netnews Cancel-Lock hash algorithm name: sha1
Intended usage: LIMITED USE
Note: This algorithm is intended for backward compatibility
Donc, l'article dont tu parles et qui ne possède qu'un seul CL en SHA256, il sera bien supprimé des serveurs récents (qui gèrent SHA256) mais ne pourra pas être supprimé par ceux qui ne gèrent que SHA1.
D'où l'utilité pour les serveurs de mettre deux CL, un en SHA1 et un en SHA256 comme ça, peut importe le serveur, l'article sera bien annulé.

Son monde va s'écrouler ! ;-)

S'écouler? Bah non, toujours pas :-)
Je te renvoie en arrière pour relire ce que j'ai écris et dans quel cas il peut y avoir qu'un seul CL dans un article. Et quand j'écris "généralement", cela sous entend DE FAIT que le serveur SOIT configuré pour le faire sinon bien évidement il ne le fait pas.
Il y a une nuance entre DEVRAIT et DOIT.
Donc il peut y avoir 1 seul CL dans un article si :
1ère possibilité : Le client sait gérer (et à donc ajouté 1 CL utilisateur) ET le serveur n'est pas configuré pour ajouter un CL administrateur ou qu'il ne gère tout simplement pas CK/CL.
Dans ce cas, le seul CL correspond à celui apposé par le client.
Pourquoi? Parce que dans le cas où un client qui SAIT ajouter les CL à ses articles, le serveur n'a AUCUN INTÉRÊT à en ajouter un (c'est déjà fait). Ce qui est plus important pour l'administrateur c'est d'ajouter un CL administrateur pour pouvoir annuler ce même article puisqu'il ne connait pas le secret utilisé par le client pour poser SON CL initial!
Ainsi, le client peut annuler son article (en générant un CK avec SON secret) et l'administrateur aussi (en générant un CK avec SON secret - gencancel dans INN). Les deux possibilités "légales" de suppression sont donc remplies (le client car l'article lui appartient et l'administrateur car l'article a été posté sur SON serveur et qu'il estime qu'il enfreint une règle).
2° possibilité : Le client ne sait pas générer les CL/CK et le serveur a ajouté un CL (utilisateur ou administrateur) car, soit il n'en a qu'un de configuré, soit il ne les différencie pas (ce qui n'est pas conseillé par la RFC 8315).
Dans ce cas, le seul CL est un CL du serveur.
---
Je crois que l'incompréhension vient du fait que vous mélangez ce qu'un client PEUT faire (ou pas) et ce qu'un serveur DEVRAIT faire (ou pas).
Et tout part des secrets du serveur:
- Le secret utilisateur permet au serveur d'agir pour le compte des clients qui ne prennent pas en charge CK/CL. S'il y en a pas, le serveur   n’offrira pas cette possibilité.
   Dans ce cas, il s'agit de cette partie de la RFC 8315:
   An injecting agent wants to act as a representative for a posting
   agent that has no support for the authentication system described
   in this document.
- Le secret administrateur offre la possibilité à l'administrateur de supprimer tous les articles qui sont postés sur son serveur.
   Dans ce cas, il s'agit de cette partie de la RFC 8315:
   --------
   A news administrator wants the ability to cancel articles that
   were injected by its system (because, for example, they violate
   its abuse policy).
Et pour appuyer mon propos, je te renvoie à la RFC 8315, partie 3.1 et 3.2, qui expliquent comment ajouter un CL dans l'entête ou comment la compléter par d'autres CL :
MAY = DEVRAIT
MUST = DOIT
Posting agent = client (reader)
Injecting agent = serveur
RFC 8315:
--------
3.1
A Cancel-Lock header field MAY be added to a proto-article by the
poster or posting agent and will include one or more <c-lock>
elements.
If the poster or posting agent doesn't add a Cancel-Lock header field
to a proto-article, then an injecting agent (or moderator) MAY add
one, including one or more <c-lock> elements.
If an injecting agent (or moderator) wants to act as a representative
for a posting agent without support for the authentication system
described in this document, then it MUST be able to positively
authenticate the poster and MUST be able to automatically add a
working Cancel-Key header field for all proto-articles with
cancelling or superseding attempts from that poster.
Other agents MUST NOT add this header field to articles or
proto-articles that they process.
3.2 Extending the Cancel-Lock Header Field of a Proto-Article
If a Cancel-Lock header field has already been added to a
proto-article, then any agent further processing the proto-article up
to the injecting agent (inclusively) MAY append additional <c-lock>
elements to those already in the header field body.
If multiple <c-lock> elements are appended to the Cancel-Lock header
field by a single agent, each <c-lock> element MUST use a unique
key "K" to improve security.
If an injecting agent (or moderator) wants to act as a representative
for a posting agent without support for the authentication system
described in this document, then the same requirements apply as those
mentioned in Section 3.1.
Once an article is injected, then this header field MUST NOT be
altered.  In particular, relaying agents beyond the injecting agent
MUST NOT alter it.