10 ms·

Sigstore – A new standard for signing, verifying and protecting software

118 points by decodebytes 5y ago

andrewmcwatters 5y ago
Can I ask, is this a real, actual concern? Why do I need to sign and verify my software is my software? Why is a hash not sufficient integrity verification? I have never heard of a good argument for this besides the Apple-esque control of remotely disabling the ability for software to run based on certificate authority, which is not a feature I'm interested in. Further, I'd like to not see this as possible, since year after year more and more software companies seem to think they're entitled to more and more.
- schoen 5y ago
  This isn't about users' entitlement to run software, but about publishers and users' ability to confirm that everyone has the same version of the software -- to mitigate supply-chain attacks. This is a real, actual concern because governments and probably organized crime are interested in attacking supply chains in order to attack end users, for example by hacking software developers or publishers in order to substitute a slightly modified version of code. It could be useful for software distributors to have their version history memorialized somewhere outside of their own control, for example to reduce the attractiveness of governments trying to compel them to secretly tamper with some users' versions of a program, or to make it meaningful and more straightforward to check later on whether they published what they thought they published.
  - andrewmcwatters 5y ago
    So once again, what is the difference between this and an authorized list of integrity hash values? Edit: I misread the latter portion of your post. I see now. Thanks.
    - schoen 5y ago
      As some other replies pointed out, if that list is distributed in the same place as the software itself, an attacker can modify both of them at the same time. Maybe the list is digitally signed by the publisher, but then often the signing key is also distributed in the same place as the software itself (and also often used on the same infrastructure that the software was compiled on). Also, if the list of hash values is distributed only by a software publisher, the software publisher will get the ability to secretly backdoor some users, but not others, by creating two or more different versions of that list. Then it can deny the existence of the backdoored version to the public (or to itself, if the backdooring was done by an unauthorized insider!).
      - andrewmcwatters 5y ago
        Right, I can understand how this would be important now. Thank you.
  - allset_ 5y ago
    It's also a significant step in a direction to where every dependency that these software publishers is also signed, increasing the overall confidence that there's no malicious code in the software they publish.
- detaro 5y ago
  How do you know which hash is the correct one? you can a) check a signature on the hash (current method) b) check with a central authority if the hash is ok (now that's central control) c) somehow discover the hash from some other source - possible, but not something users will generally manually verify, and the question of how to trust that hash again quickly comes down to signatures or authority.
  - andrewmcwatters 5y ago
    That's not control.
    - detaro 5y ago
      At least as much as a signature check, and if you send a hash to somewhere to look it up it reveals more about your system than the signature verification does. If you fetch a list of trusted hashes, the source can customize it more precisely to what to tell you is ok than if you verify a signature. How is telling you "don't trust this hash" any less "Apple-esque control of remotely disabling the ability for softwareto run" than something saying "don't trust this certificate after $date"? (E.g. the recent-ish Apple outrage was that they switched to uploading hashes over just verifying signatures)
      - andrewmcwatters 5y ago
        I see now.
  - mfer 5y ago
    > How do you know which hash is the correct one? Figuring out the correct hash is different from knowing that the software you got is from who you expected it to be from. If you sign 100 versions of something and you verify what you got... you'll know they came from who you expected (rather than a bad actor) but you might not know which version to run from that.
- wmf 5y ago
  Is there a trustable, out-of-band way for users to get the hash? How? There's a real vulnerability where users get a compromised package and a matching hash from the same compromised repository.
  - decodebytes 5y ago
    This is where the transparency log comes in. The hash / signature and public key (by way of a signed x509 certificate) are hashed into an tamper resistant immutable merkle tree. This makes it hard to tamper with the hash. However a bad hash could still be put into the tree, but this is sort of a feature not a bug aspect of a transparency log, anyone can audit the log and see those bad entries. You as an individual are not susceptible to a targeted attack, you see what everyone else sees. This is an idiom borrowed from certificate transparency. You kind of want the badly signed certs to be recorded, as they can be monitored and audited for. Everything is out in the open in the plain light of day.
- zahllos 5y ago
  Yes it is a real concern. If you're running a Linux distribution, chances are you are downloading your packages from a mirror and not the primary mirror for your distribution. This is done to everyone's benefit bandwidth-wise. However it opens up the possibility that the artefacts can be tampered with on the server. Signing confirms their authenticity. In a (cryptographically secure) hash, there is no 'key' and so anyone can create a valid one for their modified bundle. Ditto for containers, Android Apps, and just about anything else we use.
- enragedcacti 5y ago
  > Why is a hash not sufficient integrity verification? not necessarily endorsing the need for this, but one reason is that if the hash and file are hosted by the same site an attacker who compromised the web server can trivially change the hash to match their payload. With this system, they would have to compromise both the web server and the signing server. You can also leverage this to trust a binary even from an unknown source because the signature will match and confirm authenticity regardless of how trustworthy the source of the binary is.
  - andrewmcwatters 5y ago
    That's just an incorrect usage of an integrity hash. If you obtain a resource from another party other than the original vendor, you need to verify integrity. If the vendor itself is compromised, then I can understand such a system.
- simonw 5y ago
  Fifteen years ago the principle security worry in running a web application was that some "script kiddy" would break in and deface your homepage. Today the threats are much more real. Ransomware, cryptocurrency miners, even state actors. An enormous point of weakness in modern software is the supply chain - many projects now have thousands of nested dependencies. Most of those dependencies represents at least one human being who can be threatened with a crowbar and forced to ship an exploit, which can then infect vast numbers of production applications. So yes, for me this is a very real concern!
  - BenTheElder 5y ago
    Why can't they be "threatened with a crowbar" to sign the exploit?
    - dane-pgp 5y ago
      Ultimately the system will need to support signatures which represent not just "I made this" but "I reviewed this", and people will need to set policies for whose reviews they trust, and how many reviews they require for each component. If reviewers can build up a reputation anonymously, that will make it harder to find the human who needs to be crowbarred, but I'm not sure how you prove you are a good reviewer in a way which isn't gameable. Alternatively, the reviewers could be well known teams in multiple jurisdictions, such that an attacker would need to buy multiple crowbars and multiple plane tickets.
      - BenTheElder 5y ago
        Those are interesting points / possible approaches, however is there any indication that this particular project enables any of that? This seems focused on signing binaries / build artifacts. IMHO it seems like if you have the threat model of "crowbared maintainer forced to insert backdoor" you probably don't trust sources let alone binaries and need to vet your dependency sources and then compile your own binaries from them. Many open source dependencies will not have a jurisdictionally diverse review team, or any review team at all (single maintainer).
- mfer 5y ago
  > Can I ask, is this a real, actual concern? Why do I need to sign and verify my software is my software? Why is a hash not sufficient integrity verification? Security is layered so there is no one thing to just secure it. With that in mind, how do you control which revision of something is deployed? Do you use the hash? What if someone pushed a different version to your container repo? Could that be somehow run somewhere? It may require someone gaining privileges but that is not an uncommon situation. This is why multi-layered security is useful. If something is signed and verified you can know WHO it came from. Someone with access to sign it. In the situation where a bad actor pushed something to a container repo the verification step would fail and you would catch it. This is just one example. There are many others.
alexeyoganezov 5y ago
I hope this feature will be completely optional. Code signing in every major OS (Windows, macOS, Android, iOS) is pure pain, you cannot distribute your own apps properly without obtaining a signature for 100$ (usually per OS, sometimes per year).
- hulitu 5y ago
  This is the point. To pay. Security ? Do you trust MS or Apple or Google ?
- decodebytes 5y ago
  One of the co-founders here. sigstore will be a non profit / free to use service. Think Let's Encrypt for software signing. My hope is that we shift the paradigm so that consuming untrusted software via packages / dependencies etc becomes as unappealing as serving a website over just plain ole HTTP has now become. In order to make that shift, open source communities require a free and easy to use service and this is what we hope sigstore will become, which is why it's a Linux Foundation project with all code being developed and maintained by a community.
  - yosamino 5y ago
    What is your rationale behind this (if I understood it correctly) being a Service rather than a way of doing things ? It's becoming increasingly difficult for me to run my own code, that I am perfectly happy to sign myself, on my own devices. That might seem like a fringe case. But it shows a deeper problem: I do not trust you. I don't even know you in the first place. Yet you (well, as part of a goup) are asking me to give you more power over my devices. What is this push towards centralizing trust ? Example: Firefox extensions need to be signed now. I can't send my friends the extensions I wrote myself. There is just no way. I can't go over to their house, sit next to them, and install my self signed-root certificate, and have their version of firefox trust it. It must be signed by Mozilla: An organization that most people will never ever in their lives's interact with. That makes no sense. And not even to speak of trying to install private Root CAs into iPhones or Android devices. How does your solution empower users to own their own devices, and not have them owned by someone they are separated from by several degrees and whom they have never met ?
toiletaccount 5y ago
My wishlist for embiggening package security: Signed checksums of binaries baked into the package manager Reproducible builds made dead-simple stupid-easy Selinux/sandboxing made more transparent and simple enough to use for mere mortals Something like tripwire, by default (I think netbsd has this built in, but it's not default)
- neolog 5y ago
  https://nixos.org/ https://nixos.org/
mwcampbell 5y ago
As a hardening measure for production container or machine images, it would be good if code interpreters, including things like Python and Node.js but also shells, could be restricted to only accept source code that comes from a signed and verifiable bundle. That would mean no interactive mode, no running code supplied on the command line (meaning no shell injection vulns), and no support for eval or equivalent. But we wouldn't have to go to the full trouble of using a distroless, shell-less image. Does anyone know of active work in this area?
- alfiedotwtf 5y ago
  > signed and verifiable bundle I'd even be happy with no SemVer and only commit hashes for version control. This way, you know the version you just tested will always be the same, and nobody could modify it from under you whilst keeping the same SemVer
vhanda 5y ago
Would it be correct to say that "Sigstore" is only for containers and not all software? I'm genuinely confused. Does this also apply to "user-facing" software such as CLI tools or GUIs?
- decodebytes 5y ago
  Good question, cosign is a client that works with containers OCI / registries. We are also develop clients to work with pypi, rust cargo and cases such as helping to protect against curl | bash attacks
est31 5y ago
This is pretty cool and i think one of the good application areas of distributed ledger technology. Signing is still a hard problem, even for established projects like Rust. Right now, rustup does not verify signatures in any way or form. The security is solely thanks to https and the S3 bucket not being compromised. https://github.com/rust-lang/rustup/issues/2028 https://github.com/rust-lang/rustup/issues/2028 https://github.com/rust-lang/rustup/issues/2027 https://github.com/rust-lang/rustup/issues/2027
- ryan_lane 5y ago
  The mantra you need to remember and repeat in your head: blockchain is never a solution to anything.
- decodebytes 5y ago
  https://twitter.com/decodebytes/status/1404540227474046980 https://twitter.com/decodebytes/status/1404540227474046980
CyberRabbi 5y ago
> It's for open source maintainers, by open source maintainers. > Google > Red Hat (IBM) Marketing in this manner is deceptive. Saying it’s “by and for” open source maintainers gives the impression this is a grass roots effort, when in reality this is a corporate initiative.
- aeturnum 5y ago
  There are still independent developers who contribute to passion projects in their spare time, of course, but if you've been using open source software because you believe corporations aren't substantial contributors I think you should update your priors.
  - CyberRabbi 5y ago
    So you think their grassroots marketing is appropriate?
    - aeturnum 5y ago
      I don't think saying something is built "by and for open source maintainers" is implying it's a grassroots project. All it means is that it's designed with the intent of supporting the integration of patches from members of the public, which has very little to do with it being run by a corporation or unpaid individuals.
      - CyberRabbi 5y ago
        > which has very little to do with it being run by a corporation On what basis can you say that? It’s clear that a corporation that accepts legal liability for the software they run in production or ship would have a strong incentive to create a process around determining the origin of said software.
        deleted 5y ago
        [deleted]
waynesonfire 5y ago
if this isn't gpg based it can be easily ignored.
- decodebytes 5y ago
  It supports GPG if you really want to use it (no idea why someone would want to in this day and age).
  - waynesonfire 5y ago
    because your boxes and web of charts do little to give this project credibility. Maybe if you're around in 10 years and when it comes to security, that burden of proof is on you.
    - decodebytes 5y ago
      you're free to take a parse, or even create your own project or fork.
myWindoonn 5y ago
What advantage does this have over a Nix/Guix expression tree, which carries hashes for everything downloaded from the network already?
- wmf 5y ago
  People aren't willing to adopt Nix/Guix.
terrycody 5y ago
interesting project
tuananh 5y ago
with more and more enterprises adopting k8s, this space is going to be very interesting
atonse 5y ago
To me the most fascinating thing here apart from the idea of a software signing standard, was that I’ve never witnessed a remote key signing ceremony before. I’m used to the root ones where they take laptops out of safes, etc. But no reason why this can’t happen right?

118 points by decodebytes 5y ago

Can I ask, is this a real, actual concern? Why do I need to sign and verify my software is my software? Why is a hash not sufficient integrity verification? I have never heard of a good argument for this besides the Apple-esque control of remotely disabling the ability for software to run based on certificate authority, which is not a feature I'm interested in. Further, I'd like to not see this as possible, since year after year more and more software companies seem to think they're entitled to more and more.

schoen 5y ago
This isn't about users' entitlement to run software, but about publishers and users' ability to confirm that everyone has the same version of the software -- to mitigate supply-chain attacks. This is a real, actual concern because governments and probably organized crime are interested in attacking supply chains in order to attack end users, for example by hacking software developers or publishers in order to substitute a slightly modified version of code. It could be useful for software distributors to have their version history memorialized somewhere outside of their own control, for example to reduce the attractiveness of governments trying to compel them to secretly tamper with some users' versions of a program, or to make it meaningful and more straightforward to check later on whether they published what they thought they published.
- andrewmcwatters 5y ago
  So once again, what is the difference between this and an authorized list of integrity hash values? Edit: I misread the latter portion of your post. I see now. Thanks.
  - schoen 5y ago
    As some other replies pointed out, if that list is distributed in the same place as the software itself, an attacker can modify both of them at the same time. Maybe the list is digitally signed by the publisher, but then often the signing key is also distributed in the same place as the software itself (and also often used on the same infrastructure that the software was compiled on). Also, if the list of hash values is distributed only by a software publisher, the software publisher will get the ability to secretly backdoor some users, but not others, by creating two or more different versions of that list. Then it can deny the existence of the backdoored version to the public (or to itself, if the backdooring was done by an unauthorized insider!).
    - andrewmcwatters 5y ago
      Right, I can understand how this would be important now. Thank you.
- allset_ 5y ago
  It's also a significant step in a direction to where every dependency that these software publishers is also signed, increasing the overall confidence that there's no malicious code in the software they publish.
detaro 5y ago
How do you know which hash is the correct one? you can a) check a signature on the hash (current method) b) check with a central authority if the hash is ok (now that's central control) c) somehow discover the hash from some other source - possible, but not something users will generally manually verify, and the question of how to trust that hash again quickly comes down to signatures or authority.
- andrewmcwatters 5y ago
  That's not control.
  - detaro 5y ago
    At least as much as a signature check, and if you send a hash to somewhere to look it up it reveals more about your system than the signature verification does. If you fetch a list of trusted hashes, the source can customize it more precisely to what to tell you is ok than if you verify a signature. How is telling you "don't trust this hash" any less "Apple-esque control of remotely disabling the ability for softwareto run" than something saying "don't trust this certificate after $date"? (E.g. the recent-ish Apple outrage was that they switched to uploading hashes over just verifying signatures)
    - andrewmcwatters 5y ago
      I see now.
- mfer 5y ago
  > How do you know which hash is the correct one? Figuring out the correct hash is different from knowing that the software you got is from who you expected it to be from. If you sign 100 versions of something and you verify what you got... you'll know they came from who you expected (rather than a bad actor) but you might not know which version to run from that.
wmf 5y ago
Is there a trustable, out-of-band way for users to get the hash? How? There's a real vulnerability where users get a compromised package and a matching hash from the same compromised repository.
- decodebytes 5y ago
  This is where the transparency log comes in. The hash / signature and public key (by way of a signed x509 certificate) are hashed into an tamper resistant immutable merkle tree. This makes it hard to tamper with the hash. However a bad hash could still be put into the tree, but this is sort of a feature not a bug aspect of a transparency log, anyone can audit the log and see those bad entries. You as an individual are not susceptible to a targeted attack, you see what everyone else sees. This is an idiom borrowed from certificate transparency. You kind of want the badly signed certs to be recorded, as they can be monitored and audited for. Everything is out in the open in the plain light of day.
zahllos 5y ago
Yes it is a real concern. If you're running a Linux distribution, chances are you are downloading your packages from a mirror and not the primary mirror for your distribution. This is done to everyone's benefit bandwidth-wise. However it opens up the possibility that the artefacts can be tampered with on the server. Signing confirms their authenticity. In a (cryptographically secure) hash, there is no 'key' and so anyone can create a valid one for their modified bundle. Ditto for containers, Android Apps, and just about anything else we use.
enragedcacti 5y ago
> Why is a hash not sufficient integrity verification? not necessarily endorsing the need for this, but one reason is that if the hash and file are hosted by the same site an attacker who compromised the web server can trivially change the hash to match their payload. With this system, they would have to compromise both the web server and the signing server. You can also leverage this to trust a binary even from an unknown source because the signature will match and confirm authenticity regardless of how trustworthy the source of the binary is.
- andrewmcwatters 5y ago
  That's just an incorrect usage of an integrity hash. If you obtain a resource from another party other than the original vendor, you need to verify integrity. If the vendor itself is compromised, then I can understand such a system.
simonw 5y ago
Fifteen years ago the principle security worry in running a web application was that some "script kiddy" would break in and deface your homepage. Today the threats are much more real. Ransomware, cryptocurrency miners, even state actors. An enormous point of weakness in modern software is the supply chain - many projects now have thousands of nested dependencies. Most of those dependencies represents at least one human being who can be threatened with a crowbar and forced to ship an exploit, which can then infect vast numbers of production applications. So yes, for me this is a very real concern!
- BenTheElder 5y ago
  Why can't they be "threatened with a crowbar" to sign the exploit?
  - dane-pgp 5y ago
    Ultimately the system will need to support signatures which represent not just "I made this" but "I reviewed this", and people will need to set policies for whose reviews they trust, and how many reviews they require for each component. If reviewers can build up a reputation anonymously, that will make it harder to find the human who needs to be crowbarred, but I'm not sure how you prove you are a good reviewer in a way which isn't gameable. Alternatively, the reviewers could be well known teams in multiple jurisdictions, such that an attacker would need to buy multiple crowbars and multiple plane tickets.
    - BenTheElder 5y ago
      Those are interesting points / possible approaches, however is there any indication that this particular project enables any of that? This seems focused on signing binaries / build artifacts. IMHO it seems like if you have the threat model of "crowbared maintainer forced to insert backdoor" you probably don't trust sources let alone binaries and need to vet your dependency sources and then compile your own binaries from them. Many open source dependencies will not have a jurisdictionally diverse review team, or any review team at all (single maintainer).
mfer 5y ago
> Can I ask, is this a real, actual concern? Why do I need to sign and verify my software is my software? Why is a hash not sufficient integrity verification? Security is layered so there is no one thing to just secure it. With that in mind, how do you control which revision of something is deployed? Do you use the hash? What if someone pushed a different version to your container repo? Could that be somehow run somewhere? It may require someone gaining privileges but that is not an uncommon situation. This is why multi-layered security is useful. If something is signed and verified you can know WHO it came from. Someone with access to sign it. In the situation where a bad actor pushed something to a container repo the verification step would fail and you would catch it. This is just one example. There are many others.

alexeyoganezov 5y ago

I hope this feature will be completely optional. Code signing in every major OS (Windows, macOS, Android, iOS) is pure pain, you cannot distribute your own apps properly without obtaining a signature for 100$ (usually per OS, sometimes per year).

hulitu 5y ago
This is the point. To pay. Security ? Do you trust MS or Apple or Google ?
decodebytes 5y ago
One of the co-founders here. sigstore will be a non profit / free to use service. Think Let's Encrypt for software signing. My hope is that we shift the paradigm so that consuming untrusted software via packages / dependencies etc becomes as unappealing as serving a website over just plain ole HTTP has now become. In order to make that shift, open source communities require a free and easy to use service and this is what we hope sigstore will become, which is why it's a Linux Foundation project with all code being developed and maintained by a community.
- yosamino 5y ago
  What is your rationale behind this (if I understood it correctly) being a Service rather than a way of doing things ? It's becoming increasingly difficult for me to run my own code, that I am perfectly happy to sign myself, on my own devices. That might seem like a fringe case. But it shows a deeper problem: I do not trust you. I don't even know you in the first place. Yet you (well, as part of a goup) are asking me to give you more power over my devices. What is this push towards centralizing trust ? Example: Firefox extensions need to be signed now. I can't send my friends the extensions I wrote myself. There is just no way. I can't go over to their house, sit next to them, and install my self signed-root certificate, and have their version of firefox trust it. It must be signed by Mozilla: An organization that most people will never ever in their lives's interact with. That makes no sense. And not even to speak of trying to install private Root CAs into iPhones or Android devices. How does your solution empower users to own their own devices, and not have them owned by someone they are separated from by several degrees and whom they have never met ?

toiletaccount 5y ago

My wishlist for embiggening package security: Signed checksums of binaries baked into the package manager Reproducible builds made dead-simple stupid-easy Selinux/sandboxing made more transparent and simple enough to use for mere mortals Something like tripwire, by default (I think netbsd has this built in, but it's not default)

neolog 5y ago
https://nixos.org/ https://nixos.org/

mwcampbell 5y ago

As a hardening measure for production container or machine images, it would be good if code interpreters, including things like Python and Node.js but also shells, could be restricted to only accept source code that comes from a signed and verifiable bundle. That would mean no interactive mode, no running code supplied on the command line (meaning no shell injection vulns), and no support for eval or equivalent. But we wouldn't have to go to the full trouble of using a distroless, shell-less image. Does anyone know of active work in this area?

alfiedotwtf 5y ago
> signed and verifiable bundle I'd even be happy with no SemVer and only commit hashes for version control. This way, you know the version you just tested will always be the same, and nobody could modify it from under you whilst keeping the same SemVer

vhanda 5y ago

Would it be correct to say that "Sigstore" is only for containers and not all software? I'm genuinely confused. Does this also apply to "user-facing" software such as CLI tools or GUIs?

decodebytes 5y ago
Good question, cosign is a client that works with containers OCI / registries. We are also develop clients to work with pypi, rust cargo and cases such as helping to protect against curl | bash attacks

est31 5y ago

This is pretty cool and i think one of the good application areas of distributed ledger technology. Signing is still a hard problem, even for established projects like Rust. Right now, rustup does not verify signatures in any way or form. The security is solely thanks to https and the S3 bucket not being compromised. https://github.com/rust-lang/rustup/issues/2028 https://github.com/rust-lang/rustup/issues/2028 https://github.com/rust-lang/rustup/issues/2027 https://github.com/rust-lang/rustup/issues/2027

ryan_lane 5y ago
The mantra you need to remember and repeat in your head: blockchain is never a solution to anything.
decodebytes 5y ago
https://twitter.com/decodebytes/status/1404540227474046980 https://twitter.com/decodebytes/status/1404540227474046980

CyberRabbi 5y ago

> It's for open source maintainers, by open source maintainers. > Google > Red Hat (IBM) Marketing in this manner is deceptive. Saying it’s “by and for” open source maintainers gives the impression this is a grass roots effort, when in reality this is a corporate initiative.

aeturnum 5y ago
There are still independent developers who contribute to passion projects in their spare time, of course, but if you've been using open source software because you believe corporations aren't substantial contributors I think you should update your priors.
- CyberRabbi 5y ago
  So you think their grassroots marketing is appropriate?
  - aeturnum 5y ago
    I don't think saying something is built "by and for open source maintainers" is implying it's a grassroots project. All it means is that it's designed with the intent of supporting the integration of patches from members of the public, which has very little to do with it being run by a corporation or unpaid individuals.
    - CyberRabbi 5y ago
      > which has very little to do with it being run by a corporation On what basis can you say that? It’s clear that a corporation that accepts legal liability for the software they run in production or ship would have a strong incentive to create a process around determining the origin of said software.
      - deleted 5y ago
        [deleted]

waynesonfire 5y ago

if this isn't gpg based it can be easily ignored.

decodebytes 5y ago
It supports GPG if you really want to use it (no idea why someone would want to in this day and age).
- waynesonfire 5y ago
  because your boxes and web of charts do little to give this project credibility. Maybe if you're around in 10 years and when it comes to security, that burden of proof is on you.
  - decodebytes 5y ago
    you're free to take a parse, or even create your own project or fork.

myWindoonn 5y ago

What advantage does this have over a Nix/Guix expression tree, which carries hashes for everything downloaded from the network already?

wmf 5y ago
People aren't willing to adopt Nix/Guix.

terrycody 5y ago

interesting project

tuananh 5y ago

with more and more enterprises adopting k8s, this space is going to be very interesting

atonse 5y ago

To me the most fascinating thing here apart from the idea of a software signing standard, was that I’ve never witnessed a remote key signing ceremony before. I’m used to the root ones where they take laptops out of safes, etc. But no reason why this can’t happen right?