Re: usage de cancel-clock

jdd <jdd@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.