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.
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.
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
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.
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
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.
The signing key for Firefox stored on a single hardware yubikey available to a single person?
Could be multiple individuals, each with a different key.
https://eprint.iacr.org/2020/540
https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
Multiple hardware devices can have the same key.
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.
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
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 ;)
Storing the secret on a hardware token will most certainly help with not committing into source control.
Most use another build host siloed from the dev staging area, regression tested/audited, and with limited administrative access. =3
Ye, and how do you get source code from devs into that silo?
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
> these dongles are mostly security theater
...as opposed to? What's your criteria for "non-security-theater"?
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
Isn't this the sort of thing TUF[1] was invented to combat ?
[1]https://theupdateframework.io/