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

[Eli Zaretskii]

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

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

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

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

> The responsibility is to update it regularly.

Or not.  Blindly upgrading could get users in trouble.

> EZ> A user who installs software on her computer is already trusted with
> EZ> certain responsibilities, because a single mistyped command or a badly
> EZ> built package can easily shut down a perfectly healthy system for
> EZ> hours, if not days.  Users install dozens of packages needed to create
> EZ> a workable environment for whatever they need to accomplish.  Why is
> EZ> GnuTLS so special?
> 
> Installing and keeping GnuTLS up to date should not be the
> responsibility of the user.

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

> To put it another way, if you want that responsibility, you're in a very
> small percentage of the Emacs user population.  Most users don't want it
> and will neglect it badly.

Again, nothing new or special here.

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

Not sure based on what you say this.

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

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

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