Enforcing TLS for GNU ELPA

Enforcing TLS for GNU ELPA

[Vasilij Schneidermann]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

Some time ago I've contributed a change to a certain package
repository's webserver setup that responds to http:// requests with a
301 redirect to the https:// version.  Should the same be done for GNU
ELPA?  Why/why not?

Some data points for the "why not" faction I've discovered after that
change:

- 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.
- Emacs versions below 26.1 are affected by a HTTPS proxy bug [1] that
  makes life in corporate environments hard.
- The initializer of `package-archives` already generates the
  appropriate URL, so this will affect people who have redefined that
  variable and break their setup for no reason.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Enforcing TLS for GNU ELPA

[Vasilij Schneidermann]

[-- Attachment #1: Type: text/plain, Size: 194 bytes --]

> - Emacs versions below 26.1 are affected by a HTTPS proxy bug [1] that
>   makes life in corporate environments hard.

The bug in question: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11788

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Enforcing TLS for GNU ELPA

[Stefan Monnier]

> Some time ago I've contributed a change to a certain package
> repository's webserver setup that responds to http:// requests with a
> 301 redirect to the https:// version.  Should the same be done for GNU
> ELPA?  Why/why not?

I'd vote for no: I'm happy to encourage the use of `https` but that
would prevent access over `http` which doesn't seem like
a friendly choice.

I'm not sure what would be the benefits (and for whom).

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

We could emit a disapproving message from package.el when gnutls is
unavailable (same thing for PGP, incidentally).


        Stefan

Re: Enforcing TLS for GNU ELPA

[tomas]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

On Mon, Oct 19, 2020 at 06:30:17PM -0400, Stefan Monnier wrote:
> > Some time ago I've contributed a change to a certain package
> > repository's webserver setup that responds to http:// requests with a
> > 301 redirect to the https:// version.  Should the same be done for GNU
> > ELPA?  Why/why not?
> 
> I'd vote for no: I'm happy to encourage the use of `https` but that
> would prevent access over `http` which doesn't seem like
> a friendly choice.
> 
> I'm not sure what would be the benefits (and for whom).

[...]

Wholeheartedly agree. Strongly suggest, warmly encourage: by all
means. Enforce, no.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Enforcing TLS for GNU ELPA

[Jean Louis]

* Vasilij Schneidermann <mail@vasilij.de> [2020-10-20 01:11]:
> Some time ago I've contributed a change to a certain package
> repository's webserver setup that responds to http:// requests with a
> 301 redirect to the https:// version.  Should the same be done for GNU
> ELPA?  Why/why not?
> 
> Some data points for the "why not" faction I've discovered after that
> change:
> 
> - 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.

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.

> - The initializer of `package-archives` already generates the
>   appropriate URL, so this will affect people who have redefined that
>   variable and break their setup for no reason.

There is reason of security, it could be announced in new Emacs
version. Provided it is done.

Re: Enforcing TLS for GNU ELPA

[Vasilij Schneidermann]

[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]

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

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

> There is reason of security, it could be announced in new Emacs
> version. Provided it is done.

Yes, an announcement would be required in any case.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Enforcing TLS for GNU ELPA

[Jean Louis]

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