#codesigning — Public Fediverse posts

@squiblydoo : perhaps this is related to the DigiCert hack described in https://bugzilla.mozilla.org/show_bug.cgi?id=2033170?

#DigiCert #CodeSigning #EVcertificates

@squiblydoo : perhaps this is related to the DigiCert hack described in https://bugzilla.mozilla.org/show_bug.cgi?id=2033170?

#DigiCert #CodeSigning #EVcertificates

@squiblydoo : perhaps this is related to the DigiCert hack described in https://bugzilla.mozilla.org/show_bug.cgi?id=2033170?

#DigiCert #CodeSigning #EVcertificates

@squiblydoo : perhaps this is related to the DigiCert hack described in https://bugzilla.mozilla.org/show_bug.cgi?id=2033170?

#DigiCert #CodeSigning #EVcertificates

If your looking for lower cost code signing certificate for an open source project then Certium has options:

https://www.certum.eu/en/

€69 for the first year, which apparently includes a USB device to house the certificate hardware, renewals is a lot less.

Seems like a good option, although I've not tried this personally 🙂🤷‍♂️

#AppDevelopment #OpenSource #Certificates #DigitalCertificates #CodeSigning

Someone was looking for inexpensive or at least less expensive Code Signing Certs:

https://cheapsslweb.com/

$219 per year from Comoddo and available for individual developers 🙂

#CodeSigning #DigitalCertificate

Help, I need a code signing certificate that won't bankrupt me.

Three years ago, I paid $100 for a three-year code signing certificate. I've signed all my open-source projects' releases with it. Now that it's renewal time, Certera (SignMyCode.com) wants almost $700 for the same three-year certificate (excluding the mandatory HSM purchase, which I am totally on board with).

I write silly C and PowerShell code, and I timestamp my signatures so that they're perpetually valid. My PowerShell Gallery stuff, as well as binaries of aprs-weather-submit on Windows and macOS, are all signed and hashed (but not notarized by Apple, because that's another $99 a year for something that feels done unless Bob Bruninga's followers are thinking about APRS 2.0).

If I can't find a solution, anything I write or update in the future will have to be released as unsigned unless I half-ass something (like the Notepad++ developer using self-signed certs -- semi-dangerously clever). $100 every three years, fine. $700 every three years, and I'll do it if my three fans click my Buy Me A Coffee link over and over.

Is there any CA out there that will offer open-source, not-for-profit developers like me a chance to get globally-trusted code signing certificates? I don't think SigStore ever took off (sadly), and even if it did, I don't think it's part of the Microsoft Authenticode program.

#CodeSigning #SSL #TLS #certificates #Certera #SoftwareDevelopment #C #PowerShell #PowerShellGallery #AmateurRadio #HamRadio #APRS #APRS-Weather-Submit #GitHub #security #developer #Windows #macOS #Linux #Authenticode #DevSecOps #DevOps

Help! I would like use use AWS CloudHSM to sign a Debian package. We currently have a gpg-based flow using reprepo to create an APT repository.

I cannot for the life of me figure out how to put all the pieces together. All the Debian tooling I can find assumes gpg. I don't see how to put a gpg or gpgme-shaped front end in front of CloudHSM.

But maybe I just don't know which of the available protocols is the correct one. (Is it PKCS11? The compatibility between various smartcard-based gpg use cases and CloudHSM does not seem very clear.)

I would greatly appreciate some pointers on how to put these pieces together. Surely some cryptography or AWS nerd has published a Medium article about this?

#Debian #CodeSigning #CloudHSM

The SignServer Team is happy to announce the release of SignServer CE 7.1.1

Featuring NIST approved quantum-safe algorithms ML-DSA and SLH-DSA.

https://github.com/Keyfactor/signserver-ce/releases/tag/v7.1.1

#Keyfactor #SignServer #digitalsignatures #codesigning #pki #postquantum

@SecurityWriter Individual hobbyists who develop games and other programs for Windows often ask the user to bypass SmartScreen because the dev can't afford a commercial code signing certificate. Is that also just like "disable their security software"?

#WindowsDefender #SmartScreen #CodeSigning #CARacket

The Importance of Code Signing Best Practices in the Software Development Lifecycle – Source: securityboulevard.com https://ciso2ciso.com/the-importance-of-code-signing-best-practices-in-the-software-development-lifecycle-source-securityboulevard-com/ #HardwareSecurityModules(HSMs) #CertificateAuthority(CA) #rssfeedpostgeneratorecho #SecurityBloggersNetwork #CertificateManagement #CyberSecurityNews #SecureCodeSigning #SecurityBoulevard #codesigning #CA/BForum #ISO27001 #NIST #SOC2

The SignServer team is happy to announce the community release of SignServer 7.0.0:

https://github.com/Keyfactor/signserver-ce/releases/tag/v7.0.0

#SignServer #Keyfactor #KeyfactorCommunity #codesigning #DigitalSign #pki #infosec

CodeSigning для разработчиков под Windows по новым правилам

С 1.06.2023 году вступили в действие новые требования к сертификатам для подписи кода (aka CodeSigning), которые значительно осложнили жизнь разработчиков ПО. Суть изменений - прощай старый добрый PFX, закрытые ключи теперь должны быть неизвлекаемыми и некопируемыми . Примеры изменений у поставщиков: раз , два , три - в общем-то у всех одно и тоже. Мы, как российские разработчики, оказались точно также затронуты этими нововведениями. Эта статья родилась как итог экспериментов и проб по преодолению новых вызовов, появившихся на ровном месте, потому что кто-то решил, что... Безопасность должна быть более безопасной

https://habr.com/ru/articles/880696/

#CodeSigning #usbtoken #net #aspnet #powershell #signtool #cng

As I write this, the most recent big move by Matt Mullenweg in his ongoing dispute with WP Engine was to abuse his position to seize control of a WP Engine owned plugin, justifying this act with a security fix. This justification might, under other circumstances, be believable. For example, if WP Engine weren’t actively releasing security fixes.

Now, as I wrote on a Hacker News thread, I’d been staying out of this drama. It wasn’t my fight, I wasn’t deeply familiar with the lore of the players involved, etc.

BUT! This specific tactic that Mullenweg employed happens to step on the toes of some underappreciated work I had done from 2016 to 2019 to try to mitigate supply chain attacks against WordPress. Thus, my HN comment about it.

Mullenweg’s behavior also calls into question the trustworthiness of WordPress not just as a hosting platform (WP.com, which hosts this website), but also the open source community (WP.org).

The vulnerability here is best demonstrated in the form of a shitpost:

I do not have a crystal ball that tells me the future, so whatever happens next is uncertain and entirely determined by the will of the WordPress community.

Even before I decided it was appropriate to chime in on this topic, or had really even paid attention to it, I had been hearing rumors of a hard-fork. And that maybe the right answer, but it could be excruciating for WordPress users if that happens.

Regardless of whether a hard-fork happens (or the WordPress community shifts sufficient power away from Mullenweg and Automattic), this vulnerability cannot continue if WordPress is to continue to be a trustworthy open source project.

Since this is a cryptography-focused blog, I’d like to examine ways that the WordPress community could build governance mechanisms to mitigate the risk of one man’s ego.

Revisit Code-Signing

The core code, as well as any plugins and themes, should be signed by a secret key controlled by the developer that publishes said code. There should be a secure public key infrastructure for ensuring that it’s difficult for the infrastructure operators to surreptitiously replace a package or public key without possessing one of those secret keys.

I had previously begun work on a proposal to solve this problem for the PHP community, and in turn, WordPress. However, my solution (called Gossamer) wasn’t designed with GDPR (specifically, the Right to be Forgotten) in mind.

Today, I’m aware of SigStore, which has gotten a lot of traction with other programming language ecosystems.

Additionally, there is an ongoing proposal for an authority-free PKI for the Fediverse that appears to take GDPR into consideration (though that’s more of an analysis for lawyers than cryptography experts to debate).

I think, at the intersection of both systems, there is a way to build a secure PKI where the developer maintains the keys as part of the normal course of operation.

Break-Glass Security with FROST

However, even with code-signing where the developers own their own keys, there is always a risk of a developer going rogue, or getting totally owned up.

Ideally, we’d want to mitigate that risk without reintroducing the single point of vulnerability that exists today. And we’d want to do it without a ton of protocol complexity visible to users (above what they’d already need to accept to have secure code signing in place).

Fortunately, cryptographers already built the tool we would need: Threshold Signatures.

From RFC 9591, we could use FROST(Ed25519, SHA-512) to require a threshold quorum (say, 3) of high-trust entities (for which there would be, for example, 5) to share a piece of an Ed25519 secret key. Cryptographers often call these t-of-N (in this example, 3-of-5) thresholds. The specific values for t and N vary a lot for different threat models.

When a quorum of entities do coordinate, they can produce a signature for a valid protocol message to revoke a developer’s access to the system, thus allowing a hostile takeover. However, it’s not possible for them to coordinate without their activity being publicly visible to the entire community.

The best part about FROST(Ed25519, SHA-512) is that it doesn’t require any code changes for signature verification. It spits out a valid Ed25519 signature, which you can check with just libsodium (or sodium_compat).

Closing Thoughts

If your threat model doesn’t include leadership’s inflated ego, or the corruption of social, political, and economic power, you aren’t building trustworthy software.

Promises and intentions don’t matter here. Mechanisms do.

Whatever the WordPress community decides is their best move forward (hard forks are the nuclear option, naturally), the end result cannot be replacing one tyrant with another.

The root cause isn’t that Mullenweg is particularly evil, it’s that a large chunk of websites are beholden to only his whims (whether they realized it or not).

One can only make decisions that affects millions of lives and thousands of employees (though significantly fewer today than when this drama began) for so long before an outcome like this occurs.

If you aren’t immune to propaganda, you aren’t immune to the corruption of power, either.

But if you architect your systems (governance and technological) to not place all this power solely in the hands of one unelected nerd, you mitigate the risk by design.

(Yes, you do invite a different set of problems, such as decision paralysis and inertia. But given WordPress’s glacial pace of minimum PHP version bumps over its lifetime, I don’t think that’s actually a new risk.)

With all that said, whatever the WordPress community decides is best for them, I’m here to help.

https://scottarc.blog/2024/10/14/trust-rules-everything-around-me/

#AdvancedCustomFields #arrogance #automaticUpdates #Automattic #codeSigning #cybersecurity #ego #MattMullenweg #news #PKI #pluginSecurity #powerCorrupts #SecureCustomFields #security #softwareGovernance #supplyChain #supplyChainSecurity #supplyChainSecurity #technology #threatModels #trust #WordPress #WPEngine

As I write this, the most recent big move by Matt Mullenweg in his ongoing dispute with WP Engine was to abuse his position to seize control of a WP Engine owned plugin, justifying this act with a security fix. This justification might, under other circumstances, be believable. For example, if WP Engine weren’t actively releasing security fixes.

Now, as I wrote on a Hacker News thread, I’d been staying out of this drama. It wasn’t my fight, I wasn’t deeply familiar with the lore of the players involved, etc.

BUT! This specific tactic that Mullenweg employed happens to step on the toes of some underappreciated work I had done from 2016 to 2019 to try to mitigate supply chain attacks against WordPress. Thus, my HN comment about it.

Mullenweg’s behavior also calls into question the trustworthiness of WordPress not just as a hosting platform (WP.com, which hosts this website), but also the open source community (WP.org).

The vulnerability here is best demonstrated in the form of a shitpost:

I do not have a crystal ball that tells me the future, so whatever happens next is uncertain and entirely determined by the will of the WordPress community.

Even before I decided it was appropriate to chime in on this topic, or had really even paid attention to it, I had been hearing rumors of a hard-fork. And that maybe the right answer, but it could be excruciating for WordPress users if that happens.

Regardless of whether a hard-fork happens (or the WordPress community shifts sufficient power away from Mullenweg and Automattic), this vulnerability cannot continue if WordPress is to continue to be a trustworthy open source project.

Since this is a cryptography-focused blog, I’d like to examine ways that the WordPress community could build governance mechanisms to mitigate the risk of one man’s ego.

Revisit Code-Signing

The core code, as well as any plugins and themes, should be signed by a secret key controlled by the developer that publishes said code. There should be a secure public key infrastructure for ensuring that it’s difficult for the infrastructure operators to surreptitiously replace a package or public key without possessing one of those secret keys.

I had previously begun work on a proposal to solve this problem for the PHP community, and in turn, WordPress. However, my solution (called Gossamer) wasn’t designed with GDPR (specifically, the Right to be Forgotten) in mind.

Today, I’m aware of SigStore, which has gotten a lot of traction with other programming language ecosystems.

Additionally, there is an ongoing proposal for an authority-free PKI for the Fediverse that appears to take GDPR into consideration (though that’s more of an analysis for lawyers than cryptography experts to debate).

I think, at the intersection of both systems, there is a way to build a secure PKI where the developer maintains the keys as part of the normal course of operation.

Break-Glass Security with FROST

However, even with code-signing where the developers own their own keys, there is always a risk of a developer going rogue, or getting totally owned up.

Ideally, we’d want to mitigate that risk without reintroducing the single point of vulnerability that exists today. And we’d want to do it without a ton of protocol complexity visible to users (above what they’d already need to accept to have secure code signing in place).

Fortunately, cryptographers already built the tool we would need: Threshold Signatures.

From RFC 9591, we could use FROST(Ed25519, SHA-512) to require a threshold quorum (say, 3) of high-trust entities (for which there would be, for example, 5) to share a piece of an Ed25519 secret key. Cryptographers often call these t-of-N (in this example, 3-of-5) thresholds. The specific values for t and N vary a lot for different threat models.

When a quorum of entities do coordinate, they can produce a signature for a valid protocol message to revoke a developer’s access to the system, thus allowing a hostile takeover. However, it’s not possible for them to coordinate without their activity being publicly visible to the entire community.

The best part about FROST(Ed25519, SHA-512) is that it doesn’t require any code changes for signature verification. It spits out a valid Ed25519 signature, which you can check with just libsodium (or sodium_compat).

Closing Thoughts

If your threat model doesn’t include leadership’s inflated ego, or the corruption of social, political, and economic power, you aren’t building trustworthy software.

Promises and intentions don’t matter here. Mechanisms do.

Whatever the WordPress community decides is their best move forward (hard forks are the nuclear option, naturally), the end result cannot be replacing one tyrant with another.

The root cause isn’t that Mullenweg is particularly evil, it’s that a large chunk of websites are beholden to only his whims (whether they realized it or not).

One can only make decisions that affects millions of lives and thousands of employees (though significantly fewer today than when this drama began) for so long before an outcome like this occurs.

If you aren’t immune to propaganda, you aren’t immune to the corruption of power, either.

But if you architect your systems (governance and technological) to not place all this power solely in the hands of one unelected nerd, you mitigate the risk by design.

(Yes, you do invite a different set of problems, such as decision paralysis and inertia. But given WordPress’s glacial pace of minimum PHP version bumps over its lifetime, I don’t think that’s actually a new risk.)

With all that said, whatever the WordPress community decides is best for them, I’m here to help.

https://scottarc.blog/2024/10/14/trust-rules-everything-around-me/

#AdvancedCustomFields #arrogance #automaticUpdates #Automattic #codeSigning #cybersecurity #ego #MattMullenweg #news #PKI #pluginSecurity #powerCorrupts #SecureCustomFields #security #softwareGovernance #supplyChain #supplyChainSecurity #supplyChainSecurity #technology #threatModels #trust #WordPress #WPEngine

As I write this, the most recent big move by Matt Mullenweg in his ongoing dispute with WP Engine was to abuse his position to seize control of a WP Engine owned plugin, justifying this act with a security fix. This justification might, under other circumstances, be believable. For example, if WP Engine weren’t actively releasing security fixes.

Now, as I wrote on a Hacker News thread, I’d been staying out of this drama. It wasn’t my fight, I wasn’t deeply familiar with the lore of the players involved, etc.

BUT! This specific tactic that Mullenweg employed happens to step on the toes of some underappreciated work I had done from 2016 to 2019 to try to mitigate supply chain attacks against WordPress. Thus, my HN comment about it.

Mullenweg’s behavior also calls into question the trustworthiness of WordPress not just as a hosting platform (WP.com, which hosts this website), but also the open source community (WP.org).

The vulnerability here is best demonstrated in the form of a shitpost:

I do not have a crystal ball that tells me the future, so whatever happens next is uncertain and entirely determined by the will of the WordPress community.

Even before I decided it was appropriate to chime in on this topic, or had really even paid attention to it, I had been hearing rumors of a hard-fork. And that maybe the right answer, but it could be excruciating for WordPress users if that happens.

Regardless of whether a hard-fork happens (or the WordPress community shifts sufficient power away from Mullenweg and Automattic), this vulnerability cannot continue if WordPress is to continue to be a trustworthy open source project.

Since this is a cryptography-focused blog, I’d like to examine ways that the WordPress community could build governance mechanisms to mitigate the risk of one man’s ego.

Revisit Code-Signing

The core code, as well as any plugins and themes, should be signed by a secret key controlled by the developer that publishes said code. There should be a secure public key infrastructure for ensuring that it’s difficult for the infrastructure operators to surreptitiously replace a package or public key without possessing one of those secret keys.

I had previously begun work on a proposal to solve this problem for the PHP community, and in turn, WordPress. However, my solution (called Gossamer) wasn’t designed with GDPR (specifically, the Right to be Forgotten) in mind.

Today, I’m aware of SigStore, which has gotten a lot of traction with other programming language ecosystems.

Additionally, there is an ongoing proposal for an authority-free PKI for the Fediverse that appears to take GDPR into consideration (though that’s more of an analysis for lawyers than cryptography experts to debate).

I think, at the intersection of both systems, there is a way to build a secure PKI where the developer maintains the keys as part of the normal course of operation.

Break-Glass Security with FROST

However, even with code-signing where the developers own their own keys, there is always a risk of a developer going rogue, or getting totally owned up.

Ideally, we’d want to mitigate that risk without reintroducing the single point of vulnerability that exists today. And we’d want to do it without a ton of protocol complexity visible to users (above what they’d already need to accept to have secure code signing in place).

Fortunately, cryptographers already built the tool we would need: Threshold Signatures.

From RFC 9591, we could use FROST(Ed25519, SHA-512) to require a threshold quorum (say, 3) of high-trust entities (for which there would be, for example, 5) to share a piece of an Ed25519 secret key. Cryptographers often call these t-of-N (in this example, 3-of-5) thresholds. The specific values for t and N vary a lot for different threat models.

When a quorum of entities do coordinate, they can produce a signature for a valid protocol message to revoke a developer’s access to the system, thus allowing a hostile takeover. However, it’s not possible for them to coordinate without their activity being publicly visible to the entire community.

The best part about FROST(Ed25519, SHA-512) is that it doesn’t require any code changes for signature verification. It spits out a valid Ed25519 signature, which you can check with just libsodium (or sodium_compat).

Closing Thoughts

If your threat model doesn’t include leadership’s inflated ego, or the corruption of social, political, and economic power, you aren’t building trustworthy software.

Promises and intentions don’t matter here. Mechanisms do.

Whatever the WordPress community decides is their best move forward (hard forks are the nuclear option, naturally), the end result cannot be replacing one tyrant with another.

The root cause isn’t that Mullenweg is particularly evil, it’s that a large chunk of websites are beholden to only his whims (whether they realized it or not).

One can only make decisions that affects millions of lives and thousands of employees (though significantly fewer today than when this drama began) for so long before an outcome like this occurs.

If you aren’t immune to propaganda, you aren’t immune to the corruption of power, either.

But if you architect your systems (governance and technological) to not place all this power solely in the hands of one unelected nerd, you mitigate the risk by design.

(Yes, you do invite a different set of problems, such as decision paralysis and inertia. But given WordPress’s glacial pace of minimum PHP version bumps over its lifetime, I don’t think that’s actually a new risk.)

With all that said, whatever the WordPress community decides is best for them, I’m here to help.

https://scottarc.blog/2024/10/14/trust-rules-everything-around-me/

#AdvancedCustomFields #arrogance #automaticUpdates #Automattic #codeSigning #cybersecurity #ego #MattMullenweg #news #PKI #pluginSecurity #powerCorrupts #SecureCustomFields #security #softwareGovernance #supplyChain #supplyChainSecurity #supplyChainSecurity #technology #threatModels #trust #WordPress #WPEngine

As I write this, the most recent big move by Matt Mullenweg in his ongoing dispute with WP Engine was to abuse his position to seize control of a WP Engine owned plugin, justifying this act with a security fix. This justification might, under other circumstances, be believable. For example, if WP Engine weren’t actively releasing security fixes.

Now, as I wrote on a Hacker News thread, I’d been staying out of this drama. It wasn’t my fight, I wasn’t deeply familiar with the lore of the players involved, etc.

BUT! This specific tactic that Mullenweg employed happens to step on the toes of some underappreciated work I had done from 2016 to 2019 to try to mitigate supply chain attacks against WordPress. Thus, my HN comment about it.

Mullenweg’s behavior also calls into question the trustworthiness of WordPress not just as a hosting platform (WP.com, which hosts this website), but also the open source community (WP.org).

The vulnerability here is best demonstrated in the form of a shitpost:

I do not have a crystal ball that tells me the future, so whatever happens next is uncertain and entirely determined by the will of the WordPress community.

Even before I decided it was appropriate to chime in on this topic, or had really even paid attention to it, I had been hearing rumors of a hard-fork. And that maybe the right answer, but it could be excruciating for WordPress users if that happens.

Regardless of whether a hard-fork happens (or the WordPress community shifts sufficient power away from Mullenweg and Automattic), this vulnerability cannot continue if WordPress is to continue to be a trustworthy open source project.

Since this is a cryptography-focused blog, I’d like to examine ways that the WordPress community could build governance mechanisms to mitigate the risk of one man’s ego.

Revisit Code-Signing

The core code, as well as any plugins and themes, should be signed by a secret key controlled by the developer that publishes said code. There should be a secure public key infrastructure for ensuring that it’s difficult for the infrastructure operators to surreptitiously replace a package or public key without possessing one of those secret keys.

I had previously begun work on a proposal to solve this problem for the PHP community, and in turn, WordPress. However, my solution (called Gossamer) wasn’t designed with GDPR (specifically, the Right to be Forgotten) in mind.

Today, I’m aware of SigStore, which has gotten a lot of traction with other programming language ecosystems.

Additionally, there is an ongoing proposal for an authority-free PKI for the Fediverse that appears to take GDPR into consideration (though that’s more of an analysis for lawyers than cryptography experts to debate).

I think, at the intersection of both systems, there is a way to build a secure PKI where the developer maintains the keys as part of the normal course of operation.

Break-Glass Security with FROST

However, even with code-signing where the developers own their own keys, there is always a risk of a developer going rogue, or getting totally owned up.

Ideally, we’d want to mitigate that risk without reintroducing the single point of vulnerability that exists today. And we’d want to do it without a ton of protocol complexity visible to users (above what they’d already need to accept to have secure code signing in place).

Fortunately, cryptographers already built the tool we would need: Threshold Signatures.

From RFC 9591, we could use FROST(Ed25519, SHA-512) to require a threshold quorum (say, 3) of high-trust entities (for which there would be, for example, 5) to share a piece of an Ed25519 secret key. Cryptographers often call these t-of-N (in this example, 3-of-5) thresholds. The specific values for t and N vary a lot for different threat models.

When a quorum of entities do coordinate, they can produce a signature for a valid protocol message to revoke a developer’s access to the system, thus allowing a hostile takeover. However, it’s not possible for them to coordinate without their activity being publicly visible to the entire community.

The best part about FROST(Ed25519, SHA-512) is that it doesn’t require any code changes for signature verification. It spits out a valid Ed25519 signature, which you can check with just libsodium (or sodium_compat).

Closing Thoughts

If your threat model doesn’t include leadership’s inflated ego, or the corruption of social, political, and economic power, you aren’t building trustworthy software.

Promises and intentions don’t matter here. Mechanisms do.

Whatever the WordPress community decides is their best move forward (hard forks are the nuclear option, naturally), the end result cannot be replacing one tyrant with another.

The root cause isn’t that Mullenweg is particularly evil, it’s that a large chunk of websites are beholden to only his whims (whether they realized it or not).

One can only make decisions that affects millions of lives and thousands of employees (though significantly fewer today than when this drama began) for so long before an outcome like this occurs.

If you aren’t immune to propaganda, you aren’t immune to the corruption of power, either.

But if you architect your systems (governance and technological) to not place all this power solely in the hands of one unelected nerd, you mitigate the risk by design.

(Yes, you do invite a different set of problems, such as decision paralysis and inertia. But given WordPress’s glacial pace of minimum PHP version bumps over its lifetime, I don’t think that’s actually a new risk.)

With all that said, whatever the WordPress community decides is best for them, I’m here to help.

https://scottarc.blog/2024/10/14/trust-rules-everything-around-me/

#AdvancedCustomFields #arrogance #automaticUpdates #Automattic #codeSigning #cybersecurity #ego #MattMullenweg #news #PKI #pluginSecurity #powerCorrupts #SecureCustomFields #security #softwareGovernance #supplyChain #supplyChainSecurity #supplyChainSecurity #technology #threatModels #trust #WordPress #WPEngine

As I write this, the most recent big move by Matt Mullenweg in his ongoing dispute with WP Engine was to abuse his position to seize control of a WP Engine owned plugin, justifying this act with a security fix. This justification might, under other circumstances, be believable. For example, if WP Engine weren’t actively releasing security fixes.

Now, as I wrote on a Hacker News thread, I’d been staying out of this drama. It wasn’t my fight, I wasn’t deeply familiar with the lore of the players involved, etc.

BUT! This specific tactic that Mullenweg employed happens to step on the toes of some underappreciated work I had done from 2016 to 2019 to try to mitigate supply chain attacks against WordPress. Thus, my HN comment about it.

Mullenweg’s behavior also calls into question the trustworthiness of WordPress not just as a hosting platform (WP.com, which hosts this website), but also the open source community (WP.org).

The vulnerability here is best demonstrated in the form of a shitpost:

I do not have a crystal ball that tells me the future, so whatever happens next is uncertain and entirely determined by the will of the WordPress community.

Even before I decided it was appropriate to chime in on this topic, or had really even paid attention to it, I had been hearing rumors of a hard-fork. And that maybe the right answer, but it could be excruciating for WordPress users if that happens.

Regardless of whether a hard-fork happens (or the WordPress community shifts sufficient power away from Mullenweg and Automattic), this vulnerability cannot continue if WordPress is to continue to be a trustworthy open source project.

Since this is a cryptography-focused blog, I’d like to examine ways that the WordPress community could build governance mechanisms to mitigate the risk of one man’s ego.

Revisit Code-Signing

The core code, as well as any plugins and themes, should be signed by a secret key controlled by the developer that publishes said code. There should be a secure public key infrastructure for ensuring that it’s difficult for the infrastructure operators to surreptitiously replace a package or public key without possessing one of those secret keys.

I had previously begun work on a proposal to solve this problem for the PHP community, and in turn, WordPress. However, my solution (called Gossamer) wasn’t designed with GDPR (specifically, the Right to be Forgotten) in mind.

Today, I’m aware of SigStore, which has gotten a lot of traction with other programming language ecosystems.

Additionally, there is an ongoing proposal for an authority-free PKI for the Fediverse that appears to take GDPR into consideration (though that’s more of an analysis for lawyers than cryptography experts to debate).

I think, at the intersection of both systems, there is a way to build a secure PKI where the developer maintains the keys as part of the normal course of operation.

Break-Glass Security with FROST

However, even with code-signing where the developers own their own keys, there is always a risk of a developer going rogue, or getting totally owned up.

Ideally, we’d want to mitigate that risk without reintroducing the single point of vulnerability that exists today. And we’d want to do it without a ton of protocol complexity visible to users (above what they’d already need to accept to have secure code signing in place).

Fortunately, cryptographers already built the tool we would need: Threshold Signatures.

From RFC 9591, we could use FROST(Ed25519, SHA-512) to require a threshold quorum (say, 3) of high-trust entities (for which there would be, for example, 5) to share a piece of an Ed25519 secret key. Cryptographers often call these t-of-N (in this example, 3-of-5) thresholds. The specific values for t and N vary a lot for different threat models.

When a quorum of entities do coordinate, they can produce a signature for a valid protocol message to revoke a developer’s access to the system, thus allowing a hostile takeover. However, it’s not possible for them to coordinate without their activity being publicly visible to the entire community.

The best part about FROST(Ed25519, SHA-512) is that it doesn’t require any code changes for signature verification. It spits out a valid Ed25519 signature, which you can check with just libsodium (or sodium_compat).

Closing Thoughts

If your threat model doesn’t include leadership’s inflated ego, or the corruption of social, political, and economic power, you aren’t building trustworthy software.

Promises and intentions don’t matter here. Mechanisms do.

Whatever the WordPress community decides is their best move forward (hard forks are the nuclear option, naturally), the end result cannot be replacing one tyrant with another.

The root cause isn’t that Mullenweg is particularly evil, it’s that a large chunk of websites are beholden to only his whims (whether they realized it or not).

One can only make decisions that affects millions of lives and thousands of employees (though significantly fewer today than when this drama began) for so long before an outcome like this occurs.

If you aren’t immune to propaganda, you aren’t immune to the corruption of power, either.

But if you architect your systems (governance and technological) to not place all this power solely in the hands of one unelected nerd, you mitigate the risk by design.

(Yes, you do invite a different set of problems, such as decision paralysis and inertia. But given WordPress’s glacial pace of minimum PHP version bumps over its lifetime, I don’t think that’s actually a new risk.)

With all that said, whatever the WordPress community decides is best for them, I’m here to help.

https://scottarc.blog/2024/10/14/trust-rules-everything-around-me/

#AdvancedCustomFields #arrogance #automaticUpdates #Automattic #codeSigning #cybersecurity #ego #MattMullenweg #news #PKI #pluginSecurity #powerCorrupts #SecureCustomFields #security #softwareGovernance #supplyChain #supplyChainSecurity #supplyChainSecurity #technology #threatModels #trust #WordPress #WPEngine

TIL: #Apple launched the next-stage with their #codesigning-thingy. During the past a warning for #unsigned Apps popped up, which can be clicked away at the UI.

New hotness: macos tells: "Binary damaged, eject DMG". Only workaround is some shell-magic.

i don't want to buy a cert. damn.

Anybody with the same problems?

#followerpower #developer

Earlier this week me and the team released #SignServer Community 6.0 with additional Post Quantum support, new REST interface and tons of maintenance under the hood. #OpenSource #DigitalSignatures #CodeSigning #PKI #PQC #Dilithium #SPHINCS https://www.signserver.org/resources/signserver-community-6-is-released/

Microsoft digital certificates have once again been abused to sign malware - Enlarge (credit: Getty Images)

Microsoft has once again been c... - https://arstechnica.com/?p=1904163 #digitalcertificate #codesigning #microsoft #malware #biz&it