* Enforcing TLS for GNU ELPA
@ 2020-10-19 22:10 Vasilij Schneidermann
2020-10-19 22:20 ` Vasilij Schneidermann
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Vasilij Schneidermann @ 2020-10-19 22:10 UTC (permalink / raw
To: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Enforcing TLS for GNU ELPA
2020-10-19 22:10 Enforcing TLS for GNU ELPA Vasilij Schneidermann
@ 2020-10-19 22:20 ` Vasilij Schneidermann
2020-10-19 22:30 ` Stefan Monnier
2020-10-20 9:05 ` Jean Louis
2 siblings, 0 replies; 7+ messages in thread
From: Vasilij Schneidermann @ 2020-10-19 22:20 UTC (permalink / raw
To: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Enforcing TLS for GNU ELPA
2020-10-19 22:10 Enforcing TLS for GNU ELPA Vasilij Schneidermann
2020-10-19 22:20 ` Vasilij Schneidermann
@ 2020-10-19 22:30 ` Stefan Monnier
2020-10-20 7:50 ` tomas
2020-10-20 9:05 ` Jean Louis
2 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2020-10-19 22:30 UTC (permalink / raw
To: emacs-devel
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Enforcing TLS for GNU ELPA
2020-10-19 22:30 ` Stefan Monnier
@ 2020-10-20 7:50 ` tomas
0 siblings, 0 replies; 7+ messages in thread
From: tomas @ 2020-10-20 7:50 UTC (permalink / raw
To: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Enforcing TLS for GNU ELPA
2020-10-19 22:10 Enforcing TLS for GNU ELPA Vasilij Schneidermann
2020-10-19 22:20 ` Vasilij Schneidermann
2020-10-19 22:30 ` Stefan Monnier
@ 2020-10-20 9:05 ` Jean Louis
2020-10-20 10:07 ` Vasilij Schneidermann
2 siblings, 1 reply; 7+ messages in thread
From: Jean Louis @ 2020-10-20 9:05 UTC (permalink / raw
To: emacs-devel
* 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Enforcing TLS for GNU ELPA
2020-10-20 9:05 ` Jean Louis
@ 2020-10-20 10:07 ` Vasilij Schneidermann
2020-10-20 11:38 ` Jean Louis
0 siblings, 1 reply; 7+ messages in thread
From: Vasilij Schneidermann @ 2020-10-20 10:07 UTC (permalink / raw
To: Jean Louis; +Cc: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Enforcing TLS for GNU ELPA
2020-10-20 10:07 ` Vasilij Schneidermann
@ 2020-10-20 11:38 ` Jean Louis
0 siblings, 0 replies; 7+ messages in thread
From: Jean Louis @ 2020-10-20 11:38 UTC (permalink / raw
To: emacs-devel
* 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-10-20 11:38 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-10-19 22:10 Enforcing TLS for GNU ELPA Vasilij Schneidermann
2020-10-19 22:20 ` Vasilij Schneidermann
2020-10-19 22:30 ` Stefan Monnier
2020-10-20 7:50 ` tomas
2020-10-20 9:05 ` Jean Louis
2020-10-20 10:07 ` Vasilij Schneidermann
2020-10-20 11:38 ` Jean Louis
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.