Hi,
What do y'all think about requiring GPG signed commits for the php-src
repository?
I had a look, and this is also something we can enforce through GitHub
as well (by using branch protections).
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
Am 02.04.2024 um 16:15 schrieb Derick Rethans:
What do y'all think about requiring GPG signed commits for the php-src
repository?
+1
Hi,
What do y'all think about requiring GPG signed commits for the php-src
repository?
+1, most of the devs already do that. I CC'd few of the regular devs that
don't sign commits (taken from the latest history) so they are aware of
this.
Cheers
Jakub
Hi,
What do y'all think about requiring GPG signed commits for the php-src
repository?+1, most of the devs already do that. I CC'd few of the regular devs that
don't sign commits (taken from the latest history) so they are aware of
this.
I meant regular committers, of course.
No problem with this, I apply this since couple of days.
Cheers.
Hi,
What do y'all think about requiring GPG signed commits for the php-src
repository?+1, most of the devs already do that. I CC'd few of the regular devs that
don't sign commits (taken from the latest history) so they are aware of
this.I meant regular committers, of course.
Hi,
What do y'all think about requiring GPG signed commits for the php-src
repository?I had a look, and this is also something we can enforce through GitHub
as well (by using branch protections).cheers,
Derick--
https://derickrethans.nl | https://xdebug.org | https://dram.ioAuthor of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
+1 from me as well, and quite good timing with all the xz fiasco just last week.
Git can also sign with SSH keys now, so this is now merely a config update
What do y'all think about requiring GPG signed commits for the
php-src repository?I had a look, and this is also something we can enforce through
GitHub as well (by using branch protections).+1 from me as well, and quite good timing with all the xz fiasco just
last week.Git can also sign with SSH keys now, so this is now merely a config
update
The issue with SSH keys is that they can not be signed by others to form
a "web of trust". For example, my key has been signed by several other
people:
https://keyserver.ubuntu.com/pks/lookup?search=derick%40php.net&fingerprint=on&op=index
cheers,
Derick
Hi,
What do y'all think about requiring GPG signed commits for the php-src
repository?
I actually thought this was already required since the github move (and the events that led to it) 3 years ago.
It was certainly discussed: https://externals.io/message/113838#113840 and a user guide was created on the PHP wiki: https://wiki.php.net/vcs/commit-signing
Feedback for the idea was generally positive, but maybe nobody got around to actually doing it.
--
Rowan Tommins
[IMSoP]
What do y'all think about requiring GPG signed commits for the php-src
repository?I had a look, and this is also something we can enforce through GitHub
as well (by using branch protections).
Would this affect only direct pushes to master, or would it be required
for pull requests too? I'd be worried the average drive-by contributor
wouldn't have GPG signing set up.
What do y'all think about requiring GPG signed commits for the php-src
repository?I had a look, and this is also something we can enforce through GitHub
as well (by using branch protections).Would this affect only direct pushes to master, or would it be required
for pull requests too? I'd be worried the average drive-by contributor
wouldn't have GPG signing set up.
As Ayesh said, you can also use SSH for this now:
https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#ssh-commit-signature-verification
I think it would apply to people merging the commits. But, I am not 100%
sure (until we try, I suppose).
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
What do y'all think about requiring GPG signed commits for the php-src
repository?I had a look, and this is also something we can enforce through GitHub
as well (by using branch protections).
Would this affect only direct pushes to master, or would it be required
for pull requests too? I'd be worried the average drive-by contributor
wouldn't have GPG signing set up.
FWIW, I'm a drive-by contributor and I have GPG signing
https://github.com/php/php-src/pull/13845/commits set up.
What do y'all think about requiring GPG signed commits for the php-src
repository?
+1
Hi,
What do y'all think about requiring GPG signed commits for the php-src
repository?I had a look, and this is also something we can enforce through GitHub
as well (by using branch protections).cheers,
Derick
I'm in favor of this.
Hey List, Hey Derick
Am 02.04.24 um 16:15 schrieb Derick Rethans:
Hi,
What do y'all think about requiring GPG signed commits for the php-src
repository?
In general I think it is a good idea to do GPG signed commits. But in
terms of security the idea is to be able to authenticate a user. But the
only thing we truly and reliably can do is connect a github account to a
commit. Whether that commit author is actually Jane Doe or Karl Napp is
still not necessarily proven.
So if we want to make sure that something like XY doesn't happen, we
have to add some additional restrictions to those GPG keys.
If it is just to have signed commits: I am absolutely in favour.
Cheers
Andreas
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
So if we want to make sure that something like XY doesn't happen, we
have to add some additional restrictions to those GPG keys.
Looks like all those geeky colleagues of ours back in the day having key-signing parties at conferences were on to something, maybe..
Let's be clear about something -- having GPG key requirements isn't going to help a situation like XZ. The XZ attack was done by an active maintainer of the project (who arguably manipulated the original maintainer of the project to become a maintainer themselves). It was as much a social engineering attack as anything.
Having GPG key requirements is all fine and dandy I suppose, but my tongue-in-cheek comment above has a real point behind it: GPG keys don't mean jack if you can't trust who owns the key. Unless we want to start limiting contributors to people who show up at conferences to do key signings of their GPG keys, I question exactly what this buys the project other than an illusion of security and additional complexity? I couldn't even really trust Derick to read me his GPG public key character-by-character over the phone now days thanks to AI.
Just Sayin'
John
So if we want to make sure that something like XY doesn't happen, we
have to add some additional restrictions to those GPG keys.Looks like all those geeky colleagues of ours back in the day having
key-signing parties at conferences were on to something, maybe..Let's be clear about something -- having GPG key requirements isn't going
to help a situation like XZ. The XZ attack was done by an active maintainer
of the project (who arguably manipulated the original maintainer of the
project to become a maintainer themselves). It was as much a social
engineering attack as anything.Having GPG key requirements is all fine and dandy I suppose, but my
tongue-in-cheek comment above has a real point behind it: GPG keys don't
mean jack if you can't trust who owns the key. Unless we want to start
limiting contributors to people who show up at conferences to do key
signings of their GPG keys, I question exactly what this buys the project
other than an illusion of security and additional complexity? I couldn't
even really trust Derick to read me his GPG public key
character-by-character over the phone now days thanks to AI.
It's not meant to prevent XZ attack. The purpose is really just for the
actual contributors to have some assurance that just some random person
won't commit anything in their name just by changing the author of the
commit.
See another thread [1] about prevention of the XZ attack - that basically
requires moving the actual build to the CI and have the right process to
verify it.
[1] https://externals.io/message/122811
Regards
Jakub
So if we want to make sure that something like XY doesn't happen, we
have to add some additional restrictions to those GPG keys.Looks like all those geeky colleagues of ours back in the day having
key-signing parties at conferences were on to something, maybe..
Let's be clear about something -- having GPG key requirements isn't
going to help a situation like XZ. The XZ attack was done by an active
maintainer of the project (who arguably manipulated the original
maintainer of the project to become a maintainer themselves). It was
as much a social engineering attack as anything.
Having GPG key requirements is all fine and dandy I suppose, but my
tongue-in-cheek comment above has a real point behind it: GPG keys
don't mean jack if you can't trust who owns the key.
GitHub doesn't show the web of trust anyway, just "verified". Command
line GIT doesn't either, just:
$ git verify-commit HEAD~1
gpg: Signature made Tue 02 Apr 2024 14:55:21 BST
gpg: using RSA key 5A52880781F755608BF815FC910DEB46F53EA312
…
gpg: aka "Derick Rethans (GitHub) github@derickrethans.nl" [ultimate]
gpg: aka "Derick Rethans (PHP) derick@php.net" [ultimate]
cheers,
Derick
Having GPG key requirements is all fine and dandy I suppose, but my
tongue-in-cheek comment above has a real point behind it: GPG keys
don't mean jack if you can't trust who owns the key.GitHub doesn't show the web of trust anyway, just "verified". Command
line GIT doesn't either, just:
That's really unfortunate (why even bother). IMO without some sort of web of trust verification process for GPG, this just feels like added barriers for no actual win. In fact, if anything I think it's more likely to give the project a false sense of security.
Cheers,
John
Hi
[Resending, because my mail server failed to look up php.net. It looks
good now, I apologize for duplicate copies.]
That's really unfortunate (why even bother). IMO without some sort of web of trust verification process for GPG, this just feels like added barriers for no actual win. In fact, if anything I think it's more likely to give the project a false sense of security.
While it does not prevent any attacks, it possibly simplifies an
investigation:
For example: Did John Doe suddenly start signing with a new key? Or was
only a single commit signed with a different key?
If John uses a different key for each computer (e.g. one for the work
laptop and one for the private gaming computer), then the signature
possibly allows determining which machine was compromised.
These are useful signals to determine the possible scope of an attack.
Best regards
Tim Düsterhus
Hi Derick
What do y'all think about requiring GPG signed commits for the php-src
repository?
Let me repost my internal response for visibility.
I'm currently struggling to understand what kind of attack signing
commits prevents.
If your GitHub account is compromised, GitHub allows the attacker to
commit via web interface and will happily sign their commits with a
gpg key auto-generated for your account.
GitHub will automatically use GPG to sign commits you make using the web interface. Commits signed by GitHub will have a verified status. You can verify the signature locally using the public key available at https://github.com/web-flow.gpg.
Even if this wasn't the case, the attacker may simply register their
own gpg key in your account, with the commits appearing as verified.
If your ssh key is compromised instead, and you use ssh to sign your
commits, the attacker may sign their malicious commits with that same
key they may use to push.
The only thing this really seems to prevent is pushing commits via a
compromised ssh key, while commits need to be signed with gpg. If
that's the intention, we should require using gpg rather than ssh for
signing (or using a different ssh key, I suppose). Additionally, it
may help for people who push via HTTP+auth token, but that's probably
not advisable in the first place.
Something that may also help is restricting pushes to patch branches
(PHP-x.y.z) to release managers. These branches are not commonly
looked at by the public, and so it may be easier to sneak malicious
commits into them.
In addition, we should keep GitHub privileges narrow, especially
branch protection configuration.
As mentioned by others, this does not prevent the xz issue. But paired
with an auto-deployment solution, it could definitely help. It would
be even better if release managers cannot change CI, and CI
maintainers cannot create releases, as this essentially enforces the
4-eyes principle. The former may be hard to enforce, as CI lives in
the same repository.
Another solution might be to require PRs, and PR verifications. But
this will inevitably create overhead for maintainers.
Ilija
Hi Derick
What do y'all think about requiring GPG signed commits for the php-src
repository?Let me repost my internal response for visibility.
I'm currently struggling to understand what kind of attack signing
commits prevents.If your GitHub account is compromised, GitHub allows the attacker to
commit via web interface and will happily sign their commits with a
gpg key auto-generated for your account.GitHub will automatically use GPG to sign commits you make using the web interface. Commits signed by GitHub will have a verified status. You can verify the signature locally using the public key available at https://github.com/web-flow.gpg.
Even if this wasn't the case, the attacker may simply register their
own gpg key in your account, with the commits appearing as verified.If your ssh key is compromised instead, and you use ssh to sign your
commits, the attacker may sign their malicious commits with that same
key they may use to push.The only thing this really seems to prevent is pushing commits via a
compromised ssh key, while commits need to be signed with gpg. If
that's the intention, we should require using gpg rather than ssh for
signing (or using a different ssh key, I suppose). Additionally, it
may help for people who push via HTTP+auth token, but that's probably
not advisable in the first place.Something that may also help is restricting pushes to patch branches
(PHP-x.y.z) to release managers. These branches are not commonly
looked at by the public, and so it may be easier to sneak malicious
commits into them.In addition, we should keep GitHub privileges narrow, especially
branch protection configuration.As mentioned by others, this does not prevent the xz issue. But paired
with an auto-deployment solution, it could definitely help. It would
be even better if release managers cannot change CI, and CI
maintainers cannot create releases, as this essentially enforces the
4-eyes principle. The former may be hard to enforce, as CI lives in
the same repository.Another solution might be to require PRs, and PR verifications. But
this will inevitably create overhead for maintainers.Ilija
Coming from corporate projects at the moment, I always hard-block pushing straight to the master branch. Everything goes through a PR, and has to be approved by someone other than the author, guaranteeing 4 eyes for every line of code. And that's for internal backend services.
It's always struck me as mind-boggling that a project the size of PHP doesn't do that. Yes, it's a little more overhead, but with the larger team we now have (thanks to the Foundation) I believe the human-security checks it gives us are well worth it. (And just from a technical standpoint, even the best developer goofs up and needs their code reviewed by someone.)
I have no particular input on the code signing front, other than please have clear documentation to follow for someone setting it up for the first time as GPG has always been a UX nightmare. :-)
--Larry Garfield
If your GitHub account is compromised,
[...] the attacker may simply register their
own gpg key in your account, with the commits appearing as verified.If your ssh key is compromised instead, and you use ssh to sign your
commits, the attacker may sign their malicious commits with that same
key they may use to push.
The key point (pun not intended) is that git doesn't record who pushed a
commit - pushing is just data synchronization, not part of the history.
What it records is who "authored" the commit, and by default that's just
plain text; so if somebody compromises an SSH key or access token
authorised to your GitHub account, they can push commits "authored by"
Derick, or Nikita, or Bill Gates, and there is no way to tell them apart
from the real thing.
In fact, you don't need to compromise anybody's key: you could socially
engineer a situation where you have push access to the repository, or
break the security in some other way. As I understand it, this is
exactly what happened 3 years ago: someone gained direct write access to
the git.php.net server, and added commits "authored by" Nikita and
others to the history in the repository.
If all commits are signed, a compromised key or account can only be used
to sign commits with that specific identity: your GitHub account can't
be used to sign commits as Derick or Nikita, only as you. The impact is
limited to one identity, not the integrity of the entire repository.
Regards,
--
Rowan Tommins
[IMSoP]
Hi Rowan
On Tue, Apr 2, 2024 at 8:48 PM Rowan Tommins [IMSoP]
imsop.php@rwec.co.uk wrote:
In fact, you don't need to compromise anybody's key: you could socially engineer a situation where you have push access to the repository, or break the security in some other way. As I understand it, this is exactly what happened 3 years ago: someone gained direct write access to the git.php.net server, and added commits "authored by" Nikita and others to the history in the repository.
Right, but I would like to believe that attaining push access without
gaining access to a maintainers account should be substantially
harder on GitHub than our self-hosted git server. :)
If all commits are signed, a compromised key or account can only be used to sign commits with that specific identity: your GitHub account can't be used to sign commits as Derick or Nikita, only as you. The impact is limited to one identity, not the integrity of the entire repository.
But, does it matter? I'm not sure we look at some commits closer than
others, based on its author. It's true that it might be easier to
identify malicious commits if they all come from the same user, but it
wouldn't prevent them.
To be clear: I'm not against commit signing, I've been doing it for
years. I'm just unsure if it's a sufficient solution (apart from
releases, which are a whole different can of worms).
Ilija
But, does it matter? I'm not sure we look at some commits closer than
others, based on its author. It's true that it might be easier to
identify malicious commits if they all come from the same user, but it
wouldn't prevent them.
It's like the difference between stealing someone's credit card, and
cloning the card of everyone who comes into the shop: in the first case,
someone needs to check their credit card statements carefully; in the
second, you'll have a hard job even working out who to contact.
Similarly, if you discover a compromised key or signing account, you can
look for uses of that key or account, which might be a tiny number from
a non-core contributor; if you discover a compromised account pushing
unsigned commits, you have to audit every commit in the repository.
I agree it's not a complete solution, but no security measure is; it's
always about reducing the attack surface or limiting the damage.
Regards,
--
Rowan Tommins
[IMSoP]
On Tue, Apr 2, 2024 at 8:45 PM Rowan Tommins [IMSoP] imsop.php@rwec.co.uk
wrote:
But, does it matter? I'm not sure we look at some commits closer than
others, based on its author. It's true that it might be easier to
identify malicious commits if they all come from the same user, but it
wouldn't prevent them.It's like the difference between stealing someone's credit card, and
cloning the card of everyone who comes into the shop: in the first case,
someone needs to check their credit card statements carefully; in the
second, you'll have a hard job even working out who to contact.Similarly, if you discover a compromised key or signing account, you can
look for uses of that key or account, which might be a tiny number from a
non-core contributor; if you discover a compromised account pushing
unsigned commits, you have to audit every commit in the repository.I agree it's not a complete solution, but no security measure is; it's
always about reducing the attack surface or limiting the damage.
Nice comparison. Fully agree with that. I would add that potentially even
more important point than auditability is possibility to revoke access of
the compromised account as otherwise you can't easily identify such account
and prevent further issues.
Regards
Jakub
On Tue, Apr 2, 2024 at 9:43 PM Rowan Tommins [IMSoP]
imsop.php@rwec.co.uk wrote:
Similarly, if you discover a compromised key or signing account, you can look for uses of that key or account, which might be a tiny number from a non-core contributor; if you discover a compromised account pushing unsigned commits, you have to audit every commit in the repository.
Right, that and what Jakub mentioned are fair arguments.
I agree it's not a complete solution, but no security measure is; it's always about reducing the attack surface or limiting the damage.
Right. That was the original intention of my e-mail: To point out that
we might also want to consider other mitigations. Not that we
shouldn't do commit signing.
Ilija
But, does it matter? I'm not sure we look at some commits closer than
others, based on its author. It's true that it might be easier to
identify malicious commits if they all come from the same user, but it
wouldn't prevent them.It's like the difference between stealing someone's credit card, and cloning the card of everyone who comes into the shop: in the first case, someone needs to check their credit card statements carefully; in the second, you'll have a hard job even working out who to contact.
Similarly, if you discover a compromised key or signing account, you can look for uses of that key or account, which might be a tiny number from a non-core contributor; if you discover a compromised account pushing unsigned commits, you have to audit every commit in the repository.
I agree it's not a complete solution, but no security measure is; it's always about reducing the attack surface or limiting the damage.
Regards,
--
Rowan Tommins
[IMSoP]
FWIW, I store my signing and ssh keys on yubikeys. Even then, when I managed to lose one several years ago, revoking the certificate on GitHub was relatively straightforward. Further, it marked every commit made by that key (ever) as unverified.
So, in the very least, if a key were to be compromised, any open PRs would need to be resigned by the author to get them back in good standing; if verified commits are required.
This, of course, makes GitHub the "single point of failure." If someone were to gain access to my GH (even on an unattended laptop), they could add their own keys, and on another computer; log in with another account, and then push commits with my email address and their gpg key. GitHub would show them as verified (IIRC) and from me. This is by design, since "in theory," I could have pushed my commits to a coworker's git repo, who then pushed it to GH.
Terrifying stuff... but it is even more terrifying than not having signed commits at all, since literally anyone can push a commit with anyone's name on it and nobody would even know it was a counterfeit. So, at least requiring signed commits makes the bar that much higher to counterfeit/hide malicious commits.
If this stuff terrifies you too, I recommend turning on vigilant mode: https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits
— Rob
What do y'all think about requiring GPG signed commits for the php-src
repository?I had a look, and this is also something we can enforce through GitHub
as well (by using branch protections).
It seems that most of the reply to this was positive, although with the
realisation that it wouldn't be a panacea.
I will therefore propose a minimalistic RFC to create this requirement
to sign commits to all branches, in the next few days.
I probably would have prefered requiring GPG signing (due to a web of
trust), but GitHub's requirement isn't that granuar (it's either
SSG+GPG, or nothing).
Any other opinions, I'd be delighted to hear them.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
Hi
It seems that most of the reply to this was positive, although with the
realisation that it wouldn't be a panacea.I will therefore propose a minimalistic RFC to create this requirement
to sign commits to all branches, in the next few days.I probably would have prefered requiring GPG signing (due to a web of
trust), but GitHub's requirement isn't that granuar (it's either
SSG+GPG, or nothing).Any other opinions, I'd be delighted to hear them.
Web of trust for PGP is effectively dead since
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f.
Requiring any type of signature on the commits is fine. The distinct
public keys will build reputation on their own by making good commits.
More signatures is certainly better than fewer. In fact I would find it
sufficient to just strongly encourage the regular committers to set up
signing, even without actually enforcing it on GitHub.
Best regards
Tim Düsterhus