[HN Gopher] Sigstore - A new standard for signing, verifying and...
___________________________________________________________________
Sigstore - A new standard for signing, verifying and protecting
software
Author : decodebytes
Score : 73 points
Date : 2021-08-09 19:14 UTC (3 hours ago)
(HTM) web link (sigstore.dev)
(TXT) w3m dump (sigstore.dev)
| alexeyoganezov wrote:
| 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 wrote:
| This is the point. To pay. Security ? Do you trust MS or Apple
| or Google ?
| decodebytes wrote:
| 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 wrote:
| 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 ?
| nonameiguess wrote:
| Did you follow the link to the project list on Github? The
| actual tool for doing the signing, cosign, is just a binary
| you can install on your device and generate signatures and
| keys yourself. The "service" part of it seems to just be
| having your public certificate vouched for by a trusted
| code signing CA. I don't see anything in the tooling that
| requires your users to only trust that CA. If you want to
| sign your cert with your own CA and tell your users to
| trust that instead, they seemingly can do that, just as you
| can do that today in browsers. That you can't do it with
| Firefox extensions and mobile app stores is a limitation
| intentionally built into the distribution channel. It's not
| a limitation of PKI itself. iOS, Android, and Mozilla could
| have chosen to let users install arbitrary trusted CAs. You
| shouldn't dismiss all PKI based on the fact that a few
| vendors have chosen to implement it in a crappy way to make
| walled gardens.
|
| It doesn't say this on the announcement, but looking at the
| actual PKI service (https://github.com/sigstore/fulcio), it
| seems to be entirely possible to self-host the service and
| roll your own CA.
| schoen wrote:
| This service is more like Certificate Transparency
|
| https://certificate.transparency.dev/
|
| and less like AuthentiCode or app store code signing.
| ChrisMarshallNY wrote:
| I 100% support youse guys in this. Good on ya.
|
| I think that compromised dependency chains are a nightmare,
| and we're just getting started.
|
| I write Apple apps, and dread the whole provisioning thing
| (which they seem to change, regularly), so this is not heavy-
| duty at all.
| toiletaccount wrote:
| 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 wrote:
| https://nixos.org/
| vhanda wrote:
| 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?
| mwcampbell wrote:
| 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?
| waynesonfire wrote:
| if this isn't gpg based it can be easily ignored.
| est31 wrote:
| 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/2027
| andrewmcwatters wrote:
| 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.
| simonw wrote:
| 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 wrote:
| Why can't they be "threatened with a crowbar" to sign the
| exploit?
| jeofken wrote:
| Harder to manage scaling that
| dane-pgp wrote:
| 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 wrote:
| 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).
| dane-pgp wrote:
| With reproducible builds, the difference between signing
| a binary and signing the source code from which it is
| built should be meaningless.
|
| I agree that the threat model should include the threat
| of untrustworthy source code, because we want the
| countermeasures to work equally well against backdoors,
| "bugdoors", and genuine bugs.
| BenTheElder wrote:
| Good points.
|
| I suspect for a lot of projects reproducible builds are
| themselves a bit of a hurdle and not being verified in
| the rarer case that they already exist, but the point of
| reproducible + signed builds as indirect source-signing
| stands.
| the_duke wrote:
| The reviewing aspect sounds a lot like cargo-crev. [1]
|
| [1] https://github.com/crev-dev/cargo-crev
| hulitu wrote:
| And when the certificate is compromised ? Crxpto AG ? There
| are a lot of companies/states which supply certificates which
| are then used for MITM.
| decodebytes wrote:
| This is where the transparency log comes in, certificate
| signing is openly auditable. It's the same as certificate
| transparency, malicious or mistakenly administered
| certificates are openly auditable (instead of being a
| transaction that occurs behind the doors of a commercial
| CA).
| mfer wrote:
| > 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.
| schoen wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Right, I can understand how this would be important now.
| Thank you.
| detaro wrote:
| 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.
| mfer wrote:
| > 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.
| andrewmcwatters wrote:
| That's not control.
| detaro wrote:
| 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 wrote:
| I see now.
| wmf wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| myWindoonn wrote:
| What advantage does this have over a Nix/Guix expression tree,
| which carries hashes for everything downloaded from the network
| already?
| CyberRabbi wrote:
| > 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 wrote:
| 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 wrote:
| So you think their grassroots marketing is appropriate?
| jacques_chester wrote:
| They are still open source maintainers, regardless of who they
| do or don't work for.
| kook_throwaway wrote:
| I seem to recall something on HN a few months back where google
| wanted to require full names for FOSS code, but can't find it
| now. (If anyone remembers that I'd appreciate a link.) This
| smells like it's trying to do the same thing and let google try
| to attain the control over the foss ecosystem that it has over
| the web.
___________________________________________________________________
(page generated 2021-08-09 23:00 UTC)