Pidgin

On Oct 22, 2006, at 10:34 PM, Daniel Atallah wrote:

> On 10/22/06, Etan Reisner <deryni@...> wrote:
>> What authentication system do we want this to use? (This goes in hand
>> with the open registration bit, we (more or less) need to use the
>> internal database if we want open registration, but if we don't we  
>> can
>> have it look at just about anywhere else we want, ldap, mysql,  
>> pam, etc.
>> The ldap and mysql/obdc support is built in, for pam we'd have to  
>> use an
>> auth module I wrote at Rutgers.)
>
> While we're on the subject of authentication, we should talk about
> Trac authentication.
>
> In talking to Luke, he came up with the very reasonable requirement
> that users must be registered in order to file bugs and other tickets.

I'd like to recommend strongly the use of AccountManagerPlugin [1].   
It adds an automatic registration system (including password  
retrieval) and a way for users to associate their email with their  
username for notification purposes without it being publicly  
viewable.  Permissions can be set at a registered-user level by  
setting them for the user 'authenticated' from which all logged-in  
users inherit.

[1] http://trac-hacks.org/wiki/AccountManagerPlugin

-Evan

On 10/22/06, Etan Reisner <deryni@...> wrote:
> What features do we want enabled? (I'm assuming muc, but do we want
> pubsub, vcards, muc room logging, etc?)

vcards and MUC logging both sound good.

-s.

On 10/23/06, Evan Schoenberg <evan.s@...> wrote:
> I'd like to recommend strongly the use of AccountManagerPlugin [1].
> It adds an automatic registration system (including password
> retrieval) and a way for users to associate their email with their
> username for notification purposes without it being publicly
> viewable.  Permissions can be set at a registered-user level by
> setting them for the user 'authenticated' from which all logged-in
> users inherit.

I now have this set up up.  It seems to be pretty cool and will do
what we need it to.

Thanks, Evan.

On 10/23/06, Daniel Atallah <daniel.atallah@...> wrote:
> I now have this set up up.  It seems to be pretty cool and will do
> what we need it to.

I think we should have pidgin.im/trac just be developer.pidgin.im.

-s.

On Mon, Oct 23, 2006 at 06:10:05PM -0700, Sean Egan wrote:
> On 10/23/06, Daniel Atallah <daniel.atallah@...> wrote:
> > I now have this set up up.  It seems to be pretty cool and will do
> > what we need it to.
> 
> I think we should have pidgin.im/trac just be developer.pidgin.im.
> 
> -s.

This makes sense to me.

luke

On 10/23/06, Luke Schierer <lschiere@...> wrote:
> On Mon, Oct 23, 2006 at 06:10:05PM -0700, Sean Egan wrote:
> > I think we should have pidgin.im/trac just be developer.pidgin.im.
>
> This makes sense to me.

Done.  Trac is now at http://developer.pidgin.im

On 10/23/06, Daniel Atallah <daniel.atallah@...> wrote:
> Done.  Trac is now at http://developer.pidgin.im

Alright, who's the wise guy who edited the wiki with such slander?!

Also, how do I get an account to edit it back?

-s.

On 10/24/06, Sean Egan <seanegan@...> wrote:
> Alright, who's the wise guy who edited the wiki with such slander?!

Survey says... me :)
http://developer.pidgin.im/wiki/WikiStart?action=diff&version=3

> Also, how do I get an account to edit it back?

If you register an account in trac, Luke, Nathan or I can give you privileges.

-D

Daniel Atallah spake unto us the following wisdom:
> On 10/24/06, Sean Egan <seanegan@...> wrote:
> > Alright, who's the wise guy who edited the wiki with such slander?!
>=20
> Survey says... me :)
> http://developer.pidgin.im/wiki/WikiStart?action=3Ddiff&version=3D3
>=20
> > Also, how do I get an account to edit it back?
>=20
> If you register an account in trac, Luke, Nathan or I can give you
> privileges.

How are the trac passwords stored?  Are we going to put the login form
behind SSL?  (That is, do I need to make up Yet Another throwaway
password for this thing?)

Ethan

--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764

On 10/24/06, Ethan Blanton <elb@...> wrote:
> How are the trac passwords stored?  Are we going to put the login form
> behind SSL?  (That is, do I need to make up Yet Another throwaway
> password for this thing?)

An excellent question.

The password is hashed and the hash stored it in a htdigest2 compatible file.

I'm assuming that we will be using SSL when we get the cert, but
currently the password is submitted in plain-text over HTTP.

Someone motivated could probably without much difficulty update the
AccountManagerPlugin to be capable to hash the password in javascript
and send the hash - that would be neat.

-D

Daniel Atallah spake unto us the following wisdom:
> An excellent question.
>=20
> The password is hashed and the hash stored it in a htdigest2 compatible f=
ile.

Hashed with a real hash, and as such safe on disk?

> I'm assuming that we will be using SSL when we get the cert, but
> currently the password is submitted in plain-text over HTTP.

Can trac be made to use SSL only for logins/etc., and non-SSL for
everything else?  I assume we don't want SSL for the entire tracker
and wiki.  If this is the case, can we get a self-signed certificate
installed temporarily?

> Someone motivated could probably without much difficulty update the
> AccountManagerPlugin to be capable to hash the password in javascript
> and send the hash - that would be neat.

That hash would be plaintext-equivalent, though, so while it wouldn't
disclose the password you typed in, it wouldn't fix anything about
plaintext login.

Ethan

--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764

On 10/24/06, Ethan Blanton <elb@...> wrote:
> Daniel Atallah spake unto us the following wisdom:
> > The password is hashed and the hash stored it in a htdigest2 compatible file.
>
> Hashed with a real hash, and as such safe on disk?

I guess I didn't honestly know the answer to that - so I looked.
It is a MD5 hash, of username:realm:password.
Source: http://svn.apache.org/viewvc/httpd/httpd/branches/2.0.x/support/htdigest.c?revision=421178&view=markup

> Can trac be made to use SSL only for logins/etc., and non-SSL for
> everything else?  I assume we don't want SSL for the entire tracker
> and wiki.  If this is the case, can we get a self-signed certificate
> installed temporarily?

I'm assuming that we can use SSL just for auth - I'll have to try it.
I'll get back to y'all about this.

>
> > Someone motivated could probably without much difficulty update the
> > AccountManagerPlugin to be capable to hash the password in javascript
> > and send the hash - that would be neat.
>
> That hash would be plaintext-equivalent, though, so while it wouldn't
> disclose the password you typed in, it wouldn't fix anything about
> plaintext login.

Sure, I was thinking more from a perspective of having to use a
throwaway password.  A real digest based auth with a nonce word and
stuff would be a lot more work.

-D

Daniel Atallah wrote:
> On 10/24/06, Ethan Blanton <elb@...> wrote:
>> How are the trac passwords stored?  Are we going to put the login form
>> behind SSL?  (That is, do I need to make up Yet Another throwaway
>> password for this thing?)
> 
> An excellent question.
> 
> The password is hashed and the hash stored it in a htdigest2 compatible file.
> 
> I'm assuming that we will be using SSL when we get the cert, but
> currently the password is submitted in plain-text over HTTP.
> 
> Someone motivated could probably without much difficulty update the
> AccountManagerPlugin to be capable to hash the password in javascript
> and send the hash - that would be neat.
> 
> -D

Why not use digest or digest-md5 instead of basic?

-- 
Gary Kramlich <grim@...>

On 10/24/06, Gary Kramlich <grim@...> wrote:
> Why not use digest or digest-md5 instead of basic?

We're using the Trac AccountManager plugin, not HTTP Authentication.

-D

Gary Kramlich spake unto us the following wisdom:
> Daniel Atallah wrote:
> > On 10/24/06, Ethan Blanton <elb@...> wrote:
> >> How are the trac passwords stored?  Are we going to put the login form
> >> behind SSL?  (That is, do I need to make up Yet Another throwaway
> >> password for this thing?)
> >=20
> > An excellent question.
> >=20
> > The password is hashed and the hash stored it in a htdigest2 compatible=
 file.
> >=20
> > I'm assuming that we will be using SSL when we get the cert, but
> > currently the password is submitted in plain-text over HTTP.
> >=20
> > Someone motivated could probably without much difficulty update the
> > AccountManagerPlugin to be capable to hash the password in javascript
> > and send the hash - that would be neat.
> >=20
> > -D
>=20
> Why not use digest or digest-md5 instead of basic?

I actually prefer basic + ssl for this, as it means my password won't
be stored on disk in the clear.  Certificate-based auth would be even
better.  ;-)

Ethan

--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764

Daniel Atallah wrote:
> On 10/24/06, Gary Kramlich <grim@...> wrote:
>> Why not use digest or digest-md5 instead of basic?
> 
> We're using the Trac AccountManager plugin, not HTTP Authentication.
> 
> -D

As am I for guifications.org but /trac/login requires auth, unless of 
course I missed something in the configuration for the AccountManager 
since i set it up way after I did the basic trac setup.

-- 
Gary Kramlich <grim@...>

On 10/24/06, Ethan Blanton <elb@...> wrote:
> Gary Kramlich spake unto us the following wisdom:
> > Why not use digest or digest-md5 instead of basic?
>
> I actually prefer basic + ssl for this, as it means my password won't
> be stored on disk in the clear.  Certificate-based auth would be even
> better.  ;-)

What am I missing here? Why would digest auth require your password
stored on disk any more than basic?

On 10/24/06, Gary Kramlich <grim@...> wrote:
> Daniel Atallah wrote:
> > We're using the Trac AccountManager plugin, not HTTP Authentication.
>
> As am I for guifications.org but /trac/login requires auth, unless of
> course I missed something in the configuration for the AccountManager
> since i set it up way after I did the basic trac setup.

AccountManager contains a HTTP form-based replacement for the /login action.

I suppose, we could simply not use it and point the apache digest auth
file to the account file generated by AccountManager.  I hadn' t
thought of that possiblity - I think it would work.

Daniel Atallah wrote:
> On 10/24/06, Gary Kramlich <grim@...> wrote:
>> Daniel Atallah wrote:
>>> We're using the Trac AccountManager plugin, not HTTP Authentication.
>> As am I for guifications.org but /trac/login requires auth, unless of
>> course I missed something in the configuration for the AccountManager
>> since i set it up way after I did the basic trac setup.
> 
> AccountManager contains a HTTP form-based replacement for the /login action.
> 
> I suppose, we could simply not use it and point the apache digest auth
> file to the account file generated by AccountManager.  I hadn' t
> thought of that possiblity - I think it would work.

I'm not sure of the version of trac 0.10, but the one for 0.9 can use 
digest.  Look at the webadmin interface under plugins in trac 0.9 and as 
such trac.conf or ini or whatever it is ;)

-- 
Gary Kramlich <grim@...>

Daniel Atallah spake unto us the following wisdom:
> On 10/24/06, Ethan Blanton <elb@...> wrote:
> > Gary Kramlich spake unto us the following wisdom:
> > > Why not use digest or digest-md5 instead of basic?
> >
> > I actually prefer basic + ssl for this, as it means my password won't
> > be stored on disk in the clear.  Certificate-based auth would be even
> > better.  ;-)
>=20
> What am I missing here? Why would digest auth require your password
> stored on disk any more than basic?

Challenge-response authentications always[1] require a password-
equivalent string to be kept at the server.  If it is a hash, then one
can log in knowing the hash and not the password.  The reason for this
is that a successful login is negotiated by way of a function f(x, y)
which takes two "secrets" as its argument.  One is a nonce (the
challenge), and the other is the secret password of the user.  The
server sends the nonce to the user, who computes f(nonce, password),
and sends it back to the server.  The server then also computes
f(nonce, password), and if this matches what hte user sent, then the
login is successful.

The advantage of this scheme is that, if nonces are chosen
intelligently (say, from a huge random number space), and f() is a
good hash function, then the login can take place completely in the
clear and an eavesdropper still doesn't know the password (and can't
replay, either).  The disadvantage is that the server has to
persistently store a password-equivalent string.

Ethan

[1] In practice -- maybe one could be designed which doesn't.

--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764

On Sun, 22 Oct 2006 22:34:38 -0400, Daniel Atallah wrote
> In talking to Luke, he came up with the very reasonable requirement
> that users must be registered in order to file bugs and other tickets.

I'm probably in the minority, and I'll probably be overruled, but I don't like
requiring users to register in order to file bugs, patches, leave comments, or
modify the wiki.  I think it discourages people from contributing, and creates
a less-friendly culture.  I think the barrier to entry should be as low as
possible.

I know Adium had problems with spam on their trac.  My best suggestion for
counteracting that is to place a .htpasswd restriction over our entire trac
with a username/password of "gaimtrac/gaimtrac" or something, and put the
username in the auth message that prompts for the username and password.

-Mark

On Sun, 2006-10-29 at 23:45 -0500, Mark Doliner wrote:
> On Sun, 22 Oct 2006 22:34:38 -0400, Daniel Atallah wrote
> > In talking to Luke, he came up with the very reasonable requirement
> > that users must be registered in order to file bugs and other tickets.
>=20
> I'm probably in the minority, and I'll probably be overruled, but I don't=
 like
> requiring users to register in order to file bugs, patches, leave comment=
s, or
> modify the wiki.  I think it discourages people from contributing, and cr=
eates
> a less-friendly culture.  I think the barrier to entry should be as low a=
s
> possible.

Requiring a bug reporting account is pretty common. It's a little
frustrating, I'll admit. However, it makes it much easier for us to get
feedback from the submitters, since we'll have their e-mail address. Of
course, I don't have any direct experience with users NOT needing
registration, so I'd be willing to give it a shot.

> I know Adium had problems with spam on their trac.  My best suggestion fo=
r
> counteracting that is to place a .htpasswd restriction over our entire tr=
ac
> with a username/password of "gaimtrac/gaimtrac" or something, and put the
> username in the auth message that prompts for the username and password.

I spoke with one of the Adium developers at the GSoc Mentor Summit and
he told me they used to do this, then they switched to requiring
registration. Apparently, having a shared username and password was more
complicated than requiring registration. The users didn't read the
instructions giving them the shared username and password. I assume
registration was easier for them because it's more familiar.

Richard

Quoting Mark Doliner <mark@...>:

> I'm probably in the minority, and I'll probably be overruled, but I 
> don't like
> requiring users to register in order to file bugs, patches, leave 
> comments, or
> modify the wiki.  I think it discourages people from contributing, 
> and creates
> a less-friendly culture.  I think the barrier to entry should be as low as
> possible.
A barrier to entry as low as possible leads to sloppy bug reporting, 
unfortunately.  Registration as implemented by Trac w/ AccountManager 
doesn't require an email address, email confirmation, or any of that; 
it's literally a 2-click process with immediate access granted.  
Registration also allows association of an email address with a user 
name in a non-publically-viewable way so that Trac can send email 
notifications of changes *without* requiring users to disclose their 
email publically.


> I know Adium had problems with spam on their trac.  My best suggestion for
> counteracting that is to place a .htpasswd restriction over our entire trac
> with a username/password of "gaimtrac/gaimtrac" or something, and put the
> username in the auth message that prompts for the username and password.

Our initial solution was to just use the Trac antispam measures.  
They're better than nothing... and not nearly sufficient.  We were 
still overwhelmed by spam.

Our next solution was precisely what you describe: username/password 
'adium'.  There are at least 2 problems with this. 1) Users are then 
forced, as of Trac 0.10 and later, to list their name as 'adium'.  
There's absolutely no accountability for bug reports, no ability to 
contact the user to find out more unless he puts his name in the report 
itself, etc.  It's ugly in addition to nonfunctional. 2) Email change 
notifications are impossible.

I strongly recommend against that solution - it sounded attractive to 
me before we implemented it, but experience showed it to be really 
suboptimal.

On Sun, Oct 29, 2006 at 11:45:44PM -0500, Mark Doliner wrote:
> On Sun, 22 Oct 2006 22:34:38 -0400, Daniel Atallah wrote
> > In talking to Luke, he came up with the very reasonable requirement
> > that users must be registered in order to file bugs and other tickets.
> 
> I'm probably in the minority, and I'll probably be overruled, but I don't like
> requiring users to register in order to file bugs, patches, leave comments, or
> modify the wiki.  I think it discourages people from contributing, and creates
> a less-friendly culture.  I think the barrier to entry should be as low as
> possible.
> 
> I know Adium had problems with spam on their trac.  My best suggestion for
> counteracting that is to place a .htpasswd restriction over our entire trac
> with a username/password of "gaimtrac/gaimtrac" or something, and put the
> username in the auth message that prompts for the username and password.
> 
> -Mark

I remember the problems *we* had with the SF trackers before
requiring an account.  We did not have problems with spam, but we did
have problems with utterly useless reports.

To this day, we rarely have a bug report we do not have to ask a
question in.  If we allow anonymous reports, then we have no way to get
answers to those questions unless the anonymous user just happens to
come back and check the status of his/her report at some later date.
experience says this will not happen very often.

Requiring registration with an email address gives us the ability to ask
questions and, as importantly, have the user know we asked a question.
This is, I sincerely believe, critical.

Keeping the bar low is certainly valuable.  That's why I am intrigued by
the possibility of converting email to bug reports.  That should offer
an interesting combination of being able to control spam, being able to
get additional information, and keeping the bar low.  We can filter the
incoming mail to that address for spam before allowing it to post for
example, or require that a responce email not bounce.  I'm not sure how
possible this is with trac though.

luke