Pidgin

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

On Mon, 2006-10-23 at 14:28 -0700, Sean Egan wrote:
> Because I want the renaming/icon changes to be in svn so that other
> people can use and hack on it. Step 3 is more complicated than you're
> letting on to.

Fair enough.

It looks like the "branch" happened at 17548. Is there some intelligent
way to pull in 17549-HEAD from Gaim SVN to Pidgin SVN? Alternatively, do
we want to apply one bit changeset, or apply them individually?

/me wishes we were already using a distributed VCS, where this would be
easy.

Richard

Richard Laager spake unto us the following wisdom:
> /me wishes we were already using a distributed VCS, where this would be
> easy.

Incidentally, I've been tailor'ing over to monotone for some time
now.[1]  We could always switch SCMs in the process...  ;-)

Ethan

[1] Excepting state before the revisions across which svn cannot even
    update for itself ... which is a lot.  Subversion has pretty much
    hosed our ability to ever losslessly switch to another VCS.

--=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 Mon, 2006-10-23 at 18:53 -0400, Ethan Blanton wrote:
> Richard Laager spake unto us the following wisdom:
> > /me wishes we were already using a distributed VCS, where this would be
> > easy.
>=20
> Incidentally, I've been tailor'ing over to monotone for some time
> now.[1]  We could always switch SCMs in the process...  ;-)

I think now would be a good time to give Monotone a try. Ethan suggested
using tailor to copy the trunk to SVN, so that "casual developers"/"itch
scratchers"/whatever-you-want-to-call-them don't have to checkout the
entire revision history. That sounds reasonable to me.

=46rom my talk with a couple Monotone developers, I became pretty excited
about Monotone with respect to the potential for workflow enhancements
in the future. Also from what I gather, Subversion is aiming to be just
CVS++. While that's enough in a lot of scenarios, I think we could gain
something from a distributed VCS.

Richard