bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on w32

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 24 May 2013 23:27:07 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Cc: 14380@debbugs.gnu.org,  joaotavora@gmail.com
>> Date: Fri, 24 May 2013 15:48:20 -0400
>> 
EZ> What risk? what responsibility?
>> 
>> The risk is that their version of GnuTLS is out of date.

EZ> That happens with dozens of packages on each user's machine.  There's
EZ> nothing in GnuTLS that makes it unique in this regard.

Yes, of course.  I don't know the other packages we require to enable
extra features on W32, sorry.  I think GnuTLS is somewhat unique in this
regard by being the only way to do secure communications with the
outside world, but it's worth considering putting the other packages
under the same mechanism as GnuTLS for installations and updates.

EZ> Moreover, the latest and greatest GnuTLS sometimes simply won't build
EZ> on some systems.  Like with the latest release, for example.  How is
EZ> it a good idea to upgrade to a version that is broken?  And if the
EZ> latest version is not always the one to upgrade to, then who will make
EZ> the research required to tell users to which version to upgrade?
EZ> You?

Yes, possibly.

EZ> I did that research for the single version whose Windows port I made
EZ> available.  I built it, fixed the build problems, tested it, fixed the
EZ> problems revealed by that, and after doing all that I could in good
EZ> faith tell people they can use that version without too much fear.
EZ> Why is it safer for users to upgrade to a newer version than to stay
EZ> with the one I tested?  Shouldn't whoever wants to tell them to
EZ> upgrade invest a similar effort in that newer version?  If she
EZ> doesn't, she is actually shifting the responsibility to the users
EZ> anyway!

You're right.  It's a lot of work.  I appreciate it very much.  I hope
to be able to find the resources to make these reviews happen.

>> Installing and keeping GnuTLS up to date should not be the
>> responsibility of the user.

EZ> Says you.  But since there's no one else to pick up the gauntlet,
EZ> that's where this responsibility will need to rest.  If J.R. Hacker
EZ> needs GnuTLS today, he has no one else but himself to rely on.  All
EZ> we, the Emacs developers, do is just talk.

I like to ask before I make changes, hence my request for votes in
emacs-devel.  Sorry if it seems like empty talk to you.

>> As far as I know GnuTLS status is back to "kosher."

EZ> Not sure based on what you say this.

Monitoring the GnuTLS mailing lists.  I don't mean there are no issues,
only that the FSF has not made a statement about changing its preference
for GnuTLS.

>> I see it as a responsibility we're avoiding.  But if we had these
>> regular builds, how would the user know about a critical update he
>> really must install?
>> 
>> See here http://bugs.python.org/issue17425 for an example of how the
>> Python community dealt with an security issue in the OpenSSL libraries
>> they ship for Windows.  I guess we have to answer the question of
>> whether that's a standard we as Emacs developers should aspire to, or
>> not.

EZ> I'm sorry, but you are expecting from the Emacs development something
EZ> it can never provide in its present shape and form.  Tracking security
EZ> issues to this degree in even a single package is a very time
EZ> consuming job.  Unless we have several volunteers on board taking
EZ> responsibility for the various packages which Emacs supports, what you
EZ> seem to want is nothing more than a pipe dream.  I don't see any such
EZ> volunteers; in fact, I don't even see a single one.  If we had such an
EZ> individual, my year-old port would have been replaced by newer ones
EZ> already.  (Of course, the Windows build in GnuTLS is regularly broken,
EZ> so it's not really easy, either.)  Until that changes, all this talk
EZ> is just a huge waste of energy.

EZ> If you think this kind of effort is possible, how about if you present
EZ> a complete realistic plan for having a secure Emacs, name individuals
EZ> who would test the releases of those packages for security issues, and
EZ> make sure any problems that are detected are promptly fixed on all
EZ> platforms we support, etc.?  Otherwise, let's just stop these endless
EZ> discussions and admit that we don't have the resources to live up to
EZ> it.

I'm trying to get the work started by first and foremost deciding if
Emacs as a project wants to do this at all.  This is a decision for the
maintainers and you've voted against it on emacs-devel, so let's see
what the vote count is and what the maintainers say.

If the maintainers are OK with this direction, I will start working on
automating the builds (which will need your help initially, if you're
willing, to replicate your build process), asking for volunteers, and
packaging the libraries.  I don't have a 5-year plan but hope to get far
enough to make it something sustainable.

Ted