Re: [PHP-DEV] Requiring GPG Commit Signing

[Tim Düsterhus]

Hi

On 4/9/24 13:02, Derick Rethans wrote:

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

Re: [PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

On Tue, 2 Apr 2024, Derick Rethans wrote:

> 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

Re: [PHP-DEV] Requiring GPG Commit Signing

[Tim Düsterhus]

Hi

[Resending, because my mail server failed to look up php.net. It looks 
good now, I apologize for duplicate copies.]


On 4/3/24 19:28, John Coggeshall wrote:

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

Re: [PHP-DEV] Requiring GPG Commit Signing

[John Coggeshall]

> > 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

Re: [PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

On Tue, 2 Apr 2024, John Coggeshall wrote:

> 
> > 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) " 
[ultimate]
gpg: aka "Derick Rethans (PHP) " [ultimate]


cheers,
Derick

Re: [PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

On Tue, 2 Apr 2024, Ayesh Karunaratne wrote:

> > 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=on=index

cheers,
Derick

Re: [PHP-DEV] Requiring GPG Commit Signing

[Rob Landers]

On Tue, Apr 2, 2024, at 21:40, Rowan Tommins [IMSoP] wrote:
> On 02/04/2024 20:02, Ilija Tovilo 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.
> 
> 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

Re: [PHP-DEV] Requiring GPG Commit Signing

[Ilija Tovilo]

On Tue, Apr 2, 2024 at 9:43 PM Rowan Tommins [IMSoP]
 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

Re: [PHP-DEV] Requiring GPG Commit Signing

[Jakub Zelenka]

On Tue, Apr 2, 2024 at 8:45 PM Rowan Tommins [IMSoP] 
wrote:

> On 02/04/2024 20:02, Ilija Tovilo 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

Re: [PHP-DEV] Requiring GPG Commit Signing

[Rowan Tommins [IMSoP]]

On 02/04/2024 20:02, Ilija Tovilo 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.


Regards,

--
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] Requiring GPG Commit Signing

[Ilija Tovilo]

Hi Rowan

On Tue, Apr 2, 2024 at 8:48 PM Rowan Tommins [IMSoP]
 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

Re: [PHP-DEV] Requiring GPG Commit Signing

[Rowan Tommins [IMSoP]]

On 02/04/2024 18:27, Ilija Tovilo wrote:

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]

Re: [PHP-DEV] Requiring GPG Commit Signing

[Larry Garfield]

On Tue, Apr 2, 2024, at 5:27 PM, Ilija Tovilo wrote:
> Hi Derick
>
> On Tue, Apr 2, 2024 at 4:15 PM Derick Rethans  wrote:
>>
>> 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.
>
> See: 
> https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification
>
>> 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

Re: [PHP-DEV] Requiring GPG Commit Signing

[Ilija Tovilo]

Hi Derick

On Tue, Apr 2, 2024 at 4:15 PM Derick Rethans  wrote:
>
> 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.

See: 
https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification

> 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

Re: [PHP-DEV] Requiring GPG Commit Signing

[Jakub Zelenka]

On Tue, Apr 2, 2024 at 5:05 PM John Coggeshall  wrote:

>
> 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

Re: [PHP-DEV] Requiring GPG Commit Signing

[John Coggeshall]

> 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

Re: [PHP-DEV] Requiring GPG Commit Signing

[Bilge]

On 02/04/2024 15:55, Calvin Buckley wrote:

On Apr 2, 2024, at 11:15 AM, Derick Rethans  wrote:

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 
 set up.

Re: [PHP-DEV] Requiring GPG Commit Signing

[Andreas Heigl]

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:andr...@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  |
+-+


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Requiring GPG Commit Signing

[Niels Dossche]

On 02/04/2024 16:15, Derick Rethans wrote:
> 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.

Re: [PHP-DEV] Requiring GPG Commit Signing

[Arnaud Le Blanc]

On Tue, Apr 2, 2024 at 4:16 PM Derick Rethans  wrote:

> What do y'all think about requiring GPG signed commits for the php-src
> repository?
>

+1

Re: [PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

On Tue, 2 Apr 2024, Calvin Buckley wrote:

> On Apr 2, 2024, at 11:15 AM, Derick Rethans  wrote:
> > 
> > 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

Re: [PHP-DEV] Requiring GPG Commit Signing

[Calvin Buckley]

On Apr 2, 2024, at 11:15 AM, Derick Rethans  wrote:
> 
> 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.

Re: [PHP-DEV] Requiring GPG Commit Signing

[Rowan Tommins [IMSoP]]

On Tue, 2 Apr 2024, at 15:15, Derick Rethans wrote:
> 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]

Re: [PHP-DEV] Requiring GPG Commit Signing

[Ayesh Karunaratne]

>
> 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

+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

Re: [PHP-DEV] Requiring GPG Commit Signing

[David CARLIER]

No problem with this, I apply this since couple of days.

Cheers.

On Tue, 2 Apr 2024 at 15:37, Jakub Zelenka  wrote:

> On Tue, Apr 2, 2024 at 3:36 PM Jakub Zelenka  wrote:
>
>> On Tue, Apr 2, 2024 at 3:17 PM Derick Rethans  wrote:
>>
>>> 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.
>

Re: [PHP-DEV] Requiring GPG Commit Signing

[Jakub Zelenka]

On Tue, Apr 2, 2024 at 3:36 PM Jakub Zelenka  wrote:

> On Tue, Apr 2, 2024 at 3:17 PM Derick Rethans  wrote:
>
>> 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.

Re: [PHP-DEV] Requiring GPG Commit Signing

[Jakub Zelenka]

On Tue, Apr 2, 2024 at 3:17 PM Derick Rethans  wrote:

> 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

Re: [PHP-DEV] Requiring GPG Commit Signing

[Sebastian Bergmann]

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

[PHP-DEV] Requiring GPG Commit Signing

[Derick Rethans]

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