bug#61277: FR: ELPA security - Restrict package builds to signed git commits

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Daniel Mendler]

As discussed on emacs-devel it would be good if ELPA security could be
improved, preventing potential breaches on the side of the source
repository. This feature becomes more relevant the more packages are
:auto-sync'ed from their source repository.

My git commits are usually signed, so one could check the signature of
each commit which leads to a package build. This feature could be opt-in
for now, enabled via an attribute :signature in the elpa-packages
configuration. Maybe elpa-packages could store the fingerprint(s) of the
expected GPG key(s)?

In the case of a breach, both the SSH and GPG keys may be stolen, which
would allow an attacker to create commits on hosted repositories, such
that the mechanism would not help. However the source repository may
also get compromised via other vectors.

https://lists.gnu.org/archive/html/emacs-devel/2023-02/msg00120.html

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Ihor Radchenko]

Daniel Mendler <mail@daniel-mendler.de> writes:

> My git commits are usually signed, so one could check the signature of
> each commit which leads to a package build. This feature could be opt-in
> for now, enabled via an attribute :signature in the elpa-packages
> configuration. Maybe elpa-packages could store the fingerprint(s) of the
> expected GPG key(s)?

I think that requiring every single commit to be signed is an overkill.
Maybe just the release tags?

I guess, :signature, if optional, may allow multiple levels of
verification:
1. nil :: no verification
2. (tags key1 key2 ...) :: verify release tags to match any of the
   listed GPG keys
3. (commits key1 key2 ...) :: verify every commit   

I am not sure what would be the most reliable way to specify the keys.

Also, people with write access to ELPA repo may be required to sign
their commits -- in the case of security breach if the SSH key gets
stolen, signing may be a barrier to protect altering the elpa-packages
configuration from injecting malicious GPG keys.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > As discussed on emacs-devel it would be good if ELPA security could be
  > improved, preventing potential breaches on the side of the source
  > repository. This feature becomes more relevant the more packages are
  > :auto-sync'ed from their source repository.

I agree that we need to clean up the social system for maintaining GNU ELPA
packages.  It should be as clear and documented as that for Emacs core.

  > My git commits are usually signed, so one could check the signature of
  > each commit which leads to a package build. This feature could be opt-in
  > for now, enabled via an attribute :signature in the elpa-packages
  > configuration. Maybe elpa-packages could store the fingerprint(s) of the
  > expected GPG key(s)?

What do other maintainers think of this?

It addresses one ways of handlng GNU ELPA packagesm, but not all GNU
ELPA packages are handled in this way.  What other categories of
packages do we need to consider?

  > In the case of a breach,

Breach of precisely what?  To think about this issue
requires an answer to that question.

                             both the SSH and GPG keys may be stolen, which
  > would allow an attacker to create commits on hosted repositories, such
  > that the mechanism would not help. However the source repository may
  > also get compromised via other vectors.

Is this a problem that has a solution?

Should we move this to emacs-devel?  A specific bug ticket
is not the right place for such an important topic.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

> Should we move this to emacs-devel?  A specific bug ticket
> is not the right place for such an important topic.

This was explicitly requested to be made into a bug ticket on
emacs-devel. See
https://yhetil.org/emacs-devel/CADwFkmkx3J=LvWT1upGMBaC3MRuyuxmAOB4ghRpYu-BCuX3sSg@mail.gmail.com

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Eli Zaretskii]

> Cc: Daniel Mendler <mail@daniel-mendler.de>, 61277@debbugs.gnu.org,
>  stefan@marxist.se, monnier@iro.umontreal.ca
> From: Ihor Radchenko <yantar92@posteo.net>
> Date: Tue, 07 Feb 2023 11:44:31 +0000
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > Should we move this to emacs-devel?  A specific bug ticket
> > is not the right place for such an important topic.
> 
> This was explicitly requested to be made into a bug ticket on
> emacs-devel. See
> https://yhetil.org/emacs-devel/CADwFkmkx3J=LvWT1upGMBaC3MRuyuxmAOB4ghRpYu-BCuX3sSg@mail.gmail.com

The bug report is OK, but we want to discuss more general issues, I
think.

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I wrote:

  > > Should we move this to emacs-devel?  A specific bug ticket
  > > is not the right place for such an important topic.

You replied:

  > This was explicitly requested to be made into a bug ticket on
  > emacs-devel. See
  > https://yhetil.org/emacs-devel/CADwFkmkx3J=LvWT1upGMBaC3MRuyuxmAOB4ghRpYu-BCuX3sSg@mail.gmail.com

I looked at that URL but I can't understand what it says.  I see
several ways to parse "This was explicitly requested to be made into a
bug ticket on emacs-devel" so I don't know what it means.  Can you
state your point more explicitly and not tersely?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

>   > This was explicitly requested to be made into a bug ticket on
>   > emacs-devel. See
>   > https://yhetil.org/emacs-devel/CADwFkmkx3J=LvWT1upGMBaC3MRuyuxmAOB4ghRpYu-BCuX3sSg@mail.gmail.com
>
> I looked at that URL but I can't understand what it says.  I see
> several ways to parse "This was explicitly requested to be made into a
> bug ticket on emacs-devel" so I don't know what it means.  Can you
> state your point more explicitly and not tersely?

I meant that Daniel submitted this bug ticket after Stefan's message
stating that

>>>   I think we should add some flag to the build system saying that a
>>>   package should only be released if the new tag has a valid signature...
>>>
>>>   IMO, opening a feature request for this in the bug tracker would be
>>>   useful.  A patch would be even better.

The emacs-devel discussion that includes the topic of this FR has been
started earlier in the thread I linked to. So, there is no need to move
this FR to emacs-devel - it is already being discussed there.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I looked at that URL but I can't understand what it says.  I see
  > > several ways to parse "This was explicitly requested to be made into a
  > > bug ticket on emacs-devel" so I don't know what it means.  Can you
  > > state your point more explicitly and not tersely?

  > I meant that Daniel submitted this bug ticket after Stefan's message
  > stating that

  > >>>   I think we should add some flag to the build system saying that a
  > >>>   package should only be released if the new tag has a valid signature...
  > >>>
  > >>>   IMO, opening a feature request for this in the bug tracker would be
  > >>>   useful.  A patch would be even better.

Now I think I understand.

Thanks, Daniel.  That was a useful thing to do.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Eli Zaretskii]

> Cc: 61277@debbugs.gnu.org, stefan@marxist.se, yantar92@posteo.net,
>  monnier@iro.umontreal.ca
> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 06 Feb 2023 22:56:35 -0500
> 
>   > My git commits are usually signed, so one could check the signature of
>   > each commit which leads to a package build. This feature could be opt-in
>   > for now, enabled via an attribute :signature in the elpa-packages
>   > configuration. Maybe elpa-packages could store the fingerprint(s) of the
>   > expected GPG key(s)?
> 
> What do other maintainers think of this?

I don't have an opinion.  Frankly, I don't really understand what
would signing commits give in this regard, given that people who
install a package normally install a tarball, they don't clone the Git
repository.  I also don't think the goals were stated clearly, so it's
hard to reason about this.  But then I'm nowhere near being an expert
on this stuff, so I could easily miss something important.

> Should we move this to emacs-devel?  A specific bug ticket
> is not the right place for such an important topic.

Agreed.

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

>   > In the case of a breach,
>
> Breach of precisely what?  To think about this issue
> requires an answer to that question.

The idea is that the likelihood of both an SSH and a PGP key getting
stolen at the same time is lower than either one of them getting stolen
separately.

>
>                              both the SSH and GPG keys may be stolen, which
>   > would allow an attacker to create commits on hosted repositories, such
>   > that the mechanism would not help.
>
> Is this a problem that has a solution?

Yes, for example you could you could put your PGP key (usually a subkey)
on a smartcard, and have no copy on the local filesystem.

PGP keys usually also have an additional password, in addition to the
one that developers normally (we hope) use for their SSH key.

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Daniel Mendler]

On 2/12/23 07:37, Stefan Kangas wrote:
>> Breach of precisely what?  To think about this issue
>> requires an answer to that question.
> 
> The idea is that the likelihood of both an SSH and a PGP key getting
> stolen at the same time is lower than either one of them getting stolen
> separately.

There could also be a breach on the server where the git repository is
hosted. The repository could be manipulated directly on the server. It
is not that likely but if such incidents happen they have a huge
fallout. I also expect that more and more people move their
:auto-sync'ed git repositories to private servers or smaller forges,
which may not be as protected as the most popular ones.

Daniel

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > There could also be a breach on the server where the git repository is
  > hosted. The repository could be manipulated directly on the server. It
  > is not that likely but if such incidents happen they have a huge
  > fallout. I also expect that more and more people move their
  > :auto-sync'ed git repositories to private servers or smaller forges,
  > which may not be as protected as the most popular ones.

Do we know of any security experts who appeciate the moral principles
of free software, who could help us come up with methods that properly
handle both?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >   > In the case of a breach,
  > >
  > > Breach of precisely what?  To think about this issue
  > > requires an answer to that question.

  > The idea is that the likelihood of both an SSH and a PGP key getting
  > stolen at the same time is lower than either one of them getting stolen
  > separately.

That seems plausible to me, but we are miscommunicating.
You're discussing the "how" of a possible breach,
but what I really need to know is the "what".
What is being breached?  What is the context here?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> You're discussing the "how" of a possible breach,
> but what I really need to know is the "what".
> What is being breached?  What is the context here?

The "what" is the git repository of a GNU ELPA or NonGNU ELPA package.

If an attacker can introduce a commit containing malicious code, and
create a new git tag pointing to that commit, the GNU ELPA scripts will
fetch it, and release a new version of the package (now including the
malicious code).  By requiring tags to be cryptographically signed, we
can have a greater confidence that any new tag has at the very least
been signed off by the developer him/herself.

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> If an attacker can introduce a commit containing malicious code, and
> create a new git tag pointing to that commit, the GNU ELPA scripts will
> fetch it, and release a new version of the package (now including the
> malicious code).  By requiring tags to be cryptographically signed, we
> can have a greater confidence that any new tag has at the very least
> been signed off by the developer him/herself.

Technical nitpick: currently, the elpa.gnu.org scripts do not pay
attention to any Git tags (signed or not) to do their work.  We only use
the commits and their contents/history.


        Stefan

bug#61277: FR: ELPA security - Restrict package builds to signed git commits

[Richard Stallman]

Please forgive my delay in replying.

  > If an attacker can introduce a commit containing malicious code, and
  > create a new git tag pointing to that commit, the GNU ELPA scripts will
  > fetch it, and release a new version of the package (now including the
  > malicious code).  By requiring tags to be cryptographically signed, we
  > can have a greater confidence that any new tag has at the very least
  > been signed off by the developer him/herself.

This seems wise to me.  Does anyone have arguments against?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)