Menu
▾
▴
pidgin-cabal — DO NOT USE. See https://pidgin.im/cgi-bin/mailman/listinfo/devel
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(28) |
May
(32) |
Jun
(11) |
Jul
(24) |
Aug
(94) |
Sep
(74) |
Oct
(71) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Luke S. <lsc...@us...> - 2007-03-24 03:35:22
|
On Fri, Mar 23, 2007 at 03:09:06PM -0400, Warren Togami wrote: > Any news? > > Warren Togami > wt...@re... We have had a lot of back and forth with the AOL lawyers. We've come very close to just giving up and going public, and if there's much more delay, I believe the consensus is that we will do so. Sean last told me that he thinks we are very very close. He has taken the step of having the lawyers tell them about the new name, which they had been previously advising that we not do. luke |
|
From: Warren T. <wt...@re...> - 2007-03-23 19:09:39
|
Any news? Warren Togami wt...@re... |
|
From: Luke S. <lsc...@us...> - 2006-10-30 17:20:27
|
On Mon, Oct 30, 2006 at 10:51:49AM -0600, Richard Laager wrote: > Sending to the cabal so folks know what is happening... > > On Sun, 2006-10-22 at 01:53 -0700, Sean Egan wrote: > > The official (no need for quotes; it really is official) address of > > the corporation is: > > 2515 4th Avenue #1108 > > Seattle WA, 98121 > > I've re-submitted the request to GoDaddy, since I haven't heard from > them yet. I included a request to contact me, so we'll see what happens. > > I'm intending to request a cert for developer.pidgin.im (for Trac & > SVN). Do we need certs for any other domains? Are we going to need one > for pidgin.im for e-mail or Jabber or something? > > Richard > We can either get one for pidgin.im for imaps, or we can assume everyone is going to check locally, or we can use a self-signed cert. luke |
|
From: Richard L. <rl...@wi...> - 2006-10-30 16:51:58
|
Sending to the cabal so folks know what is happening... On Sun, 2006-10-22 at 01:53 -0700, Sean Egan wrote: > The official (no need for quotes; it really is official) address of > the corporation is: > 2515 4th Avenue #1108 > Seattle WA, 98121 I've re-submitted the request to GoDaddy, since I haven't heard from them yet. I included a request to contact me, so we'll see what happens. I'm intending to request a cert for developer.pidgin.im (for Trac & SVN). Do we need certs for any other domains? Are we going to need one for pidgin.im for e-mail or Jabber or something? Richard |
|
From: Luke S. <lsc...@us...> - 2006-10-30 12:34:33
|
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 |
|
From: Evan S. <ev...@dr...> - 2006-10-30 12:06:29
|
Quoting Mark Doliner <ma...@ki...>: > 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. |
|
From: Richard L. <rl...@wi...> - 2006-10-30 05:15:05
|
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 |
|
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 |
|
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: 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: 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: 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: 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: 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: 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-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 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: 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 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: 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: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: 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 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: 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: 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. |
