[Grok-dev] grokproject status

[Uli Fouquet]

Hi there,

First, many thanks to all the people that have done so much good work on
grok recently!

Jan-Wijbrand Kolman wrote:
> Martijn Faassen <faassen at startifact.com> wrote:
[snip]

> >> * The buildout.cfg file of a newly created project includes a [zpasswd] 
> >> section. It will create a cmdline tool based on code in zope.app.server to 
> >>> easily create 
> >> a zcml snippet for a new principal definition (including an correctly hashed 
> >> password). I do not like pulling in zope.app.server just for this feature - I 
> >> think it is nog used otherwise. So either we rip out this "feature" (is it 
> >> used by anyone?) or we re-create the script somehow - but where?
> > 
> > How does grokproject itself create the initial password? If it doesn't 
> > use zope.app.server, shouldn't the script we generate be able to use the 
> > same method?

Generating the password is not difficult. We already have a utility
function that cares for that, although, as JW correctly points out, it
would be nice to have secure SHA1 passwords.

The main point with the zope.app.server stuff is, that it defines a
complete commandline tool including options and all that in zpasswd. It
also looks up available password managers and such. It's more than just
creating a little string and pasting it somewhere. This tool, however,
might be better placed in zope.password, I think. That's at least, where
I would look for such a utility function first.

The zpasswd tool internally only needs zope.component,
zope.configuration and zope.password IIRC (also z.a.applicationcontrol,
but that could be ditched). Could moving the zpassword stuff to
zope.password help with our dependecy reduction project?

> Grokproject will interpolate a SHA1 encoded password itself in the site.zcml.in 
> template. For that it uses a function in the utils.py module in grokproject.
> 
> I now remember a third todo item left: I want to use the SSHA1 encoding for 
> passwords by default. Zope's SHA1 encoding apparently is somewhat sub-optimal 
> and the SSHA1 implementation fixes that.

Yeah, the salt is not used correctly in SHA1 password manager (opposed
to SSHA1 password manager). That should be fixed ASAP. I'd be happy to
help.

Right now we create faulty (hm, 'not-too-strong'-encoded) SHA1 passwords
in grokproject because as the time of writing it, 'standard' grok
installs didn't provide the SSHA1 password manager. In fact the SSHA1
manager came into life as a result of examining password generation in
grokproject :-)

Nowadays we have this manager available. As we're considering also other
compatibility breaks with older grok installs, I think right now would
be a good point in time to switch to SSHA1 completely.

So, what about:

- moving zpasswd from zope.app.server to zope.password

- using SSHA1 by default everywhere, especially in grokproject?

As an alternative, we could also copy over the zpasswd bits over from
z.a.server to grokproject.

What do you think?

Best regards, 

-- 
Uli

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20100429/1782d23b/attachment.bin