unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#33825: 25.2; Failing to verify signature for ELPA debbugs package
@ 2018-12-21 13:38 clemera
  2018-12-21 23:39 ` Glenn Morris
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: clemera @ 2018-12-21 13:38 UTC (permalink / raw)
  To: 33825

Hi,

I get the following error when I try to install debbugs package:


Failed to verify signature debbugs-0.16.tar.sig:
Bad signature from 474F05837FBDEF9B GNU ELPA Signing Agent 
<elpasign@elpa.gnu.org>
Command output:
gpg: Signature made Wed Oct 17 11:10:03 2018 CEST
gpg:                using DSA key CA442C00F91774F17F59D9B0474F05837FBDEF9B
gpg: BAD signature from "GNU ELPA Signing Agent <elpasign@elpa.gnu.org>" 
[unknown]






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#33825: 25.2; Failing to verify signature for ELPA debbugs package
  2018-12-21 13:38 bug#33825: 25.2; Failing to verify signature for ELPA debbugs package clemera
@ 2018-12-21 23:39 ` Glenn Morris
  2018-12-22 12:08 ` bug#33825: 25.2; , " clemera
  2019-09-13 19:50 ` Stefan Kangas
  2 siblings, 0 replies; 14+ messages in thread
From: Glenn Morris @ 2018-12-21 23:39 UTC (permalink / raw)
  To: clemera; +Cc: 33825

clemera wrote:

> Failed to verify signature debbugs-0.16.tar.sig:
> Bad signature from 474F05837FBDEF9B GNU ELPA Signing Agent
> <elpasign@elpa.gnu.org>
> Command output:
> gpg: Signature made Wed Oct 17 11:10:03 2018 CEST
> gpg:                using DSA key CA442C00F91774F17F59D9B0474F05837FBDEF9B
> gpg: BAD signature from "GNU ELPA Signing Agent
> <elpasign@elpa.gnu.org>" [unknown]

FWIW, it verifies fine here with Emacs 25.2, and also manually using
wget https://elpa.gnu.org/packages/debbugs-0.16.tar and tar.sig.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#33825: 25.2; , Failing to verify signature for ELPA debbugs package
  2018-12-21 13:38 bug#33825: 25.2; Failing to verify signature for ELPA debbugs package clemera
  2018-12-21 23:39 ` Glenn Morris
@ 2018-12-22 12:08 ` clemera
  2018-12-30 12:12   ` Robert Pluim
  2019-09-13 19:50 ` Stefan Kangas
  2 siblings, 1 reply; 14+ messages in thread
From: clemera @ 2018-12-22 12:08 UTC (permalink / raw)
  To: rgm; +Cc: 33825

 > FWIW, it verifies fine here with Emacs 25.2

I tried it again and now it works for me, too. Strange..., what could 
have caused that it failed before?






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#33825: 25.2; , Failing to verify signature for ELPA debbugs package
  2018-12-22 12:08 ` bug#33825: 25.2; , " clemera
@ 2018-12-30 12:12   ` Robert Pluim
  2018-12-30 12:34     ` Clemens Radermacher
  0 siblings, 1 reply; 14+ messages in thread
From: Robert Pluim @ 2018-12-30 12:12 UTC (permalink / raw)
  To: clemera; +Cc: 33825

clemera <clemens.radermacher@posteo.de> writes:

>> FWIW, it verifies fine here with Emacs 25.2
>
> I tried it again and now it works for me, too. Strange..., what could
> have caused that it failed before?

There are 'transparent' proxies which will untar archives and then
retar them, resulting in a file that fails signature verification even
though the contents are identical. When you then repeat the download,
the proxy knows it has previously inspected the file, and thus lets
through the original. Using https solves this issue 99% of the time.

If youʼre using https already, then Iʼm out of ideas :-)

Robert





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#33825: 25.2; , Failing to verify signature for ELPA debbugs package
  2018-12-30 12:12   ` Robert Pluim
@ 2018-12-30 12:34     ` Clemens Radermacher
  2018-12-30 12:55       ` Robert Pluim
  0 siblings, 1 reply; 14+ messages in thread
From: Clemens Radermacher @ 2018-12-30 12:34 UTC (permalink / raw)
  To: 33825; +Cc: rpluim


On 30.12.18 13:12, Robert Pluim wrote:

> There are 'transparent' proxies which will untar archives and then
> retar them, resulting in a file that fails signature verification even
> though the contents are identical. When you then repeat the download,
> the proxy knows it has previously inspected the file, and thus lets
> through the original. Using https solves this issue 99% of the time.

That's interesting thanks! For GNU ELPA I use http indeed, because I rely on Emacs 
taking care of the verification. I don't understand why those proxies should 
unpack archives though, is that for filtering purposes?

-- 
Clemens





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#33825: 25.2; , Failing to verify signature for ELPA debbugs package
  2018-12-30 12:34     ` Clemens Radermacher
@ 2018-12-30 12:55       ` Robert Pluim
  0 siblings, 0 replies; 14+ messages in thread
From: Robert Pluim @ 2018-12-30 12:55 UTC (permalink / raw)
  To: Clemens Radermacher; +Cc: 33825

Clemens Radermacher <clemens.radermacher@posteo.de> writes:

> On 30.12.18 13:12, Robert Pluim wrote:
>
>> There are 'transparent' proxies which will untar archives and then
>> retar them, resulting in a file that fails signature verification even
>> though the contents are identical. When you then repeat the download,
>> the proxy knows it has previously inspected the file, and thus lets
>> through the original. Using https solves this issue 99% of the time.
>
> That's interesting thanks! For GNU ELPA I use http indeed, because I rely on Emacs 
> taking care of the verification. I don't understand why those proxies should 
> unpack archives though, is that for filtering purposes?

In enlightened democracies they want to see if there is any malware
hiding inside. In other types of countries they're filtering
'undesirable' content. Identifying which type youʼre living in is
becoming harder every day :-)

Robert





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#33825: 25.2; , Failing to verify signature for ELPA debbugs package
  2018-12-21 13:38 bug#33825: 25.2; Failing to verify signature for ELPA debbugs package clemera
  2018-12-21 23:39 ` Glenn Morris
  2018-12-22 12:08 ` bug#33825: 25.2; , " clemera
@ 2019-09-13 19:50 ` Stefan Kangas
  2019-09-16  9:07   ` Robert Pluim
  2 siblings, 1 reply; 14+ messages in thread
From: Stefan Kangas @ 2019-09-13 19:50 UTC (permalink / raw)
  To: clemera; +Cc: 33825

Robert Pluim <rpluim@gmail.com> writes:

> clemera <clemens.radermacher@posteo.de> writes:
>
>>> FWIW, it verifies fine here with Emacs 25.2
>>
>> I tried it again and now it works for me, too. Strange..., what could
>> have caused that it failed before?
>
> There are 'transparent' proxies which will untar archives and then
> retar them, resulting in a file that fails signature verification even
> though the contents are identical. When you then repeat the download,
> the proxy knows it has previously inspected the file, and thus lets
> through the original. Using https solves this issue 99% of the time.
>
> If youʼre using https already, then Iʼm out of ideas :-)

The reporter verified he was indeed using http.  Is there anything
that can or should be done here, or is this to be closed as notabug?

Best regards,
Stefan Kangas





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#33825: 25.2; , Failing to verify signature for ELPA debbugs package
  2019-09-13 19:50 ` Stefan Kangas
@ 2019-09-16  9:07   ` Robert Pluim
  2019-09-16 11:04     ` Stefan Kangas
  0 siblings, 1 reply; 14+ messages in thread
From: Robert Pluim @ 2019-09-16  9:07 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 33825, clemera

>>>>> On Fri, 13 Sep 2019 21:50:27 +0200, Stefan Kangas <stefan@marxist.se> said:

    Stefan> Robert Pluim <rpluim@gmail.com> writes:
    >> clemera <clemens.radermacher@posteo.de> writes:
    >> 
    >>>> FWIW, it verifies fine here with Emacs 25.2
    >>> 
    >>> I tried it again and now it works for me, too. Strange..., what could
    >>> have caused that it failed before?
    >> 
    >> There are 'transparent' proxies which will untar archives and then
    >> retar them, resulting in a file that fails signature verification even
    >> though the contents are identical. When you then repeat the download,
    >> the proxy knows it has previously inspected the file, and thus lets
    >> through the original. Using https solves this issue 99% of the time.
    >> 
    >> If youʼre using https already, then Iʼm out of ideas :-)

    Stefan> The reporter verified he was indeed using http.  Is there anything
    Stefan> that can or should be done here, or is this to be closed as notabug?

I think this is notabug. We can always reopen it if needed.

Robert





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#33825: 25.2; , Failing to verify signature for ELPA debbugs package
  2019-09-16  9:07   ` Robert Pluim
@ 2019-09-16 11:04     ` Stefan Kangas
  2019-09-16 13:28       ` Robert Pluim
  2019-09-16 14:29       ` Eli Zaretskii
  0 siblings, 2 replies; 14+ messages in thread
From: Stefan Kangas @ 2019-09-16 11:04 UTC (permalink / raw)
  To: Robert Pluim; +Cc: 33825, clemera

Robert Pluim <rpluim@gmail.com> writes:

>     Stefan> The reporter verified he was indeed using http.  Is there anything
>     Stefan> that can or should be done here, or is this to be closed as notabug?
>
> I think this is notabug. We can always reopen it if needed.

Perhaps we could also add something about this issue to PROBLEMS?

How about also adding a recommendation to use https, as far as
possible, for package archives?  I guess that could be added to both
the doc string of package-archives and possibly also the manual.  That
would help security and avoid issues such as these.

Best regards,
Stefan Kangas





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#33825: 25.2; , Failing to verify signature for ELPA debbugs package
  2019-09-16 11:04     ` Stefan Kangas
@ 2019-09-16 13:28       ` Robert Pluim
  2019-09-16 14:29       ` Eli Zaretskii
  1 sibling, 0 replies; 14+ messages in thread
From: Robert Pluim @ 2019-09-16 13:28 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 33825, clemera

>>>>> On Mon, 16 Sep 2019 13:04:55 +0200, Stefan Kangas <stefan@marxist.se> said:

    Stefan> Robert Pluim <rpluim@gmail.com> writes:
    Stefan> The reporter verified he was indeed using http.  Is there anything
    Stefan> that can or should be done here, or is this to be closed as notabug?
    >> 
    >> I think this is notabug. We can always reopen it if needed.

    Stefan> Perhaps we could also add something about this issue to PROBLEMS?

Maybe.

    Stefan> How about also adding a recommendation to use https, as far as
    Stefan> possible, for package archives?  I guess that could be added to both
    Stefan> the doc string of package-archives and possibly also the manual.  That
    Stefan> would help security and avoid issues such as these.

This Iʼd be more in favour of.

Robert





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#33825: 25.2; , Failing to verify signature for ELPA debbugs package
  2019-09-16 11:04     ` Stefan Kangas
  2019-09-16 13:28       ` Robert Pluim
@ 2019-09-16 14:29       ` Eli Zaretskii
  2019-09-16 19:13         ` Stefan Kangas
  1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2019-09-16 14:29 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: rpluim, 33825, clemens.radermacher

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 16 Sep 2019 13:04:55 +0200
> Cc: 33825@debbugs.gnu.org, clemera <clemens.radermacher@posteo.de>
> 
> > I think this is notabug. We can always reopen it if needed.
> 
> Perhaps we could also add something about this issue to PROBLEMS?

Feel free to do that.

> How about also adding a recommendation to use https, as far as
> possible, for package archives?  I guess that could be added to both
> the doc string of package-archives and possibly also the manual.  That
> would help security and avoid issues such as these.

I'd leave this out of the manual.  Doc string should be enough.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#33825: 25.2; , Failing to verify signature for ELPA debbugs package
  2019-09-16 14:29       ` Eli Zaretskii
@ 2019-09-16 19:13         ` Stefan Kangas
  2019-09-17 13:34           ` Robert Pluim
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Kangas @ 2019-09-16 19:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Robert Pluim, 33825, Clemens Radermacher

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

Eli Zaretskii <eliz@gnu.org> writes:

> > How about also adding a recommendation to use https, as far as
> > possible, for package archives?  I guess that could be added to both
> > the doc string of package-archives and possibly also the manual.  That
> > would help security and avoid issues such as these.
>
> I'd leave this out of the manual.  Doc string should be enough.

Thanks.  How about the attached patch?

Best regards,
Stefan Kangas

[-- Attachment #2: 0001-Recommend-https-for-package-archives.patch --]
[-- Type: text/x-patch, Size: 1094 bytes --]

From afc49ccd4e3e593f1f2dfffbdd6e457132efa9cd Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@gmail.com>
Date: Mon, 16 Sep 2019 21:09:32 +0200
Subject: [PATCH] Recommend https for package-archives

* lisp/emacs-lisp/package.el (package-archives): Doc fix to recommend
using https sources instead of http where possible.  (Bug#33825)
---
 lisp/emacs-lisp/package.el | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index ef0c5171de..69c4427e0a 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -214,7 +214,10 @@ package-archives
   (Other types of URL are currently not supported.)
 
 Only add locations that you trust, since fetching and installing
-a package can run arbitrary code."
+a package can run arbitrary code.
+
+It is advisable to prefer HTTPS URLs over HTTP URLs where
+possible, for improved security and stability."
   :type '(alist :key-type (string :tag "Archive name")
                 :value-type (string :tag "URL or directory name"))
   :risky t
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* bug#33825: 25.2; , Failing to verify signature for ELPA debbugs package
  2019-09-16 19:13         ` Stefan Kangas
@ 2019-09-17 13:34           ` Robert Pluim
  2019-09-20 17:24             ` Stefan Kangas
  0 siblings, 1 reply; 14+ messages in thread
From: Robert Pluim @ 2019-09-17 13:34 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 33825, Clemens Radermacher

>>>>> On Mon, 16 Sep 2019 21:13:13 +0200, Stefan Kangas <stefan@marxist.se> said:

    Stefan> Eli Zaretskii <eliz@gnu.org> writes:
    >> > How about also adding a recommendation to use https, as far as
    >> > possible, for package archives?  I guess that could be added to both
    >> > the doc string of package-archives and possibly also the manual.  That
    >> > would help security and avoid issues such as these.
    >> 
    >> I'd leave this out of the manual.  Doc string should be enough.

    Stefan> Thanks.  How about the attached patch?

Nits below

    Stefan> Best regards,
    Stefan> Stefan Kangas

    Stefan> From afc49ccd4e3e593f1f2dfffbdd6e457132efa9cd Mon Sep 17 00:00:00 2001
    Stefan> From: Stefan Kangas <stefankangas@gmail.com>
    Stefan> Date: Mon, 16 Sep 2019 21:09:32 +0200
    Stefan> Subject: [PATCH] Recommend https for package-archives

    Stefan> * lisp/emacs-lisp/package.el (package-archives): Doc fix to recommend
    Stefan> using https sources instead of http where possible.
    Stefan> (Bug#33825)

"Recommend using https..." is shorter and more direct.

    Stefan> ---
    Stefan>  lisp/emacs-lisp/package.el | 5 ++++-
    Stefan>  1 file changed, 4 insertions(+), 1 deletion(-)

    Stefan> diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
    Stefan> index ef0c5171de..69c4427e0a 100644
    Stefan> --- a/lisp/emacs-lisp/package.el
    Stefan> +++ b/lisp/emacs-lisp/package.el
    Stefan> @@ -214,7 +214,10 @@ package-archives
    Stefan>    (Other types of URL are currently not supported.)
 
    Stefan>  Only add locations that you trust, since fetching and installing
    Stefan> -a package can run arbitrary code."
    Stefan> +a package can run arbitrary code.
    Stefan> +
    Stefan> +It is advisable to prefer HTTPS URLs over HTTP URLs where
    Stefan> +possible, for improved security and stability."

Similarly: "HTTPS URLs should be used where possible, as they offer
superior security."

"stability" is not really something you can define, so probably better
not to mention it..

Robert





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#33825: 25.2; , Failing to verify signature for ELPA debbugs package
  2019-09-17 13:34           ` Robert Pluim
@ 2019-09-20 17:24             ` Stefan Kangas
  0 siblings, 0 replies; 14+ messages in thread
From: Stefan Kangas @ 2019-09-20 17:24 UTC (permalink / raw)
  To: Robert Pluim; +Cc: 33825-done, Clemens Radermacher

Robert Pluim <rpluim@gmail.com> writes:
> Nits below

Thanks, I've now installed the patch with your suggested changes as
commit f1f2de7cdf.

Since we seem to agree that there is not much else to do here, I'm
also closing this bug.

Best regards,
Stefan Kangas





^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2019-09-20 17:24 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-12-21 13:38 bug#33825: 25.2; Failing to verify signature for ELPA debbugs package clemera
2018-12-21 23:39 ` Glenn Morris
2018-12-22 12:08 ` bug#33825: 25.2; , " clemera
2018-12-30 12:12   ` Robert Pluim
2018-12-30 12:34     ` Clemens Radermacher
2018-12-30 12:55       ` Robert Pluim
2019-09-13 19:50 ` Stefan Kangas
2019-09-16  9:07   ` Robert Pluim
2019-09-16 11:04     ` Stefan Kangas
2019-09-16 13:28       ` Robert Pluim
2019-09-16 14:29       ` Eli Zaretskii
2019-09-16 19:13         ` Stefan Kangas
2019-09-17 13:34           ` Robert Pluim
2019-09-20 17:24             ` Stefan Kangas

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).