Am 09.11.2014 um 17:02 schrieb Kurt Roeckx:
> Package: fetchmail
> Tags: patch
>
> Hi,
>
> The attached patch improves fethcmail SSL/TLS support. It seems
> to have some misunderstandings of openssl / SSL / TLS.
Dear Kurt,
thank you very much for spending time on this matter.
What you are writing is generally correct (while I have not audited your
patch in minute detail).
The SSL support patches that went into fetchmail years ago, from various
authors, in various stages, are flakey and used to be incomplete in
older versions. Some of that was due to the very scattered and
incomplete SSL documentation in general.
Some of the original contributors mingled SSL/TLS versions with the
point in time when negotiation takes place: up front
("SSL/TLS-wrapped"), or in-band after STLS/STARTTLS, or not at all.
The option set fetchmail offers is awkward in 6.x. Sorting this out,
however, isn't easily done without breaking existing semantics. While I
appreciate very much that your change also affects documentation, I fear
the patch is inacceptable for stable releases. (About future releases,
please see the end of this message.)
> First, STARTTLS should work with both SSL and TLS, not just from
> TLS 1.0. The TLS in STARTTLS does not mean it's TLS only, TLS is
> just a different name for SSL.
I understand that, the original contributors did not. (Technically, TLS
1.0 is SSL v3.1, TLS 1.1 SSL v3.2, TLS 1.2 SSL v3.3 during handshakes,
for instance.)
> It also still seems to think only TLS 1.0 is supported while there
> are more recent versions, and it encourages SSL3 because SSL2 is
> broken.
True.
> I've also changed the way in which opportunistic TLS works a
> little. It seems to have only done this with TLS1 for the above
> stated reasons which were wrong.
>
> This patch results in the following changes with a server support
> STARTTLS:
> | --ssl | no option | sslproto ssl23| sslproto tls1
> Old: | TLS 1.2 | TLS1.0 | not working | TLS1.0
> New: | TLS 1.2 | TLS1.2 | TLS1.2 | TLS1.0
>
> The "sslproto ssl23" case just send logout, I assume because
> maybe_tls returns false.
>
> This started by making the call to SSLv3_client_method() optional
> in case openssl doesn't support it.
I am not sure I understand the last two phrases. The next-to-last is
probably a matter of reading code and perhaps debugging (also your later
sslproto "" behaving differently than an omitted sslproto option - this
may have to do with automated repolls for opportunistic TLS).
I am rather loathe to propose/endorse/support changing option semantics
for a stable release; we'd probably need to add new switches.
Please have a look at the current state of fetchmail's "master" (note:
it is non-default, so you'll need to "git checkout master" after
cloning) branch in Git, either here
<https://gitorious.org/fetchmail/fetchmail/source/master:> or here:
<http://sourceforge.net/p/fetchmail/git/ci/master/tree/>
and let me know what you think of the --sslmode and --sslproto as you've
found, if documentation is missing or inaccurate. I would personally
prefer discussion through the fetchmail-devel@ mailing list (which has
public archives, but requires subscrption), but if you can't be
bothered, the Debian BTS will be better than no feedback.
We should then see if we want to backport that without the
obsolete-options-warnings (but perhaps with an --ssl-newstyle option
required to switch semantics) or if we leave that for 7.x.
Thank you very much.
Best regards,
Matthias
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
