From swuwenxiao at gmail.com  Wed Feb  1 02:33:19 2012
From: swuwenxiao at gmail.com (Xiao Wen)
Date: Wed, 1 Feb 2012 15:33:19 +0800
Subject: Anyway to forward msg when receiving?
Message-ID: <CAEKoOfYBhwgd1+zxCgsQOfd__E1LQrxZ9rfVF=W53t1e4oWWDA@mail.gmail.com>

Hello.Pidgin-devel:
      As to pidgin, is there anyway to forward messages I received
automaticlly to the users I choosed prevously?If not, could you give me
some tips on development? In fact, I have read the dev-wiki on
www.pidgin.imabout sigals-HowTo and UiOps-HowTo as follows:
http://developer.pidgin.im/doxygen/dev/html/pages.html
http://developer.pidgin.im/doxygen/dev/html/ui-ops.html

Do you think which sigals or UiOps should I choose to program?

Thanks all the time!

-- 
400715 ?????????????? ????
??
Xiao Wen
College of Computer and Information Science & College of Software
SOUTHWEST UNIVERSITY
BEIBEI, CHONGQING, P. R. CHINA,400715
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20120201/70303281/attachment.html>

From swuwenxiao at gmail.com  Sat Feb  4 03:32:52 2012
From: swuwenxiao at gmail.com (Xiao Wen)
Date: Sat, 4 Feb 2012 16:32:52 +0800
Subject: Fwd: Anyway to forward msg when receiving?
In-Reply-To: <CAEKoOfYBhwgd1+zxCgsQOfd__E1LQrxZ9rfVF=W53t1e4oWWDA@mail.gmail.com>
References: <CAEKoOfYBhwgd1+zxCgsQOfd__E1LQrxZ9rfVF=W53t1e4oWWDA@mail.gmail.com>
Message-ID: <CAEKoOfZzTs9TQkNcr1gseKKGeWFHPG13c1KdgR+JKVbGEyOBVA@mail.gmail.com>

Hi,I send the previous mail again to see if certain solutions existed.
Thanks!

---------- ????? ----------
???? Xiao Wen <swuwenxiao at gmail.com>
??? 2012?2?1? ??3:33
??? Anyway to forward msg when receiving?
???? devel <devel at pidgin.im>


Hello.Pidgin-devel:
      As to pidgin, is there anyway to forward messages I received
automaticlly to the users I choosed prevously?If not, could you give me
some tips on development? In fact, I have read the dev-wiki on
www.pidgin.imabout sigals-HowTo and UiOps-HowTo as follows:
http://developer.pidgin.im/doxygen/dev/html/pages.html
http://developer.pidgin.im/doxygen/dev/html/ui-ops.html

Do you think which sigals or UiOps should I choose to program?

Thanks all the time!

-- 
400715 ?????????????? ????
??
Xiao Wen
College of Computer and Information Science & College of Software
SOUTHWEST UNIVERSITY
BEIBEI, CHONGQING, P. R. CHINA,400715




-- 
400715 ?????????????? ????
??
Xiao Wen
College of Computer and Information Science & College of Software
SOUTHWEST UNIVERSITY
BEIBEI, CHONGQING, P. R. CHINA,400715
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20120204/250539b8/attachment.html>

From madthanu at gmail.com  Sat Feb  4 05:25:44 2012
From: madthanu at gmail.com (thanumalayan mad)
Date: Sat, 4 Feb 2012 04:25:44 -0600
Subject: Pidgin release process
Message-ID: <CAJ6LpRpdztGa8e=hu+RPpGB=xcqD9bN3DuPa7mrM6T7caJvGAA@mail.gmail.com>

Hi All,

I'm a researcher working on improving the reliability of all open
source software, and was hoping to get a question cleared on the
Pidgin software release process. I once used to hack Pidgin's source
code, and wrote a patch for Yahoo! file transfer support in Pidgin
2.4.0; I'm personally interested in Pidgin's release process for that
reason.

In Pidgin, bug-fixing patches usually target the next minor version
release. I believe this is because a version release involves a lot of
work; otherwise, we could release a version immediately for each
bug-fixing patch that has been committed to <im.pidgin.pidgin> (for
example, ticket 14884 could become release version 2.10.1.1 instead of
waiting for 2.10.2 or 3.0.0).

My question is: Assuming no changes to translatable strings, what's
the biggest time-guzzling and effort-involving part of the release
process? Is it the testing (i.e. gaining confidence that the patch is
not buggy)?

Another way to put the question: If I provide a way to automatically
test patches (or monotone revisions) in thousands of real pidgin
deployments, with real users using it, but without the pidgin users
noticing any possible bad effects of the tested patches (such as a
crash due to the patch), is it possible to adopt a rolling-release
strategy for bug-fixing patches?

Thanks for any inputs provided!

---
madthanu

PS: I kinda already asked QuLogic about this in IRC. I'm hoping people
don't consider this as troll-mail, am really attempting to make good
software development easier.


From elb at pidgin.im  Sat Feb  4 13:00:47 2012
From: elb at pidgin.im (Ethan Blanton)
Date: Sat, 4 Feb 2012 13:00:47 -0500
Subject: Pidgin release process
In-Reply-To: <CAJ6LpRpdztGa8e=hu+RPpGB=xcqD9bN3DuPa7mrM6T7caJvGAA@mail.gmail.com>
References: <CAJ6LpRpdztGa8e=hu+RPpGB=xcqD9bN3DuPa7mrM6T7caJvGAA@mail.gmail.com>
Message-ID: <20120204180047.GA16254@colt>

thanumalayan mad spake unto us the following wisdom:
> I'm a researcher working on improving the reliability of all open
> source software, and was hoping to get a question cleared on the
> Pidgin software release process. I once used to hack Pidgin's source
> code, and wrote a patch for Yahoo! file transfer support in Pidgin
> 2.4.0; I'm personally interested in Pidgin's release process for that
> reason.
> 
> In Pidgin, bug-fixing patches usually target the next minor version
> release. I believe this is because a version release involves a lot of
> work; otherwise, we could release a version immediately for each
> bug-fixing patch that has been committed to <im.pidgin.pidgin> (for
> example, ticket 14884 could become release version 2.10.1.1 instead of
> waiting for 2.10.2 or 3.0.0).

This is not precisely true.  Bugfix patches typically target the next
release required by their ABI changes; see the Pidgin FAQ for more
information on Pidgin version numbering.  Simple bug fixes (forgot to
free something or NULL a pointer, typos in strings, etc.) can
typically go in the next micro release, while bug fixes which require
more invasive changes or depend on existing restructurings in
development may have to wait for minor or major releases.

> My question is: Assuming no changes to translatable strings, what's
> the biggest time-guzzling and effort-involving part of the release
> process? Is it the testing (i.e. gaining confidence that the patch is
> not buggy)?

There are several time-guzzling parts of the release process.  In my
experience, they are the following (in no particular order):

* As you mention, determining that a specific patch is suitable for
  inclusion

* The variety of steps which take just enough time and intervention
  that you can't fire them all back to back without sitting around and
  waiting

* The SourceForge file release system

* Checks to ensure that there are no patches which Should Really Go In
  to this release which haven't yet made it[1]

* Checks with other developers and regular users to make sure there
  are no outstanding issues the developer doing the release is unaware
  of[1]

* Chasing down contact information for patches which turn up in the
  above process[2]

* Taking at least a stab at making sure compilation didn't break on OS
  X, Windows, or other bizarre or broken platforms.

[1] This could be fixed by better intra-project communication.  We
    don't have a great system for making sure everyone is On the Same
    Page.  In the past, Luke Schierer always had a very good idea of
    what was outstanding and who was blocking what.  After Luke
    stepped aside to deal with real life concerns which were taking
    more and more of his time, we had a period without any such
    bug-wrangler, and then John Bailey stepped up to that plate.
    Recently, John has been very busy with work and other things, and
    we once again have a vacuum in that department.

[2] We try to keep this to a minimum by gathering all of this
    information in the bug tracker or on the email list when a patch
    shows up, and including it at application time, but for patches
    which are included at the last minute this can be trouble.  It is
    particularly painful when users submit patches via the bug tracker
    and either provide a bogus email address or use an email address
    they seldom check, then don't update the bug when asked for more
    information.

The specific nature of a given patch may or may not make it difficult
to triage.  If it's deep within a protocol plugin, finding a developer
who knows about that plugin, and that developer finding time to
examine it carefully, can take a while.

> Another way to put the question: If I provide a way to automatically
> test patches (or monotone revisions) in thousands of real pidgin
> deployments, with real users using it, but without the pidgin users
> noticing any possible bad effects of the tested patches (such as a
> crash due to the patch), is it possible to adopt a rolling-release
> strategy for bug-fixing patches?

There's another issue at hand here, and that's whether it's
*desirable* to constantly make tiny releases with trivial patches
included.  I am of the opinion that it's probably not.  Unless the
patch fixes a security vulnerability, corrects a bug which affects a
large number of users in a nontrival way, or has some other Big
Impact, I don't think making a release for a small patch is a good
idea.  For one thing, it causes either staying up-to-date to become
painful, or people to stop worrying about staying up-to-date.

I have no doubt that we could integrate patches more quickly and
release more often to the benefit of all, but I would still suggest
bundling fairly large numbers of trivial patches into point releases,
rather than releasing for every individual change.

I would also point out here that it's going to be impossible to
prevent users of untested patches for noticing any possible bad
effects.  You may be able to mitigate effects.

Testing and testers *would* be valuable, and I'd love to see us have
more testers and patch & bug traigers.  However, the usual offer of
"I'd be happy to run the development version to test for you!" is not
as helpful as it looks on the surface; we really need people who can
both run the development code *and* provide detailed and comprehensive
bug reports and/or bug fixes directly.  Simply saying "I used the
patch on bug #nnnnnn and it crashed" is of very limited utility.  We
have had, at various points in the past, dedicated bug tester and
triagers, and it is indeed quite helpful.  However, it requires a
large investment of time and skills very much related to becoming an
actual developer (in fact, it's a great place for novice developers to
get into open source development).

The biggest single slowdown in Pidgin patch acceptance and Pidgin
releases at the moment is simply that almost all of the primary Pidgin
developers are extremely busy and have very little time for Pidgin
development.  You are correct that streamlining the release process
would help that, and we've made some strides toward that in the past
(like 'make release'), but it's only one piece of the puzzle.

Hope that helps.

Ethan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20120204/da8d0f29/attachment.pgp>

From madthanu at gmail.com  Sat Feb  4 14:42:06 2012
From: madthanu at gmail.com (thanumalayan mad)
Date: Sat, 4 Feb 2012 13:42:06 -0600
Subject: Pidgin release process
In-Reply-To: <20120204180047.GA16254@colt>
References: <CAJ6LpRpdztGa8e=hu+RPpGB=xcqD9bN3DuPa7mrM6T7caJvGAA@mail.gmail.com>
	<20120204180047.GA16254@colt>
Message-ID: <CAJ6LpRpgsVTvBv8qLXkZJ2pzmSKiKv2KpYtm6pp=Q9ETUmJ1qg@mail.gmail.com>

Ethan (and everyone else),

Helps a lot, thanks for the reply. No need to read the rest of the
email unless you are curious why I'm concerned about all this.

---

I now understand that there is more, logistically, to the release
process, than just testing; like Ethan says, a rolling updates/release
process (which I was imagining) has many philosophical differences,
compared to the major-minor-micro versioning release process. And of
course, for a patch, you can't even commit it without making an expert
developer examine it in detail.

So, I guess the solution I'm thinking of[1] can't be directly applied
in Pidgin for even simple bug fixes (like NULL pointer checks and
memory frees), even after they are are examined by an expert
developer, unless a very philosophically different release process is
followed.

> I would also point out here that it's going to be impossible to
> prevent users of untested patches for noticing any possible bad
> effects. ?You may be able to mitigate effects.

[1] Just in case it seems interesting, however, I believe there's a
way to prevent users from noticing any bad effects (other than
imperceptible performance overhead) while testing patches, including
compilation errors. The testing process would be totally transparent
to the user; he/she will perceive it as running a stable version of
the application. The testing process, in case the patch is buggy,
would also report exactly how the run of the patched version was
different from the stable version (it's not just a stack trace, it'll
be useful, I'm just worried about privacy concerns for now, EFF would
probably not like it). The method would not, however, provide
automatic fixes for buggy patches: that'd be like magic. Assuming
significant usage, you could use this method to practically gain 100%
confidence in any simple, committed patch.

Again, this would take a lot of time to move from a research idea to a
practical solution, and would even then not help Pidgin because of the
philosophical differences. Still, if someone has any views on this, do
mail me privately.

Thanks again.
---
madthanu


From bleeter at gmail.com  Sun Feb  5 04:33:18 2012
From: bleeter at gmail.com (Peter Lawler)
Date: Sun, 05 Feb 2012 20:33:18 +1100
Subject: Privacy Rewrite
In-Reply-To: <CAJz=V7wEMxve7Y_pr8=_6OTXkW+6A0TewzMzV7rwkKSaxtsCUA@mail.gmail.com>
References: <4EEE6BB2.8030209@gmail.com>
	<CAJz=V7wEMxve7Y_pr8=_6OTXkW+6A0TewzMzV7rwkKSaxtsCUA@mail.gmail.com>
Message-ID: <4F2E4CDE.4080705@gmail.com>

>> On Mon, Dec 19, 2011 at 4:09 AM, Peter Lawler <bleeter at gmail.com>
>> wrote:
>>
>> Hi there,
>> Just curious how many folks on the devel at p.i list are (in)actively
>> involved in the Privacy Rewrite. I'm still at an 'unsure' kind of >>
stage,
>> but if I do say 'Yes' I wouldn't want to step on anyone's toes.
>>
>> I'm guessing elb may kind of be involved, has he mentored the 2009 >>
GSoC
>> project. Wondering if there are contributors, etc., lurking and/or
>> active on that project still.
>>
>> Regards,
>>
>> Pete.

On 28/12/11 03:56, Sulabh Mahajan wrote:
> Hi Pete,
> 
> I am the GSoC student who worked on privacy rewrite. I haven't worked on
> pidgin dev since then, got really busy.
> I am thinking of starting development activities again.
> 
> As of now no one is working on privacy rewrite.
> I am planning to start again from next week.
> 
> Sulabh Mahajan

Hi Sulabh,
Do you have any updates to report on progress?

Pete.


From ingowolfd at gmail.com  Fri Feb 10 16:15:20 2012
From: ingowolfd at gmail.com (iwl)
Date: Fri, 10 Feb 2012 13:15:20 -0800 (PST)
Subject: Instant Sound on Message
Message-ID: <20895384.1185.1328908520022.JavaMail.geo-discussion-forums@vbbgq7>


I just don't noticed an incoming Message for 2 hours sitting at the 
computer nearly all the time.
I would like an Sound playing again and again configurable and the chat 
window coming up and blinking all over and such stuff...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20120210/13722941/attachment.html>

From bleeter at gmail.com  Sun Feb 12 16:27:16 2012
From: bleeter at gmail.com (Peter Lawler)
Date: Mon, 13 Feb 2012 08:27:16 +1100
Subject: Instant Sound on Message
In-Reply-To: <20895384.1185.1328908520022.JavaMail.geo-discussion-forums@vbbgq7>
References: <20895384.1185.1328908520022.JavaMail.geo-discussion-forums@vbbgq7>
Message-ID: <4F382EB4.10408@gmail.com>

On 11/02/12 08:15, iwl wrote:
> 
> I just don't noticed an incoming Message for 2 hours sitting at the 
> computer nearly all the time.
> I would like an Sound playing again and again configurable and the chat 
> window coming up and blinking all over and such stuff...

It's not my call, but I doubt this would be included in default pidgin.
You could probably bang together a plugin to do it for you. Or extend
the default Message Notification plugin itself to add constant buzzing
beyond the "'URGENT' hint" and "Rasie conversation" and "Present
conversation" stuff.

Pete.


From sulabh.dev at gmail.com  Wed Feb 15 22:08:37 2012
From: sulabh.dev at gmail.com (Sulabh Mahajan)
Date: Thu, 16 Feb 2012 08:38:37 +0530
Subject: Privacy Rewrite
In-Reply-To: <4F2E4CDE.4080705@gmail.com>
References: <4EEE6BB2.8030209@gmail.com>
	<CAJz=V7wEMxve7Y_pr8=_6OTXkW+6A0TewzMzV7rwkKSaxtsCUA@mail.gmail.com>
	<4F2E4CDE.4080705@gmail.com>
Message-ID: <CAJz=V7zNxe0AV+4xNm_+_jHUnJg0oy_s3bm_FEFMv1NGw2xGTQ@mail.gmail.com>

Hi,

No updates as of now, too busy with office work. Can't start working on
privacy rewrite till feb end.
If you have some ideas, please go ahead, don't wait because of me. I am
tied up at work these days.

I will ping you as soon as I get free.

Thanks and Regards,
Sulabh

On Sun, Feb 5, 2012 at 3:03 PM, Peter Lawler <bleeter at gmail.com> wrote:

> >> On Mon, Dec 19, 2011 at 4:09 AM, Peter Lawler <bleeter at gmail.com>
> >> wrote:
> >>
> >> Hi there,
> >> Just curious how many folks on the devel at p.i list are (in)actively
> >> involved in the Privacy Rewrite. I'm still at an 'unsure' kind of >>
> stage,
> >> but if I do say 'Yes' I wouldn't want to step on anyone's toes.
> >>
> >> I'm guessing elb may kind of be involved, has he mentored the 2009 >>
> GSoC
> >> project. Wondering if there are contributors, etc., lurking and/or
> >> active on that project still.
> >>
> >> Regards,
> >>
> >> Pete.
>
> On 28/12/11 03:56, Sulabh Mahajan wrote:
> > Hi Pete,
> >
> > I am the GSoC student who worked on privacy rewrite. I haven't worked on
> > pidgin dev since then, got really busy.
> > I am thinking of starting development activities again.
> >
> > As of now no one is working on privacy rewrite.
> > I am planning to start again from next week.
> >
> > Sulabh Mahajan
>
> Hi Sulabh,
> Do you have any updates to report on progress?
>
> Pete.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20120216/39f0b624/attachment.html>

From mark at kingant.net  Mon Feb 20 18:02:13 2012
From: mark at kingant.net (Mark Doliner)
Date: Mon, 20 Feb 2012 15:02:13 -0800
Subject: Plans for IPv6 support on windows?
In-Reply-To: <4F1765C4.8020906@rekkanoryo.org>
References: <4F167A65.2060904@uninett.no>
	<CAFt0mkp6yHf+_yxTM1_OwmKfmL205i1z=H77JFmhimYmeC+gvA@mail.gmail.com>
	<CACOgDb1ZxCQ__EH2ocjBGfiRO0o3=2et+d8ZNkvkTJHRURXccA@mail.gmail.com>
	<CAFt0mkoxVPq0t9Z7ZS=SrLAZmmGm8jK2r4S6KRP6mtMr==ASwA@mail.gmail.com>
	<4F1765C4.8020906@rekkanoryo.org>
Message-ID: <CAPZ8mV4njQoU7-kyrqQUrCGSOrVGLab3UrV4ciu-otSzJofrdA@mail.gmail.com>

On Wed, Jan 18, 2012 at 4:37 PM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
> On 01/18/2012 02:39 PM, Eion Robb wrote:
>> Didn't we drop support for 95/98 a while ago?
>> http://developer.pidgin.im/wiki/Installing%20Pidgin#CanIrunPidginonWindows98ME
>
> Yes, but we *do* still support Windows 2000, which has no IPv6 support at all.

If supporting Windows 2000 requires any extra work or reduces
functionality in any way, then I'm in favor of dropping support for
it.  It's kind of old.  It's been out of mainstream support for 6
years and out of extended support for a year and a half.  Its
replacements, Windows XP and Windows 2003, have been available for
over 8 years.  People should have upgraded by now.


From daniel.atallah at gmail.com  Mon Feb 20 18:08:36 2012
From: daniel.atallah at gmail.com (Daniel Atallah)
Date: Mon, 20 Feb 2012 18:08:36 -0500
Subject: Plans for IPv6 support on windows?
In-Reply-To: <CAPZ8mV4njQoU7-kyrqQUrCGSOrVGLab3UrV4ciu-otSzJofrdA@mail.gmail.com>
References: <4F167A65.2060904@uninett.no>
	<CAFt0mkp6yHf+_yxTM1_OwmKfmL205i1z=H77JFmhimYmeC+gvA@mail.gmail.com>
	<CACOgDb1ZxCQ__EH2ocjBGfiRO0o3=2et+d8ZNkvkTJHRURXccA@mail.gmail.com>
	<CAFt0mkoxVPq0t9Z7ZS=SrLAZmmGm8jK2r4S6KRP6mtMr==ASwA@mail.gmail.com>
	<4F1765C4.8020906@rekkanoryo.org>
	<CAPZ8mV4njQoU7-kyrqQUrCGSOrVGLab3UrV4ciu-otSzJofrdA@mail.gmail.com>
Message-ID: <CACOgDb3Ba+nid5ANSKEXqy-X7FoZymY+ntUKKU1SrFbKM+td_w@mail.gmail.com>

On Mon, Feb 20, 2012 at 18:02, Mark Doliner <mark at kingant.net> wrote:
> On Wed, Jan 18, 2012 at 4:37 PM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
>> On 01/18/2012 02:39 PM, Eion Robb wrote:
>>> Didn't we drop support for 95/98 a while ago?
>>> http://developer.pidgin.im/wiki/Installing%20Pidgin#CanIrunPidginonWindows98ME
>>
>> Yes, but we *do* still support Windows 2000, which has no IPv6 support at all.
>
> If supporting Windows 2000 requires any extra work or reduces
> functionality in any way, then I'm in favor of dropping support for
> it. ?It's kind of old. ?It's been out of mainstream support for 6
> years and out of extended support for a year and a half. ?Its
> replacements, Windows XP and Windows 2003, have been available for
> over 8 years. ?People should have upgraded by now.


Yeah, I've been thinking along the same lines.

For 3.0.0, we can bump the required Windows version to XP and
hopefully that'll make adding IPv6 support "easy".

-D


From swuwenxiao at gmail.com  Tue Feb 21 00:35:52 2012
From: swuwenxiao at gmail.com (Xiao Wen)
Date: Tue, 21 Feb 2012 13:35:52 +0800
Subject: Way to receive offline message?
Message-ID: <CAEKoOfZ4KYP1tiVAArU-8LQFJrAiGQ_g2nhRchJfyFOLDgXMZA@mail.gmail.com>

Hi,
How to make sure that user can receive offline message when I create a
conversation manully as follows?Thanks!

PurpleConversation<http://developer.pidgin.im/doxygen/2.7.11/html/struct__PurpleConversation.html>*
purple_conversation_new(PurpleConversationType<http://developer.pidgin.im/doxygen/2.7.11/html/conversation_8h.html#9e9f3ae232444332eb34f16aef64f721>
 type,PurpleAccount<http://developer.pidgin.im/doxygen/2.7.11/html/struct__PurpleAccount.html>
 * account,const char * name )

Creates a new conversation of the specified type.

Parameters:type The type of conversation.account The account opening the
conversation window on the purple user's end.name The name of the
conversation. For PURPLE_CONV_TYPE_IM, this is the name of the buddy.
Returns:The new conversation.

400715 ?????????????? ????
> ??
> Xiao Wen
> College of Computer and Information Science & College of Software
> SOUTHWEST UNIVERSITY
> BEIBEI, CHONGQING, P. R. CHINA,400715
>
>

-- 
400715 ?????????????? ????
??
Xiao Wen
College of Computer and Information Science & College of Software
SOUTHWEST UNIVERSITY
BEIBEI, CHONGQING, P. R. CHINA,400715
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20120221/20e01fc3/attachment.html>

From mark at kingant.net  Tue Feb 21 02:55:00 2012
From: mark at kingant.net (Mark Doliner)
Date: Mon, 20 Feb 2012 23:55:00 -0800
Subject: Administrative changes I made
Message-ID: <CAPZ8mV4gs3s2i4=2ug7t81NHFUvuY8qmmYRV2u-Dxi1ZC7bVig@mail.gmail.com>

Just want to keep people updated on a few changes I made today to our
SourceForge project page and to rock.pidgin.im.

- Added/removed developers and admins from the Pidgin SourceForge
project.  I think it's useful to users, new developers, press, other
projects, etc. if this list is more accurate.  You can see the current
list here: http://sourceforge.net/project/memberlist.php?group_id=235
Elliott, please let me know if your sourceforge username is not
qulogic.  Also, if anyone prefers not to be listed please let me or
someone else know and we can remove you (you also might be able to
remove yourself).  And please try to use a reasonably secure password
for your SourceForge account.

- Got rid of the lighttpd configuration for
http://community.pidgin.im/ on rock.  It was redirecting to
http://pidgin.im/support/.  I think Casey Ho wanted to create
something for users using Drupal here, but maybe we shot it down?  Or
maybe this is what we used for the user survey/poll?
> sudo rm -f /etc/lighttpd/conf-available/20-community.pidgin.im.conf /etc/lighttpd/conf-enabled/20-community.pidgin.im.conf
> sudo service lighttpd reload

- Removed the long-unused Drupal files leftover from an earlier
iteration of community.pidgin.im.
> sudo rm -rf /srv/www/community.pidgin.im/

- Removed the community.pidgin.im DNS A record.
> sudo vim /etc/bind/pidgin/db.pidgin.im
> Remove the "community" line.  Update the serial number at the top of the file.
> sudo service bind9 reload

- Removed the legacy _jabber._tcp DNS SRV record.  I don't expect this
to cause any problems
(http://mail.jabber.org/pipermail/standards/2007-February/014001.html).
> sudo vim /etc/bind/pidgin/db.pidgin.im
> Remove the "_jabber._tcp" line.  Update the serial number at the top of the file.
> sudo service bind9 reload

- Removed the soc.pidgin.im DNS A record.  It was pointing to
imperial, but was showing "developer.pidgin.im is currently down!
Sorry for the inconvenience. We're dealing with a few hosting
problems. We hope to have things back up and running again soon, but
we don't have an estimate on when that will be."  Not sure what was
supposed to be here, but it doesn't seem like we need it.
> sudo vim /etc/bind/pidgin/db.pidgin.im
> Remove the "soc" line.  Update the serial number at the top of the file.
> sudo service bind9 reload

- apt-get upgraded rock.  It upgraded apache, clamav, erlang, php,
mediawiki, and other things

- Uninstalled Apache on rock.  It wasn't running and I don't think we
need it for anything.


From dimitris at census-labs.com  Sat Feb 25 11:19:59 2012
From: dimitris at census-labs.com (Dimitris Glynos)
Date: Sat, 25 Feb 2012 18:19:59 +0200
Subject: private messages on dbus
In-Reply-To: <4EF12D25.1040403@census-labs.com>
References: <4EF05D3E.5020907@census-labs.com>
	<d60900010bdd820d9893fdc451dc8a94@hxbc.us>
	<4EF12D25.1040403@census-labs.com>
Message-ID: <4F490A2F.1030601@census-labs.com>

On 12/21/2011 02:49 AM, Dimitris Glynos wrote:
> On 12/21/2011 01:11 AM, khc at hxbc.us wrote:
>> On Tue, 20 Dec 2011 12:02:38 +0200, Dimitris Glynos wrote:
>>> Hello all,
>>>
>>> I was wondering if pidgin could allow for certain chat types
>>> to be flagged as private and not transmit these over dbus.
>>> I don't know how much dbus is hardwired to pidgin (is it used
>>> also for capturing the messages displayed on the pidgin GUI?)
>>> but the fact that a local attacker can access OTR plaintext
>>> from a dbus session monitor is quite unnerving.
>>
>> a local attacker can already ptrace the pidgin process and do
>> pretty much anything.
> 
> Yes, the word 'local' is used incorrectly in the original post.
> Consider a remote attacker that exploits some app running
> in the same desktop session as pidgin. It is trivial
> to fork-exec a dbus session monitor from there and retrieve the
> sensitive info.
> 
> Now, regarding ptrace although it was generally possible in
> the past to attach to processes of the same user, this has
> been restricted somewhat in modern distro's. Specifically,
> distro's like Ubuntu allow (non-root) ptrace only to
> processes that are children of the ptrace-caller.
> 
> For more info on this, have a look here:
> https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection
> 
> Hope this clarifies things a bit,

Coming back to this after a while. You may now find an advisory
and a proof-of-concept script for the DBUS info leak here:

http://census-labs.com/news/2012/02/25/pidgin-otr-info-leak/

This issue has received CVE-2012-1257.

It would be good to see this issue addressed in the next release
of pidgin and pidgin-otr. Most users would be surprised to find
that their private chatting is somehow accessible to other apps..

Best regards,

Dimitris
--
http://census-labs.com -- IT security research, development and services


From bleeter at gmail.com  Sun Feb 26 17:40:42 2012
From: bleeter at gmail.com (Peter Lawler)
Date: Mon, 27 Feb 2012 09:40:42 +1100
Subject: Privacy Rewrite
In-Reply-To: <CAJz=V7zNxe0AV+4xNm_+_jHUnJg0oy_s3bm_FEFMv1NGw2xGTQ@mail.gmail.com>
References: <4EEE6BB2.8030209@gmail.com>
	<CAJz=V7wEMxve7Y_pr8=_6OTXkW+6A0TewzMzV7rwkKSaxtsCUA@mail.gmail.com>
	<4F2E4CDE.4080705@gmail.com>
	<CAJz=V7zNxe0AV+4xNm_+_jHUnJg0oy_s3bm_FEFMv1NGw2xGTQ@mail.gmail.com>
Message-ID: <4F4AB4EA.60400@gmail.com>

On 16/02/12 14:08, Sulabh Mahajan wrote:
> Hi,
> 
> No updates as of now, too busy with office work. Can't start working on
> privacy rewrite till feb end.
> If you have some ideas, please go ahead, don't wait because of me. I am
> tied up at work these days.
> 
> I will ping you as soon as I get free.
> 
> Thanks and Regards,
> Sulabh

Hi!
I've got a Privacy component report added to Trac, I've also taken it
upon myself to have new tickets under this component assigned to me.

I've requested a Trac canned response for 'Please retest and get back to
us' as quite a few bugs that may be privacy related are fairly old and
I'd like to hear back from reporters whether it's still a problem with
current release.

Further, I've taken 'ownership' of Ticket #38 - the ancient 'Make
Privacy Work' catchall. I've requested that the noise on that ticket be
taken elsewhere and referenced back, I guess we'll see what happens here.

I expect that over the next few weeks, I'll be updating the Privacy
Rewrite wiki page adding further details that have been 'uncovered'
since it was last edited as well as adding in the details of what was
achieved in the '09 GSoC project but not yet merged.

Regards,

Pete.




> 
> On Sun, Feb 5, 2012 at 3:03 PM, Peter Lawler <bleeter at gmail.com> wrote:
> 
>>>> On Mon, Dec 19, 2011 at 4:09 AM, Peter Lawler <bleeter at gmail.com>
>>>> wrote:
>>>>
>>>> Hi there,
>>>> Just curious how many folks on the devel at p.i list are (in)actively
>>>> involved in the Privacy Rewrite. I'm still at an 'unsure' kind of >>
>> stage,
>>>> but if I do say 'Yes' I wouldn't want to step on anyone's toes.
>>>>
>>>> I'm guessing elb may kind of be involved, has he mentored the 2009 >>
>> GSoC
>>>> project. Wondering if there are contributors, etc., lurking and/or
>>>> active on that project still.
>>>>
>>>> Regards,
>>>>
>>>> Pete.
>>
>> On 28/12/11 03:56, Sulabh Mahajan wrote:
>>> Hi Pete,
>>>
>>> I am the GSoC student who worked on privacy rewrite. I haven't worked on
>>> pidgin dev since then, got really busy.
>>> I am thinking of starting development activities again.
>>>
>>> As of now no one is working on privacy rewrite.
>>> I am planning to start again from next week.
>>>
>>> Sulabh Mahajan
>>
>> Hi Sulabh,
>> Do you have any updates to report on progress?
>>
>> Pete.
>>
> 


From Byrd.B at insightcom.com  Mon Feb 27 12:28:14 2012
From: Byrd.B at insightcom.com (Byrd, Brendan)
Date: Mon, 27 Feb 2012 17:28:14 +0000
Subject: [OTR-dev] private messages on dbus
In-Reply-To: <4F490A2F.1030601@census-labs.com>
References: <4EF05D3E.5020907@census-labs.com>
	<d60900010bdd820d9893fdc451dc8a94@hxbc.us>
	<4EF12D25.1040403@census-labs.com> <4F490A2F.1030601@census-labs.com>
Message-ID: <EB9E8181A5BE3B4787CD0F19EFD532FD0195FB@HUBMAIL02.insight.ds>

Wait, are we talking about the potential for an attacker to:

1. Load a Trojan/Virus on their PC that allows remote access
2. ...Who the $^#% cares at that point?!

Once security has been breached at point #1, it doesn't matter.  The PC is already impacted.  Re-format, restart, reload, and change all of your security information, passwords, keys, etc.

The private key is already vulnerable.  Hell, -memory- is already vulnerable.  Everything is in plaintext if you find the right memory location.  There's no way to fix that, especially if the attacker has admin/root access.  Everything is compromised.  There's no point in trying to lock down the app for that sort of critical security failure.

"The best way to protect a server is to unplug the network cable, put it in a lock box, throw away the key, and bury it.  Even then, there's still a small chance it might be compromised."

--
Brendan Byrd <byrd.b at insightcom.com>
System Integration Analyst (NOC Web Developer)

-----Original Message-----
From: otr-dev-bounces at lists.cypherpunks.ca [mailto:otr-dev-bounces at lists.cypherpunks.ca] On Behalf Of Dimitris Glynos
Sent: Saturday, February 25, 2012 11:20 AM
To: devel at pidgin.im
Cc: otr-dev at lists.cypherpunks.ca
Subject: Re: [OTR-dev] private messages on dbus

On 12/21/2011 02:49 AM, Dimitris Glynos wrote:
> On 12/21/2011 01:11 AM, khc at hxbc.us wrote:
>> On Tue, 20 Dec 2011 12:02:38 +0200, Dimitris Glynos wrote:
>>> Hello all,
>>>
>>> I was wondering if pidgin could allow for certain chat types to be 
>>> flagged as private and not transmit these over dbus.
>>> I don't know how much dbus is hardwired to pidgin (is it used also 
>>> for capturing the messages displayed on the pidgin GUI?) but the 
>>> fact that a local attacker can access OTR plaintext from a dbus 
>>> session monitor is quite unnerving.
>>
>> a local attacker can already ptrace the pidgin process and do pretty 
>> much anything.
> 
> Yes, the word 'local' is used incorrectly in the original post.
> Consider a remote attacker that exploits some app running in the same 
> desktop session as pidgin. It is trivial to fork-exec a dbus session 
> monitor from there and retrieve the sensitive info.
> 
> Now, regarding ptrace although it was generally possible in the past 
> to attach to processes of the same user, this has been restricted 
> somewhat in modern distro's. Specifically, distro's like Ubuntu allow 
> (non-root) ptrace only to processes that are children of the 
> ptrace-caller.
> 
> For more info on this, have a look here:
> https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Pr
> otection
> 
> Hope this clarifies things a bit,

Coming back to this after a while. You may now find an advisory and a proof-of-concept script for the DBUS info leak here:

http://census-labs.com/news/2012/02/25/pidgin-otr-info-leak/

This issue has received CVE-2012-1257.

It would be good to see this issue addressed in the next release of pidgin and pidgin-otr. Most users would be surprised to find that their private chatting is somehow accessible to other apps..

Best regards,

Dimitris
--
http://census-labs.com -- IT security research, development and services _______________________________________________
OTR-dev mailing list
OTR-dev at lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev


From mark at kingant.net  Mon Feb 27 14:47:07 2012
From: mark at kingant.net (Mark Doliner)
Date: Mon, 27 Feb 2012 11:47:07 -0800
Subject: [OTR-dev] private messages on dbus
In-Reply-To: <EB9E8181A5BE3B4787CD0F19EFD532FD0195FB@HUBMAIL02.insight.ds>
References: <4EF05D3E.5020907@census-labs.com>
	<d60900010bdd820d9893fdc451dc8a94@hxbc.us>
	<4EF12D25.1040403@census-labs.com>
	<4F490A2F.1030601@census-labs.com>
	<EB9E8181A5BE3B4787CD0F19EFD532FD0195FB@HUBMAIL02.insight.ds>
Message-ID: <CAPZ8mV7PHzbqqcrko-Fdjf4+gV5e0SUyipWhQb6Wswj=jJ0esQ@mail.gmail.com>

FYI there has been some good discussion about this here:
http://developer.pidgin.im/ticket/14830


From paul at cypherpunks.ca  Mon Feb 27 17:43:40 2012
From: paul at cypherpunks.ca (Paul Wouters)
Date: Mon, 27 Feb 2012 17:43:40 -0500 (EST)
Subject: [OTR-dev] private messages on dbus
In-Reply-To: <4F490A2F.1030601@census-labs.com>
References: <4EF05D3E.5020907@census-labs.com>
	<d60900010bdd820d9893fdc451dc8a94@hxbc.us>
	<4EF12D25.1040403@census-labs.com>
	<4F490A2F.1030601@census-labs.com>
Message-ID: <alpine.LFD.2.02.1202271739250.22392@bofh.nohats.ca>

On Sat, 25 Feb 2012, Dimitris Glynos wrote:

>>>> I was wondering if pidgin could allow for certain chat types
>>>> to be flagged as private and not transmit these over dbus.
>>>> I don't know how much dbus is hardwired to pidgin (is it used
>>>> also for capturing the messages displayed on the pidgin GUI?)
>>>> but the fact that a local attacker can access OTR plaintext
>>>> from a dbus session monitor is quite unnerving.
>>>
>>> a local attacker can already ptrace the pidgin process and do
>>> pretty much anything.

not neccessarilly. For instance with SElinux or AppArmor you can
take that ability away from the process.

> Coming back to this after a while. You may now find an advisory
> and a proof-of-concept script for the DBUS info leak here:
>
> http://census-labs.com/news/2012/02/25/pidgin-otr-info-leak/
>
> This issue has received CVE-2012-1257.
>
> It would be good to see this issue addressed in the next release
> of pidgin and pidgin-otr. Most users would be surprised to find
> that their private chatting is somehow accessible to other apps..

I am still a bit confused how serious this issue really is. If you can
read as the uid of the user, you can already read the OTR keys from
disk. Now PFS will prevent decrypting, but whether you listen in on dbus
or the X11 channels doesnt really matter much. So I see value in
protecting the pidgin process from reading OTR materials outside
pidgin-otr, and hardening pidgin against network input, I see less value
into closing the dbus from the user for themselves.

Paul


From dimitris at census-labs.com  Mon Feb 27 17:53:10 2012
From: dimitris at census-labs.com (Dimitris Glynos)
Date: Tue, 28 Feb 2012 00:53:10 +0200
Subject: [OTR-dev] private messages on dbus
In-Reply-To: <alpine.LFD.2.02.1202271739250.22392@bofh.nohats.ca>
References: <4EF05D3E.5020907@census-labs.com>
	<d60900010bdd820d9893fdc451dc8a94@hxbc.us>
	<4EF12D25.1040403@census-labs.com>
	<4F490A2F.1030601@census-labs.com>
	<alpine.LFD.2.02.1202271739250.22392@bofh.nohats.ca>
Message-ID: <4F4C0956.7040004@census-labs.com>

On 02/28/2012 12:43 AM, Paul Wouters wrote:
> I am still a bit confused how serious this issue really is. If you can
> read as the uid of the user, you can already read the OTR keys from
> disk. Now PFS will prevent decrypting, but whether you listen in on dbus
> or the X11 channels doesnt really matter much. So I see value in
> protecting the pidgin process from reading OTR materials outside
> pidgin-otr, and hardening pidgin against network input, I see less value
> into closing the dbus from the user for themselves.

Paul the real problem here is broadcasting sensitive info
over DBUS. If the sender chooses not to log this info
so that they don't end up on the disk, there is no way
for pidgin to enforce the same security policy to the
3rd party (possibly unrelated) apps that sit on the
other end of DBUS. Such an app might accidentally log these
messages because it cannot qualify that they were meant to be
private.

Hope this helps,

Dimitris


From hyc at symas.com  Mon Feb 27 18:09:59 2012
From: hyc at symas.com (Howard Chu)
Date: Mon, 27 Feb 2012 15:09:59 -0800
Subject: [OTR-dev] private messages on dbus
In-Reply-To: <4F4C0956.7040004@census-labs.com>
References: <4EF05D3E.5020907@census-labs.com>
	<d60900010bdd820d9893fdc451dc8a94@hxbc.us>
	<4EF12D25.1040403@census-labs.com>
	<4F490A2F.1030601@census-labs.com>
	<alpine.LFD.2.02.1202271739250.22392@bofh.nohats.ca>
	<4F4C0956.7040004@census-labs.com>
Message-ID: <4F4C0D47.1080600@symas.com>

Dimitris Glynos wrote:
> On 02/28/2012 12:43 AM, Paul Wouters wrote:
>> I am still a bit confused how serious this issue really is. If you can
>> read as the uid of the user, you can already read the OTR keys from
>> disk. Now PFS will prevent decrypting, but whether you listen in on dbus
>> or the X11 channels doesnt really matter much. So I see value in
>> protecting the pidgin process from reading OTR materials outside
>> pidgin-otr, and hardening pidgin against network input, I see less value
>> into closing the dbus from the user for themselves.
>
> Paul the real problem here is broadcasting sensitive info
> over DBUS. If the sender chooses not to log this info
> so that they don't end up on the disk, there is no way
> for pidgin to enforce the same security policy to the
> 3rd party (possibly unrelated) apps that sit on the
> other end of DBUS. Such an app might accidentally log these
> messages because it cannot qualify that they were meant to be
> private.

That sounds like a bug in the 3rd party code then, since pidgin marks its 
messages with PURPLE_MESSAGE_NO_LOG if they should not be logged, and the otr 
plugin will turn off conversation logging if the user chooses that.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


From dimitris at census-labs.com  Mon Feb 27 18:35:00 2012
From: dimitris at census-labs.com (Dimitris Glynos)
Date: Tue, 28 Feb 2012 01:35:00 +0200
Subject: [OTR-dev] private messages on dbus
In-Reply-To: <4F4C0D47.1080600@symas.com>
References: <4EF05D3E.5020907@census-labs.com>
	<d60900010bdd820d9893fdc451dc8a94@hxbc.us>
	<4EF12D25.1040403@census-labs.com>
	<4F490A2F.1030601@census-labs.com>
	<alpine.LFD.2.02.1202271739250.22392@bofh.nohats.ca>
	<4F4C0956.7040004@census-labs.com> <4F4C0D47.1080600@symas.com>
Message-ID: <4F4C1324.4080906@census-labs.com>

On 02/28/2012 01:09 AM, Howard Chu wrote:
> Dimitris Glynos wrote:
>> On 02/28/2012 12:43 AM, Paul Wouters wrote:
>>> I am still a bit confused how serious this issue really is. If you can
>>> read as the uid of the user, you can already read the OTR keys from
>>> disk. Now PFS will prevent decrypting, but whether you listen in on dbus
>>> or the X11 channels doesnt really matter much. So I see value in
>>> protecting the pidgin process from reading OTR materials outside
>>> pidgin-otr, and hardening pidgin against network input, I see less value
>>> into closing the dbus from the user for themselves.
>>
>> Paul the real problem here is broadcasting sensitive info
>> over DBUS. If the sender chooses not to log this info
>> so that they don't end up on the disk, there is no way
>> for pidgin to enforce the same security policy to the
>> 3rd party (possibly unrelated) apps that sit on the
>> other end of DBUS. Such an app might accidentally log these
>> messages because it cannot qualify that they were meant to be
>> private.
> 
> That sounds like a bug in the 3rd party code then, since pidgin marks
> its messages with PURPLE_MESSAGE_NO_LOG if they should not be logged,
> and the otr plugin will turn off conversation logging if the user
> chooses that.

Well, actually it doesn't do that :-)

I have logging disabled, but as you can see below the other
end of DBUS only sees PURPLE_MESSAGE_SEND / PURPLE_MESSAGE_RECV
switched on.

signal sender=:1.11 -> dest=(null destination)
path=/im/pidgin/purple/PurpleObject;
interface=im.pidgin.purple.PurpleInterface; member=WroteImMsg
   int32 66666
   string "anonymized at example.com"
   string "this is a test"
   int32 77777
   uint32 1 <------------- PURPLE_MESSAGE_SEND
...
signal sender=:1.11 -> dest=(null destination)
path=/im/pidgin/purple/PurpleObject;
interface=im.pidgin.purple.PurpleInterface; member=ReceivedImMsg
   int32 66666
   string "anonymized at example.com"
   string "ok"
   int32  77777
   uint32 2 <------------- PURPLE_MESSAGE_RECV

And I mentioned logging only as an example. There is no way to make
sure that the 3rd party apps on the other end of DBUS adhere
to the same security policies enforced by the sender.

So, a suggestion is to create a new type for private messages.
By default private messages should not be broadcasted over DBUS
or be logged. Users will have the option of changing this
if they want to.

Regards,

Dimitris


From hyc at symas.com  Mon Feb 27 19:06:35 2012
From: hyc at symas.com (Howard Chu)
Date: Mon, 27 Feb 2012 16:06:35 -0800
Subject: [OTR-dev] private messages on dbus
In-Reply-To: <4F4C1324.4080906@census-labs.com>
References: <4EF05D3E.5020907@census-labs.com>
	<d60900010bdd820d9893fdc451dc8a94@hxbc.us>
	<4EF12D25.1040403@census-labs.com>
	<4F490A2F.1030601@census-labs.com>
	<alpine.LFD.2.02.1202271739250.22392@bofh.nohats.ca>
	<4F4C0956.7040004@census-labs.com> <4F4C0D47.1080600@symas.com>
	<4F4C1324.4080906@census-labs.com>
Message-ID: <4F4C1A8B.70406@symas.com>

Dimitris Glynos wrote:
> On 02/28/2012 01:09 AM, Howard Chu wrote:
>> Dimitris Glynos wrote:
>>> On 02/28/2012 12:43 AM, Paul Wouters wrote:
>>>> I am still a bit confused how serious this issue really is. If you can
>>>> read as the uid of the user, you can already read the OTR keys from
>>>> disk. Now PFS will prevent decrypting, but whether you listen in on dbus
>>>> or the X11 channels doesnt really matter much. So I see value in
>>>> protecting the pidgin process from reading OTR materials outside
>>>> pidgin-otr, and hardening pidgin against network input, I see less value
>>>> into closing the dbus from the user for themselves.
>>>
>>> Paul the real problem here is broadcasting sensitive info
>>> over DBUS. If the sender chooses not to log this info
>>> so that they don't end up on the disk, there is no way
>>> for pidgin to enforce the same security policy to the
>>> 3rd party (possibly unrelated) apps that sit on the
>>> other end of DBUS. Such an app might accidentally log these
>>> messages because it cannot qualify that they were meant to be
>>> private.
>>
>> That sounds like a bug in the 3rd party code then, since pidgin marks
>> its messages with PURPLE_MESSAGE_NO_LOG if they should not be logged,
>> and the otr plugin will turn off conversation logging if the user
>> chooses that.
>
> Well, actually it doesn't do that :-)

Ah you're right, my mistake. Sounds to me like, independent of any other 
issues, it *should* do that.

> And I mentioned logging only as an example. There is no way to make
> sure that the 3rd party apps on the other end of DBUS adhere
> to the same security policies enforced by the sender.

True.

> So, a suggestion is to create a new type for private messages.
> By default private messages should not be broadcasted over DBUS
> or be logged. Users will have the option of changing this
> if they want to.

Unfortunately, the purple API only lets the receiving-*-msg handler touch the 
msgflags. For sending, the flags aren't passed along, so this would require 
another API change to accommodate that.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


From tomkiewicz.groups at gmail.com  Wed Feb 29 11:15:15 2012
From: tomkiewicz.groups at gmail.com (Tomasz Wasilczyk)
Date: Wed, 29 Feb 2012 17:15:15 +0100
Subject: Google Summer of Code 2012
Message-ID: <CA+24i=e+09Tf1vtETCyYkz9Cx4g-MFBji7ESvBE15c8SMbh54w@mail.gmail.com>

Hi,

are there any plans for Pidgin/libpurple to participate in GSoC 2012?
I am interested in taking part in this edition as a student and I
would be happy to take advantage of this chance to develop our
project. Also, I have some ideas for GSoC Pidgin projects, if there
are no eligible ones ;).

Mentoring organizations can apply from 27th February (2 days ago) to
9th March (1 week and 2 days left). Please consider applying, I would
rather code for Pidgin, than for any other project.

Greetings,
Tomasz Wasilczyk (CPW)