Cancel locks?

Cancel locks?

[Per Abrahamsen]

At one point, there was some talk about making Gnus use cancel locks
per default.  Did anything came from that?

Re: Cancel locks?

[Simon Josefsson]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> At one point, there was some talk about making Gnus use cancel locks
> per default.  Did anything came from that?

There is contrib/canlock.el.  Didn't the canlock draft expire?

Re: Cancel locks?

[Per Abrahamsen]

Simon Josefsson <jas@extundo.com> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>
>> At one point, there was some talk about making Gnus use cancel locks
>> per default.  Did anything came from that?
>
> There is contrib/canlock.el.  Didn't the canlock draft expire?

I believe so, but it should nonetheless be useful for Gnus even if
nobody else supports them[1], and it might encourage others to support it
if something visible (like Gnus) out here actually make active use of
them.

They have been discussed on USEFOR recently, with no real resolution.

Footnotes: 
[1]  I remember the suggestion was that to use cancel locks to
determine whether the user would be allowed to cancel a message, thus
solving the problem with people posting from different mail addresses
(gnus-posting-styles) that made it necessary to generate a Sender
header. 

Re: Cancel locks?

[Simon Josefsson]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Simon Josefsson <jas@extundo.com> writes:
> 
>> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>>
>>> At one point, there was some talk about making Gnus use cancel locks
>>> per default.  Did anything came from that?
>>
>> There is contrib/canlock.el.  Didn't the canlock draft expire?
> 
> I believe so, but it should nonetheless be useful for Gnus even if
> nobody else supports them[1], and it might encourage others to support it
> if something visible (like Gnus) out here actually make active use of
> them.

Hm, does anyone know how good the canlock.el <-> Gnus integration is?
Does everything "just work" if we load the library?  Since there isn't
any documentation, anything more than loading the library is non-obvious.

Re: Cancel locks?

[Jesper Harder]

jas@extundo.com (Simon Josefsson) writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>
>> I believe so, but it should nonetheless be useful for Gnus even if
>> nobody else supports them[1], and it might encourage others to support it
>> if something visible (like Gnus) out here actually make active use of
>> them.
>
> Hm, does anyone know how good the canlock.el <-> Gnus integration is?
> Does everything "just work" if we load the library?  Since there isn't
> any documentation, anything more than loading the library is
> non-obvious.

I have been using it for some time without problems. To generate the
header all you need is something like:

   (add-hook 'message-header-hook 'canlock-insert-header)
   (setq canlock-password "hemmeligt")
   (require 'canlock)

To use it when actually cancelling I had to modify message-cancel-news a
little bit, i.e. replace the current checking with:

   (if (canlock-verify) (error "This article is not yours"))

Re: Cancel locks?

[Per Abrahamsen]

Jesper Harder <harder@ifa.au.dk> writes:

>    (setq canlock-password "hemmeligt")

We would either need to generate the password automatically (and in a
not too easily predictable way), or alternatively prompt the user for
a password first time he post.  And if we prompt, we need a really
good formulation.

Re: Cancel locks?

[Simon Josefsson]

On Wed, 17 Oct 2001, Per Abrahamsen wrote:

> Jesper Harder <harder@ifa.au.dk> writes:
>
> >    (setq canlock-password "hemmeligt")
>
> We would either need to generate the password automatically (and in a
> not too easily predictable way), or alternatively prompt the user for
> a password first time he post.  And if we prompt, we need a really
> good formulation.

Customize auto-save it, initialized to something random [1]? But the user
should then be informed about keeping .emacs read-protected in multi-user
environments. Which is a can of worms that shouldn't be opened.  Sigh.

[1] There isn't a good PRNG available in elisp... Hm.  Maybe a random
number library would be nice.

Re: Cancel locks?

[Per Abrahamsen]

Simon Josefsson <jas@extundo.com> writes:

> Customize auto-save it, initialized to something random [1]? But the user
> should then be informed about keeping .emacs read-protected in multi-user
> environments. Which is a can of worms that shouldn't be opened.  Sigh.

If it is auto-generated, keeping .emacs read only is not really that
important, as there currently are no real security with cancels.
Anyone can cancel messages from anybody.  If servers start honoring
cancel locks, it become more important, as keeping the password secret
will then buy you some extra security.

If it is given by the user, the danger is larger, as he might use the
same password for something important.

> [1] There isn't a good PRNG available in elisp... Hm.  Maybe a random
> number library would be nice.

Mostly we need some random data.  Probably the time and pid is enough
for this low impact use, in particular if the password is generated
when the user start Gnus the first time, and not when he post the
first time (in which case the time will be visible to an attacker in
the Date header).

Re: Cancel locks?

[Henrik Enberg]

Simon Josefsson <jas@extundo.com> writes:

> On Wed, 17 Oct 2001, Per Abrahamsen wrote:
> 
>> Jesper Harder <harder@ifa.au.dk> writes:
>>
>> >    (setq canlock-password "hemmeligt")
>>
>> We would either need to generate the password automatically (and in a
>> not too easily predictable way), or alternatively prompt the user for
>> a password first time he post.  And if we prompt, we need a really
>> good formulation.
> 
> Customize auto-save it, initialized to something random [1]? But the user
> should then be informed about keeping .emacs read-protected in multi-user
> environments. Which is a can of worms that shouldn't be opened.  Sigh.
> 
> [1] There isn't a good PRNG available in elisp... Hm.  Maybe a random
> number library would be nice.

make-password.el by Jim Blandy lets you hit the spacebar an ungodly
number of times to generate the random seed.  Maybe this idea could be
stolen?

Henrik
-- 
..  bleakness....  desolation....  plastic forks...

Re: Cancel locks?

[Per Abrahamsen]

Jesper Harder <harder@ifa.au.dk> writes:

> To use it when actually cancelling I had to modify message-cancel-news a
> little bit, i.e. replace the current checking with:
>
>    (if (canlock-verify) (error "This article is not yours"))

We probably should use a heuristic like

IF article has cancel-lock THEN
   IF we can load canlock THEN
      IF we can verify it THEN
         issue cancel
      ELSE
         error: cancellock: article is not yours
   ELSE
      error: message is cancel locked
ELSE
   Use old rules, comparing sender...

It would work whether or not we have "canlock.el".

Re: Cancel locks?

[Simon Josefsson]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> We probably should use a heuristic like
> 
> IF article has cancel-lock THEN
>    IF we can load canlock THEN
>       IF we can verify it THEN
>          issue cancel
>       ELSE
>          error: cancellock: article is not yours
>    ELSE
>       error: message is cancel locked
> ELSE
>    Use old rules, comparing sender...
> 
> It would work whether or not we have "canlock.el".

Should be added to Oort now.

Re: Cancel locks?

[Simon Josefsson]

Simon Josefsson <jas@extundo.com> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
>> We probably should use a heuristic like
>> 
>> IF article has cancel-lock THEN
>>    IF we can load canlock THEN
>>       IF we can verify it THEN
>>          issue cancel
>>       ELSE
>>          error: cancellock: article is not yours
>>    ELSE
>>       error: message is cancel locked
>> ELSE
>>    Use old rules, comparing sender...
>> 
>> It would work whether or not we have "canlock.el".
> 
> Should be added to Oort now.

Hm, how does cancel locks interact with supersedes?  Should the above
logic apply to supersedes as well?

(Maybe it is explained in the expired draft...  Does anyone have a
copy of it?)

Re: Cancel locks?

[Per Abrahamsen]

Simon Josefsson <jas@extundo.com> writes:

> (Maybe it is explained in the expired draft...  Does anyone have a
> copy of it?)

<URL: http://www.landfield.com/usefor/ >

Look under "previous usefor internet-drafts".

Re: Cancel locks?

[Per Abrahamsen]

Simon Josefsson <jas@extundo.com> writes:

> Should be added to Oort now.

Cool!

Re: Cancel locks?

[ShengHuo ZHU]

Simon Josefsson <jas@extundo.com> writes:

[...]

> Hm, does anyone know how good the canlock.el <-> Gnus integration is?
> Does everything "just work" if we load the library?  Since there isn't
> any documentation, anything more than loading the library is non-obvious.

sha1.el, which is in the contrib directory, is required.  Other
required libraries are obvious to Gnus.

My setting is

      (require 'canlock)
      (setq canlock-password "XXXXXXXXX")
      (add-hook 'message-header-hook 'canlock-insert-header t)

But I never tested the cancel function.

See also http://www.tamaru.kuee.kyoto-u.ac.jp/~kokada/wl/src/emacs-canlock

ShengHuo

Re: Cancel locks?

[Per Abrahamsen]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> sha1.el, which is in the contrib directory, is required.  

Neither seem to be assigned to FSF, which mean Gnus cannot depend on
them.  Too bad.  They are only really useful, if they can be on by
default. 

Re: Cancel locks?

[Simon Josefsson]

On Wed, 17 Oct 2001, Per Abrahamsen wrote:

> ShengHuo ZHU <zsh@cs.rochester.edu> writes:
>
> > sha1.el, which is in the contrib directory, is required.
>
> Neither seem to be assigned to FSF, which mean Gnus cannot depend on
> them.  Too bad.  They are only really useful, if they can be on by
> default.

Exactly.  I thought about re-implementing it but as the draft expired
several years ago, I assumed noone cared about deploying the idea.

sha1.el isn't a problem, I think I have more than tree different
implementations of it in Elisp and at least one is Copyright by FSF (the
one that is part of FLIM).  I doubt cancel locks have been implemented as
frequently though.

I committed a FSF-copyrighted SHA1 implementation to gnus/contrib/ and
updated canlock.el to make use of it.  I didn't test it too much though,
does it work?