Rendered at 20:04:49 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
noman-land 2 days ago [-]
If the signing subkey was committed, that implies developers have it as a file on their system which I find surprising if true. They should be using hardware like a Yubikey or something. Especially for something this important.
anon7000 2 days ago [-]
The signing key for Firefox stored on a single hardware yubikey available to a single person?
pamcake 2 days ago [-]
Could be multiple individuals, each with a different key.
SSS doesn't support signing AFAIK. When I last looked into it GPG/PGP doesn't support shared signing.
You can use SSS to encrypt the signing key, but then you need to fully materialize the signing key to actually sign the release. Which makes the exact situation that occurred here possible.
The only way to do multi-signer PGP is outside of the PGP protocol, you just need to sign the artifact multiple times then have the verifier assert that a sufficient number of signatures are present. But again, this isn't supported by the regular PGP tools.
pamcake 22 hours ago [-]
You are right that SSS requires temporarily rematerializing the raw key at the moment of signing. Even so it would be a huge improvement:
> Which makes the exact situation that occurred here possible.
Not so. The situation here was operator errror and someone mistakenly committing signing key in cleartext to repo. So this exact situation would not be possible. They could also have a process of signing on a dedicated instance (possibly with its own shard) which would remove key exposure completely from operator machines. This is all achivable with existing tooling and without changing implementations on verifier side.
The first link shows how an actual threshold signature scheme for PGP could be constructed.
computerfriend 2 days ago [-]
Multiple hardware devices can have the same key.
_bernd 1 days ago [-]
Yes but then you have to take extra care of this one special system which generates the key on this local system and which transfers the key material to the HSM. Sure it's a valid use case but depending on your requirements this could be a no go.
But sharing key files with developers comes also with a price tag.
Joel_Mckay 2 days ago [-]
People don't need an extra supply-chain failure mode to consider, and CVE proved these dongles are mostly security theater. Likewise, the recent Coinkite user key prediction breach certainly wasn't cool for folks that lost their holdings. =3
Antirust3743 2 days ago [-]
Wrong cve and a side channel attack doesn't mean these dongles are useless. It would have stopped the firefox team's ai from commiting their subkey ;)
eptcyka 2 days ago [-]
Storing the secret on a hardware token will most certainly help with not committing into source control.
Joel_Mckay 2 days ago [-]
Most use another build host siloed from the dev staging area, regression tested/audited, and with limited administrative access. =3
eptcyka 2 days ago [-]
Ye, and how do you get source code from devs into that silo?
Joel_Mckay 2 days ago [-]
Usually set up a custom build-bot that pulled a named branch into a VM with a read-only backing image. Had to be done that way for a number of reasons, but mainly simplified dealing with fussy fragile cross-platform build/test environments.
I should also add even simple visgrep and xdotool can automate a lot of checks that normally takes hours of repetitive testing.
Best of luck =3
perching_aix 2 days ago [-]
> these dongles are mostly security theater
...as opposed to? What's your criteria for "non-security-theater"?
Joel_Mckay 2 days ago [-]
Siloed functional regression test verification, structural audits, and package signing.
Probably would conclude dev staging areas can't run continuous integration with the current design team. Asking them to take on additional tasks while they already are YOLO'ing it with an LLM is a suckers bet. =3
ButlerianJihad 1 days ago [-]
While TFA indicates that "committed" here refers to an inadvertent `git commit`, it is important to note that, in cryptography, there are some very important meanings of "committed key" that are useful and desirable. TFA does not mention these:
https://eprint.iacr.org/2020/540
https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
You can use SSS to encrypt the signing key, but then you need to fully materialize the signing key to actually sign the release. Which makes the exact situation that occurred here possible.
The only way to do multi-signer PGP is outside of the PGP protocol, you just need to sign the artifact multiple times then have the verifier assert that a sufficient number of signatures are present. But again, this isn't supported by the regular PGP tools.
> Which makes the exact situation that occurred here possible.
Not so. The situation here was operator errror and someone mistakenly committing signing key in cleartext to repo. So this exact situation would not be possible. They could also have a process of signing on a dedicated instance (possibly with its own shard) which would remove key exposure completely from operator machines. This is all achivable with existing tooling and without changing implementations on verifier side.
The first link shows how an actual threshold signature scheme for PGP could be constructed.
I should also add even simple visgrep and xdotool can automate a lot of checks that normally takes hours of repetitive testing.
Best of luck =3
...as opposed to? What's your criteria for "non-security-theater"?
Probably would conclude dev staging areas can't run continuous integration with the current design team. Asking them to take on additional tasks while they already are YOLO'ing it with an LLM is a suckers bet. =3
Key-committing AEAD: https://en.wikipedia.org/wiki/Authenticated_encryption#Key-c...
Signing Git commits: https://docs.github.com/en/authentication/managing-commit-si...
[1]https://theupdateframework.io/
It would be good if there way a way to attest that a key was generated on and bound to a specific HSM.