Hacker News Reader

Comment by gary_0 | Hacker News Reader

We need a LetsEncrypt for executable signing. Although I suspect Microsoft and Apple are making distributing executables for their platforms costly and inconvenient on purpose in order to drive developers onto their app stores. If that's the case, I guess we'll just have to train users to ignore all the security prompts about unsigned installers (some developers already do).

View on HN

The whole point of digital signing is to verify and have strong trust in the provenance of the code.

This requires identity validation and controls for it to actually work, which is fundamentally incompatible with a Let's Encrypt-style pretend-CA.

This means storage of keys in hardware. Otherwise code signing keys are stolen and used for malware distribution in high profile attacks. This happened one too many times hence the more stringent requirements.

Ironically these guys want their cake and eat it too, there is no reason they couldn't just manually sign release builds which come once in a while. Many small OSS projects do this. No, they want full automation with an organization cert and now are complaining about meeting the requirements for that.

The whole point of identity verification is pointless, given LOLbins and LOLdrivers that are never updated nor fixed.

I wish we had a cryptographic verification mechanism based on code and reproducibility of their builds, and local-sensitive hashing mechanisms rather than the current ones.

Technically this might actually be a decentralized ledging use case that makes sense.

A certificate that says "this installer really did come from the owner of exampleapp.com" is better than users just trusting whatever random file came up in a Google search.

And meanwhile, in Linux land, people will install things by piping curl into bash[0][1], so the bar is just not that high. And the ultimate answer to security will come from better app sandboxing, not from charging every native-app developer in the world $700/year for a code signing certificate.

[0] https://docs.chef.io/chef_install_script/ [1] https://github.com/zyedidia/micro#quick-install-script

>meanwhile, in Linux land

Just because some operating systems are decades behind on security that does not mean that security does not matter.

That’s the idea behind Sigstore[1]. The larger challenge is the vendors themselves: Sigstore (or anyone else, really) can give code-signing certificates and tooling to developers for free, but that tooling has limited value if the host OS doesn’t bundle the CA certificates that would enable native validation.

[1]: https://www.sigstore.dev/

Wait, their certificates aren't trusted by the os? What's the point of their service, then? A self-signed certificate accomplishes the same result!

There are lots of systems (and ecosystems) where host trust doesn’t matter, like containers or language-specific package management. Sigstore is currently well-suited for those contexts.

With a self-signed certificate, you are effectively your own PKI. The goal is generally to deduplicate that kind of work while also providing better security properties than “my host trusts self-signed certificates from a root CA that I keep on disk somewhere.”

Well the assumption is that the root CA stores them more safely than "on my laptop in my unlocked bedroom in an unassuming neighborhood of brighton" that most developers lean on for their secret storage, but, well, you never know.

A more specific example: nuget allows pinning the certs. https://learn.microsoft.com/en-us/nuget/reference/nuget-conf... I feel signing a nuget package with a self-signed cert is not worse than any PGP signing method in term of trust level. They both are identified by a crypto fingerprint and you have to manually get the fingerprint from somewhere and just trust it. I do not see a big difference there.

The landing page linked above gives a pretty detailed write-up about the point of their service

Sigstore doesn’t seem to verify actual legal identity, just control over a GitHub account or similar. It therefore doesn’t provide the same level of assurance as a code-signing certificate. OSs thus do well to not bundle their CA certificate as a trusted root.

Github already provides a proxy of actual legal identity, at least in the EU. For a business owned org, the VAT id is provided along with validation and billing information must match.

I don't think your OS intends to imply or guarantee a legal entity relationship with every CA certificate in your trust store. It's not even clear what that guarantee, as an end user, would get you: the presence of a legal entity doesn't somehow make that entity accountable to you or your locality.

> I don't think your OS intends to imply or guarantee a legal entity relationship with every CA certificate in your trust store.

I get the feeling that it's exactly what Windows "intends to imply or guarantee", it's just taking a long time to get there. The whole code signing part is trying to create a reality where to be able to create software for Windows, you need to be a business entity, and need to have business relationships with Microsoft - directly, or transitively. Basically, a corporate web of trust.

It's a racket.

Nawh, it's just a Scheme.

lol, I never thought about scheme/racket naming in this context.

Is this an inside joke in the community or maybe even a an official take?

Scheme was the third in a series of languages designed at the MIT AI lab; the first two were Planner and Conniver. The third was going to be called Schemer, but ITS only allowed 6-character filenames (because, encoded in sixbit, that fits in one machine word). Thus the pattern was established from the very beginning.

Also consider that another widely-used scheme implementation is called Guile.

Absolutely! Another good option is to just use Linux.

Reply on news.ycombinator.com