all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefan@marxist.se>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 19479@debbugs.gnu.org, Noam Postavsky <npostavs@gmail.com>
Subject: bug#19479: Package manager vulnerable to replay attacks
Date: Wed, 25 Nov 2020 21:06:38 -0500	[thread overview]
Message-ID: <CADwFkmnKvC3KQhc5tdPTK9YtrcoUbCzyG1AW5Gn7_eK1OK9--A@mail.gmail.com> (raw)
In-Reply-To: <jwvsg8xc65z.fsf-monnier+emacs@gnu.org>

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Do we need this hash-checksum, really?

AFAIK, a cryptographic hash is the generally accepted solution for
securely verifying the contents of a file.  That is, when you worry
about that file having been tampered with by a hostile actor.

> AFAICT, I think if we want to avoid replay attacks we need indeed
> a monotone "counter" (e.g. a timestamp) on the `archive-contents` and
> then a way to verify that the tarballs are what they claim to be.

We also need to sign `archive-contents', of course.  But otherwise
correct: we need to know that the metadata is not out-of-date, and we
need to have a (secure) mapping from the package metadata to individual
packages.

> We can already verify that they are what they claim to be since the
> tarball includes the version number inside the `<pkg>-pkg.el` file.
>
> So, I think all we need is to verify the contents of `<pkg>-pkg.el`
> after unpacking a tarball, to make sure it is indeed the package and
> version its name claimed to be.  This check would be welcome in any case
> to detect packaging errors.

I think the question here is: how do we securely map from the (signed)
package metadata to an individual package?

While not perfect, with a secure hash function, collisions are hard
enough to find that we for our purposes (like the rest of the world) can
happily not worry about it.  In comparison, it is immeasurably easier to
fake a version number than having to defeat a hash function.  I think
this is a significant drawback of what you propose.

We would need to add in a number of assumptions (e.g. packages are
individually signed, we never accidentally sign an old package with a
newer version number, etc.), to gain more confidence in a simple version
number check.

But even then the security it provides will not be as strong, and much
more brittle; there are just more moving parts where things could go
wrong.  And I'm not sure what we would gain.  Importantly, I don't think
it would simplify our implementation in Emacs (or GNU/NonGNU ELPA)
significantly.

But we could of course also check that the version number is correct.
That sounds like a useful sanity check to do.

Thanks for taking a look at this!

PS. Note that if we add a checksum, there will no longer be any need to
    sign individual packages for future versions of Emacs.  We would
    then only need to sign the metadata.





  reply	other threads:[~2020-11-26  2:06 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-30 10:42 Emacs package manager vulnerable to replay attacks Kelly Dean
2014-12-30 11:45 ` Ivan Shmakov
2015-01-01 12:38 ` bug#19479: Package manager vulnerable Kelly Dean
2015-01-04 20:00   ` Stefan Monnier
2015-01-05  1:11     ` Kelly Dean
2015-01-05  2:16       ` Stefan Monnier
2015-01-08  3:31         ` bug#19479: [PATCH] " Kelly Dean
2015-01-08  3:44           ` Glenn Morris
2015-01-08  5:29             ` Kelly Dean
2015-01-08 14:39               ` Stefan Monnier
2015-01-08 21:06                 ` Kelly Dean
2015-01-09  2:37                   ` Stefan Monnier
2015-01-09  6:59               ` bug#19479: Copyright issue (was: Re: bug#19479: Package manager vulnerable) Kelly Dean
2015-01-09 15:17                 ` bug#19479: Copyright issue Stefan Monnier
2015-01-09 15:29                   ` David Kastrup
2015-01-09 21:00                     ` Kelly Dean
2015-01-09 21:49                       ` Kelly Dean
2015-01-09 23:47                         ` Stefan Monnier
2015-01-10  1:18                           ` Kelly Dean
2015-01-11  1:39                             ` Stefan Monnier
2015-01-11  3:20                               ` Kelly Dean
2015-01-11  6:33                                 ` Werner LEMBERG
2015-01-12 15:38                               ` Richard Stallman
2015-01-10 19:29                         ` Richard Stallman
2015-01-09 15:29                   ` David Kastrup
2015-01-09 19:57                   ` Kelly Dean
2015-01-09 19:57                   ` Kelly Dean
2015-01-09 20:24                     ` bug#19479: " Glenn Morris
2015-01-09 20:24                     ` Glenn Morris
2015-01-09 20:32                       ` Glenn Morris
2015-01-09 20:32                       ` Glenn Morris
2015-02-24  8:47           ` bug#19479: Emacs package manager vulnerable to replay attacks Kelly Dean
2015-02-24  8:47           ` Kelly Dean
2015-01-11  2:56   ` bug#19479: (on-topic) Re: bug#19479: Package manager vulnerable Kelly Dean
2015-01-20 21:18   ` bug#19479: Disclaimer is now on file at FSF Kelly Dean
2015-02-24 18:11     ` Glenn Morris
2015-02-24 23:02       ` Kelly Dean
2015-02-24 23:02       ` Kelly Dean
2015-02-25 21:09         ` Glenn Morris
2015-02-25 21:09         ` Glenn Morris
2017-09-02 12:24           ` Eli Zaretskii
2015-02-25  4:41       ` Vibhav Pant
2015-02-25  5:32         ` Stephen J. Turnbull
2015-02-24 18:11     ` Glenn Morris
2017-09-03  1:10   ` bug#19479: Package manager vulnerable Glenn Morris
2019-10-04  9:49   ` Stefan Kangas
2020-05-06  0:55     ` Noam Postavsky
2020-09-06 23:59       ` Stefan Kangas
2020-09-07 14:14         ` Noam Postavsky
2020-09-07 18:11           ` Stefan Kangas
2020-11-21 23:51     ` bug#19479: Package manager vulnerable to replay attacks Stefan Kangas
2020-11-26  0:43       ` Stefan Monnier
2020-11-26  2:06         ` Stefan Kangas [this message]
2020-11-26  2:30           ` Stefan Monnier
2020-11-26  3:02             ` Stefan Kangas
2020-11-26  3:11               ` Stefan Monnier
2020-11-26  3:56           ` Jean Louis
2020-09-07 17:19   ` bug#19479: Package manager vulnerable Stefan Kangas
2020-09-07 23:54     ` Noam Postavsky
2020-09-08  8:10       ` Stefan Kangas
  -- strict thread matches above, loose matches on Subject: below --
2015-01-08  3:33 bug#19536: [PATCH] package-upload-buffer-internal fails for tar files Kelly Dean
2015-01-08  5:50 ` Stefan Monnier
2015-01-08  7:10   ` Kelly Dean
2015-01-08 11:40   ` bug#19479: Package manager vulnerable Kelly Dean
2015-02-18  1:03 ` bug#19536: package-upload-buffer-internal fails for tar files Kelly Dean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADwFkmnKvC3KQhc5tdPTK9YtrcoUbCzyG1AW5Gn7_eK1OK9--A@mail.gmail.com \
    --to=stefan@marxist.se \
    --cc=19479@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=npostavs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.