usage de cancel-clock

[jdd]

Bonjour,

Je n'ai sans doute pas cherché assez, mais je n'ai pas trouvé comment un
simple utilisateur pas forcément doué en informatique peut utiliser
cette procédure :-(

merci
jdd
--
mon serveur dodin.fr.nf

[DV]

jdd a écrit ceci :

> Je n'ai sans doute pas cherché assez, mais je n'ai pas trouvé comment un
> simple utilisateur pas forcément doué en informatique peut utiliser
> cette procédure :-(

L'utilisateur n'a pas à s'en soucier : une fois que c'est mis en place
sur le serveur, c'est complètement transparent pour lui.

--
Denis

Liste de serveurs offrant un accès gratuit à la hiérarchie fr.* :
<http://usenet-fr.yakakwatik.org>

[Marc SCHAEFER]

jdd <j...@dodin.org> wrote:
> Je n'ai sans doute pas cherché assez, mais je n'ai pas trouvé comment un
> simple utilisateur pas forcément doué en informatique peut utiliser
> cette procédure :-(

Il faut déjà comprendre les fondamentaux. Et il y a un bug en ce qui te
concerne vu ton choix de non authentification (voir (*) ci-dessous).

filter_nnrpd.pl sert à l'injection d'articles par tes utilisateurs,
et tu peux y MODIFIER certains entêtes.

filter_innd.pl (qui appelle cleanfeed.local) est appelé pour les
articles transitant par ton serveur, et tu ne peux rien modifier.

Rappelons que pour Cancel-Lock, il peut y avoir N valeurs (p.ex.
une Cancel-Lock utilisateur et une Cancel-Lock serveur). Il suffit
que le Cancel-Key corresponde à un des Cancel-Lock pour que l'article
soit supprimé. Cela permet par exemple au newsmaster d'émettre des
cancels authentifiés.

Pour Cancel-Lock, il y a donc deux fonctionnalités séparées:

1) appliquer les cancels uniquement lorsque le Cancel-Key dévoilé
correspond au Cancel-Lock de l'article original

-> ça c'est dans filter_innd.pl (cleanfeed.local), et c'est
assez facile à faire.

2) éventuellement et en option, protéger tes utilisateurs locaux
qui n'auraient pas de client NNTP/NNRP capable d'ajouter le
Cancel-Lock, et aussi te donner la possibilité de supprimer
globalement en cas de besoin: ajouter un Cancel-Lock serveur.

Ici, il y a ajout de Cancel-Lock par filter_nnrpd.pl, avec
un secret global au serveur (les clés étant générées par
hashage).

Mais il y a un élément à ne pas oublier: si l'utilisateur ne gère pas
les Cancel-Lock lui-même, quand un utilisateur *authentifié localement*
émet un Cancel, il faut y ajouter la Cancel-Key correspondante du
serveur! Sinon un utilisateur local NE PEUT PLUS supprimer ses
propres messages!

Et sur ce dernier point, tu as un gros souci, car tu n'authentifies
pas les utilisateurs! (*)

Une solution serait alors de calculer la Cancel-Key de chaque article
non pas p.ex. avec hash(user, msgid) mais avec hash(adresse IP, msgid).
Ou faire des vérifications d'authentification complexes locales avant
d'émettre la Cancel-Key. Ce qui revient un peu au même que de définir
quels sont ces identifiants pour le hachage.

[jdd]

Le 09/09/2022 à 10:11, DV a écrit :
> jdd a écrit ceci :
>
>> Je n'ai sans doute pas cherché assez, mais je n'ai pas trouvé comment un
>> simple utilisateur pas forcément doué en informatique peut utiliser
>> cette procédure :-(
>
> L'utilisateur n'a pas à s'en soucier : une fois que c'est mis en place
> sur le serveur, c'est complètement transparent pour lui.
>

ce n'est pas ce que j'ai compris :-), si c'est une façon d'authentifier
un cancel, il faut bien que l'utilisateur mette une clé dans ses
messages, non?

[jdd]

Le 09/09/2022 à 10:11, Marc SCHAEFER a écrit :

> Il faut déjà comprendre les fondamentaux. Et il y a un bug en ce qui te
> concerne vu ton choix de non authentification (voir (*) ci-dessous).

je ne vois nulle part dans la RFC que ce n'est valable que pour les
utilisateurs authentifiés, auquel cas je n'en vois pas trop l'intérêt
(l'authentification usuellement utilisée étant très faible)

> soit supprimé. Cela permet par exemple au newsmaster d'émettre des
> cancels authentifiés.

donc d'effacer les articles sur son propre serveur (j'ai cru comprendre
qu'un cancel n'est jamais propagé)

> 2) éventuellement et en option, protéger tes utilisateurs locaux
> qui n'auraient pas de client NNTP/NNRP capable d'ajouter le
> Cancel-Lock,

là on arrive réellement à ma question.

comment fait l'utilisateur pour ajouter un cancel-lock? faut-il un
client qui ai une fonction spéciale pour ça, ou peut-on le faire à la
main une fois pour toute (et pas à chaque post)?

> Une solution serait alors de calculer la Cancel-Key de chaque article
> non pas p.ex. avec hash(user, msgid) mais avec hash(adresse IP, msgid).

voilà qui serait bien, la seule contrainte serait qu'on ne peut émettre
de cancel qu'avec l'ID et l'IP du message d'origine, ce qui est quand
même bénin.

mais le problème reste que seuls les serveurs comprenant le message vont
le mettre en œuvre, non?

[DV]

M.V. a écrit ceci :

>> ce n'est pas ce que j'ai compris :-), si c'est une façon d'authentifier
>> un cancel, il faut bien que l'utilisateur mette une clé dans ses
>> messages, non?
>

> C'est le serveur qui peut se charger de tout.

Voilà. À condition, comme le souligne Marc, que ledit serveur soit en
mesure d'identifier l'utilisateur et donc de générer pour lui le fameux
« secret » nécessaire à la procédure. Sans authentification, ça risque
d'être très compliqué.

[jdd]

Le 09/09/2022 à 10:40, M.V. a écrit :
> Dans le message <tfetfs$ge4$1...@ns507557.dodin.fr.nf>, jdd a écrit le 9
> septembre 2022 à 10 h 28 :

>
>> ce n'est pas ce que j'ai compris :-), si c'est une façon d'authentifier
>> un cancel, il faut bien que l'utilisateur mette une clé dans ses
>> messages, non?
>

> C'est le serveur qui peut se charger de tout.

mais il faut qu'il identifie l'usager, utiliser un cancel-lock avec une
identification forte à partir d'une identification faible de l'usager me
parait curieux. à quoi ça sert? il suffirait- de comparer from et IP des
messages pour accepter le cancel!

qui plus est comment un cancel-lock *serveur* est géré par les autres
serveurs?

le seul intérêt du système est que l'annulation soit propagée à toutes
les copies du message, un simple cancel ne l'est pas.

ca marche comment?

> Regarde dans ce message : tu as 3 cancel-lock
> Les deux premiers proviennent de mon lecteur (et j'ai effectivement
> défini un « secret » dans les préférences du bidule mais je ne l'ai pas
> changé depuis que mon logiciel sait le gérer)

peux-tu préciser de quel logiciel il s'agit et la procédure à suivre? merci

et le 3ème est entièrement
> géré par le serveur que j'utilise.
>
> Sans les deux premiers, je pourrais malgré tout supprimer ou modifier
> mon message depuis le même serveur.

*sur* ce même serveur, oui, et sur les autres?

[jdd]

Le 09/09/2022 à 10:48, DV a écrit :
> M.V. a écrit ceci :
>
>>> ce n'est pas ce que j'ai compris :-), si c'est une façon d'authentifier
>>> un cancel, il faut bien que l'utilisateur mette une clé dans ses
>>> messages, non?
>>
>> C'est le serveur qui peut se charger de tout.
>
> Voilà. À condition, comme le souligne Marc, que ledit serveur soit en
> mesure d'identifier l'utilisateur et donc de générer pour lui le fameux
> « secret » nécessaire à la procédure. Sans authentification, ça risque
> d'être très compliqué.
>

c'est là que ça blesse, le cancel-lock utilise une clé sha, donc une
authentification très forte.

si c'est lié à une authentification comme celle de ponx (je sais, ce
n'est pas usenet) avec login et mdp en trois lettres, à quoi ça sert de
faire une usine à gaz?

je ne juge rien, j'essaie juste de comprendre, dans le but d'expliquer
ça en termes simples

[Marc SCHAEFER]

jdd <j...@dodin.org> wrote:
> c'est là que ça blesse, le cancel-lock utilise une clé sha, donc une
> authentification très forte.

Non, c'est un simple hachage. Toute la beauté du truc est de ne pas
utiliser de système de chiffrement asymétrique (à clé publique), et donc
de ne pas nécessiter de moyen d'authentifier les clés (PKI).

En bref, sur chaque article vient un code, Cancel-Lock, généré comme
hachage(secret, Message-ID). Et celui qui veut l'effacer ou le remplacer
doit prouver sa connaissance du secret en le publiant (Cancel-Key).
Les serveurs vérifient alors que hachage(Cancel-Key, Message-ID) est
le bon!

Là où c'est génial c'est qu'en fait le secret n'est pas statique, mais
peut être généré par secret = hachage(très_secret, Message-ID). Ou par
tout autre moyen qui fait que chaque article a un autre secret, et donc
qu'éventer le secret lors du cancel ou Supersedes: n'a pas d'impact.

Tout ceci est basé sur le fait que les hachage cryptographiques sont
difficilement inversibles.

Maintenant, si tu veux que ton serveur AJOUTE un Cancel-Lock de plus
(soit car l'utilisateur n'en a en fait pas mis, ou pour te donner le
droit de supprimer plus tard!), il faut trouver un moyen de générer
des secrets "par utilisateur" (ce n'est pas strictement obligatoire),
souvent on fait:

secret = hachage(très_secret_du_serveur, utilisateur, Message-ID)

Et donc, quand l'utilisateur-qui-ne-génère-pas-soi-même-les-Cancel-Lock
veut supprimer ou remplacer un article, ton serveur dévoilera ce secret.

Mais pour qu'il le fasse, il faut être sûr que c'est le bon utilisateur.
Pour faire cela, ben on vérifie l'authentification ... ah zut, donc chez
toi, le plus proche est l'adresse IP du posteur, donc du genre:

secret = hachage(très_secret_du_serveur, adresse IP, Message-ID)

Tu peux même te PASSER de vérifier que c'est le bon utilisateur: si
l'adresse IP est différente dans l'article à supprimer/remplacer de
celle de l'article qui supprime/remplace, le secret ne sera alors pas
le bon.

Attention: l'adresse IP, lors du calcul du secret, doit toujours être
celle de l'article courant (soit le message original pour le
Cancel-Lock, soit le message de remplacement/suppression pour le
Cancel-Key).

[Marc SCHAEFER]

M.V. <m...@gmail.com.invalid> wrote:
> À dire vrai, je ne sais pas comment fait un serveur pour calculer
> cancel-key et cancel-lock et je ne suis pas certain que tous les
> serveurs qui savent gérer le couple CK / CL procèdent de la même manière.

J'ai donné l'explication dans un autre article. Tous les serveurs
doivent faire de même pour la génération et la vérif, mais le secret lié
à chaque article, lui, peut être généré comme on veut.

[Gilbert OLIVIER]

le 9 septembre 2022; jdd m'a confié :

> là on arrive réellement à ma question.
>
> comment fait l'utilisateur pour ajouter un cancel-lock? faut-il un
> client qui ai une fonction spéciale pour ça, ou peut-on le faire à la
> main une fois pour toute (et pas à chaque post)?

C'est son application qui fait automatiquement le travail.

Tu as ici comment ça fonctionne dans la doc de MacCafé
<http://mc.yakakwatik.org/documentation/index.html#annexe5>

Et vu du côté utilisateur dans d'autres chapitres.

>
>> Une solution serait alors de calculer la Cancel-Key de chaque article
>> non pas p.ex. avec hash(user, msgid) mais avec hash(adresse IP, msgid).
>
> voilà qui serait bien, la seule contrainte serait qu'on ne peut émettre
> de cancel qu'avec l'ID et l'IP du message d'origine, ce qui est quand
> même bénin.
>
> mais le problème reste que seuls les serveurs comprenant le message vont
> le mettre en œuvre, non?

Soit le serveur gère le couple Cancel-Lock et Cancel-Key et seul celui
pouvant joindre à un message de cancel ou de supersedes le bon
Cancel-Key pourra agir sur le message désigné.

Soit le serveur ne le gère pas et fait comme s'il n'existait pas ;-)
>

--
Gilbert
<https://maccafe-osx.pagesperso-orange.fr>

[jdd]

Le 09/09/2022 à 11:19, Marc SCHAEFER a écrit :
> jdd <j...@dodin.org> wrote:
>> c'est là que ça blesse, le cancel-lock utilise une clé sha, donc une
>> authentification très forte.
>
> Non, c'est un simple hachage. Toute la beauté du truc est de ne pas
> utiliser de système de chiffrement asymétrique (à clé publique), et donc
> de ne pas nécessiter de moyen d'authentifier les clés (PKI).

(j'ai lu le reste, mais il est hors sujet sur ce fil)

ce que je demande ici c'est comment l'utilisateur peut/doit faire

* quand il règle son logiciel pour envoyer le message
* quand il veut envoyer une annulation du message en question.

deux cas mélangés dans les réponses:

# l'utilisateur ne fait rien, c'est automatique. quelle que soit la
méthode utilisée par cancel-lock, il faut 1) savoir si l'utilisateur qui
demande l'annulation est bien celui qui a écrit l'article, sans
intervention dans le post original on ne peut se fier qu'à
l'authentification faite par l'usager. Une comparaison from/IP serait
aussi efficace

# l'utilisateur génère un cancel-lock, là c'est efficace, mais comment
fait-il? Il faut un client capable de créer la paire cancel-lock/cancel-key!

ensuite, il, s'agit bien de cancels, et j'ai posé la question ici il y a
quelques mois, on m'a bien dit que les cancels étaient de la
responsabilité de chaque serveur et ne se propageaient donc pas
autrement que par la publication dans le groupe approprié.

donc pour que ca marche il faut que *chaque serveur* reconnaisse les
clés. il faut donc qu'il soit compatible ck/cl

[jdd]

Le 09/09/2022 à 11:25, M.V. a écrit :

> Le calcul du CK se fait le plus souvent à partir du pseudo utilisé par
> l'auteur du message ciblé, par le MID du message et par un « secret »
> défini par le serveur.

mais cela n'évite pas l'usurpation, qui consiste justement à utiliser le
pseudo d'un autre utilisateur, le mid du message est public et le secret
est évidemment connu du serveur (c'est le sien)

[jdd]

Le 09/09/2022 à 12:09, Gilbert OLIVIER a écrit :
> le 9 septembre 2022; jdd m'a confié :
>
>> là on arrive réellement à ma question.
>>
>> comment fait l'utilisateur pour ajouter un cancel-lock? faut-il un
>> client qui ai une fonction spéciale pour ça, ou peut-on le faire à la
>> main une fois pour toute (et pas à chaque post)?
>
> C'est son application qui fait automatiquement le travail.
>
> Tu as ici comment ça fonctionne dans la doc de MacCafé
> <http://mc.yakakwatik.org/documentation/index.html#annexe5>
>
> Et vu du côté utilisateur dans d'autres chapitres.

d'accord, donc pour Mac café pas de souci, ça roule, merci

> Soit le serveur gère le couple Cancel-Lock et Cancel-Key et seul celui
> pouvant joindre à un message de cancel ou de supersedes le bon
> Cancel-Key pourra agir sur le message désigné.
>
> Soit le serveur ne le gère pas et fait comme s'il n'existait pas ;-)
>>
>

et donc passes les usurpations :-(

merci, ta réponse est exactement ce que j'attendais

et les autres clients? qui sait si c'est fait aussi par thunderbird,
mewnews, nemoweb, ...

merci encore

[jdd]

Le 09/09/2022 à 12:22, M.V. a écrit :

> par le concepteur pour que l'utilisateur de MacCafé ne puisse pas
> rédiger de message d'annulation ou de remplacement de messages qui ne
> seraient pas de son fait : c'est donc indépendamment du serveur que
> MacCafé génère ces deux cancel-Lock…

mais c'est très bien, c'est même idéal :-)

> Tu veux dire joindre toujours le même CL à ses messages ???

je ne sais pas. Comment faire si on a pas de Mac?

[Erwan David]

jdd <j...@dodin.org> écrivait :

Il y a d'autres clients qui ont la fonction, Gnus par exemple (cf les
en-têtes de mon message)

--
Les simplifications c'est trop compliqué

[DV]

jdd a écrit ceci :

> et les autres clients? qui sait si c'est fait aussi par thunderbird,
> mewnews, nemoweb, ...

Personnellement, je ne connais que deux clients news qui gèrent le
Cancel-Lock : MacCafé donc, et Gnus. Il en existe peut-être d'autres,
mais ceux que tu cites ne le font pas.

[Eric M]

jdd a écrit le Fri, 09 Sep 2022 10:57:10 dans fr.comp.usenet.serveurs :

> si c'est lié à une authentification comme celle de ponx (je sais, ce
> n'est pas usenet) avec login et mdp en trois lettres, à quoi ça sert de
> faire une usine à gaz?

Ponx est seul sur son circuit fermé, il fait ce qu'il veut, vous vous êtes
sur l'autoroute (et vous roulez à contresens mais c'est un détail).

[Eric M]

DV a écrit le Fri, 09 Sep 2022 13:02:05 dans fr.comp.usenet.serveurs :

>> et les autres clients? qui sait si c'est fait aussi par thunderbird,
>> mewnews, nemoweb, ...

> Personnellement, je ne connais que deux clients news qui gèrent le
> Cancel-Lock : MacCafé donc, et Gnus. Il en existe peut-être d'autres,
> mais ceux que tu cites ne le font pas.

Tin aussi le fait.

[jdd]

Le 09/09/2022 à 12:54, Erwan David a écrit :

> Il y a d'autres clients qui ont la fonction, Gnus par exemple (cf les
> en-têtes de mon message)
>

excellent :-)

[jdd]

merci

[jdd]

Le 09/09/2022 à 13:23, M.V. a écrit :

> Si je prends ton identité, je pourrais toujours annuler un de mes
> messages dès que j'envoie à mon message d'annulation le CK kivabien.


> La meilleure solution reste le serveur.
>

comment fait-il pour savoir que c'est bien l'auteur qui envoie le
message de cancel? puisque c'est le serveur qui crée le CK, pas
l'utilisateur.

je n'insiste pas pour vous embêter, mais pour pouvoir documenter.

le but c'est quand même que seul l'auteur du message puisse envoyer le
cancel. on en revient à l'identification de l'auteur.

[DV]

jdd a écrit ceci :

> comment fait-il pour savoir que c'est bien l'auteur qui envoie le
> message de cancel? puisque c'est le serveur qui crée le CK, pas
> l'utilisateur.
>
> je n'insiste pas pour vous embêter, mais pour pouvoir documenter.
>
> le but c'est quand même que seul l'auteur du message puisse envoyer le
> cancel. on en revient à l'identification de l'auteur.

Non, on en revient à son *authentification*. Si l'utilisateur doit
s'authentifier pour publier depuis ton serveur, peu importe l'identité
sous laquelle il publie, le serveur dispose de ses données
d'authentification pour savoir s'il s'agit bien de lui et pas d'un autre.

[LaLibreParole]

jdd <j...@dodin.org> composa la prose suivante:

>Le 09/09/2022 à 11:19, Marc SCHAEFER a écrit :
>> jdd <j...@dodin.org> wrote:
>>> c'est là que ça blesse, le cancel-lock utilise une clé sha, donc une
>>> authentification très forte.
>>
>> Non, c'est un simple hachage. Toute la beauté du truc est de ne pas
>> utiliser de système de chiffrement asymétrique (à clé publique), et donc
>> de ne pas nécessiter de moyen d'authentifier les clés (PKI).
>
>(j'ai lu le reste, mais il est hors sujet sur ce fil)

Je ne sais pas si c'est hors sujet, mais en tout cas c'est bien expliqué.

[Franck]

Le 09/09/2022 à 10:01, jdd a écrit :

> Bonjour,
>
> Je n'ai sans doute pas cherché assez, mais je n'ai pas trouvé comment un
> simple utilisateur pas forcément doué en informatique peut utiliser
> cette procédure :-(
>
> merci
> jdd

Bonjour jdd,

Je vais essayer d'être le plus clair possible tout en essayant de faire
simple, mais bon, le CL/CK reste technique dans sa mise en œuvre.


Commençons par les abréviations que je vais utiliser :
----------------------------------------------------

CL : Cancel-Lock
CK : Cancel-Key
sec : secret (Clef de cryptage pour l'algorithme de hashage)
mid : Message-ID
uid : Identifiant de l'utilisateur authentifié.

Hash : Algo de hashage (principalement SHA1 et SHA256).
Hmac : Type de code d'authentification de message basé sur un algo de
hashage et un secret.
Base64 : Type d'encodage de caractères.


Allons-y pour la musique :
------------------------

Un serveur dispose de deux secrets (sec) pour générer les CL/CK, un
"utilisateur" et un "administrateur" (il est le seul à les connaître).

Le premier permet de générer des CL/CK pour les utilisateurs qui
utilisent un client qui ne sait pas les générer, le second permet
principalement à l'administrateur de pouvoir supprimer les articles qui
sont POSTés sur SON serveur.


Comment ça fonctionne ?
---------------------

Le serveur appose (ou étend) l'entête "Cancel-Lock" (Lors d'un POST
uniquement) avec deux CL (utilisateur et administrateur) en sha256 et
sha1 (pour compatibilité). Ce qui fait qu'un article se retrouve
(généralement) avec une entête "Cancel-Lock" contenant quatre CL.


Comment calcule-t-on un CL ?
--------------------------

Tout simplement en commençant par générer le CK avec la formule suivante :

K = HMAC(sec, uid+mid)

Une fois "K" calculé, on y applique la formule magique :

CL = Base64(hash(Base64(K)))

C'est ce CL qui sera ajouté dans l'entête "Cancel-Lock".


Pour calculer "K", il y a deux façons (recommandées) de le faire :

- Pour un reader, l'uid doit être vierge.

- Pour un serveur :

1°) Pour le CL utilisateur, l'uid doit correspondre à l'identifiant
qui permet d'identifier le POSTeur sur le serveur.

Nota : Un serveur NE DOIT PAS APPOSER de CL utilisateur S'IL N'EST
PAS EN MESURE D'IDENTIFIER FORMELLEMENT L'UTILISATEUR sinon n'importe
qui pourrait émettre un "cancel" ou un "superseedes" valide (puisque le
serveur génère automatiquement le CK pour les readers qui ne savent pas
le faire!).


2°) Pour le CL administrateur, l'uid doit être vierge.


Comment ça fonctionne ensuite ?
-----------------------------

C'est simple, lorsqu'un serveur reçoit un "Cancel" ou un "Superseedes" :

- Sans CK lors d'un POST : le serveur crée le CK pour le client
S'IL EST EN MESURE DE L'IDENTIFIER FORMELLEMENT comme étant l'auteur de
l'article qui est ciblé par le cancel ou superseedes.

- Avec un CK : Il récupère alors le contenu de l'entête
"Cancel-Key" dans CET article et applique la formule
Base64(hash(Base64(K))) pour chaque CK qu'elle contient.


Dans les deux cas, il vérifie ensuite que le CL de l'article CIBLE
correspond à au moins un de ceux qui ont été calculés précédemment
(grâce au hash du CK).

Pour finir, si c'est bon le serveur traite le cancel ou le supersedes
sinon il ne fait rien.


That's all.
(Il y a encore quelques subtilités mais je n'irai pas plus loin ici).


Pour conclure, même si CL/CK n'est pas infaillible (notamment si la RFC
n'est pas scrupuleusement respectée), cela permet un certain niveau de
sécurité. Grâce à eux :

- Un article pourra être supprimé par l'utilisateur :

1°) En utilisant le secret qu'il est le seul à connaitre (cas d'un
reader qui sait générer les CL/CK),

2°) Grâce aux CL/CK qui sont ajoutés par le serveur aux articles
POSTés par un utilisateur IDENTIFIE (Cas d'un reader qui ne sait pas
générer les CL/CK). Ici, le serveur étant le seul à connaitre son secret
"utilisateur", personne ne pourra générer de CK valide sauf à être
FORMELLEMENT identifié par le serveur.

- Un article pourra également être supprimé par l'administrateur,
puisque un CL "administrateur" est ajouté à chaque article POSTé sur le
serveur. Le CK pourra être généré par un outil qui utilise le secret
"Administrateur" du serveur. (Pour INN c'est gencancel).

- Un administrateur ne peut pas générer de CK correct pour un article
qui n'a pas été POSTé sur SON serveur car il ne connait que SON secret
"administrateur" et pas celui des autres serveurs (heureusement!)


---


Voilà, j'espère que cela pourra aider à la compréhension du
fonctionnement des CK/CL même si je le concède, ce n'est pas forcément
simple d'en appréhender toutes les subtilités!


Tout ceci sera transparent (0 script, 0 programme externe) avec le
serveur de news (sous Windows) que je finalise et qui sera disponible
très prochainement (Avec également la possibilité de restreindre l'ajout
d'entêtes "Approved", "Control" et "Superseedes" en fonction des
utilisateurs).


Pour se faire une idée de ce à quoi cela ressemble, vous pouvez vous
connecter sur mon serveur de tests : news.spitfire-nntp.fr:119

- Hiérarchie "fr" en lecture.
- Newsgroup "local.test" en écriture pour tester les publications.
- Newsgroup "local.spitfire.news.server" en lecture pour suivre l'avancé
du projet.


Merci à Julien ELIE pour le feed 😄

Franck

[Franck]

Le 09/09/2022 à 12:10, M.V. a écrit :

> MID, STP ?

Message-ID

>> Tous les serveurs doivent faire de même pour la génération et la vérif
>

> Quand tu dis « doivent » tu veux dire « ils ont l'obligation » ou bien
> « je suppose que » ?

La RFC "préconise" ces éléments, après rien n'empêche d'utiliser un
autre moyen qui permette d'identifier le message et son auteur.

Donc MID et UID en sont le reflet.

Mais si tu veux en plus ajouter l'entête "Date:" dans le calcul du CK,
rien ne l'empêche!

Au lieu de K = HMAC(sec, uid+mid), cela peut être : K = HMAC(sec,
uid+mid+date).

De toutes façons le CL restera le Hash du CK généré, donc n'importe quel
serveur pourra hasher le CK pour vérifier le CL.

En revanche, pour les serveurs qui autorisent les posts anonymes,
l'utilisation de l'adresse IP n'est pas sûre mais peut être un début de
solution (pour identifier l'auteur de l'article). En effet, il faut
prendre en compte le fait qu'elle peut être mutualisée (VPN par exemple)
ou ne pas être statique.

C'est d'ailleurs pour cette raison que les serveurs qui utilisent cette
solution ne proposent les "Cancels/superseedes" que durant 24 heures
après la publication de l'article.

L'IP n'est pas un élément permettant d'identifier un utilisateur de
manière formelle entre deux dates (puisque entre la publication et
l'annulation, cet élément peut changer).

Que ce soit avec une identification formelle (type UID) ou avec autre
chose (IP par exemple), cet élément sera VÉRIFIÉ par le serveur et devra
être identique entre l'article cancel et celui qui en est la cible.

Plus généralement, il est recommandé de ne pas utiliser un UID qui peut
être modifié dans le temps (Par exemple l'entête "From:"). Le login
envoyé avec la commande AUTHINFO reste le meilleur moyen d'identifier
formellement l'utilisateur puisqu'il ne change jamais.

> Je ne vois en réalité pas pourquoi tous les serveurs devraient faire la
> même chose pour *générer* CK mais pour le re-calcul du CL à partir du CK
> joint à un message, là oui.

Tous les serveurs ne sont pas "obligés" de le faire, la RFC indique
simplement un moyen d'authentifier de manière unique un article et son
auteur et ces deux informations sont les plus pertinentes.

Après, cela reste de la tambouille interne et effectivement le seul
impératif reste la formule de génération du CL.

Franck

[Marc SCHAEFER]

M.V. <m...@gmail.com.invalid> wrote:
>> J'ai donné l'explication dans un autre article.
>

> MID, STP ?

>> Tous les serveurs doivent faire de même pour la génération et la vérif
>
> Quand tu dis « doivent » tu veux dire « ils ont l'obligation » ou bien
> « je suppose que » ?

L'algo de vérification est universel. hash(secret, message-id), c'est
cela que je veux dire. Mais tous les serveurs ne supportent pas CL/CK.

C'est par contre pour la génération du secret où ils ont toute
latitude. Par exemple secret = hash(très-secret-du-serveur, user,
message-id).

[Marc SCHAEFER]

jdd <j...@dodin.org> wrote:
> mais cela n'évite pas l'usurpation, qui consiste justement à utiliser le
> pseudo d'un autre utilisateur, le mid du message est public et le secret
> est évidemment connu du serveur (c'est le sien)

Si les CL serveur sont utilisés, cela donne évidemment le droit à l'admin
de ce serveur d'effacer tous les articles originaires de ce serveur sur
tous les serveurs supportant CL/CK.

[yamo']

Salut,
DV a écrit :

> M.V. a écrit ceci :

>>> ce n'est pas ce que j'ai compris :-), si c'est une façon d'authentifier
>>> un cancel, il faut bien que l'utilisateur mette une clé dans ses
>>> messages, non?
>>
>> C'est le serveur qui peut se charger de tout.

> Voilà. À condition, comme le souligne Marc, que ledit serveur soit en
> mesure d'identifier l'utilisateur et donc de générer pour lui le fameux
> « secret » nécessaire à la procédure. Sans authentification, ça risque
> d'être très compliqué.

Au niveau d'INN2/cleanfeed :
Voilà le secret pour un message est une concaténation du secret général
plus de l'utilisateur.
Sans utilisateur il faut remplacer cette chaîne par autre chose, l'adresse
ip peut être une solution...

Sur INN2.7 il y a en plus un secret seulement utilisable pour
l'administrateur.
Julien a expliqué le mécanisme sur news.software.nntp

Et le mécanisme est suffisamment souple pour gérer plusieurs cancel-lock.

--
Stéphane

[Marc SCHAEFER]

M.V. <m...@gmail.com.invalid> wrote:
>> J'ai donné l'explication dans un autre article.
>

> MID, STP ?

En fait, je crois que c'est Frank qui a fait l'explication la plus
complète. Typiquement, dans mon serveur, je ne différencie pas la clé de
suppression admin de celle de suppression de l'utilisateur.

[Franck]

Le 10/09/2022 à 08:23, Marc SCHAEFER a écrit :

> C'est par contre pour la génération du secret où ils ont toute
> latitude. Par exemple secret = hash(très-secret-du-serveur, user,
> message-id).

Ton exemple est complètement faux.

Il s'agit d'un HMAC (qui accepte un secret) et non d'un HASH (qui
n'accepte pas de secret) et il s'agit d'une concaténation de l'uid et du
mid donc, il convient d'écrire :

K = HMAC(très-secret-du-serveur, user+message-id)

Franck

[yamo']

Salut,
jdd a écrit :

> le but c'est quand même que seul l'auteur du message puisse envoyer le
> cancel. on en revient à l'identification de l'auteur.

C'est évident quand il y a authentification...
C'est pour ça sûrement que aioe ne génère pas de cancel-key/lock...

> jdd


--
Stéphane

[Franck]

Le 10/09/2022 à 08:38, Marc SCHAEFER a écrit :

> L'algo de vérification est universel. hash(secret, message-id), c'est
> cela que je veux dire. Mais tous les serveurs ne supportent pas CL/CK.

Re-faux.

HASH n'accepte pas de secret (c'est HMAC qui l'accepte), et le secret
n'est absolument pas utilisé pour la vérification.

Pour vérifier un CL on hashe simplement le CK.

donc : CL = Base64(hash(Base64(K)))


Le secret est utilisé pour la génération du CL. On commence par générer
le CK (avec le secret qu'on cannait) :

K = HMAC(sec, uid+mid)

Puis on le hashe pour obtenir le CL :

CL = Base64(hash(Base64(K)))

C'est ce CL qui est ajouté à l'article.

Lorsqu'un serveur veut vérifier la paire CL/CK il hashe simplement le CK
pour voir s'il tombe sur le CL.

Franck

[Franck]

Le 10/09/2022 à 08:38, Marc SCHAEFER a écrit :

> En fait, je crois que c'est Frank qui a fait l'explication la plus
> complète. Typiquement, dans mon serveur, je ne différencie pas la clé de
> suppression admin de celle de suppression de l'utilisateur.

Ne pas faire de différence est contraire à la RFC qui stipule :

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 multiple <c-lock> elements are added to the Cancel-Lock header
field by a single agent, each <c-lock> element MUST use a unique
key "K" to improve security.


C'est le MUST qui l'impose!

Dans le cas d'un post, le serveur va ajouter plusieurs CLock
(User/Admin, généralement en SHA1 et SHA256) donc 4 CL.

Il faut donc différencier le secret admin et le secret utilisateur.

[yamo']

Salut jdd,

Tu n'as pas d'utilisateur sur ton serveur :
<http://al.howardknight.net/?STYPE=msgid&MSGI=%3Ctfev0c%24gog%241%40ns507557.dodin.fr.nf%3E>
VS
<http://al.howardknight.net/?STYPE=msgid&MSGI=%3Ctfhcih%24vdn%241%40rasp.pasdenom.info%3E>
Dans le premier cas il n'y a pas de posting-account, le deuxième est moins
anonyme!

Pour compliquer, le serveur n'est pas forcé de l'afficher...

Dans filter_nnrpd.pl $user est non affecté ou vide chez toi.

MV, t'explique quelque chose qui ne t'aidera pas pour générer ça sur
dodin.fr.nf

--
Stéphane

[yamo']

jdd a écrit :

L'authentification n'a rien à voir avec le From...

--
Stéphane

[yamo']

DV a écrit :

> jdd a écrit ceci :

>> et les autres clients? qui sait si c'est fait aussi par thunderbird,
>> mewnews, nemoweb, ...

> Personnellement, je ne connais que deux clients news qui gèrent le
> Cancel-Lock : MacCafé donc, et Gnus. Il en existe peut-être d'autres,
> mais ceux que tu cites ne le font pas.

Et tin, slrn et flnews.

Pour les deux derniers je n'y suis pas arrivé...

Pour jdd, il faudrait pour être plus clair parler de :
CL-USERAGENT généré par exemple par tin
CL-server-user généré par le serveur : alphanet,eternal-september,le
mien...
CL-server-admin, nouvelle fonctionnalité implémentée sur INN2.7 par le
serveur de Julien Élie et peut-être d'autres...

--
Stéphane

[jdd]

Le 09/09/2022 à 20:59, Franck a écrit :

> - Sans CK lors d'un POST : le serveur crée le CK pour le client
> S'IL EST EN MESURE DE L'IDENTIFIER FORMELLEMENT comme étant l'auteur de
> l'article qui est ciblé par le cancel ou superseedes.
>

merci pour ces explications, que je sauve pour usage ultérieur

mais ce n'est pas la réponse que j'attends *ici*

dans ce fil, je voudrais me placer strictement à la place de l'usager
qui ne connaît rien à perl ni au fonctionnement du serveur.

s'il à la chance d'utiliser MacCafé (ou équivalent), son client génère
une clé qui identifie à la fois le message et son expéditeur. Il peut
donc annuler son message et personne d'autre ne le peut.

dans le cas contraire, le serveur, si j'ai bien compris, ne devrait
ajouter de clé que s'il identifie parfaitement l'utilisateur. Or sur mon
serveur je n'ai *pas* cette identification.

l'annulation des message n'est également pas possible par le mécanisme
classique (innd -C)

Or on me dit que les messages avec CL sont effectivement annulés. Si
c'est avec McCafé, c'est très bien.

mais je constate qu'un CL est ajouté alors même que la serveur ne
demande pas d'authentification.

dans cas cas y a-t-il annulation possible du message? cette annulation
est-elle possible uniquement par l'auteur (reconnu comment?) ou par
n'importe qui?

merci

[jdd]

Le 10/09/2022 à 11:41, M.V. a écrit :
> Dans le message <tfhjf7$2vm$1...@ns507557.dodin.fr.nf>, jdd a écrit le 10

>> dans cas cas y a-t-il annulation possible du message?
>

> (Aparté : Pourquoi ne l'expérimentes-tu pas toi-même ? C'est quand même
> assez simple à faire, non ?)

en fait non, je ne sais pas le faire avec Thunderbird

>> cette annulation est-elle possible uniquement par l'auteur (reconnu
>> comment?) ou par n'importe qui?
>

> Ben essaye ! Je viens de publier un message sur fr.test : essaye de le
> supprimer pour voir !
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> From: m...@gmail.com.invalid (M.V.)
> Subject: [Ignore] Test pour être annulé
> Date: Sat, 10 Sep 2022 11:40:19 +0200
> Message-ID: <news:1py2dq1.1xlt1q17zlp3bN%m...@gmail.com.invalid>
> Newsgroups: fr.test
> Cancel-Lock: sha256:7apbR52T5y8DL7hCh1Fen7dNGcv+KtAKMnwzqpU2BeQ=
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

avec mesnws, "supprimer le message du serveur" me réponds "il ne vous
appartient pas.

les clients ont la mauvaise habitude d'avoir une option "supprimer" qui
ne supprime le message que du client, pas du serveur, du coup difficile
de savoir exactement ce qu'on fait :-(

reste à voir si un des farfelus de fr* saura le faire :(-

[yamo']

Salut,
jdd a tapoté le 10/09/2022 12:48:

> reste à voir si un des farfelus de fr* saura le faire :(-

Pour le Cancel d'un post de pasdenom.info, ton code fonctionne (c'est
bien refusé).
Félicitations!

Par contre le Supersedes fonctionne alors qu'il devrait être refusé.

cf fr.test <tfhrph$6tn$1...@rasp.pasdenom.info>

Test avec Seamonkey/pasdenom et flnews/dodin.

--
Stéphane
<https://news2web.pasdenom.info/article.php?id=%3Ctfhrph$6tn$1...@rasp.pasdenom.info%3E&group=fr.test>

[DV]

jdd a écrit ceci :

> avec mesnws, "supprimer le message du serveur" me réponds "il ne vous
> appartient pas.
>
> les clients ont la mauvaise habitude d'avoir une option "supprimer" qui
> ne supprime le message que du client, pas du serveur, du coup difficile
> de savoir exactement ce qu'on fait :-(

Dans MesNews, tu as deux commandes distinctes :

- Supprimer le message (sur le serveur)

- Supprimer le message (en local)

Vu la réponse que tu as reçue, c'est clairement la première commande que
tu as utilisée.

Dans Thunderbird, tu as :

- Annuler le message (dans le menu Messages) -> Cancel

- Supprimer le message (dans le menu contextuel) -> suppression locale.

[yamo']

Salut,
M.V. a tapoté le 10/09/2022 14:41:
> C'est donc confirmé : il n'y a aucune authentification utilisée dans le
> calcul de CK effectué par le serveur.

Il a du laisser le code de Gérald tel quel où c'est $user qui est
utilisé pour le calcul du hash*.

Mais c'est déjà un début.

* Désolé si ce n'est pas exactement ça...
--
Stéphane

[yamo']

Salut,
M.V. a tapoté le 10/09/2022 17:32:
> Je ne comprends pas bien : comment le serveur dodin.fr.nf aurait été
> capable de retrouver le cancel-key correspondant au message ciblé ?
> Pour ça, il faudrait qu'il connaisse le mode de calcul du cancel-key que
> ton serveur pratique et les éléments du calcul dont le principal est
> normalement introuvable : le « secret ».

Logiquement, le filtre nnrpd doit refuser l'émission du cancel s'il n'y
a pas au minimum un cancel-key qui correspond avec un cancel-lock du
message ciblé.

<https://home.gegeweb.org/rfc8315.html>

C'est ce que j'ai testé par contre ça ne fonctionne que avec Cancel.

--
Stéphane

[Franck]

Bonsoir,

> C'est donc confirmé : il n'y a aucune authentification utilisée dans le
> calcul de CK effectué par le serveur.

Ce n'est pas exact.

L'authentification (uid) EST BIEN UTILISÉE dans le calcul du CK
"utilisateur" mais il y a une subtilité que je vais développer plus loin.

L'authentification n'est en revanche pas REQUISE pour le calcul du CK
"administrateur" (raison pour laquelle il faut différencier les secrets
utilisateur ET administrateur).


Rappel du contexte :
------------------

Dodin permet les publications ANONYMES (comme aioe). Donc, dans anonyme,
il y a UTILISATEUR NON FORMELLEMENT IDENTIFIE.

Pour faire encore plus simple, pour publier, le reader n'a pas besoin de
préalablement envoyer la succession des commandes AUTHINFO USER/PASS (il
ne s'identifie donc pas formellement auprès du serveur).

Tout le monde suit?
OK.


Exemple de ce qui se passe dans les deux cas :
--------------------------------------------

mid = <monarticle@monserveur>
sec = un_secret_utilisateur_ou_serveur

Je m'identifie FORMELLEMENT auprès du serveur avec AUTHINFO USER/PASS,
donc :

uid = franck

Le calcul de la clef sera donc :

HMAC(un_secret_utilisateur_ou_serveur, franck<monarticle@monserveur>)


Maintenant, si je ne m'identifie pas FORMELLEMENT auprès du serveur :

uid = "" (rien)

Le calcul de la clef sera donc :

HMAC(un_secret_utilisateur_ou_serveur, <monarticle@monserveur>)


Résultat des courses, n'importe qui peu annuler le message de n'importe
qui, puisque tout le monde à le même uid = "" (rien)! Et c'est vraiment
le cas de le dire, cet uid ne vaut rien!

Pour que cela fonctionne "à minima", il faudrait que dodin utilise comme
uid l'adresse IP du client à la place du login (puisqu'il n'en demande pas).

Mais ce n'est pas une solution fiable car cet élément peut :

- Être mutualisé (Vpn etc...)
- Changer entre la publication et l'annulation.

Car OUI, en INJECTION la paire CL/CK ne suffit pas, il faut aussi que
cet élément (qui identifie formellement l'auteur) soit IDENTIQUE entre
l'article "cancel" et l'article d'origine sinon il ne DEVRAIT pas le
traiter et encore moins le relayer!

(Ce qui n'est pas vrai pour les messages relayés puisque dans ce cas, le
cancel est traité si la paire CL/CK est correcte).

Vous êtes toujours là???

Je POSTe aujourd'hui un message depuis l'IP 1.2.3.4 et demain je poste
l'annulation depuis 4.3.2.1 (Soit parce que le DHCP de mon FAI m'a
attribué une nouvelle IP soit parce que j'ai changé de serveur VPN).

Même si j'envoie un CK correct (ou que le serveur me le génère) et même
si le CL sera forcément correct après hashage, le serveur NE DEVRAIT PAS
accepter de le traiter/relayer car les deux éléments qui identifient
l'auteur des articles (cancel et original) sont différents (1.2.3.4 et
4.3.2.1).

Je suis AFFIRMATIF pour le serveur que je code, je laisse Julien
répondre pour INN.

Voilà, j'espère avoir été plus clair.
Franck

[Franck]

Le 10/09/2022 à 17:32, M.V. a écrit :

> Je ne comprends pas bien : comment le serveur dodin.fr.nf aurait été
> capable de retrouver le cancel-key correspondant au message ciblé ?

Dans l'entête "Cancel-Key" de l'article d'annulation.

Il prend chaque CK contenu dans cette entête, les hashe et compare le
résultat avec l'un des CL contenu dans l'entête "Cancel-Lock" du message
à annuler.

> Pour ça, il faudrait qu'il connaisse le mode de calcul du cancel-key que
> ton serveur pratique et les éléments du calcul dont le principal est
> normalement introuvable : le « secret ».

Absolument pas.

Quand le serveur appose un CL (un verrou) à un message pour le
"protéger", il commence par calculer la clef (le CK). Il ne la
communique pas!

Il hashe ensuite le CK pour le transformer en CL (et c'est ce que tout
les serveurs feront par la suite).

Quand un client demande l'annulation d'un article, le serveur ajoute un
CK (il le dilvulgue) dans l'article de controle "cancel". Les serveurs
vont se servir de cette information, la hasher pour essayer de retomber
sur le CL.

Si c'est bon, on traite sinon on zappe.

[jdd]

Le 10/09/2022 à 13:23, yamo' a écrit :

> Pour le Cancel d'un post de pasdenom.info, ton code fonctionne (c'est
> bien refusé).
> Félicitations!

tout le mérite revient à l'auteur du fichier

>
> Par contre le Supersedes fonctionne alors qu'il devrait être refusé.

pourquoi?

c'est plus ou moins la même chose, non?

[jdd]

Le 10/09/2022 à 14:18, DV a écrit :
> jdd a écrit ceci :
>
>> avec mesnws, "supprimer le message du serveur" me réponds "il ne vous
>> appartient pas.
>>
>> les clients ont la mauvaise habitude d'avoir une option "supprimer" qui
>> ne supprime le message que du client, pas du serveur, du coup difficile
>> de savoir exactement ce qu'on fait :-(
>
> Dans MesNews, tu as deux commandes distinctes :
>
> - Supprimer le message (sur le serveur)
>
> - Supprimer le message (en local)
>
> Vu la réponse que tu as reçue, c'est clairement la première commande que
> tu as utilisée.
>
> Dans Thunderbird, tu as :
>
> - Annuler le message (dans le menu Messages) -> Cancel
>
> - Supprimer le message (dans le menu contextuel) -> suppression locale.
>

vu, je vais noter ça

"Ce message n’est manifestement pas de vous. Vous pouvez seulement
annuler les messages que vous avez envoyés vous-même."

mais je n'ai pas essayer de truquer les en-têtes

merci

[jdd]

Le 10/09/2022 à 14:26, M.V. a écrit :

> Je dois donc être en mesure de supprimer tout message émanant de
> dodin.fr.nf, ce qui serait légèrement embêtant !

tout à fait :-(
>
> Je vais faire d'autres tests pour voir, mais ce 1er test est assez
> inquiétant.

merci

[jdd]

Le 10/09/2022 à 14:41, M.V. a écrit :

> C'est donc confirmé : il n'y a aucune authentification utilisée dans le
> calcul de CK effectué par le serveur.

et donc le système est même contre-productif, en permettant l'annulation
d'un message qui n'aurait pas pu l'être précédemment. zut.

merci
--
mon serveur dodin.fr.nf

[jdd]

ah oui, je n'ai rien touché au code.

il faudrait donc inactiver cette partie du code (laisser celle ou le
CL/CK est généré par le client)

[jdd]

Le 10/09/2022 à 17:50, Franck a écrit :

j'apprécie beaucoup tes explications, très claires :-) merci.

> Pour que cela fonctionne "à minima", il faudrait que dodin utilise comme
> uid l'adresse IP du client à la place du login (puisqu'il n'en demande pas).
>
> Mais ce n'est pas une solution fiable car cet élément peut :
>
> - Être mutualisé (Vpn etc...)
> - Changer entre la publication et l'annulation.

oui. Je sais (pour en être victime) que Free bloque les comptes *mail*
qui viennent d'un vpn. J'ai (un peu) commencé à en faire autant en
bannissant pas mal d'IP

c'est une solution à étudier, car en toute logique une annulation doit
avoir lieu peu après l'émission, et ce serait pas de bol que l'auteur et
le pénible utilisent le même vpn (encore que connaissant l'IP il doit re
possible de deviner le VPN)

> Vous êtes toujours là???

oui!

> Voilà, j'espère avoir été plus clair.
> Franck
>

merci, je note tout ça.

pour la compréhension de ma façon de travailler, j'archive les articles
de ce genre jusqu'à ce que j'ai eu le temps de les relire, assimiler et
résumer au besoin dans ma doc, mais ça peut prendre un peu de temps.

note2: si la doc de ton serveur est du niveau de ces posts, bravo, ça va
être très intéressant à lire!

[jdd]

Le 10/09/2022 à 18:43, M.V. a écrit :
> Dans le message <tfiebd$8dh$3...@ns507557.dodin.fr.nf>, jdd a écrit le 10
> septembre 2022 à 18 h 34 :

>
>> et donc le système est même contre-productif, en permettant l'annulation
>> d'un message qui n'aurait pas pu l'être précédemment. zut.
>

> Heureusement, ce dysfonctionnement ne touche que ton serveur : ce sont
> les posts émis depuis ton serveur qui sont vulnérables.
>

pour utiliser l'IP, il doit être possible de remplir la variable user
avec l'ip + le from. Pas incassable, mais pas si mal.

reste à le faire, on verra

merci

[Julien ÉLIE]

Salut Franck,

> Je suis AFFIRMATIF pour le serveur que je code, je laisse Julien
> répondre pour INN.

Je n'ai pas lu la discussion dans le détail mais en tout cas je confirme
que INN 2.7.0 est conforme à la RFC 8315 (Cancel-Lock) dont je suis le
"Document Shepherd".
Le serveur de Franck a certainement une implémentation similaire
puisqu'il s'est basé sur la RFC 8315 et gère toutes les subtilités de la
RFC 8315.

> Voilà, j'espère avoir été plus clair.

L’ambiguïté provient du fait que le serveur duquel on parle ici est un
INN 2.6.2 qui utilise du code tiers pour la fonctionnalité Cancel-Lock.
Je ne saurais dire exactement ce qui est en place dans ses
filter_innd.pl et filter_nnrpd.pl, ni le contenu de la variable $user
(qui est probablement la même chaîne de caractères valorisée dans le
"default" de son bloc "auth" correspondant aux utilisateurs non
authentifiés dans readers.conf => ce qui expliquerait que tout le monde
peut annuler un article d'autrui).

--
Julien ÉLIE

« C'est une liqueur de grain distillée en Calédonie. » (Astérix)

[Franck]

Le 10/09/2022 à 18:31, M.V. a écrit :

>> Résultat des courses, n'importe qui peu annuler le message de n'importe
>> qui, puisque tout le monde à le même uid = "" (rien)! Et c'est vraiment
>> le cas de le dire, cet uid ne vaut rien!
>

> C'est en réalité équivalent à ce que j'ai dit…

La démonstration et les explications en moins :-)

> Dire que uid est "" ou dire que le calcul se fait sans authentification
> est, de ce fait, strictement la même chose et aboutit à la même
> conclusion : je peux annuler n'importe quel message émis depuis
> dodin.fr.nf, chose que j'ai pu vérifier par ailleurs.

Alors c'est parfait, je n'ai donc plus besoin d'écrire une ligne, je
vais te laisser t'y coller :-)

[Franck]

Le 10/09/2022 à 18:11, M.V. a écrit :

> Ah ?
>
> J'envoie un article via pasdenom.info : il y a un CL (et un seul).

Un seul CL voudrait dire soit :

- Que ton reader ne sait pas gérer les CL/CK et que le serveur n'a pas
de secret admin (sinon il y aurait deux CL, un user et un admin).

- Soit que ton reader sait gérer les CL/CK et qu'il a donc apposé un
seul CL utilisateur à ton article. Dans ce cas, j'espère que c'est du
SHA1 car les serveurs anciens ne savent pas hasher en SHA256.


Une fois posté sur le serveur, ton article vas s'en prendre généralement
un autre, apposé par le serveur (CL admin) pour que l'administrateur
puisse supprimer ton message s'il enfreint une quelconque règle.

On est déjà à deux CL. Et généralement, un serveur récent va en apposer
un en SHA1 et un en SHA256 car tous les serveurs ne savent pas hasher en
SHA256.

On est arrivé à trois CL en deux paragraphes :)

> Comment pourrais-je annuler ce message depuis un autre serveur, en
> particulier depuis dodin.nf.fr ?

Si ton reader SAIT gérer les CK/CL, la question ne se pose pas. Il
pourra créer un CK tout seul puisqu'il connait SON secret avec lequel il
a créé le CL initial (en hashant le CK).

Tu pourras donc annuler ton article depuis n'importe quel serveur.

En revanche, si ton lecteur ne sait pas gérer les CK/CL, c'est le
serveur sur lequel tu postes tes articles qui va faire ce travail pour
toi (Avec un secret que lui seul connait).

Pour la RFC 8315, tu en entres alors dans le cas :

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.

Si tu as POSTé un article sur un serveur et qu'il a ajouté un CL pour
toi (car ton reader sait pas le faire), il faudra que tu passes
également par lui pour qu'il te crée un CK valide lorsque tu posteras
une annulation (Puisqu'il est le seul à connaitre SON secret utilisateur
pour générer le CK valide).

Un fois qu'il aura bossé pour toi, il va traiter le cancel et le
transmettre à ses pairs, qui hasheront à leur tour le CK, retomberont
sur le CL et annuleront ton article.

> Tu lis ce que j'écris ou bien tu délires.

Ah, une petite agression en vue, on arrive donc au bout des arguments?
Cela m'étonne dans "fr" :)

Alors oui, je lis ce que tu écris.
Cela ne me fait pas délirer, sourire oui mais délirer non :)

Franck

[yamo']

Salut,
jdd a tapoté le 10/09/2022 18:36:

Soit installer inn 2.7 et ne faire que CL/CK de l'administrateur.
Soit demander à Julien comment le faire sur un inn 2.6 (CL de l'admin).

Ou alors faire dans filter_nnrpd.pl :
$user= $attributes{'ipaddress'};

Ça limiterais à l'IP...

Les deux premières solutions sont meilleures mais plus complexes
(j'attends une version pour debian testing ou si je rêve en backport).

--
Stéphane

[yamo']

Salut,
M.V. a tapoté le 10/09/2022 18:29:
> Il y a donc bien un petit problème de ton côté : ton serveur laisse
> passer des supersedes sans tenir compte de CK - CL.

Oui et honnêtement, ça m'étonne :(


--
Stéphane

[yamo']

jdd a tapoté le 10/09/2022 18:28:

Oui, je ne vois pas pourquoi.

Bref vivement inn 2.7 sur debian...
--
Stéphane

[jdd]

Le 10/09/2022 à 20:08, yamo' a écrit :

> Ou alors faire dans filter_nnrpd.pl :
> $user= $attributes{'ipaddress'};
>
> Ça limiterais à l'IP...
>

j'ai envie de tester ça. peut-on y ajouter le from? (est-ce utile?)

merci

[Franck]

Salut Julien,

> L’ambiguïté provient du fait que le serveur duquel on parle ici est un
> INN 2.6.2 qui utilise du code tiers pour la fonctionnalité Cancel-Lock.
> Je ne saurais dire exactement ce qui est en place dans ses
> filter_innd.pl et filter_nnrpd.pl, ni le contenu de la variable $user
> (qui est probablement la même chaîne de caractères valorisée dans le
> "default" de son bloc "auth" correspondant aux utilisateurs non
> authentifiés dans readers.conf => ce qui expliquerait que tout le monde
> peut annuler un article d'autrui).

Merci pour les explications techniques pour INN.

Ne sachant pas exactement comment est implémenté la RFC 8315 dans INN,
je préférais que tu y apportes un avis bien plus éclairé que le mien.

Pour le reste, je pense que nous avons suffisamment écrit sur le sujet
CL/CK, tout le monde semble maitriser maintenant, je vais donc partir en
vacances soulagé :-)

Franck

[LaLibreParole]

"M.V." <m...@gmail.com.invalid> composa la prose suivante:

>Comments: no-dodin

Faut vraiment être pervers pour discuter d'une chose qui intéresse jdd
en demandant à son serveur de ne pas accepter le message...

@jdd: tu devrait désactiver la fonctionnalité
"Comments: no-dodin"
de ton serveur: elle n'apporte sinon de la confusion.

[yamo']

Salut,
Franck a écrit :

> Si c'est bon, on traite sinon on zappe.

Merci pour cette explication très claire!
Pour y faire référence :
<http://al.howardknight.net/?STYPE=msgid&MSGI=%3Ctficbq%241hr5%241%40gioia.aioe.org%3E>

Pour mon problème de Supersedes, je me demande si c'est INN2 qui après le
traitement de Cleanfeed* applique le Supersedes...
Je vais jeter un œil du côté des flags INN2...

*(cleanfeed n'applique pas le Supersedes mais le message fautif n'est pas
rejeté).


Bon dimanche,

--
Stéphane

[yamo']

Salut,
jdd a écrit :

> Le 10/09/2022 à 20:08, yamo' a écrit :

>> Ou alors faire dans filter_nnrpd.pl :
>> $user= $attributes{'ipaddress'};
>>
>> Ça limiterais à l'IP...
>>

> j'ai envie de tester ça. peut-on y ajouter le from? (est-ce utile?)

Oui ça respecterait l'usage classique mais, comme il est très libre je
l'ajouterais en tant que hash.
J'ai déjà eu un bug avec des caractères non ASCII dans le mot de passe.


--
Stéphane

[jdd]

pourquoi? c'est un choix laissé à l'utilisateur

[LaLibreParole]

jdd <j...@dodin.org> composa la prose suivante:

Un choix laissé à un utilisateur d'un autre serveur de ne pas
faire figurer les messages sur le tien ? drôle de choix.

Regarde ici: il fait une réponse sur un fil ou tu es partie prenante,
mais tu n'as pas vu sa réponse car il a mis ce "filtre" destiné à
ton serveur uniquement...

[jdd]

Le 11/09/2022 à 10:18, LaLibreParole a écrit :
> jdd <j...@dodin.org> composa la prose suivante:

>> pourquoi? c'est un choix laissé à l'utilisateur
>
> Un choix laissé à un utilisateur d'un autre serveur de ne pas
> faire figurer les messages sur le tien ? drôle de choix.

c'est le sien :-)

>
> Regarde ici: il fait une réponse sur un fil ou tu es partie prenante,
> mais tu n'as pas vu sa réponse car il a mis ce "filtre" destiné à
> ton serveur uniquement...
>

tant pis pour lui :-)

c'est anecdotique

[jdd]

Le 11/09/2022 à 10:44, M.V. a écrit :
> Dans le message <tfk46p$i1p$1...@rasp.pasdenom.info>, yamo' a écrit le 11
> septembre 2022 à 09 h 54 :

>
>>> j'ai envie de tester ça. peut-on y ajouter le from? (est-ce utile?)

> Le From pouvant toujours être « forgé », je crains que ça ne soit pas
> d'une grande utilité.
>
si ça vous convient, on pourrait passer la discussion sur
dodin.innserver.info, ça ne concerne guère que mon serveur (je crois)

le but est d'ajouter le from et l'IP, au cas ou deux usagers
utiliseraient la même IP

[jdd]

Le 11/09/2022 à 11:24, M.V. a écrit :
> Dans le message <tfk7u2$km9$4...@ns507557.dodin.fr.nf>, jdd a écrit le 11
> septembre 2022 à 10 h 57 :

>
>> si ça vous convient, on pourrait passer la discussion sur
>> dodin.innserver.info
>

> Non : quelqu'un qui n'utilise pas ton serveur pourrait aider si tu
> laisses la discussion se poursuivre ici.

pas de problème (de toutes façon je ne met pas de suivi pour un groupe
local :-)

[jdd]

Le 11/09/2022 à 11:44, M.V. a écrit :
> Dans le message <tfk9ts$l7p$1...@ns507557.dodin.fr.nf>, jdd a écrit le 11
> septembre 2022 à 11 h 31 :

>
>>> Non : quelqu'un qui n'utilise pas ton serveur pourrait aider si tu
>>> laisses la discussion se poursuivre ici.
>>
>> pas de problème
>

> Par contre, tu pourrais ouvrir une nouvelle enfilade demandant
> spécifiquement de l'aide pour configurer ton bidule.

pour l'instant il faut que j'absorbe ce qu'on m'a déjà donné :-)

je comprends vite, mais il faut m'expliquer longtemps :-)

[Franck]

Le 10/09/2022 à 10:56, jdd a écrit :

> dans le cas contraire, le serveur, si j'ai bien compris, ne devrait
> ajouter de clé que s'il identifie parfaitement l'utilisateur. Or sur mon
> serveur je n'ai *pas* cette identification.

On a bien compris et c'est la source principale de ton problème puisque
nous t'expliquons tous que pour que cela fonctionne correctement il faut
qu'il y ait AUTHENTIFICATION FORMELLE.

Je ne sais pas ce que tu n'arrives pas à comprendre ici, c'est pourtant
assez clair!

> Or on me dit que les messages avec CL sont effectivement annulés. Si
> c'est avec McCafé, c'est très bien.

Normal, tous tes utilisateurs ont le même UID, donc n'importe qui peut
annuler l'article de n'importe qui, puisque tout le monde est IDENTIFIE
par ton serveur SOUS LA MÊME IDENTITÉ.

Cette IDENTIFICATION PAR DÉFAUT est attribuée automatiquement par ton
serveur à la connexion du client et ne change que s'il s'authentifie
formellement avec les commandes AUTHINFO.

> mais je constate qu'un CL est ajouté alors même que la serveur ne
> demande pas d'authentification.

Il est ajouté avec l'identité qui est attribuée "par défaut" aux
utilisateurs anonymes (Et qui est donc la même pour tous), voir supra.
Comme je suis certain de ce qu'à écrit Julien, cela doit être "anonymous".

Je ne sais pas comment est implémentée la RFC 8315 dans la dernière
version d'INN (je crois que tu utilises une version antérieure), je
n'irai donc pas plus loin mais je suis persuadé de cela doit être
similaire au fonctionnement de mon serveur.

En gros :

- A la connexion, tous les utilisateurs se voient attribuer l'identité
par défaut "Anonymous" jusqu'à ce qu'ils s'identifient formellement avec
les commandes AUTHINFO.

- Pour les utilisateurs anonymes (identifiés sous l'identité
"Anonymous"), AUCUN CK utilisateur n'est ajouté, seul le CK
administrateur l'est (Pour que l'admin puisse supprimer l'article qui ne
respecterait pas une règle).

--> Ce qui veut dire que personne ne peut annuler un article posté par
un utilisateur anonyme hormis l'administrateur du serveur (Puisqu'il n'y
a que lui qui pourra générer le CK à l'aide du secret administrateur du
serveur).

NOTA: Cette règle est bien évidement différente si l'utilisateur anonyme
poste avec un client qui SAIT gérer les CL/CK, auquel cas il pourra
supprimer ses articles puisqu'il sera en mesure de générer le CK
d'annulation TOUT SEUL sans avoir besoin de déléguer cette tâche au
serveur. L'administrateur pourra également supprimer l'article puisque
TOUS les articles qui sont POSTés sur son serveur se voient ajouté un CL
administrateur.

> dans cas cas y a-t-il annulation possible du message? cette annulation
> est-elle possible uniquement par l'auteur (reconnu comment?) ou par
> n'importe qui?

J'ai répondu plus haut, je n'y reviendrai plus: Sur ton serveur, tous
tes utilisateurs se voient attribuer une UID qui est identique (Voir
l'explication de Julien) donc si tout le monde "s'appelle pareil", le
serveur ne peut faire aucune différence (logique non?) et donc :

Tout le monde annule les articles de tout le monde.

[Franck]

Oups...

> - Pour les utilisateurs anonymes (identifiés sous l'identité
> "Anonymous"), AUCUN CK utilisateur n'est ajouté, seul le CK
> administrateur l'est (Pour que l'admin puisse supprimer l'article qui ne
> respecterait pas une règle).

Je pense que tout le monde avait corrigé par soi-même mais dans ce
paragraphe, il convient de lire "CL" au lieu de "CK".

[jdd]

Le 12/09/2022 à 07:55, Franck a écrit :
> Le 10/09/2022 à 10:56, jdd a écrit :

>> mais je constate qu'un CL est ajouté alors même que la serveur ne
>> demande pas d'authentification.
>
> Il est ajouté avec l'identité qui est attribuée "par défaut" aux
> utilisateurs anonymes

mais si j'ai bien lu la RFC, ca ne devrait pas être le cas. Sinon, oui,
j'ai bien compris tes explications

> --> Ce qui veut dire que personne ne peut annuler un article posté par
> un utilisateur anonyme

alors que justement, tout le monde peut l'annuler... avec les réglages
par défaut

mais je crois que depuis l'article auquel tu réponds on a avancé sur la
question :-)

merci

[yamo']

Salut Julien,
Julien ÉLIE a écrit :

> Je ne saurais dire exactement ce qui est en place dans ses
> filter_innd.pl et filter_nnrpd.pl, ni le contenu de la variable $user
> (qui est probablement la même chaîne de caractères valorisée dans le
> "default" de son bloc "auth" correspondant aux utilisateurs non
> authentifiés dans readers.conf => ce qui expliquerait que tout le monde
> peut annuler un article d'autrui).

C'est effectivement ce que nous avions conclu il y a quelques mois ici-même.

Et il me semble que tu avais écrit que sur la version 2.7, INN ne
générera au mieux* qu'un CL-admin si l'utilisateur est anonymous.

Note pour jdd, à lire aussi :
<http://al.howardknight.net/?STYPE=msgid&MSGI=%3Ctfmhku%241813%241%40gioia.aioe.org%3E>

J'avais écrit à jdd sur son serveur sur un groupe interne qu'il y a 3
solutions. Je viens d'en voir une quatrième : proposer à ceux qui le
veulent de s'authentifier, c'est probablement possible dans readers.conf
mais, je ne saurais dire comment...


*l'administrateur choisit la configuration qui lui convient.
--
Stéphane

[yamo']

Salut,
jdd a écrit :

> Le 12/09/2022 à 07:55, Franck a écrit :


>> --> Ce qui veut dire que personne ne peut annuler un article posté par
>> un utilisateur anonyme

> alors que justement, tout le monde peut l'annuler... avec les réglages
> par défaut

Oui c'est le hic. Mais, c'est déjà une avancée...

Alors nouvelle proposition dans filter_nnrpd.pl ajouter un truc du genre :
If($user!=anonymous) then génération du CK
Et tu pourrais ajouter un code qui te permet de générer CK sur ton ip et
localhost. Ça permettrait de ne pas bidouiller la variable $user dans
cleanfeed.local et que seul des utilisateurs authentifiés puissent annuler.

Ce code n'est pas du vrai code, c'est écrit sur un smartphone qui n'a pas
de ligne de commande...

> mais je crois que depuis l'article auquel tu réponds on a avancé sur la
> question :-)

J'espère bien!

> merci
> jdd

--
Stéphane

[jdd]

Le 12/09/2022 à 08:54, yamo' a écrit :

> Note pour jdd, à lire aussi :
> <http://al.howardknight.net/?STYPE=msgid&MSGI=%3Ctfmhku%241813%241%40gioia.aioe.org%3E>

mais tu y dis "on a bien compris", non, tu n'as pas compris (en tout cas
dans ce post).

la RFC dit que s'il n'y a pas d'authentification *il ne doit pas y avoir
de clé inscrite dans le message" (mais je ne retrouve pas où j'ai lu ça :-()

>
> J'avais écrit à jdd sur son serveur sur un groupe interne qu'il y a 3
> solutions.

j'ai mis en place une identification par l'IP comme tu me l'as indiqué
ailleurs

voir si ca suffit...

[yamo']

Salut,

Franck a écrit :

Les deux options sont possibles.

Il faudrait vérifier si l'implémentation de Gérald ne générerait pas un
ck même s'il n'y a pas de cl dans le post cible...

--
Stéphane

[yamo']

Salut,
jdd a écrit :

> Le 12/09/2022 à 08:54, yamo' a écrit :

>> Note pour jdd, à lire aussi :
>> <http://al.howardknight.net/?STYPE=msgid&MSGI=%3Ctfmhku%241813%241%40gioia.aioe.org%3E>

> la RFC dit que s'il n'y a pas d'authentification *il ne doit pas y avoir
> de clé inscrite dans le message" (mais je ne retrouve pas où j'ai lu ça :-()

Peut-être :
<http://al.howardknight.net/?STYPE=msgid&MSGI=%3Csvbadd%242h8ln%241%40news.trigofacile.com%3E>

>> J'avais écrit à jdd sur son serveur sur un groupe interne qu'il y a 3
>> solutions.

> j'ai mis en place une identification par l'IP comme tu me l'as indiqué
> ailleurs

Super, je suis sûr que tu auras pleins de testeurs!

C'est à mon avis déjà suffisant, tu pourras écrire dans ta doc d'éviter
d'utiliser les adresses IP partagées.
Tu pourrais même pour limiter les cancels au jour même, ajouter en plus la
date au format 20220912.

--
Stéphane

[Franck]

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 :-)

[Franck]

Le 12/09/2022 à 09:14, yamo' a écrit :

>> Je pense que tout le monde avait corrigé par soi-même mais dans ce
>> paragraphe, il convient de lire "CL" au lieu de "CK".
>
> Les deux options sont possibles.

Pour toute publication d'article par un client (via POST) le serveur
n'ajoute pas de CK sauf dans le cas ou il agit pour le compte d'un
client qui ne gère pas les CL/CK et si l'article est un "Cancel" ou
"Superseedes".

Apposer un CK revient à le divulguer la clef, cela ne se fait donc que
pour une demande d'annulation ou de remplacement.

Pour tous les autres articles c'est un CL qui est ajouté par le serveur.

[jdd]

Le 12/09/2022 à 10:13, Franck a écrit :

> Pour tous les autres articles c'est un CL qui est ajouté par le serveur.
>

j'ai ajouté dans le code de gegeweb un my $user qui contient l'IP, c'est
une identification faible, le but n'est pas forcément de bloquer tous
les pirates mais de les obliger à faire plus de boulot.

si l'efficacité est confirmée, j'ajouterai dans la doc qu'un utilisateur
peut annuler ses propres articles, à condition que ce soit fait depuis
la même IP que celle de publication

dans les jours qui viennent, je vais installer postfilter

merci

[yamo']

Salut,
M.V. a écrit :

> Quand j'ai écrit :
> « J'envoie un article via pasdenom.info : il y a un CL (et un seul). »

Sur pasdenom.info, j'utilise le même code Perl (sauf pour le $user...) que
dodin.

Avec INN 2.7 et j'espère le serveur de Franck celà va un peu se normaliser!

Là, il y a X implémentations...
Il y a de quoi se perdre.

--
Stéphane

[LaLibreParole]

"M.V." <m...@gmail.com.invalid> composa la prose suivante:

>Dans le message <tfmq69$mvn$1...@ns507557.dodin.fr.nf>, jdd a écrit le 12
>septembre 2022 à 10 h 21 :

>
>> j'ai ajouté dans le code de gegeweb
>

>Franck ne va pas en croire ses yeux : il n'y a qu'un seul CL dans
>l'en-tête de ton message et, qui plus est, en sha256 !
>Son monde va s'écrouler ! ;-)

Il t'a pourtant renvoyé dans les cordes dans ses réponses
à tes messages qui son cachés à jdd...

[yamo']

Salut,
M.V. a écrit :

> Mauvaise idée à mon avis : si je publie un message à 23 h 59, je dois
> pouvoir le supprimer ou le remplacer 2 min plus tard…

Il suffit d'attendre 00h01 ;)

--
Stéphane

[jdd]

oui, j'en vois un parce qu'il a enlevé le no-dodin :-))

en tout cas j'apprends à manier les filtres :-))

[Franck]

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.

[Franck]

Le 12/09/2022 à 09:33, M.V. a écrit :

> Mauvaise idée à mon avis : si je publie un message à 23 h 59, je dois
> pouvoir le supprimer ou le remplacer 2 min plus tard…

Que d'incompréhension ^^

Un bon bulot utiliserait la date/heure système.
Du bon boulot fait que tu utilises l'entête "Date" de l'article initial
(elle va pas changer et le serveur sait la retrouver).


Mais je le redis, IP+date n'identifie pas formellement l'utilisateur au
sens strict de la RFC. Mais c'est mieux que rien.

[Franck]

Le 12/09/2022 à 10:04, M.V. a écrit :

> Quand j'ai écrit :
> « J'envoie un article via pasdenom.info : il y a un CL (et un seul). »

> tu m'as répondu que ce n'était guère possible, qu'il y avait au moins 3
> CL ! J'en ai déduit qu'il y avait peut-être des CL invisibles aux yeux
> de l'usager.
> Je te cite :
> « On est arrivé à trois CL en deux paragraphes »
> Si je n'en vois qu'un, où sont les autres ?????

Je t'ai donné l'explication ailleurs (deux fois) mais comme tu es dur de
la feuille et que tu veux avoir raison, je te laisse à tes convictions :)

> Ça confirme que tu dis parfois n'importe quoi : j'ai plein de messages
> avec un CL et un seul et je peux t'en lister quelques uns si besoin est.

A quoi bon, puisque tu ne sait même pas pourquoi il n'y en a qu'un :)

>> C'est vraiment dommage car je dois t'avouer que tu as fait ma journée
>> avec ton CL invisible :-)
>

> Fort bien. Toi, tu ne me fais pas rire du tout.

C'est généralement le défaut des gens qui écrivent avec des phrases
toutes faites et piquantes et qui ne s'appuient sur rien pour étayer
leurs propos. Ils en arrivent à "tu me fais pas rire" car ils sont au
bout de leurs arguments.

Pow, ca va flamer ^^

[Julien ÉLIE]

Salut Stéphane,

> Et il me semble que tu avais écrit que sur la version 2.7, INN ne
> générera au mieux* qu'un CL-admin si l'utilisateur est anonymous.

Oui c'est ce que je prévoyais lors de la conception détaillée initiale,
mais j'ai au final aussi implémenté la possibilité de choisir d'utiliser
l'IP pour un groupe d'accès "anonyme" car je me doutais bien qu'il y
aurait de la demande :-)

https://www.eyrie.org/~eagle/software/inn/docs/readers.conf.html

"""
addcanlockuser:

If set to none, posts made by these users will not have a user-specific
hash in the Cancel-Lock header field (only the admin hash will be
generated). No Cancel-Key header field will be present in cancel or
supersede requests. This is a string value and the default is
"username", that is to say a user-specific hash based on the identity
assigned to the connection is used.

Another possible value to this parameter is "ip", in which case a
user-specific hash based on the IP of the connection is used (which
should be a static IP so as to actually identify users).

See inn-secrets.conf(5)
<https://www.eyrie.org/~eagle/software/inn/docs/inn-secrets.conf.html>
for more information about Cancel-Lock. The main reason for this
parameter is to deactivate this authentication mechanism when the same
identity or IP can be assigned by an access group to different people.
Otherwise, any of these people would be able to send an authenticated
withdrawal of an article originally sent by another person with the same
identity or IP.
"""


Avec quelques exemples, comme le fameux accès anonyme :

auth default {
hosts: *
default: <PUBLIC>
}

access default {
users: <PUBLIC>
newsgroups: example.*
addcanlockuser: none
}


Ou encore :

Here's an example of another common case: a server that only allows
connections from a local domain and has an additional hierarchy that's
password-restricted.

auth "example.com" {
hosts: "*.example.com"
auth: "ckpasswd -f <pathdb in inn.conf>/newsusers"
default: "anonymous"
}

access regular {
newsgroups: "*,!example.restricted.*"
addcanlockuser: none
}

access full {
users: "*,!anonymous"
newsgroups: *
}



Ce niveau de configuration offre pas mal de flexibilité :-)

> J'avais écrit à jdd sur son serveur sur un groupe interne qu'il y a 3
> solutions. Je viens d'en voir une quatrième : proposer à ceux qui le
> veulent de s'authentifier, c'est probablement possible dans readers.conf
> mais, je ne saurais dire comment...

Ah ben justement, l'exemple précédent correspond à ce cas d'usage (tu
mets un "auth" et un "default" (anonyme) dans le bloc d'authentification).

--
Julien ÉLIE

« La moitié des hommes politiques sont des bons à rien. Les autres sont
prêts à tout. » (Coluche)

[Franck]

Le 12/09/2022 à 15:43, Franck a écrit :

> (elle va pas changer et le serveur sait la retrouver).

J'irai même plus loin, -sans connaitre INN-, je suis persuadé que la
variable $user est stockée et qu'il n'y a même pas besoin de lire autre
chose que le MID dans les entêtes (et encore, c'est peut-être aussi
conservé ailleurs).

Mais là c'est une supposition, je ne connais pas INN pour m'avancer.

Personnellement, je conserve les deux en dehors de l'entête, ce qui fait
gagner un peu de temps en traitement puisque l'entête n'a pas a être
parcourue pour trouver l'information.

My2cents

[Julien ÉLIE]

Bonsoir Jean-Daniel,

> la RFC dit que s'il n'y a pas d'authentification *il ne doit pas y avoir

> de clé inscrite dans le message" (mais je ne retrouve pas où j'ai lu ça)

Le paragraphe que tu recherchais est celui-ci :

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.

Attention toutefois au fait que quand on parle de "positively
authenticate the poster", ce n'est pas nécessairement au sens
utilisateur/mot de passe (commande AUTHINFO).
Un utilisateur possédant 1 IP fixe, et étant le seul à l'utiliser, peut
aussi être considéré comme "authentifié".

Au même titre que tes feeds sont considérés comme "authentifiés" sans
pour autant avoir un compte sur ton serveur.


Donc non il ne faut pas générer de Cancel-Lock pour des connections qui
vraisemblablement peuvent être mutualisées. Autrement, c'est possible.
Et comme pour tout, c'est à l'administrateur qui paramètre son
readers.conf de décider si un groupe d'accès est "sûr" ou non.
("localhost" pourrait typiquement ne pas l'être si plusieurs personnes
ont un compte local sur la machine et utilisent inews ou autre)

--
Julien ÉLIE

« Encore un peu, et cette histoire finira en queue de poisson ! »
(Astérix)

[Franck]

Le 12/09/2022 à 19:02, Julien ÉLIE a écrit :

Salut Julien,

Merci pour ta réponse très claire et détaillée.

> """
> addcanlockuser:
>
> If set to none, posts made by these users will not have a user-specific
> hash in the Cancel-Lock header field (only the admin hash will be
> generated).  No Cancel-Key header field will be present in cancel or
> supersede requests.  This is a string value and the default is
> "username", that is to say a user-specific hash based on the identity
> assigned to the connection is used.

C'est ce qui est actuellement actif sur mon serveur car je me suis basé
strictement sur la RFC qui indique une identification formelle.

> Another possible value to this parameter is "ip", in which case a
> user-specific hash based on the IP of the connection is used (which
> should be a static IP so as to actually identify users).

On en a déjà discuté et j'ai déjà prévu cette possibilité car elle offre
un peu plus de sécurité que "none" (!).

> Ce niveau de configuration offre pas mal de flexibilité :-)

Effectivement et bien plus que ce qui est en vigueur sur mon serveur car
je ne gère pas les accès de la même manière.

Franck

[Julien ÉLIE]

Salut Franck,

Je vois que tu passes des vacances connectées :-)

>> Ce niveau de configuration offre pas mal de flexibilité :-)
>
> Effectivement et bien plus que ce qui est en vigueur sur mon serveur car
> je ne gère pas les accès de la même manière.

readers.conf est assurément très flexible mais hautement complexe à
prendre en main !
Spitfire est bien plus user-friendly :-)

--
Julien ÉLIE

« – Qui ? Encore des planqués ?
– Non ! des Gaulois !
– Alors planquons-nous !!! » (Astérix)

[Franck]

Le 12/09/2022 à 19:17, Julien ÉLIE a écrit :

Bonsoir Julien,

> Attention toutefois au fait que quand on parle de "positively
> authenticate the poster", ce n'est pas nécessairement au sens
> utilisateur/mot de passe (commande AUTHINFO).
> Un utilisateur possédant 1 IP fixe, et étant le seul à l'utiliser, peut
> aussi être considéré comme "authentifié".

Je suis tout à fait d'accord avec toi, mais il me semble que pour en
être certain, il faudrait que le serveur puisse affirmer seul ces deux
conditions, ce qui me semble difficilement réalisable.

Je pense, qu'au mieux, le serveur peut "envisager" mais pas "affirmer",
sauf à ce qu'il se soit réellement identifié avec AUTHINFO. Non?

> Au même titre que tes feeds sont considérés comme "authentifiés" sans
> pour autant avoir un compte sur ton serveur.

C'est également vrai pour une IP fixe, mais si mes souvenirs sont bons,
dans le cas d'un feed qui ne dispose pas d'une IP fixe, il faut
configurer le feed avec un mot de passe (avec n'importe quel nom
d'utilisateur, ce qui avait d'ailleurs motivé un ajout dans ta doc).
Sans ce préalable INN n'est pas en mesure de l'identifier formellement. Non?

> Et comme pour tout, c'est à l'administrateur qui paramètre son
> readers.conf de décider si un groupe d'accès est "sûr" ou non.

Décider ou envisager? :-)

> ("localhost" pourrait typiquement ne pas l'être si plusieurs personnes
> ont un compte local sur la machine et utilisent inews ou autre)

Exact!
Tout comme une IP fixe peut être utilisée par plusieurs personnes
derrière un VPN ou un routeur NAT, raison pour laquelle je pense qu'un
serveur ne peut pas être affirmatif et simplement envisager que le
groupe est sûr.

Sauf à ce que l'utilisateur s'identifie formellement.


Très bonne soirée,
Franck

[Franck]

Le 12/09/2022 à 19:57, Julien ÉLIE a écrit :
> Salut Franck,
>
> Je vois que tu passes des vacances connectées :-)

C'est la faute au temps!

> readers.conf est assurément très flexible mais hautement complexe à
> prendre en main !
> Spitfire est bien plus user-friendly :-)

C'est la faute à l'interface graphique :-)

[Julien ÉLIE]

Bonsoir Franck,

>> Attention toutefois au fait que quand on parle de "positively
>> authenticate the poster", ce n'est pas nécessairement au sens
>> utilisateur/mot de passe (commande AUTHINFO).
>> Un utilisateur possédant 1 IP fixe, et étant le seul à l'utiliser,
>> peut aussi être considéré comme "authentifié".
>
> Je suis tout à fait d'accord avec toi, mais il me semble que pour en
> être certain, il faudrait que le serveur puisse affirmer seul ces deux
> conditions, ce qui me semble difficilement réalisable.

Le serveur ne peut clairement pas le savoir, effectivement.
L'administrateur est le plus sachant, et configure son serveur en
conséquence. Libre à lui de s'affranchir du respect strict des RFCs. Il
le fait en toute connaissance de cause (au même titre qu'à travers les
filtres Perl, un administrateur peut utiliser la syntaxe qu'il souhaite,
pas forcément conforme, dans tous les en-têtes des messages injectés).

> Je pense, qu'au mieux, le serveur peut "envisager" mais pas "affirmer",
> sauf à ce qu'il se soit réellement identifié avec AUTHINFO. Non ?

Le serveur n'envisage ni n'affirme, il applique la configuration demandée.

Et si l'on veut aller plus loin, on pourrait considérer comme réellement
authentifiés que les utilisateurs avec des mots de passe d'un certain
niveau de complexité :-)
Si l'utilisateur "toto" a aussi "toto" comme mot de passe, il pourrait
être légitime de débrayer le mécanisme de Cancel-Lock ^^ bien que non
précisé par la RFC :-)

> dans le cas d'un feed qui ne dispose pas d'une IP fixe, il faut
> configurer le feed avec un mot de passe (avec n'importe quel nom
> d'utilisateur, ce qui avait d'ailleurs motivé un ajout dans ta doc).
> Sans ce préalable INN n'est pas en mesure de l'identifier formellement.
> Non?

Oui, c'est bien cela. Et dans ce cas de configuration où toutes les
connexions entrantes arrivent en mode transit, les lecteurs devront
envoyer un MODE READER, et le pair sans IP fixe devra s'authentifier
avec AUTHINFO.

Une telle configuration pourrait d'ailleurs utiliser avec profit le port
119 pour les lecteurs et le port 433 pour les feeds, ça me semble plus
propre. (Le feed sans IP fixe devra toujours bien s'authentifier.)

>> Et comme pour tout, c'est à l'administrateur qui paramètre son
>> readers.conf de décider si un groupe d'accès est "sûr" ou non.
>
> Décider ou envisager? :-)

Je dirai que l'administrateur estime que le groupe est sûr, et décide de
le paramétrer ainsi.

> Tout comme une IP fixe peut être utilisée par plusieurs personnes
> derrière un VPN ou un routeur NAT, raison pour laquelle je pense qu'un
> serveur ne peut pas être affirmatif et simplement envisager que le
> groupe est sûr.
>
> Sauf à ce que l'utilisateur s'identifie formellement.

Je suis d'accord avec toi, le serveur ne peut lui-même être affirmatif
sur le sujet... et le groupe n'est pas forcément sûr même si tous les
utilisateurs s'identifient formellement ^^
Ils pourraient tous avoir le même mot de passe "mot2passe" :-)

--
Julien ÉLIE

« – Connaissez-vous la différence entre l'ignorance et l'apathie ?
– J'en sais rien et je m'en fous. »

[Franck]

Le 12/09/2022 à 20:50, Julien ÉLIE a écrit :

Salut Julien,

> Le serveur ne peut clairement pas le savoir, effectivement.
> L'administrateur est le plus sachant, et configure son serveur en
> conséquence. Libre à lui de s'affranchir du respect strict des RFCs. Il
> le fait en toute connaissance de cause (au même titre qu'à travers les
> filtres Perl, un administrateur peut utiliser la syntaxe qu'il souhaite,
> pas forcément conforme, dans tous les en-têtes des messages injectés).

C'est une excellente explication de "l'administrateur", jdd si tu nous
lis...

> Le serveur n'envisage ni n'affirme, il applique la configuration demandée.

On est d'accord.

> Et si l'on veut aller plus loin, on pourrait considérer comme réellement
> authentifiés que les utilisateurs avec des mots de passe d'un certain
> niveau de complexité :-)
> Si l'utilisateur "toto" a aussi "toto" comme mot de passe, il pourrait
> être légitime de débrayer le mécanisme de Cancel-Lock ^^ bien que non
> précisé par la RFC :-)

P**** Julien, tu me connais, çà va rajouter plein d'options inutiles
dans mon code!!! Arrête de me filer de mauvaises idées alors que tu m'as
sagement conseillé de faire le ménage dans mes nombreux cas qui ne se
produiront peut-être jamais ^^

> Oui, c'est bien cela. Et dans ce cas de configuration où toutes les
> connexions entrantes arrivent en mode transit, les lecteurs devront
> envoyer un MODE READER, et le pair sans IP fixe devra s'authentifier
> avec AUTHINFO.

C'est bon ça, cela veut dire que je ne perds pas complètement la tête :)

> Une telle configuration pourrait d'ailleurs utiliser avec profit le port
> 119 pour les lecteurs et le port 433 pour les feeds, ça me semble plus
> propre. (Le feed sans IP fixe devra toujours bien s'authentifier.)

Çà, je l'ai supprimé lorsque tu m'as conseillé de ne pas implémenter la
commutation de modes. C'est passé à la trappe sans le vouloir ;-(

>> Décider ou envisager? :-)
>
> Je dirai que l'administrateur estime que le groupe est sûr, et décide de
> le paramétrer ainsi.

Çà me va, tant qu'il l'affirme pas :-)

> Je suis d'accord avec toi, le serveur ne peut lui-même être affirmatif
> sur le sujet... et le groupe n'est pas forcément sûr même si tous les
> utilisateurs s'identifient formellement ^^
> Ils pourraient tous avoir le même mot de passe "mot2passe" :-)

Et allez, tu insistes pour que je rajoute une condition! :-)

On peut d'ailleurs considérer que ce cas de figure existe déjà dans le
cas où un serveur est configuré pour identifier les utilisateurs
uniquement avec AUTHINFO USER (Et sans AUTHINFO PASS).

Ils ont tous le même mot de passe, vierge :)

Très bonne soirée,
Franck

[jdd]

Le 12/09/2022 à 16:35, M.V. a écrit :

mais on ne sait ps à qui il répond (on le devine)

> Je note que le serveur dodin.fr.nf ne procède à aucune authentification
> du message et que, de ce fait, n'importe qui peut annuler comme il veut
> sur son serveur

pas du tout. j'ai même un message dans dodin.test que personne n'a
réussi à annuler (ça ne va peut-être pas durer)

[Franck]

Le 12/09/2022 à 20:50, Julien ÉLIE a écrit :

> Et si l'on veut aller plus loin, on pourrait considérer comme réellement
> authentifiés que les utilisateurs avec des mots de passe d'un certain
> niveau de complexité :-)
> Si l'utilisateur "toto" a aussi "toto" comme mot de passe, il pourrait
> être légitime de débrayer le mécanisme de Cancel-Lock ^^ bien que non
> précisé par la RFC :-)

En fait, en y réfléchissant mieux, indirectement je devrais pouvoir
restreindre ces cas avec le module Web que j'envisage, puisque le
formulaire de création de compte effectuera ces vérifications et sera
protégé par un captcha, voire une double authentification.

Après, je ne dis pas que je publierai ce module Web et que je ne le
réserverai pas que pour mon usage personnel. Je verrai en temps voulu.

Franck

[jdd]

Le 12/09/2022 à 21:36, Franck a écrit :
> Le 12/09/2022 à 20:50, Julien ÉLIE a écrit :
>
> Salut Julien,
>
>> Le serveur ne peut clairement pas le savoir, effectivement.
>> L'administrateur est le plus sachant, et configure son serveur en
>> conséquence. Libre à lui de s'affranchir du respect strict des RFCs. Il
>> le fait en toute connaissance de cause (au même titre qu'à travers les
>> filtres Perl, un administrateur peut utiliser la syntaxe qu'il souhaite,
>> pas forcément conforme, dans tous les en-têtes des messages injectés).
>
> C'est une excellente explication de "l'administrateur", jdd si tu nous
> lis...

je vous lis, avec intérêt.

je voudrais quand même ajouter un bémol: nous ne gérons pas (en tout cas
moi) un serveur telegram crypté pour les services secrets. Un *certain*
niveau d'authentification est donc utile, mais point trop n'en faut.

du coup, si quelques annulations parasites existent parfois, ce n'est
pas très grave.

par exemple, actuellement j'ai un peu de mal à lire les messages de MV
car il m'a demandé de ne pas les répercuter sur mon serveur, et s'il ne
supprime pas son code je ne les lis pas.

et bien je vis très bien sans ça :-)

merci, c'est chouette d'avoir des gens à la fois compétents et
pédagogues :-))

[Franck]

Le 12/09/2022 à 16:35, M.V. a écrit :

> Ceci est ma dernière réponse. Je te plonke.
> Bonne continuation, mon ami.

Merde, j'ai perdu un ami.
Quelle désolation, ce coup-ci mon monde vient de s'écrouler pour de bon.