cancel locks

cancel locks

[Simon Josefsson]

Cancel locks is part of Gnus now, so maybe it should be integrated
better.  How/when should the cancel lock password be
initialized/generated?  Maybe a popup question similar to when you try
to use C-x n n the first time?  It could appear when you try to post
an article the first time?  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.)

On the other hand, as cancel locks isn't something that is commonly
supported out there, maybe Gnus shouldn't worry about it by default?
On the third hand, if this stuff just happens in the background, the
user probably wouldn't care, and it might be nice to have cancel locks
in all Gnus posts.

Re: cancel locks

[Bjørn Mork]

Simon Josefsson <jas@extundo.com> writes:

> On the other hand, as cancel locks isn't something that is commonly
> supported out there, maybe Gnus shouldn't worry about it by default?
> On the third hand, if this stuff just happens in the background, the
> user probably wouldn't care, and it might be nice to have cancel locks
> in all Gnus posts.

Yes, it's very practical to finally be able to cancel articles from
Gnus without having to use some bogus sender-header. But since
cancel-locks won't give you much protection anyway, maybe the default
password could be something really simple? Would it hurt to just use
the username@systemname as password? Yes anyone can fake it, but
anyone can cancel your articles whether they know the password or not, 
so it doesn't really matter. 


Bjørn
-- 
You sound like a real wally.  

Re: cancel locks

[Simon Josefsson]

"BjXrn Mork" <bmork@dod.no> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> On the other hand, as cancel locks isn't something that is commonly
>> supported out there, maybe Gnus shouldn't worry about it by default?
>> On the third hand, if this stuff just happens in the background, the
>> user probably wouldn't care, and it might be nice to have cancel locks
>> in all Gnus posts.
>
> Yes, it's very practical to finally be able to cancel articles from
> Gnus without having to use some bogus sender-header. But since
> cancel-locks won't give you much protection anyway, maybe the default
> password could be something really simple? Would it hurt to just use
> the username@systemname as password? Yes anyone can fake it, but
> anyone can cancel your articles whether they know the password or not, 
> so it doesn't really matter. 

For cancel locks to serve any purpose, doesn't the password need to be
non-guessable?  I agree there aren't any servers out there today that
requires cancel locks, but if clients start to support it, maybe they
change.  If we use non-guessable passwords with cancel locks, articles
canceled with Gnus can be proven to probably belong to the originator.

Hm.  Of course, cancel locks serves the purpose of telling the client
(Gnus) whether the articles was written by the user, without using
From/Sender.  Is that all we want from it?  But using
username@systemname would have the same problem than
From/Sender. Something else unique would be needed.
SHA1(gnus-command-method)?  Then every articles is locked to the Gnus
method used to post it, something that probably rarely change and
still is sort of unique.

Re: cancel locks

[Robin S. Socha]

* Simon Josefsson <jas@extundo.com> writes:

> For cancel locks to serve any purpose, doesn't the password need to be
> non-guessable?  

Duh.

> I agree there aren't any servers out there today that requires cancel
> locks, 

If you tell me how, news://my.gnus.org/gnu.emacs.gnus will require
them. I presume so would news://gnus.org/. So there.

> but if clients start to support it, maybe they change.  

Why should they? It's a server thing. Like, period and stuff.

Re: cancel locks

[Per Abrahamsen]

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.

Re: cancel locks

[Florian Weimer]

Simon Josefsson <jas@extundo.com> writes:

> For cancel locks to serve any purpose, doesn't the password need to be
> non-guessable?

Yes, the posting agent should create some random "password" and use
it.  It doesn't need to be presented to the user at all.

Re: cancel locks

[Florian Weimer]

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

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

I'm sorry, but it's rather straightforward to guess a password
generated by 'message-unique-id'.

Re: cancel locks

[Per Abrahamsen]

Florian Weimer <fw@deneb.enyo.de> writes:

> I'm sorry, but it's rather straightforward to guess a password
> generated by 'message-unique-id'.

Yes, but you need to read and understand the code in message to do so,
and you need google to track down the users first message to get the
necessary information (from the data and message-id headers).  That is
a lot more work than faking a cancel of an unlocked message.

If someone later wants to contribute a better password generator, it
can be installed with no problem.  

Re: cancel locks

[Matt Armstrong]

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

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> I'm sorry, but it's rather straightforward to guess a password
>> generated by 'message-unique-id'.
>
> Yes, but you need to read and understand the code in message to do
> so, and you need google to track down the users first message to get
> the necessary information (from the data and message-id headers).
> That is a lot more work than faking a cancel of an unlocked message.
>
> If someone later wants to contribute a better password generator, it
> can be installed with no problem.

Here is my contribution:

(defun gnus-random-cancel-lock-password ()
  (random t)
  (format "%x%x" (random) (random)))

:-)
  
-- 
matt

Re: cancel locks

[Per Abrahamsen]

"Matt Armstrong" <matt+dated+1007224448.7bca4c@lickey.com> writes:

> (defun gnus-random-cancel-lock-password ()
>   (random t)
>   (format "%x%x" (random) (random)))

Yes, that is much better.  Not that it matters.

Re: cancel locks

[Simon Josefsson]

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

>>> If someone later wants to contribute a better password generator, it
>>> can be installed with no problem.
>>
>> Here is my contribution:
>>
>> (defun gnus-random-cancel-lock-password ()
>>   (random t)
>>   (format "%x%x" (random) (random)))
>
> Here's another one:
>
>        (md5 (prin1-to-string (recent-keys)))

Canlock should be inserted in news by default now -- customize
`message-insert-canlock' if you want to disable it.  We need some
documentation though, preferably in the "Canceling and Superseding"
node.

The initial password is generated with the following, better ideas
welcome.

(defun message-canlock-generate ()
  "Return a string that is non-trival to guess.
Do not use this for anything important, it is cryptographically weak."
  (md5 (concat (message-unique-id)
	       (format "%x%x%x" (random) (random t) (random))
	       (prin1-to-string (recent-keys))
	       (prin1-to-string (garbage-collect)))))

Re: cancel locks

[Jesper Harder]

matt+dated+1007224448.7bca4c@lickey.com ("Matt Armstrong") writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>
>> If someone later wants to contribute a better password generator, it
>> can be installed with no problem.
>
> Here is my contribution:
>
> (defun gnus-random-cancel-lock-password ()
>   (random t)
>   (format "%x%x" (random) (random)))

Here's another one:

       (md5 (prin1-to-string (recent-keys)))

Re: cancel locks

[Matt Armstrong]

Simon Josefsson <jas@extundo.com> writes:

> (defun message-canlock-generate ()
>   "Return a string that is non-trival to guess.
> Do not use this for anything important, it is cryptographically weak."
>   (md5 (concat (message-unique-id)
> 	       (format "%x%x%x" (random) (random t) (random))
> 	       (prin1-to-string (recent-keys))
> 	       (prin1-to-string (garbage-collect)))))

I think the garbage-collect could be taken out.  It introduces a
noticeable pause on my system (a 233 MHz machine) while not
introducing any appreciable randomness.

-- 
matt

Re: cancel locks

[Florian Weimer]

"Matt Armstrong" <matt+dated+1007232467.e033d9@lickey.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> (defun message-canlock-generate ()
>>   "Return a string that is non-trival to guess.
>> Do not use this for anything important, it is cryptographically weak."
>>   (md5 (concat (message-unique-id)
>> 	       (format "%x%x%x" (random) (random t) (random))
>> 	       (prin1-to-string (recent-keys))
>> 	       (prin1-to-string (garbage-collect)))))
>
> I think the garbage-collect could be taken out.  It introduces a
> noticeable pause on my system (a 233 MHz machine) while not
> introducing any appreciable randomness.

'message-canlock-generate' is called only once, I think, so this
shouldn't matter.

Re: cancel locks

[Florian Weimer]

Simon Josefsson <jas@extundo.com> writes:

> The initial password is generated with the following, better ideas
> welcome.
>
> (defun message-canlock-generate ()
>   "Return a string that is non-trival to guess.
> Do not use this for anything important, it is cryptographically weak."
>   (md5 (concat (message-unique-id)
> 	       (format "%x%x%x" (random) (random t) (random))
> 	       (prin1-to-string (recent-keys))
> 	       (prin1-to-string (garbage-collect)))))

You could hash in the buffer list, too.

It should be documented somewhere that sharing your .emacs file might
expose the canlock "password".