[my69thaccount]

> Turning on https mode in my browser brings up, as it should, a large error message saying that the site is insecure. I can't imagine that's a terribly good first impression, even though, again, Spine is one of the best animation packages out there.

A site being on HTTP isn't necessarily insecure. That warning is inaccurate. It's more about creating censors and gatekeepers in the form of certificate authorities.

(Debian packages are still served over HTTP and are secure with no certificate authority. Try to figure that out!)

[cmeacham98]

Debian packages are verified via a separate mechanism after download. The only verification method included in your web browser is HTTPS.

[aaronmdjones]

Debian ships with its own signing keys to authenticate the packages that it downloads. They are acting as their own CA.

This isn't scalable to the web.

[my69thaccount]

Whether or not it's scalable is orthogonal to the question. A browser would call Debian's repos insecure despite the fact that they are secure by other means.

vv: whether it's authenticated by TLS or PGP is literally isomorphic except one is centralized to CAs and one is decentralized with web of trust. That's the only difference.

[aaronmdjones]

Because they are. Your web browser has no way to validate the authenticity of any content served by a Debian mirror. This is very much done that way because anyone can run a Debian mirror (or indeed a mirror for almost any distribution, which all authenticate their packages in a similar manner).

Nothing stops an admin running a repository mirror from choosing to make it serve malicious content, so the downloads need to be authenticated out of band. This is the very definition of insecure.

[stonemetal12]

A web browser would be correct. It is insecure, because the browser could not secure it. Therefore it could be showing data that has been compromised. Just because it is secure when apt pulls the package doesn't magically make the web browser's view of the data secure.

TLS and PGP maybe isomorphic, but the browser only has access to TLS. Therefore things secured by PGP are not secure in a browser, not because there is anything wrong with PGP but because the browser is incapable of checking it.

[bmm6o]

> Whether or not it's scalable is orthogonal to the question

If it's not scalable to the web then it's not a replacement for the current solution.

> whether it's authenticated by TLS or PGP is literally isomorphic

PGP is a viable solution in this scenario because there is a single organization that is signing a known set of packages. It doesn't provide confidentiality and can't authenticate arbitrary responses. A narrow use case that doesn't require a CA does not make a strong argument that CA's are unnecessary in general.

[danShumway]

Just because you can separately verify that something is secure later does not mean that it's secure at the time of the download. Browsers show that a website is securely encrypted once they've been able to verify it. It's entirely proper for them to show that a download is insecure before they've been able to verify it.

If you get a phone call from an unknown caller, do you get mad at your phone for listing that as an unknown caller just because you could theoretically add that number to your contact list later? Or to talk directly about PGP, do you get mad when you see an untrusted/unknown key warning because theoretically you could add that key to your keyring later after verifying it yourself? Of course not.

The browser is telling you that at that moment, the code/download you are getting is insecure. If you take that code/download out of the browser and verify it separately, then great! But that doesn't mean the browser was wrong. If anything, insecure connection prompts should be a welcome reminder to you that you need to externally validate the data you're receiving.

> That's the only difference.

The difference is that one of them happens inside the browser, and one of them doesn't.

[tialaramex]

> A site being on HTTP isn't necessarily insecure. That warning is inaccurate.

The actual semantics of HTTP are very surprising to humans and this is a problem.

We have a whole bunch of systems - including some that are key to making HTTPS work such as OCSP, which rely on plain HTTP but those systems know about its semantics and account for them in how they work while ordinary users do not and shouldn't be expected to learn.

HTTPS delivers much closer to the semantics people actually expect, with the remaining exception being that people are often surprised that McDonalds.phishing.example isn't necessarily anything to do with McDonalds.