Re: [Pan-users] SSL not supported?

[Duncan]

Mike Brown posted on Thu, 21 Jun 2012 00:43:32 -0500 as excerpted:

> On Wed, Jun 20, 2012 at 10:17:06PM -0700, Joe Zeff wrote:
>> I'm using Fedora 16 and Pan 0.135.  You should be able to get an update
>> from the standard repos.  What distro are you using?
> 
> Fedora 14 x86-64.  I have a friend that went to 15 and absolutely hates
> the Gnome massive change.  16 is supposed to have "fixed" a little bit
> of it, but I gather Gnome still sucks, so I have not changed to either
> version.  It seems he is not the only one who hates the "new" Gnome.
> 
> In any event, a yum update of pan gets nothing.  Doing a yum install of
> pan just stops with yum reporting that pan 0.133 is the latest.
> 
> So I tried to do a compile of pan 0.138, only to have the configure fail
> on the gmime test.  It complains that 2.4, or later, doesn't exist, yet
> a yum install (I know there are other ways to get a list of installed
> packages,
> this is just faster, in case it isn't installed) reports that gmime
> 2.5.1-1....
> is installed.
> 
> Kinda hard to compile something when configure doesn't correctly find
> installed packages.

I'm with JZ, except that I'm a kde guy... on gentoo so I compile from 
source via script, but that means it's easy, since everything is compiled 
from source via script.  Anyway, gentoo and from-source lets me build 
kde4 without the semantic-desktop stuff, which slows down the system, 
taking memory, etc, without for me being useful enough to pay-back for 
the slow-down.

But if you want to stay with the gnome2 side, try either mate or cinnamon 
on a distro that has them.  One is a continuing maintained gnome2, the 
other gnome3 but adapted back toward gnome2 work-alike.  Either of those, 
or JZ's xfce or lxde, being the other two gtk-based desktops (xfce a 
middle ground between the heavier gnome/kde and the light stuff, lxde a 
lighter weight desktop).  Between the four choices, you can probably find 
something that fits.



Meanwhile, here I believe is the direct answer to your compile-from-
sources problem:  Binary distros (unlike gentoo but like Fedora) often 
split libraries into run-time library package and dependent-package built-
time "devel" package.  Since you're attempting to build pan from sources, 
you need the "devel" package as well as the runtime library.

Note that if you just install the one, you'll probably get past that and 
have the same problem with a different library.  Probably the easiest way 
to avoid that one-at-a-time "dependency hell" is to first try getting the 
srpm of the existing pan version (0.133) and try rebuilding it, or at 
least "pretend" to rebuild it.  That'll give you a list of packages it 
needs to install first, probably mostly the development packages since 
you already have the runtimes installed, and you can then take that list 
and install the devel packages of versions corresponding to what you have 
now, checking the pan site to get the list of current dependencies in 
case you need to update various libs, to get at least most of them at 
once.


One package you'll almost certainly have to upgrade is gnutls, since pan 
requires a quite recent version.  If you look back a couple days on the 
list, you'll see a thread explaining how to tell pan that it doesn't 
really need such a high version, but you'll probably still have to 
upgrade, as the version you have most likely simply won't work -- wrong 
API.

One caveat, however.  Do check what other packages require gnutls, and be 
sure to check them after you upgrade it.  It's possible you'll either 
have to upgrade them as well, or at least rebuild them, due in the first 
case to API changes, in the second to ABI changes even if the same API is 
maintained.

One more dependency (and possibly even pan) upgrading hint:  If you've 
not yet discovered it, take a look at rpmfind.net.  This lets you check 
dependencies, etc, and you can often find rpms for either newer distro 
versions or different distros that work with your distro version too.  At 
least that was my experience back on Mandrake, quite some years ago.  But 
I've always been leading edge, not trailing edge, so I was always trying 
to install stuff that the distro hadn't packaged even in its latest 
version yet.  So while it was great for me and it could well work for 
you, it's possible it doesn't work quite so well for trailing end.  You'd 
just have to try it and see.


Finally, there's another option that will let you continue using current 
pan and still connect via SSL.  However, it's a bit complicated and while 
I understand the idea, I've never personally tried it -- but some here 
have, so you have people to ask if you decide to try this.  The idea is 
to use a package called stunnel as a sort of secure local proxy.  You 
configure it to listen on a loopback interface port (normally 127.0.0.1, 
likely standard nntp port 119 for your first server, perhaps 120 for your 
second if you have more than one, etc) for a connection from pan, which 
it then relays over its secure-tunnel (thus the name, stunnel) to the 
remote server.  Then instead of configuring pan to connect to that remote 
server directly, you tell it to connect to the loopback interface, port 
119 or whatever, that you setup stunnel listening on.

This is certainly more complicated than pan doing it by itself, but pan 
simply didn't support ssl itself until very recently, and this was the 
workaround people who needed a secure connection with pan had used for... 
well, pretty much all of pan's (or stunnel's if it's newer, I don't know) 
existence, I guess.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman