Problems updating (M)Elpa packages

Problems updating (M)Elpa packages

[Angelo Graziosi]

The following issue occurs on two machines WiFi connected, one with W10 Home 64 and one with macOS (10.13). I do:

  Options - Manage Emacs packages

a 'Network Security Manager' buffer shows up, containing 'Certificate information', saying that 

'TLS connection to elpa.gnu.org:443 is insicure for the following reasons:

safe renegotiation is not supported, connection not protected...'

and ask to accept the connection

Always
no
session only
...

I do 'session only'.

On the W10 Home machine, 3 years old, this work but on macOS machine, 8 years old, it fails:

'error in process sentinel: Error retrieving: https://elpa.gnu.org/packages/archive-contents (error connection-failed "connect" :host "elpa.gnu.org" :service 443)'

It is the first time I see this after years using (M)Elpa.

The builds regard master of about September 03.

On another machine, dual boot W10 Pro 64 and Gnu/Linux Mint 64, same master builds, ethernet connected, this DOES NOT occur.

Angelo

Re: Problems updating (M)Elpa packages

[Stefan Monnier]

> The following issue occurs on two machines WiFi connected, one with W10 Home
> 64 and one with macOS (10.13). I do:
>
>   Options - Manage Emacs packages
>
> a 'Network Security Manager' buffer shows up, containing 'Certificate information', saying that 
>
> 'TLS connection to elpa.gnu.org:443 is insicure for the following reasons:
>
> safe renegotiation is not supported, connection not protected...'

Apparently this is a bug in Emacs, when TLS-1.3 is used Emacs complains
about the lack of support for "safe renegotiation", but that
functionality has been removed from TLS-1.3 so it's perfectly normal
that it's not supported.

> and ask to accept the connection
>
> Always
> no
> session only
> ...

The right answer is "always" ;-)

[ In any case, if you have GPG installed, the security is enforced by
  checking GPG signatures already, so HTTPS mostly provides a bit of
  privacy.  ]


        Stefan

Re: Problems updating (M)Elpa packages

[Lars Ingebrigtsen]

Angelo Graziosi <angelo.g0@libero.it> writes:

> The following issue occurs on two machines WiFi connected, one with
> W10 Home 64 and one with macOS (10.13). I do:
>
>   Options - Manage Emacs packages
>
> a 'Network Security Manager' buffer shows up, containing 'Certificate
> information', saying that
>
> 'TLS connection to elpa.gnu.org:443 is insicure for the following reasons:
>
> safe renegotiation is not supported, connection not protected...'
>
> and ask to accept the connection

You don't specify what Emacs version you're using, but if this is with
Emacs 27, doing a "git pull" and rebuilding should make this go away.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Problems updating (M)Elpa packages

[Angelo Graziosi]

> Il 22 settembre 2019 alle 17.44 Stefan Monnier ha scritto:
> 
> The right answer is "always" ;-)

Thanks for clarifications and suggestions...

  Angelo

Re: Problems updating (M)Elpa packages

[Angelo Graziosi]

> Il 22 settembre 2019 alle 19.19 Lars Ingebrigtsen ha scritto:
> 
> You don't specify what Emacs version you're using, but if this is with

Really I did! I wrote

>> The builds regard master of about September 03.

So it is Emacs 27, built from master on Sept. 03.

> doing a "git pull" and rebuilding should make this go away.

Let's see at the next build, next week...

BTW, on the W10 Home 64 failing machine, the build is the same I use on W10 Pro 64 and which does not fail. (On windows I build Emacs on W10 Pro 64 and install the result also on W10 Home 64).

  Angelo

Re: Problems updating (M)Elpa packages

[Angelo Graziosi]

> Il 22 settembre 2019 alle 19.19 Lars Ingebrigtsen ha scritto:
> 

> Emacs 27, doing a "git pull" and rebuilding should make this go away.

Building master a33cda168e (Expand time-stamp unit tests to cover all formatting options) seems to work..