You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(1) |
Mar
|
Apr
(7) |
May
(17) |
Jun
(2) |
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(2) |
Jun
(22) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2004 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
|
From: <gai...@li...> - 2005-09-18 19:20:20
|
CLCUMPXAVV eeIleramIA lvAtronbA= L eiLripaiG= I btIadexeRU rexraSmiacia = nAM $1 $3$3 21 = 33.75 http://www.armualitie.co= m ill and even aged poet was entering the veranda of Griboedovs. It was now = You wanted to move into his rooms? Azazello twanged as soulfully as |
|
From: <gai...@li...> - 2005-09-09 05:24:52
|
Call out Gouranga be happy!!! Gouranga Gouranga Gouranga .... That which brings the highest happiness!! |
|
From: <gai...@li...> - 2005-09-08 06:46:18
|
VaLeUlCiM= eViXaAmCePr livitralriagnabileop umtraamisdi= araxenbrexecia $3 $1 $3 75.21.33= http://www.dowasedrate.c= om clothing, and which the executioners had rejected, called two of them and = actions, now, this evening, were no less important than the mornings |
|
From: <gai...@li...> - 2005-09-06 14:47:51
|
AmMeVaPrCiCeViXaUlLe biriliopal= leagnatrvi endiaumeciaisbrexraxamtra $3 $1 $3 75.21.33 http://www.banahoder.com individually. There are only world celebrities here. = Nod to that one ... at Again and again justice must be done to the = investigation. Every |
|
From: <gai...@li...> - 2005-09-04 15:30:32
|
LeAmVaXaMeCiCePrUlVi vibilinarialleoptrag traenumxdi= aisbrexeciaamra $3 $1= $3 75.21.33 http://www.tradefringem.com See what La Fontaine fables I have to listen to! = Stuck him with four squinted near-sightedly at the bursting-in Ivan and, = obviously mistaking him |
|
From: <gai...@li...> - 2005-08-23 14:04:23
|
Hello, executioners rode in these carts. They were followed on horseback by = the `It is, of course, not much to have done, but all the same I did = it.anyone, landed near no. 302-bis on Sadovaya Street. `How could he = not be? the redhead replied. Hes there at the end of But the = matter straight away clarified itself.him whisde. Im overcome with = sadness before the long journey. Isnt itsolemn reception. = Transparent naiads stopped their round dance over thealso happens the = other way round - oh, how it does! So, so, so, the doctor said = and, turning to Ivan, added: Hello What else? He has some = passion, perhaps?and neither of them could refute the other. They did = not agree with eachdiplomatic politeness. The majority of our = population consciously and longthe sturdiest psychic make-up out of = their minds. To say nothing of suchbetter in the country, especially in = spring. `And I really look like a hallucination. Note my = profile in thelong time, trying to grasp what it might mean. |
|
From: <gai...@li...> - 2005-06-23 18:36:46
|
Dear Buyer,
Senwer Sports Co., Ltd. is one of theleading bag manufacturers and a global famous brand bags' OEM in China.
Our products include backpacks,travel bags, sport bags, diaper bags, duffel bags, trolleys, wallets, cooler bags,
school bags, suitcases, camera bags, shoulder bags, shopping bags, luggage, water bags,cosmetic bags,shoe bags,
pencil bags, tool bags, CD holders, PP/PVC bags, promotional bags etc.
Senwer's factories, founded in 1988, with 2100 workers and annual output of USD 30 million/year, have superior equipments
and technology, advanced samples and product quality testing system and control system. We have an experienced management
team, seasoned craftsmen, complete customer service, and a strong economic business plan. Our goods have met with great favor
in Europe, America, Japan, and elsewhere because of their excellent quality, beautiful design and reasonable pricing.
ITEM: SJ195(BACKPACK)
SIZE:43cm*31.7cm*12cm
FABRIC:600D*300D/PU
LINING:210D POLYESTER
PACKING:45cm*34cm*40cm/25PCS
PRICE:FOB XIAMEN,CHINA USD1.66/PC
DESCRIPTION:
1.Large main compartment
2.Front zippered pocket
3.Fully padded back panel
4.Padded shoulder straps with D-rings
5.Webbing haul loop
6.Zipper slider cords
We have improved our website again, pls check it for more detail.
You are welcome to visit us here in Quanzhou, or contact us at the address and phone numbers listed below.
Yours sincerely
Rachel
Mob:0086-13960286700
---------------------------------------------
SENWER SPORTS CO., LTD.
ADD.: Wancheng Ge 511/516, Citong Road,
Quanzhou 362000, China.
Tel: +86-595-22216499 Fax: +86-595-22214455
---------------------------------------------
|
|
From: <gai...@li...> - 2004-05-29 18:44:17
|
Important Message to MY Downline, I just received an urgent warning email from the accounts department of the online business that you joined a few months back. They told me that you have not yet confirmed acceptance of your last months stats or money earned. If you don't do this immediately then not only will you miss being paid out, it will also mean I don't get paid my over rides which will be very sad as I am owed $12,152USD this month. Please, simply visit this link and log into your account and accept your stats statement and collect your earnings so I can get mine too. Please, click here: http://ftbb.captureform.biz/capture/ftbb/affiliates.htm Many Thanks In Advance Ken Please note: ------------------------------------------------------------------------ This is an automatic email delivered to my downline via e-soft ware. If you feel that I've breached your privacy or you would simply prefer not to receive any further reminders, please click this link or copy this URL into your browser>> http://ftbb.captureform.biz/capture/ftbb/removeme.htm and you will be immediately and automatically unsubscribed from my downline list. If this email has been received in error please accept my apologies. |
|
From: <gai...@li...> - 2004-02-20 07:43:02
|
Mike, Well the status is that a lot of things happened in my life right now, and gaim-e got put on the backburner. I haven't written it off forever, just haven't had time to deal with it in a long time. I'm in the navy, and things got busy all of a sudden. That being said, feel free to play with the CVS code. There is a lot of good stuff in there. First you will have to update some areas of the code to get it to work with the latest gaim (There have been a few api changes since I last got my hands on it) If you want to take the code and fork it, that is up to you. If you want to just send me patches, I'll commit them as soon as I get them. (I'm in Japan, so it might be a few hours before I see them) No matter what you decide to do, I'll help your effort. I'm here if you have any questions about the code, and how we did things. I hope to be able to work on gaim-e when I have a more time in a few months. (around May timeframe) good luck Eric --- gai...@li... wrote: > Hi there, > > I've been thinking about writing a gpgme plugin for > gaim for some time and now I've just discovered > gaim-e :-) > > So, I was wondering what the status of the project > is? I've noticed that the code in CVS hasn't been > touched for ages and the latest mailing list archive > entries are also about 8 months old ... > > Also, have you ever build a windoze version of the > plugin? > > Thanks > Mike > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps > Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id56&alloc_id438&op=click > _______________________________________________ > Gaim-e-developer mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-e-developer __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools |
|
From: <gai...@li...> - 2004-02-20 06:27:31
|
Hi there, I've been thinking about writing a gpgme plugin for gaim for some time = and now I've just discovered gaim-e :-) So, I was wondering what the status of the project is? I've noticed that = the code in CVS hasn't been touched for ages and the latest mailing list = archive entries are also about 8 months old ...=20 Also, have you ever build a windoze version of the plugin? Thanks Mike |
|
From: <gai...@li...> - 2003-12-19 18:30:17
|
The ChessBrain Network T o be removed from our mailing list, send an email to su...@ch... |
|
From: <gai...@li...> - 2003-07-18 00:40:44
|
FROM=3A MRS=2EMARIAM SANI ABACHA STRICTLY PRIVATE Dear Sir=2C PROPOSAL FOR THE RE TRANSFER OF US$45=2E5 MILLION UNITED STATES DOLLARS=2E I take liberty to introduce my humble self to you and permit me to write you=2E I am MRS MARIAM ABACHA =28WIDOW=29 the wife of Late General Sani Abacha Former Head of state of the defunct Military Government of Nigeria=2C who was killed=2C while in office in 1998=2E After these=2C the Present Democratic Elected Government of OLUSEGUN OBASANJO took over in 1999 as a result of Military misrule over the years=2C during the tenure of Late General Abacha =28my inlaw=29 he enriched and accumulated a lot of money while in office=2C but unfortunately for him the man died=2E This money was lodged in different banks abroad in America=2C Canada=2C Europe and Africa=2E Etc=2E However=2C the present Government succeeded in Frozening most of these Accounts and have so far recalled these money back to the country=2C with exception of the money deposited in a valt with AMICABLE SECURITY COMPANY in Cotonou Republic of Benin undiscovered up til date=2E And due to sanction placed on the family by the Present Government I can not reach this money nor withdraw it to Nigeria for use=2E Otherwise=2C we have jointly decided within the family to relocate this funds out abroad for investment=2E This is the only ways and means we can utilize this money wisely=2E Consequently=2C we beg for your assistance in investing this money ie=2E Purchase factory =28s=29=2C Estate and any other viable venture you might suggest=2E I got your contact through your country =28s=29 Embassy=2C as a trustworthy and reliable person we believe strongly=2C you will not disappoint us=2C we have also agreed to give you 30% of the total amount as share in this business=2C at the end of the day=2E Finally=2C we require the following information to facilitate and normalization of documentation with the Security Company=2E =28a=29 Your complete name =28b=29 Your Telephone=2FFax Numbers =28c=29 Complete Bank Account Numbers and Addresses=2E Again=2C all arrangement and logistics of this transaction are in place as you are free and secured in this transaction=2C you will be glad you did and we shall remain grateful=2E I most faithfully look forward to hear from you=2E Thanks in anticipations=2E Best regards=2C MRS=2EMARIAM SANI ABACHA N=2FB=3APLEASE FOR CONFIRMATION CHECK THIS WEB=2ESITE =28www=2Eecondad=2Eorg=2FAbachaLaunch=2Ehtm=29 |
|
From: <gai...@li...> - 2003-07-02 03:59:10
|
On Tue, 2003-07-01 at 18:58, gai...@li... wrote: > can someone plz clarify against which gnupg and friends versions should > the latest version gaim-e be compiled...=20 >=20 > Thanxs in advance=20 >=20 > Best Regards I have gpg 1.2.2, gpgme 0.4.0, and libgcrypt 1.1.12 installed. I am not sure what the minimum versions of each are since I have not taken a look at that yet. Hope this helps, mistwolf |
|
From: <gai...@li...> - 2003-07-02 01:58:26
|
can someone plz clarify against which gnupg and friends versions should the latest version gaim-e be compiled...=20 Thanxs in advance=20 Best Regards --=20 Ant=C3=B3nio Meireles <ant...@ep...> epandemic.com - inform=C3=A1tica e comunica=C3=A7=C3=A3o lda=20 ________________________________________________________________________ a.k.a. datashark <dat...@ge...> Gentoo Linux - enabling the future |
|
From: <gai...@li...> - 2003-06-24 23:00:14
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ceterus parabus(all things being equal), I think interoperable IM is a good thing(tm). However, the popularity of the SSL schemes overlooks a key feature of using our methodology. Unless you pay a certification authority, you don't know who you're talking to, just that it is secure. The security of our method relies in strong gpg public and private keys and the web of trust that goes along with them. Since we encrypt a session key with gpg and then use that for the encryption of the chat, we incur less overhead than using gpg to encrypt and decrypt every IM. This is especially true if the gpg/pgp keys are sufficently large. With gaim now being available on windows, perhaps we should look more at how we could get our plugin to work there, as well as publishing an interoperability document. Adam Schreiber gai...@li... wrote: > I like the concept, honestly... but I have reservations. > > Secure IM is a noble concept and absolutely must be promoted. Making our > modules interoperate would definitely promote popularity of all the > various IM encryption options users enjoy today. That's a good thing! > > However... we also need to offer options. If a security hole is exposed, > not in the algorithms we use, but in our protocols then all secure IM > solutions adhering to that standard would be vulnerable. Keeping our > codebases completely seperate in both form and concept is the only > defense the world as a whole has to protocol vulnerabilities--because > other drop-in solutions are available at all times. > > There are also other technical problems that Dario touched on. gaim-e > has opted to employ gpg as our crypto engine. other IM solutions use > SSL. the two schemes are basically entirely incompatible. If all > codebases out there adopt a standard, one has to win--somebody will be > rewriting their entire codebase. (afaik gaim-e will be doing that for > 2.0 anyways...) > > If we decide to rewrite gaim to be <catchy name>Universal Secure > IM-friendly</catchy name>, we 1) will have to react faster to protocol > vulnerabilities, since a wider audience is affected, and 2) we lessen > our freedom to alter our protocol as needed. > > I like the idea. Can we make it work? > > Stu > >> From: gai...@li... >> Reply-To: gai...@li... >> To: Alan Humpherys <al...@us...> >> CC: Gaim-e Developer Mailing List >> <gai...@li...>, >> gai...@li... >> Subject: [Gaim-e-developer] Re: [Gaim-devel] Support for Secure IM >> across multiple clients and services >> Date: 23 Jun 2003 20:54:57 -0700 >> MIME-Version: 1.0 >> Received: from sc8-sf-list1.sourceforge.net ([66.35.250.206]) by >> mc9-f40.bay6.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, >> 23 Jun 2003 20:55:53 -0700 >> Received: from sc8-sf-list2-b.sourceforge.net ([10.3.1.14] >> helo=sc8-sf-list2.sourceforge.net)by sc8-sf-list1.sourceforge.net with >> esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian))id >> 19UeuP-0008CT-00for <stu...@us...>; Mon, 23 Jun >> 2003 20:55:53 -0700 >> Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] >> helo=sc8-sf-list1.sourceforge.net)by sc8-sf-list2.sourceforge.net with >> esmtp (Exim 3.31-VA-mm2 #1 (Debian))id 19Ueu1-0002gJ-00; Mon, 23 Jun >> 2003 20:55:29 -0700 >> Received: from outbound01.telus.net ([199.185.220.220] >> helo=priv-edtnes61.telusplanet.net)by sc8-sf-list1.sourceforge.net >> with esmtp (Exim 3.31-VA-mm2 #1 (Debian))id 19Uesh-0006gM-00; Mon, 23 >> Jun 2003 20:54:07 -0700 >> Received: from akjz4447y503c.bc.hsia.telus.net >> ([207.6.33.36]) by priv-edtnes61.telusplanet.net >> (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with >> ESMTP id >> <200...@ak...>; >> Mon, 23 Jun 2003 21:54:01 -0600 >> X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP >> In-Reply-To: <D80...@us...> >> References: <D80...@us...> >> Organization: Message-Id: >> <105...@ak...> >> X-Mailer: Ximian Evolution 1.2.4- Sender: >> gai...@li... >> Errors-To: gai...@li... >> X-BeenThere: gai...@li... >> X-Mailman-Version: 2.0.9-sf.net >> Precedence: bulk >> List-Help: >> <mailto:gai...@li...?subject=help> >> List-Post: <mailto:gai...@li...> >> List-Subscribe: >> <https://lists.sourceforge.net/lists/listinfo/gaim-e-developer>,<mailto:gai...@li...?subject=subscribe> >> >> List-Id: <gaim-e-developer.lists.sourceforge.net> >> List-Unsubscribe: >> <https://lists.sourceforge.net/lists/listinfo/gaim-e-developer>,<mailto:gai...@li...?subject=unsubscribe> >> >> List-Archive: >> <http://sourceforge.net/mailarchive/forum.php?forum=gaim-e-developer> >> X-Original-Date: 23 Jun 2003 20:54:57 -0700 >> Return-Path: gai...@li... >> X-OriginalArrivalTime: 24 Jun 2003 03:55:53.0263 (UTC) >> FILETIME=[820C4BF0:01C33A04] >> >> Hello Alan, >> >> I understand the need for a common encryption mechanism. And I >> understand that some work is being done in this respect. >> >> However, there are a couple of points that I would like to share with >> you. >> >> 1) gaim does not support encryption unless the protocol itself supports >> it, or at least gaim will support it in the future. >> >> 2) encryption on gaim is handled by two plugins, gaim-e and >> gaim-encryption, so your best bet would be to contact them directly. >> >> 3) current IM encryption methods uses two different approaches >> : a) GPG based encryption, gaim-e, fire, and miranda use this method >> (afaik) >> b) SSL based encryption, gaim-encryption and trillian uses this >> method >> (afaik) >> >> 4) trillian is closed-source, so I am not sure how co-operative they are >> going to be. >> >> Chances are you are already aware of this points, but just in case you >> don't I thought I would write them down. >> >> Both gaim-e and gaim-encryption can be found on sourceforge. >> >> I hope to hear more on this. I have forward it to the gaim-e dev >> mailing list >> >> Sincerely, >> >> Dario >> >> PS: I am the UI developer for gaim-e. >> >> On Mon, 2003-06-23 at 15:20, Alan Humpherys wrote: >> > Hello, >> > >> > Hopefully I am sending this to the right address, so that it eventually >> > gets to the right person. >> > >> > I am one of the main developers of "Fire" (Multi-protocol IM client >> > for Mac OS X) an open source freeware project also hosted at >> > sourceforge.net. ( You can visit our web site at http://fire.sf.net ) >> > >> > I am writing because I have a desire to promote better interoperability >> > of Secure IM between various third party IM clients. At the present >> > time, Fire, GAIM, and Trillian all support mechanisms for encryption of >> > Instant Messages, however all three use incompatible schemes, and >> > therefore can only be used when both ends of the conversation are using >> > the same client. >> > >> > I would like to create a working group whose focus is promoting >> > interoperability of Secure Instant Messaging. As one of the leaders in >> > the third-party IM client world, I believe strongly that this effort >> > will only be successful if your team is involved in it. >> > >> > Working Group Charter >> > --------- >> > The creation of an open standard that any IM client creator can follow >> > to provide interoperable Secure Instant Messaging across any IM >> service. >> > >> > Technical Scope >> > --------- >> > 1. Key Exchange methodology and protocols >> > 2. Message Encryption >> > - Selection of algorithm(s) >> > 3. Message Signing >> > - Selection of algorithm(s) >> > 4. Definition of data payload structure >> > - Markers indicating >> > algorithm >> > signing status >> > encryption status >> > - Data format and encoding >> > 5. Detection of compatible client on other end of conversation >> > >> > Technical Challenges to Address >> > --------- >> > 1. Data payload length limitations on some services >> > - Some data payloads (like keys or long signatures) may need to be >> > broken apart and reassembled. >> > 2. Packet frequency limitations on some services >> > - AIM rate throttling >> > 3. Server interpretation of data >> > - Some IRC servers truncate messages after the first newline/return >> > - Some services may not deal with null bytes >> > - Some services may only deal with 7-byte ASCII >> > 4. Allowance for disconnected operation >> > - Yahoo, MSN, Jabber allow offline messages to be sent >> > 5. Reasonable operation with non-compatible clients. >> > - Ensure that secure messages sent to non secure clients can be >> > understood by the remote user to be an encrypted message, that their >> > client can't decipher. >> > 6. Compliance with applicable laws and patent restrictions. >> > 7. Secure messaging in a group chat environment. >> > 8. Backward compatibility with our existing client bases >> > >> > There are probably other issues to address, but this is a first attempt >> > at outlining them. I don't intend to overly formalize this process, >> > nor make it take more time than necessary. The goal is to build upon >> > the three great solutions we already have, and come to an agreement on >> > a common solution we can all move forward with. >> > >> > Please have the right person contact me at your earliest convenience so >> > we can discuss this further. >> > >> > Thank you, >> > Alan Humpherys >> > -- >> > Fire Development Team >> > al...@us... >> > >> > >> > >> > ------------------------------------------------------- >> > This SF.Net email is sponsored by: INetU >> > Attention Web Developers & Consultants: Become An INetU Hosting >> Partner. >> > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly >> Commission! >> > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >> > _______________________________________________ >> > Gaim-devel mailing list >> > Gai...@li... >> > https://lists.sourceforge.net/lists/listinfo/gaim-devel >> << signature.asc >> > > > _________________________________________________________________ > Help STOP SPAM with the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Gaim-e-developer mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-e-developer > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE++Nf2jU1oaHEI4wgRAp2AAJ9Dt516xLOgti7Z6oasNkcazyXouQCggs+6 Mtf82J1dLeHvkBg48YQJjwE= =QRTd -----END PGP SIGNATURE----- |
|
From: <gai...@li...> - 2003-06-24 21:44:33
|
I like the concept, honestly... but I have reservations. Secure IM is a noble concept and absolutely must be promoted. Making our modules interoperate would definitely promote popularity of all the various IM encryption options users enjoy today. That's a good thing! However... we also need to offer options. If a security hole is exposed, not in the algorithms we use, but in our protocols then all secure IM solutions adhering to that standard would be vulnerable. Keeping our codebases completely seperate in both form and concept is the only defense the world as a whole has to protocol vulnerabilities--because other drop-in solutions are available at all times. There are also other technical problems that Dario touched on. gaim-e has opted to employ gpg as our crypto engine. other IM solutions use SSL. the two schemes are basically entirely incompatible. If all codebases out there adopt a standard, one has to win--somebody will be rewriting their entire codebase. (afaik gaim-e will be doing that for 2.0 anyways...) If we decide to rewrite gaim to be <catchy name>Universal Secure IM-friendly</catchy name>, we 1) will have to react faster to protocol vulnerabilities, since a wider audience is affected, and 2) we lessen our freedom to alter our protocol as needed. I like the idea. Can we make it work? Stu >From: gai...@li... >Reply-To: gai...@li... >To: Alan Humpherys <al...@us...> >CC: Gaim-e Developer Mailing List <gai...@li...>, > gai...@li... >Subject: [Gaim-e-developer] Re: [Gaim-devel] Support for Secure IM across >multiple clients and services >Date: 23 Jun 2003 20:54:57 -0700 >MIME-Version: 1.0 >Received: from sc8-sf-list1.sourceforge.net ([66.35.250.206]) by >mc9-f40.bay6.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 23 Jun >2003 20:55:53 -0700 >Received: from sc8-sf-list2-b.sourceforge.net ([10.3.1.14] >helo=sc8-sf-list2.sourceforge.net)by sc8-sf-list1.sourceforge.net with >esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian))id >19UeuP-0008CT-00for <stu...@us...>; Mon, 23 Jun 2003 >20:55:53 -0700 >Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] >helo=sc8-sf-list1.sourceforge.net)by sc8-sf-list2.sourceforge.net with >esmtp (Exim 3.31-VA-mm2 #1 (Debian))id 19Ueu1-0002gJ-00; Mon, 23 Jun 2003 >20:55:29 -0700 >Received: from outbound01.telus.net ([199.185.220.220] >helo=priv-edtnes61.telusplanet.net)by sc8-sf-list1.sourceforge.net with >esmtp (Exim 3.31-VA-mm2 #1 (Debian))id 19Uesh-0006gM-00; Mon, 23 Jun 2003 >20:54:07 -0700 >Received: from akjz4447y503c.bc.hsia.telus.net ([207.6.33.36]) by >priv-edtnes61.telusplanet.net (InterMail vM.5.01.05.17 >201-253-122-126-117-20021021) with ESMTP id ><200...@ak...>; > Mon, 23 Jun 2003 21:54:01 -0600 >X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP >In-Reply-To: <D80...@us...> >References: <D80...@us...> >Organization: Message-Id: ><105...@ak...> >X-Mailer: Ximian Evolution 1.2.4- Sender: >gai...@li... >Errors-To: gai...@li... >X-BeenThere: gai...@li... >X-Mailman-Version: 2.0.9-sf.net >Precedence: bulk >List-Help: ><mailto:gai...@li...?subject=help> >List-Post: <mailto:gai...@li...> >List-Subscribe: ><https://lists.sourceforge.net/lists/listinfo/gaim-e-developer>,<mailto:gai...@li...?subject=subscribe> >List-Id: <gaim-e-developer.lists.sourceforge.net> >List-Unsubscribe: ><https://lists.sourceforge.net/lists/listinfo/gaim-e-developer>,<mailto:gai...@li...?subject=unsubscribe> >List-Archive: ><http://sourceforge.net/mailarchive/forum.php?forum=gaim-e-developer> >X-Original-Date: 23 Jun 2003 20:54:57 -0700 >Return-Path: gai...@li... >X-OriginalArrivalTime: 24 Jun 2003 03:55:53.0263 (UTC) >FILETIME=[820C4BF0:01C33A04] > >Hello Alan, > >I understand the need for a common encryption mechanism. And I >understand that some work is being done in this respect. > >However, there are a couple of points that I would like to share with >you. > >1) gaim does not support encryption unless the protocol itself supports >it, or at least gaim will support it in the future. > >2) encryption on gaim is handled by two plugins, gaim-e and >gaim-encryption, so your best bet would be to contact them directly. > >3) current IM encryption methods uses two different approaches >: a) GPG based encryption, gaim-e, fire, and miranda use this method >(afaik) > b) SSL based encryption, gaim-encryption and trillian uses this method >(afaik) > >4) trillian is closed-source, so I am not sure how co-operative they are >going to be. > >Chances are you are already aware of this points, but just in case you >don't I thought I would write them down. > >Both gaim-e and gaim-encryption can be found on sourceforge. > >I hope to hear more on this. I have forward it to the gaim-e dev >mailing list > >Sincerely, > >Dario > >PS: I am the UI developer for gaim-e. > >On Mon, 2003-06-23 at 15:20, Alan Humpherys wrote: > > Hello, > > > > Hopefully I am sending this to the right address, so that it eventually > > gets to the right person. > > > > I am one of the main developers of "Fire" (Multi-protocol IM client > > for Mac OS X) an open source freeware project also hosted at > > sourceforge.net. ( You can visit our web site at http://fire.sf.net ) > > > > I am writing because I have a desire to promote better interoperability > > of Secure IM between various third party IM clients. At the present > > time, Fire, GAIM, and Trillian all support mechanisms for encryption of > > Instant Messages, however all three use incompatible schemes, and > > therefore can only be used when both ends of the conversation are using > > the same client. > > > > I would like to create a working group whose focus is promoting > > interoperability of Secure Instant Messaging. As one of the leaders in > > the third-party IM client world, I believe strongly that this effort > > will only be successful if your team is involved in it. > > > > Working Group Charter > > --------- > > The creation of an open standard that any IM client creator can follow > > to provide interoperable Secure Instant Messaging across any IM service. > > > > Technical Scope > > --------- > > 1. Key Exchange methodology and protocols > > 2. Message Encryption > > - Selection of algorithm(s) > > 3. Message Signing > > - Selection of algorithm(s) > > 4. Definition of data payload structure > > - Markers indicating > > algorithm > > signing status > > encryption status > > - Data format and encoding > > 5. Detection of compatible client on other end of conversation > > > > Technical Challenges to Address > > --------- > > 1. Data payload length limitations on some services > > - Some data payloads (like keys or long signatures) may need to be > > broken apart and reassembled. > > 2. Packet frequency limitations on some services > > - AIM rate throttling > > 3. Server interpretation of data > > - Some IRC servers truncate messages after the first newline/return > > - Some services may not deal with null bytes > > - Some services may only deal with 7-byte ASCII > > 4. Allowance for disconnected operation > > - Yahoo, MSN, Jabber allow offline messages to be sent > > 5. Reasonable operation with non-compatible clients. > > - Ensure that secure messages sent to non secure clients can be > > understood by the remote user to be an encrypted message, that their > > client can't decipher. > > 6. Compliance with applicable laws and patent restrictions. > > 7. Secure messaging in a group chat environment. > > 8. Backward compatibility with our existing client bases > > > > There are probably other issues to address, but this is a first attempt > > at outlining them. I don't intend to overly formalize this process, > > nor make it take more time than necessary. The goal is to build upon > > the three great solutions we already have, and come to an agreement on > > a common solution we can all move forward with. > > > > Please have the right person contact me at your earliest convenience so > > we can discuss this further. > > > > Thank you, > > Alan Humpherys > > -- > > Fire Development Team > > al...@us... > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: INetU > > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > > _______________________________________________ > > Gaim-devel mailing list > > Gai...@li... > > https://lists.sourceforge.net/lists/listinfo/gaim-devel ><< signature.asc >> _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail |
|
From: <gai...@li...> - 2003-06-24 03:54:09
|
Hello Alan, I understand the need for a common encryption mechanism. And I understand that some work is being done in this respect. However, there are a couple of points that I would like to share with you. 1) gaim does not support encryption unless the protocol itself supports it, or at least gaim will support it in the future. 2) encryption on gaim is handled by two plugins, gaim-e and gaim-encryption, so your best bet would be to contact them directly. 3) current IM encryption methods uses two different approaches : a) GPG based encryption, gaim-e, fire, and miranda use this method (afaik) b) SSL based encryption, gaim-encryption and trillian uses this method (afaik) 4) trillian is closed-source, so I am not sure how co-operative they are going to be. Chances are you are already aware of this points, but just in case you don't I thought I would write them down. Both gaim-e and gaim-encryption can be found on sourceforge. I hope to hear more on this. I have forward it to the gaim-e dev mailing list Sincerely, Dario PS: I am the UI developer for gaim-e. On Mon, 2003-06-23 at 15:20, Alan Humpherys wrote: > Hello, >=20 > Hopefully I am sending this to the right address, so that it eventually=20 > gets to the right person. >=20 > I am one of the main developers of "Fire" (Multi-protocol IM client=20 > for Mac OS X) an open source freeware project also hosted at=20 > sourceforge.net. ( You can visit our web site at http://fire.sf.net ) >=20 > I am writing because I have a desire to promote better interoperability=20 > of Secure IM between various third party IM clients. At the present=20 > time, Fire, GAIM, and Trillian all support mechanisms for encryption of=20 > Instant Messages, however all three use incompatible schemes, and=20 > therefore can only be used when both ends of the conversation are using=20 > the same client. >=20 > I would like to create a working group whose focus is promoting=20 > interoperability of Secure Instant Messaging. As one of the leaders in=20 > the third-party IM client world, I believe strongly that this effort=20 > will only be successful if your team is involved in it. >=20 > Working Group Charter > --------- > The creation of an open standard that any IM client creator can follow=20 > to provide interoperable Secure Instant Messaging across any IM service. >=20 > Technical Scope > --------- > 1. Key Exchange methodology and protocols > 2. Message Encryption > - Selection of algorithm(s) > 3. Message Signing > - Selection of algorithm(s) > 4. Definition of data payload structure > - Markers indicating > algorithm > signing status > encryption status > - Data format and encoding > 5. Detection of compatible client on other end of conversation >=20 > Technical Challenges to Address > --------- > 1. Data payload length limitations on some services > - Some data payloads (like keys or long signatures) may need to be=20 > broken apart and reassembled. > 2. Packet frequency limitations on some services > - AIM rate throttling > 3. Server interpretation of data > - Some IRC servers truncate messages after the first newline/return > - Some services may not deal with null bytes > - Some services may only deal with 7-byte ASCII > 4. Allowance for disconnected operation > - Yahoo, MSN, Jabber allow offline messages to be sent > 5. Reasonable operation with non-compatible clients. > - Ensure that secure messages sent to non secure clients can be=20 > understood by the remote user to be an encrypted message, that their=20 > client can't decipher. > 6. Compliance with applicable laws and patent restrictions. > 7. Secure messaging in a group chat environment. > 8. Backward compatibility with our existing client bases >=20 > There are probably other issues to address, but this is a first attempt=20 > at outlining them. I don't intend to overly formalize this process,=20 > nor make it take more time than necessary. The goal is to build upon=20 > the three great solutions we already have, and come to an agreement on=20 > a common solution we can all move forward with. >=20 > Please have the right person contact me at your earliest convenience so=20 > we can discuss this further. >=20 > Thank you, > Alan Humpherys > -- > Fire Development Team > al...@us... >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel |
|
From: <gai...@li...> - 2003-06-23 03:59:03
|
hmmm...sorry to say this, but I think I completely broke the cvs copy. I am posting a few fixes, so at least now it compiles and loads, but that is all it does. I am going to try to figure out what the problem is....I think it is the ifndefs for GAIM_0_65 that I put in there, but I am not sure. Again, sorry for this. Dario On Sun, 2003-06-22 at 17:29, gai...@li... wrote: > ok, >=20 > I clean up the code a bit, removed unneeded variables and beautified the > code a bit >=20 > I also added missing #ifdefs to compile code that is pertinet to gtk2 > (so it will not compile the code if we use another ui), added #ifdefs > for when gaim 0.65 is released (by defining GAIM_0_65, it will compile > for 0.65 and by undefining it it will compile for 0.63/0.64), added > prefs for auto key fetching, and I think that is it. >=20 > Well, back to debugging and creating the ui changes for auto key > fetching. >=20 > Dario |
|
From: <gai...@li...> - 2003-06-23 00:28:24
|
ok, I clean up the code a bit, removed unneeded variables and beautified the code a bit I also added missing #ifdefs to compile code that is pertinet to gtk2 (so it will not compile the code if we use another ui), added #ifdefs for when gaim 0.65 is released (by defining GAIM_0_65, it will compile for 0.65 and by undefining it it will compile for 0.63/0.64), added prefs for auto key fetching, and I think that is it. Well, back to debugging and creating the ui changes for auto key fetching. Dario |
|
From: <gai...@li...> - 2003-06-22 22:02:57
|
On Sun, 2003-06-22 at 13:56, gai...@li... wrote: > The whole point of gpgme is to make it uneccesary to call gpg from system= ()=20 > calls... so I think the keyserver functions would be an appropriate reque= st. >=20 True. However, as we have found, gpgme currently lacks some aspects that we would like implemented. Making the keyserver code into its own function(s) would make it easier to replace once gpgme supports this functionality. > I see your point too. if gpgme can snag a key from the server then we rea= lly=20 > don't care how gpg behaves on default, or about it's config file. we can=20 > just keep the users gaim-e pref recorded in our own files and make gpg=20 > behave the way we want it to. >=20 I already added the necessary code to the prefs system so that we don't have to worry about modifying gpg.conf (you had an earlier concern about this). I am currently debugging the plugin code, and will be adding the ui functions as I get to that file. Currently there are two new prefs, autofetch key (boolean for enabling/disabling this ability) and keyserver (a string containing the user selected, default keyserver). > however if we have to call gpg from a system() call there's no reason not= to=20 > in my mind. we literally have to do it once per key (cause gpg will polit= ely=20 > put it in the users keyring). that's an acceptable overhead hit. >=20 > Stu hmmm...forgot about the overhead cost involved in calling system....but I think you are right, the functions should only be called once per new key. Dario |
|
From: <gai...@li...> - 2003-06-22 20:56:53
|
The whole point of gpgme is to make it uneccesary to call gpg from system() calls... so I think the keyserver functions would be an appropriate request. I see your point too. if gpgme can snag a key from the server then we really don't care how gpg behaves on default, or about it's config file. we can just keep the users gaim-e pref recorded in our own files and make gpg behave the way we want it to. however if we have to call gpg from a system() call there's no reason not to in my mind. we literally have to do it once per key (cause gpg will politely put it in the users keyring). that's an acceptable overhead hit. Stu >From: gai...@li... >Reply-To: gai...@li... >To: gai...@li... >Subject: Re: [Gaim-e-developer] Re: Auto retrieval of keys >Date: Sun, 22 Jun 2003 14:02:04 -0500 >MIME-Version: 1.0 >Received: from sc8-sf-list1.sourceforge.net ([66.35.250.206]) by >mc2-f16.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 22 >Jun 2003 12:03:48 -0700 >Received: from sc8-sf-list2-b.sourceforge.net ([10.3.1.14] >helo=sc8-sf-list2.sourceforge.net)by sc8-sf-list1.sourceforge.net with >esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian))id >19UA7w-0003Sz-00for <stu...@us...>; Sun, 22 Jun 2003 >12:03:48 -0700 >Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] >helo=sc8-sf-list1.sourceforge.net)by sc8-sf-list2.sourceforge.net with >esmtp (Exim 3.31-VA-mm2 #1 (Debian))id 19UA7b-00062k-00; Sun, 22 Jun 2003 >12:03:27 -0700 >Received: from smtp1.knology.net ([24.214.63.226])by >sc8-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian))id >19UA6J-0002wV-00for <gai...@li...>; Sun, 22 Jun >2003 12:02:08 -0700 >Received: (qmail 23922 invoked from network); 22 Jun 2003 19:02:05 -0000 >Received: from unknown (HELO clemson.edu) (24.236.84.195) by >smtp1.knology.net with SMTP; 22 Jun 2003 19:02:05 -0000 >X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP >Message-ID: <3EF...@cl...> >User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) >Gecko/20030514 >X-Accept-Language: en-us, en >References: <BAY...@ho...> >In-Reply-To: <BAY...@ho...> >X-Enigmail-Version: 0.74.3.0 >X-Enigmail-Supports: pgp-inline, pgp-mime >Sender: gai...@li... >Errors-To: gai...@li... >X-BeenThere: gai...@li... >X-Mailman-Version: 2.0.9-sf.net >Precedence: bulk >List-Help: ><mailto:gai...@li...?subject=help> >List-Post: <mailto:gai...@li...> >List-Subscribe: ><https://lists.sourceforge.net/lists/listinfo/gaim-e-developer>,<mailto:gai...@li...?subject=subscribe> >List-Id: <gaim-e-developer.lists.sourceforge.net> >List-Unsubscribe: ><https://lists.sourceforge.net/lists/listinfo/gaim-e-developer>,<mailto:gai...@li...?subject=unsubscribe> >List-Archive: ><http://sourceforge.net/mailarchive/forum.php?forum=gaim-e-developer> >X-Original-Date: Sun, 22 Jun 2003 14:02:04 -0500 >Return-Path: gai...@li... >X-OriginalArrivalTime: 22 Jun 2003 19:03:48.0861 (UTC) >FILETIME=[033562D0:01C338F1] > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Yeah, it's in it's own function just like the gaim-e config parsing >function. > >However, it may not be needed because Dario and I have been disussing >just using system() to call gpg directly. Can anyone see a good reason >not to? > >If we were going to bug the gpgme people to change anything, I'd rather >it be to simply add keyserver functions to it. The auto-key-retrieve >function I think only works when a key is needed to encrypt or verify a >signature at this point, and gaim-e doesn't even get that far if a key >is not in the keyring. > >Adam > >gai...@li... wrote: > > hey all, > > Outstanding with the get-key-from-keyservers stuff. that'll make our > > code a lot easier for the average dude to use. > > > > however. there's a little voice inside me trying to point out that we're > > gonna have headaches if the gpg peeps ever change their config file > > format. anyone know how long it's been since they did that? > > > > I don't suppose we could beg the gpgme peeps to put config file > > alteration functions into their code. it just makes a hell of a lot more > > sense there. > > > > I haven't looked at what you guys have done to the code recently. Are we > > keeping the code to interface with the gpg config file in it's own > > function? (makes it easier if we have to change it) > > > > Stu > > > > _________________________________________________________________ > > The new MSN 8: advanced junk mail protection and 2 months FREE* > > http://join.msn.com/?page=features/junkmail > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: INetU > > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > > _______________________________________________ > > Gaim-e-developer mailing list > > Gai...@li... > > https://lists.sourceforge.net/lists/listinfo/gaim-e-developer > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.2 (GNU/Linux) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iD8DBQE+9f0rjU1oaHEI4wgRAkcaAKCu4BGNByPiPD6MLc2p2fKUgbws6QCfauOQ >qAiSMfScj6LtTQLb/FEOs1g= >=wUr6 >-----END PGP SIGNATURE----- > > > >------------------------------------------------------- >This SF.Net email is sponsored by: INetU >Attention Web Developers & Consultants: Become An INetU Hosting Partner. >Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! >INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >_______________________________________________ >Gaim-e-developer mailing list >Gai...@li... >https://lists.sourceforge.net/lists/listinfo/gaim-e-developer _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail |
|
From: <gai...@li...> - 2003-06-22 19:02:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yeah, it's in it's own function just like the gaim-e config parsing function. However, it may not be needed because Dario and I have been disussing just using system() to call gpg directly. Can anyone see a good reason not to? If we were going to bug the gpgme people to change anything, I'd rather it be to simply add keyserver functions to it. The auto-key-retrieve function I think only works when a key is needed to encrypt or verify a signature at this point, and gaim-e doesn't even get that far if a key is not in the keyring. Adam gai...@li... wrote: > hey all, > Outstanding with the get-key-from-keyservers stuff. that'll make our > code a lot easier for the average dude to use. > > however. there's a little voice inside me trying to point out that we're > gonna have headaches if the gpg peeps ever change their config file > format. anyone know how long it's been since they did that? > > I don't suppose we could beg the gpgme peeps to put config file > alteration functions into their code. it just makes a hell of a lot more > sense there. > > I haven't looked at what you guys have done to the code recently. Are we > keeping the code to interface with the gpg config file in it's own > function? (makes it easier if we have to change it) > > Stu > > _________________________________________________________________ > The new MSN 8: advanced junk mail protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Gaim-e-developer mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-e-developer > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+9f0rjU1oaHEI4wgRAkcaAKCu4BGNByPiPD6MLc2p2fKUgbws6QCfauOQ qAiSMfScj6LtTQLb/FEOs1g= =wUr6 -----END PGP SIGNATURE----- |
|
From: <gai...@li...> - 2003-06-22 14:57:11
|
hey all, Outstanding with the get-key-from-keyservers stuff. that'll make our code a lot easier for the average dude to use. however. there's a little voice inside me trying to point out that we're gonna have headaches if the gpg peeps ever change their config file format. anyone know how long it's been since they did that? I don't suppose we could beg the gpgme peeps to put config file alteration functions into their code. it just makes a hell of a lot more sense there. I haven't looked at what you guys have done to the code recently. Are we keeping the code to interface with the gpg config file in it's own function? (makes it easier if we have to change it) Stu _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail |
|
From: <gai...@li...> - 2003-06-22 01:27:52
|
Adam: Godd work. Two things: 1) let me know what you needed the user to select from gaim (maybe only use the functions if the user has set a checkbox allowing gaim-e to auto fetch the keys?) 2) Yeah, send me the tarball...and I'll commit it. Maybe you should talk to Eric about getting on the list as a developer so that you can commit changes directly. (Eric, your thoughts on this? I don't mind doing Adam's commits.) Dario =20 On Sat, 2003-06-21 at 17:12, gai...@li... wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > I have written a function that at the moment just parses > ~/.gnupg/gpg.conf and puts up to 8 keyservers found into an array and > sets a character to 0xFF if the auto-retreive-keys flag is set in > gpg.conf. What we want to do with those, I'm not quite sure. But > really this function is only needed if our users don't want to edit > gpg.conf themselves. I'm not sure about writing out to this file but I > could work on it. That way the user could select from among several key > servers we suggest and add the relevant info to gpg.conf. >=20 > Let me know what you guys think. >=20 > Adam >=20 > Dario, now that I'm 2 days ahead of sf.net anon cvs should I just email > you the tarball? >=20 > gai...@li... wrote: > > Adam/emg: > > > > When either of you start writing the code for auto key retrieval, let m= e > > know what you need in the UI side (dialog boxes, preference settings, > > etc). I'll add it in to the UI code. > > > > If modifying gpg.conf gets too complicated, we can add it to the gaim-e > > preference "file". I say "file", because as of gaim 0.65, we can use > > gaim's preference system and not worry about creating/lodaing/saving ou= r > > own file. Makes it easier to port to windows since the pref system > > already is taking care of the different IO requirements between a *nix > > and a windows system. > > > > Just as an update, gaim devs are talking about finishing their core/UI > > split by 0.67. So there will me more UIs to take care of soon. > > > > Dario > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iD8DBQE+9PR0jU1oaHEI4wgRAixIAJwMYR4+bvVB3uJ6qW7u3PvZdY3VDwCfRTDP > 7iJ8M/ix3fKJwFkn29GQBMU=3D > =3DRvtF > -----END PGP SIGNATURE----- >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Gaim-e-developer mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-e-developer |
|
From: <gai...@li...> - 2003-06-22 00:12:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have written a function that at the moment just parses ~/.gnupg/gpg.conf and puts up to 8 keyservers found into an array and sets a character to 0xFF if the auto-retreive-keys flag is set in gpg.conf. What we want to do with those, I'm not quite sure. But really this function is only needed if our users don't want to edit gpg.conf themselves. I'm not sure about writing out to this file but I could work on it. That way the user could select from among several key servers we suggest and add the relevant info to gpg.conf. Let me know what you guys think. Adam Dario, now that I'm 2 days ahead of sf.net anon cvs should I just email you the tarball? gai...@li... wrote: > Adam/emg: > > When either of you start writing the code for auto key retrieval, let me > know what you need in the UI side (dialog boxes, preference settings, > etc). I'll add it in to the UI code. > > If modifying gpg.conf gets too complicated, we can add it to the gaim-e > preference "file". I say "file", because as of gaim 0.65, we can use > gaim's preference system and not worry about creating/lodaing/saving our > own file. Makes it easier to port to windows since the pref system > already is taking care of the different IO requirements between a *nix > and a windows system. > > Just as an update, gaim devs are talking about finishing their core/UI > split by 0.67. So there will me more UIs to take care of soon. > > Dario > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+9PR0jU1oaHEI4wgRAixIAJwMYR4+bvVB3uJ6qW7u3PvZdY3VDwCfRTDP 7iJ8M/ix3fKJwFkn29GQBMU= =RvtF -----END PGP SIGNATURE----- |