Some bits of code in C using openSSL that seem to work with Crypt::CBC Blowfish, should work in C++.
http://www.unixdaemons.com/~paul/crypto Cheers Paul On Thu, 13 Mar 2003, Jim Carey wrote: > Hi, > > Here is some communications that I had on this topic with Alan - > > Cheers > > Jim > > "Jim: This is good feedback for us. Thanks. > > Again, we have not yet decided on the future of our sourceforge code. > Whatever we decide, will definately be shared with resellers. > > Please feel free to distribute this email to the rest of discuss-list. > > Regards, Alan > > ----- Original Message ----- > From: "Jim Carey" <[EMAIL PROTECTED]> > To: "'Alan Hutchison'" <[EMAIL PROTECTED]> > Sent: Friday, March 07, 2003 6:09 PM > Subject: RE: Client Code Releases > > > > I found it to be substantially easier than the "legacy" code - it > > allowed addition of credit cards, transaction logging, redirects etc > etc > > all without any - note - ANY - change to the distributed code - a > major > > improvement over the hassles of upgrading that I had to go through for > > years under the old code whenever I had to upgrade. > > > > If you decide not to move forward with the code then, for goodness > sake, > > let people know - there are still mailing list archives that state > > unequivocally that the SF code is the planned direction. Let people > stop > > developing for it and wasting their time. If you don't have commitment > > to it then the reseller will continue to be behind the pack in > > implementing new featues that come out - eg email. > > > > Regards > > > > Jim > > > > -----Original Message----- > > From: Alan Hutchison [mailto:[EMAIL PROTECTED] > > Sent: Saturday, March 08, 2003 9:11 AM > > To: [EMAIL PROTECTED] > > Subject: RE: Client Code Releases > > > > > > Jim: We have received a lot of feedback that the Sourceforge version > is > > to > > difficult for many people. As such, it may not be the ideal solution > > for > > our standardized version. However, the idea of modularity remains > > important > > to us. The strengths/weaknesses of our sourceforge client will > > definitely > > be something that our new Technical Product Manager must assess. > > > > So, Sourceforge is not a dead issue - but at this point we have not > > determined if it will be embraced as our standard code. > > > > Alan > > > > -----Original Message----- > > From: Jim Carey [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 07, 2003 5:22 PM > > To: 'Alan Hutchison' > > Subject: RE: Client Code Releases > > > > > > I see no mention on the future of the SourceForge version that was > > touted as being the future direction of the code - this caused a lot > of > > people to switch - to their detriment in recent times given the > > tardiness in passing specs for new facilities to Paul Sisson. > > > > Is this a dead end or will it be the direction for the future - it > > certainly addresses the issue of modularity and simplicity in carrying > > forward local mods to new releases > > > > Regards > > > > Jim Carey > > www.ozbcoz.com" > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Thursday, March 13, 2003 5:54 AM > To: 'Alan Hutchison'; [EMAIL PROTECTED] > Subject: RE: Client Code Releases > > > So what ever happened to the Grand Design to move to the SourceForge > version of the client? That commitment is at least a year and a half old > with no activity whatsoever. > > -Tim > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Hutchison > > Sent: Friday, March 07, 2003 5:25 PM > > To: [EMAIL PROTECTED] > > Subject: Client Code Releases > > > > > > We have an outstanding commitment to provide all of you with > > visibility into our client code roadmap. Currently we are in > > the process of hiring a Technical Product Manager that will > > be responsible for defining client code releases (dates and > > features) as well as other duties. This position is > > currently posted on our web site at > > http://jobs.tucows.com/jobs3.cgi?LOCATION=1. It is proving > > to be a very challenging position to fill, so we are later > > than anticipated in putting a formal client code roadmap together. > > > > At a high level, I can tell you that our intent regarding > > client code is > > twofold: > > 1) Make the client code more modular so that when updates > > are provided, it will be easier for you to re-integrate your > > customizations > > 2) Provide client code in additional languages besides Perl. > > The first priority will be a PHP version. A Java version is > > also being considered. > > > > In the immediate future our client code release plans are as > > follows (note that the final feature set in each release is > > subject to change): > > > > March 31 > > -------- > > DOMAINS > > - .uk renewals > > EMAIL > > - Email catch all set at time of order > > > > April 15 > > -------- > > DOMAINS > > - .de registration > > CERTS > > - Ability to call expiring certs and place subsequent renewal order > > - Ability to query contacts for existing users > > - Bug fixes related to end user facing error messages > > - Reseller confirmation messages for orders placed through RCL > > > > April 30 > > -------- > > DOMAINS > > - .uk transfers > > > > May 16 > > ------ > > CERTS > > - Ability to flag certificates with auto-renew > > > > May 19 > > ------ > > DOMAINS > > - .de renewals and transfers > > > > > > Regards, > > Alan Hutchison > > Director, Product Management > > Tucows Inc. > > > > > > > > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/2003 > > -- ************************************************ Paul Khavkine Network Administrator TELOSysteme, Groupe Distributel Communications 740 Notre Dame West, Suite 1135 Montreal, Quebec, Canada, H3C 3X6 1-514-877-0064 http://www.distributel.net ************************************************
