Path: ...!weretis.net!feeder8.news.weretis.net!usenet.goja.nl.eu.org!aioe.org!RxWJWPal/atCxkx01yaYMA.user.46.165.242.91.POSTED!not-for-mail From: Franck Newsgroups: fr.comp.usenet.serveurs Subject: Re: usage de cancel-clock Date: Mon, 12 Sep 2022 15:00:34 +0200 Organization: Aioe.org NNTP Server Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: gioia.aioe.org; logging-data="21253"; posting-host="RxWJWPal/atCxkx01yaYMA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Content-Language: fr X-Notice: Filtered by postfilter v. 0.9.2 Bytes: 7151 Lines: 152 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 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 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 elements to those already in the header field body. If multiple elements are appended to the Cancel-Lock header field by a single agent, each 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.