[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"><<a
> href="mailto:address@hidden"
> target="_blank">address@hidden</a>></
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>
> > I ran into something similar recently when I applied the latest
> packages to<br>
> > my Debian Testing system. It just hangs when trying to open the
> connection.<br>
> > It appears to already be in the bug tracking system, having to do
> with SSL<br>
> > connections. I switched to using non-SSL connecting through
> stunnel4 and<br>
> > 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