Menu
▾
▴
pidgin-cabal
|
From: Etan R. <de...@ed...> - 2006-10-23 00:57:51
|
I started working on configuring the ejabberd server and I had a couple questions. What features do we want enabled? (I'm assuming muc, but do we want pubsub, vcards, muc room logging, etc?) Are we intending to have open account registration on the server? 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.) -Etan |
|
From: Luke S. <lsc...@us...> - 2006-10-23 01:24:13
|
On Sun, Oct 22, 2006 at 08:57:42PM -0400, Etan Reisner wrote: > I started working on configuring the ejabberd server and I had a couple > questions. > > What features do we want enabled? (I'm assuming muc, but do we want > pubsub, vcards, muc room logging, etc?) > > Are we intending to have open account registration on the server? > > 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.) > > -Etan I'm fairly sure we do not want open registration. We do want muc and server to server. pam sounds interesting. luke |
|
From: Etan R. <de...@ed...> - 2006-10-23 01:49:15
|
On Sun, 22 Oct 2006, Luke Schierer wrote: > On Sun, Oct 22, 2006 at 08:57:42PM -0400, Etan Reisner wrote: >> I started working on configuring the ejabberd server and I had a couple >> questions. >> >> What features do we want enabled? (I'm assuming muc, but do we want >> pubsub, vcards, muc room logging, etc?) >> >> Are we intending to have open account registration on the server? >> >> 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.) >> >> -Etan > > I'm fairly sure we do not want open registration. We do want muc and > server to server. The question was about whether we wanted to have support for logging muc rooms, for publically available (or privately available) later reading. Something like http://chatlogs.jabber.ru/eja...@co.../ and http://www.jabber.org/muc-logs/jd...@co.../ . > pam sounds interesting. The pam stuff didn't get as much testing as Rutgers as it should have (other issues prevented it from getting rolled out as early as I would have liked), so if we decided to use it it is entirely possible there may be a couple issues that will need fixing. > luke -Etan |
|
From: Daniel A. <dan...@gm...> - 2006-10-23 02:34:40
|
On 10/22/06, Etan Reisner <de...@ed...> 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 have a very basic Trac environment set up at http://pidgin.im/trac. Trac is pretty configurable as far as permissions go - they are pretty granular: http://pidgin.im/trac/wiki/TracPermissions Trac can use any of the Apache2 based authentications We're using httpd 2.0 and unfortunately, the authentication wasn't de-suckified until 2.2 (where the Authentication method (Basic or Digest) was separated out from the "Authentication Provider" (file, DBM, LDAP, etc). I think this means that we're stuck with Basic authentication because we're going to need to dynamically add users. The question then is what do we want to as the auth. provider? If we're not planning to offer open jabber registration, then it probably doesn't make sense that Trac auth is related to that. On the other hand, we probably don't want to be maintaining several different auth providers. What are you guys' thoughts? We also have to deal with the various other decisions in the configuration of Trac; some of these are going to be dependent on the L&F of the new website. Take a look and think about it. -D |
|
From: Evan S. <ev...@dr...> - 2006-10-23 12:31:11
Attachments:
PGP.sig
|
On Oct 22, 2006, at 10:34 PM, Daniel Atallah wrote: > On 10/22/06, Etan Reisner <de...@ed...> 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 |
|
From: Ethan B. <el...@ps...> - 2006-10-24 23:27:26
|
Gary Kramlich spake unto us the following wisdom: > Daniel Atallah wrote: > > On 10/24/06, Ethan Blanton <el...@ps...> 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 |
|
From: Ethan B. <el...@ps...> - 2006-10-24 21:04:18
|
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 |
|
From: Daniel A. <dan...@gm...> - 2006-10-24 21:40:46
|
On 10/24/06, Ethan Blanton <el...@ps...> 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 |
|
From: Sean E. <sea...@gm...> - 2006-10-24 00:40:53
|
On 10/22/06, Etan Reisner <de...@ed...> 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. |
|
From: Daniel A. <dan...@gm...> - 2006-10-24 00:42:39
|
On 10/23/06, Evan Schoenberg <ev...@dr...> 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. |
|
From: Sean E. <sea...@gm...> - 2006-10-24 01:10:08
|
On 10/23/06, Daniel Atallah <dan...@gm...> 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. |
|
From: Daniel A. <dan...@gm...> - 2006-10-25 01:08:57
|
On 10/24/06, Ethan Blanton <el...@ps...> 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? |
|
From: Ethan B. <el...@ps...> - 2006-10-25 02:38:46
|
Daniel Atallah spake unto us the following wisdom: > On 10/24/06, Ethan Blanton <el...@ps...> 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 |
|
From: Luke S. <lsc...@us...> - 2006-10-24 01:12:56
|
On Mon, Oct 23, 2006 at 06:10:05PM -0700, Sean Egan wrote: > On 10/23/06, Daniel Atallah <dan...@gm...> 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 |
|
From: Daniel A. <dan...@gm...> - 2006-10-24 02:55:50
|
On 10/23/06, Luke Schierer <lsc...@us...> 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 |
|
From: Sean E. <sea...@gm...> - 2006-10-24 20:09:38
|
On 10/23/06, Daniel Atallah <dan...@gm...> 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. |
|
From: Daniel A. <dan...@gm...> - 2006-10-24 20:24:07
|
On 10/24/06, Sean Egan <sea...@gm...> 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 |
|
From: Ethan B. <el...@ps...> - 2006-10-24 20:32:28
|
Daniel Atallah spake unto us the following wisdom: > On 10/24/06, Sean Egan <sea...@gm...> 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 |
|
From: Daniel A. <dan...@gm...> - 2006-10-24 20:42:52
|
On 10/24/06, Ethan Blanton <el...@ps...> 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 |
|
From: Gary K. <gr...@re...> - 2006-10-24 23:17:05
|
Daniel Atallah wrote: > On 10/24/06, Ethan Blanton <el...@ps...> 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 <gr...@re...> |
|
From: Daniel A. <dan...@gm...> - 2006-10-24 23:25:59
|
On 10/24/06, Gary Kramlich <gr...@re...> wrote: > Why not use digest or digest-md5 instead of basic? We're using the Trac AccountManager plugin, not HTTP Authentication. -D |
|
From: Gary K. <gr...@re...> - 2006-10-25 00:50:14
|
Daniel Atallah wrote: > On 10/24/06, Gary Kramlich <gr...@re...> 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 <gr...@re...> |
|
From: Daniel A. <dan...@gm...> - 2006-10-25 01:09:12
|
On 10/24/06, Gary Kramlich <gr...@re...> 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. |
|
From: Gary K. <gr...@re...> - 2006-10-25 01:14:27
|
Daniel Atallah wrote: > On 10/24/06, Gary Kramlich <gr...@re...> 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 <gr...@re...> |
|
From: Mark D. <ma...@ki...> - 2006-10-30 04:40:13
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X