Re: cancel locks

[Per Abrahamsen <abraham@dina.kvl.dk>]

Simon Josefsson <jas@extundo.com> writes:

> Should Gnus really generate this password,
> as has been suggested previously? (If so, you're restricted to using
> only one installation of Gnus which has access to the same generated
> password.  And you can't lose the file.  No, the user should chose the
> password.)

I think Gnus should generate the password if it hasn't been set, and
store it with customize in plain text in "canlock-password".  

E.g. something like this:

(defun message-canlock-password ()
  "The password used by message for cancel locks.

This is the value of `canlock-password', if that option is non-nil.
Otherwise, generate and save a value for `canlock-password' first."
  (unless canlock-password
    (customize-save-variable 'canlock-password (message-unique-id)))
  canlock-password)

The user will be able to copy the password to another installation, or
set it to something else if he really cares.

Storing the password in plain text or using (message-unique-id) to
generate it (which will make it guessable by a determined cracker, but
still a lot more effort than faking an unlocked cancel) would have
been unacceptable to a high-value password, but should be fine for
something like cancel locks which really offer very little protection
in the first place, given that servers don't support it.

The main use of cancel locks will be for Gnus to have a reliable way
to tell whether something is send by the same user or not, and get rid
of the sender header.