pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] Pan broken on Ubuntu Raring?


From: Duncan
Subject: Re: [Pan-users] Pan broken on Ubuntu Raring?
Date: Sun, 19 May 2013 06:49:38 +0000 (UTC)
User-agent: Pan/0.140 (Chocolate Salty Balls; GIT b00f96e /usr/src/portage/src/egit-src/pan2)

Jim Reiss posted on Sat, 18 May 2013 22:49:42 -0600 as excerpted:

[Full quote left in to hopefully demonstrate...]

> https://bugzilla.gnome.org/show_bug.cgi?id=698902
> 
> 
> 
> On Sat, May 18, 2013 at 8:05 PM, walt
> <address@hidden> wrote:
> 
> 
>>
>> On 05/18/2013 12:21 PM, Jim Reiss wrote:
>>
>> > I ran into something similar recently when I applied the latest
>> > packages
>> to
>> > my Debian Testing system.  It just hangs when trying to open the
>> connection.
>> > It appears to already be in the bug tracking system, having to do
>> > with
>> SSL
>> > connections.  I switched to using non-SSL connecting through stunnel4
>> > and was able to connect.
>>
>> Hi Jim. Can you give me a link to that bug report?
>>
>>
>>
>> _______________________________________________ Pan-users mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/pan-users
>>
> <div dir="ltr"><a
> href="https://bugzilla.gnome.org/show_bug.cgi?id=698902";>https://
bugzilla.gnome.org/show_bug.cgi?id=698902</a><br><br></div><div
> class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 18,
> 2013 at 8:05 PM, walt <span dir="ltr">&lt;<a
> href="mailto:address@hidden";
> target="_blank">address@hidden</a>&gt;</
span>
> wrote:<br>
> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px
> #ccc solid;padding-left:1ex"><div class="im"><br>
> <br>
> On 05/18/2013 12:21 PM, Jim Reiss wrote:<br>
> <br>
> &gt; I ran into something similar recently when I applied the latest
> packages to<br>
> &gt; my Debian Testing system.  It just hangs when trying to open the
> connection.<br>
> &gt; It appears to already be in the bug tracking system, having to do
> with SSL<br>
> &gt; connections.  I switched to using non-SSL connecting through
> stunnel4 and<br>
> &gt; was able to connect.<br>
> <br>
> </div>Hi Jim. Can you give me a link to that bug report?<br>
> <div class="HOEnZb"><div class="h5"><br>
> <br>
> <br>
> _______________________________________________<br>
> Pan-users mailing list<br>
> <a
> href="mailto:address@hidden";>Pan-
address@hidden</a><br>
> <a href="https://lists.nongnu.org/mailman/listinfo/pan-users";
> target="_blank">https://lists.nongnu.org/mailman/listinfo/pan-users</
a><br>
> </div></div></blockquote></div><br></div>
> _______________________________________________
> Pan-users mailing list address@hidden
> https://lists.nongnu.org/mailman/listinfo/pan-users


Please:

1) Turn off the HTML, at least when posting to the pan list.  There's a 
reason pan doesn't post in or parse HTML.  Please respect it on the pan 
list, even if you can't respect that basic netiquette elsewhere.

2) ?redro esrever ni gnitsop ekil yllamron uoy oD

(That's reversed: Do you normally like posting in reverse order?)

Again, there's a reason pan warns about top posting.  It violates 
netiquette and makes proper in-context replies nearly impossible without 
manually tearing the whole thing apart and reordering it.  Please reply 
in context, aka point-by-point inline or at the bottom if you're only 
replying to a single point, with long quotes edited to just the point-
context you're replying to (unless there's a specific reason not to, as 
is sometimes the case with technical posts or for demonstration, as 
here).  Again, how you reply in personal correspondence isn't really my 
business, but do consider this method for public newsgroups and mailing 
lists as it definitely makes things easier, and if /nowhere/ else, at 
/least/ please honor pan's own policies on the pan list, as many people 
actually read it as a newsgroup using pan itself, via gmane.org's 
list2news service.

To the bug at hand...

Two possibilities:

1) Ubuntu's pan may have been built with SSL turned off this time.  There 
were some problems with gnutls (the library pan uses for SSL/TLS support) 
going LGPLv3+ for a few versions, that the Debian maintainer actually 
brought to our attention here, as that's incompatible with pan's GPLv2-
only.  As a result, I believe Debian shipped with the SSL support turned 
off for a bit for legal reasons, and Ubuntu being a Debian downstream may 
well have done the same.

(FWIW, gnutls' switch to LGPLv3+ apparently caused enough problems with 
other depending apps as well, that they eventually switched back to LGPLv2
+, thus making it legal once again for people to distribute GPLv2-only 
apps linked to it, so the problem should be resolved at least with 
current enough gnutls, but it's possible the problem either wasn't 
resolved soon enough for U/RR, or they're shipping one of possibly still 
affected versions of gnutls.)

I /think/ if SSL/TLS support is turned off, the security settings that 
normally appear at the bottom of the server settings dialog are missing, 
in which case it should be easy to tell if support is compiled in or not 
by whether those settings are there, but I'm not /sure/ of that.

Similarly, I'd guess that an SSL-disabled pan encountering a config for a 
previous version with it enabled, would still try to use the same port as 
previously configured, but obviously without the SSL, which would 
probably fail.  Which would explain...

2) It could be some other incompatibility between pan and whatever gnutls 
Ubuntu shipped, or there may be a (possibly distro-patch-triggered) bug 
in their gnutls or pan.

This possibility might print some output to pan's STDERR, and thus be 
visible if pan is run from a command prompt or with STDERR redirected to 
a file.

It's also possible to use netstat and ngrep to help diagnose network 
connections.  Netstat is of course used to see current connections, and 
ngrep can then be used to grep for activity on one or more of them.  If 
you see plain text passing over what should be a secure connection, pan's 
apparently trying to use the secure port for plain text, as I guessed it 
would if it hadn't been built with secure support but was run against a 
config previously used by a secure-supporting pan.  You can also use ngrep 
to see just what /is/ passing over the port, if pan's attempting a secure 
connection but it's not being successfully negotiated for some reason.

-- 
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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]