Re: Enforcing TLS for GNU ELPA

[Jean Louis <bugs@gnu.support>]

* Vasilij Schneidermann <mail@vasilij.de> [2020-10-20 13:07]:
> > > - There's still Windows users who do not have an installation with the
> > >   gnutls libraries, despite the strong suggestion to download it for the
> > >   full experience.
> > 
> > I would say, sorry, there is no access to Emacs supported packages. If
> > they want without signing, they can find out configuration option.
> > 
> > > - Emacs versions below 26.1 are affected by a HTTPS proxy bug [1] that
> > >   makes life in corporate environments hard.
> > 
> > I would say sorry for that, and would push security.
> 
> What you propose is different: Adjust the default value of
> `package-archives` to always use https:// URLs, whereas I propose a more
> invasive change: Adjust the server-side behavior to not allow any kind
> of opt-out.

That way the SSL security is not enforced from Emacs side, but from
various servers, there can be plethora of ELPArchives online. Then
users depend on each single server.

> > Administrator in corporate environment can provide all allowed or by
> > corporation approved packages to each user, either by making general
> > settings on a single computer, or by entering defaults in
> > /etc/skel/.emacs.d/elpa/you-name-it
> > 
> > Majority of GNU/Linux distributions already have Emacs packages inside
> > of distribution. Some of them have more than few hundred packages.
> > 
> > In that sense, corporate environment is not a problem as BOFH can do
> > it for its users.
> 
> That assumes a different kind of corporate environment where the focus
> is on provisioning users with software known to be safe.  The issue I've
> pointed out is about communication via corporation-mandated proxy being
> impossible, something very different.

Those users can ask for permission and bring their packages on a
storage, as networked ELPA is for network, it assumes people have access.

ELPA can be on storage, it need not be on network, it can be on file
system.