Path: ...!weretis.net!feeder8.news.weretis.net!news.mixmin.net!aioe.org!4+IvhaFtrx9x1kZ3dfwH0w.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 09:44:01 +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="57805"; posting-host="4+IvhaFtrx9x1kZ3dfwH0w.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: 3541 Lines: 54 Le 11/09/2022 à 09:15, M.V. a écrit : > Un seul CL veut dire, dans ma bouche, qu'il n'y a qu'un seul CL dans > l'en-tête. > S'il y a d'autres CL invisibles, je n'en parle pas car ils n'intéressent > pas l'utilisateur lambda. Je pense que c'est toi qui ne lis pas bien ce que j'écris et ton assurance te fait écrire des trucs hallucinants. Un CL invisible? Pow, pow, pow! Je sais pas où tu vas chercher ça mais cela n'existe pas. Vite, une référence à lire, je suis preneur!!! Soit le CL est apposé dans l'entête Cancel-Lock, soit il ne l'est pas. Point barre. --- Quand tu postes avec un client qui SAIT GENERER les CL/CK, il va apposer SEUL (comme un grand) un CL utilisateur à l'article (pour pouvoir l'annuler si besoin). Arrivé sur le serveur, ce dernier n'ajoutera pas de CL utilisateur (si ton client l'a fait) ou en ajoutera un (si ton client ne l'a pas fait) et il ajoutera en plus un CL administrateur à ton article (pour que ce dernier puisse éventuellement annuler l'article s'il ne respecte pas une règle). Donc, il y aura UNE SEULE ENTETE "Cancel-Lock" (C'est d'ailleurs une obligation fixée par la RFC 8315), qui contiendra PLUSIEURS CL (Utilisateur et administrateur). Je t'ai également expliqué que les anciens serveurs ne savent hasher en SHA256, raison pour laquelle les serveurs récents ajoutent deux CL (un en SHA1 et l'autre en SHA256) pour chaque entrée (utilisateur et administrateur). Pourquoi? Parce que SHA256 est ce qui DOIT être utilisé depuis la sortie de la RFC 8315 et que SHA1 ÉTAIT majoritairement utilisé avant sa sortie. Pour que les anciens serveurs puissent annuler les articles, SHA1 est ajouté en complément de SHA256. Et, pour bien finir de te perdre (bien que cela ne soit visiblement pas utile), un serveur peut ajouter bien plus de CL que ça, notamment s'il dispose de plusieurs secrets, administrateur ou utilisateur. C'est très utile pour gérer une phase de transition lorsque l'administrateur décide de changer de secrets (Il génèrera donc un CL avec l'ancien secret et un autre avec le nouveau). > J'arrête-là : c'est trop pénible. C'est vraiment dommage car je dois t'avouer que tu as fait ma journée avec ton CL invisible :-)