From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <76f962c60801171105i4447dfe9vd080e4a26e484b71@mail.gmail.com> Date: Thu, 17 Jan 2008 19:05:22 +0000 From: "Lou Kamenov" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] p9p upas In-Reply-To: <140e7ec30801170058g76a4774cj192c287731bf7b12@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <140e7ec30801170058g76a4774cj192c287731bf7b12@mail.gmail.com> Topicbox-Message-UUID: 30f48ab0-ead3-11e9-9d60-3106f5b1d025 On Jan 17, 2008 8:58 AM, sqweek wrote: > Howdy, > I've been trying to get upas going over imaps here at work. Finally > today I noticed src/cmd/upas/nfs and inferred the n is for "new" so > had a play. The source served as documentation but I didn't manage to > get very far before some program called "stunnel" started whinging at > me. > OK, so it turns out stunnel is an SSL wrapper thingy. Fair enough. > After a bit of investigation I discovered why it was complaining - > upas/nfs was written for stunnel3, and then they went and completely > ballsed up the interface for stunnel4[1]. Seriously, what the fuck > were they thinking... anyway, after a failed attempt at writing a > wrapper for stunnel3 style arguments in stunnel4 I went to look for an > stunnel3 package and ran across a perl wrapper[2]. > The wrapper works, though of course I had to modify upas/nfs/imap.c > to exec it instead of /usr/sbin/stunnel directly. Now I'm off to play > with acme Mail, but I figure this information will be useful to anyone > else trying to get setup. I used a mix of two programs from ucspi-tcp (mconnect-io) and ucspi-ssl (sslclient). Though, you need to edit the mconnect-io source and strip the crlf it tries to send. This setup works pretty well on FreeBSD. > if(threadspawnl(fd, "/usr/local/bin/sslclient", "sslclient", "-RHl0", "-X", server, "993", "/usr/local/bin/mconnect-ionocrlf", nil) < 0){ cheers, l