Eh, there are usecases where SSL/TLS doesn't add any value (in terms of security). Software repositories that only serves packages that are already signed (and verified before installing) for example could be served over http or a piece of string even.
That's just kicking the ball down the road. It is more reasonable to expect one developer to perform sufficient security work than to expect N users, some of whom may be non-technical, to check verified packages.
Uploading to package managers (or convincing said managers to package your upstream, this is a particularly big problem for fragmented OSes like Linux desktops) also don't scale easily from the developer's side compared to configuring TLS which is usually a single toggle on your cloud host's DNS config.
If I had to chose between developer signed packages and TLS, I'd go with signed packages, because at least then I know I get what the developer intended to give me, no questions asked. TLS guarantees security in transport, yes that's true, but a package signed by the developer guarantees that even if the mirror itself been compromised and still has a valid TLS connection, my system won't install a rogue dependency.
Luckily in our real world, we can have both of them, and that's of course best :)
Generally yeah, but the value of it dives of the cliff in some cases, compared to the hassle it introduces. Lets say you create a encrypted LUKS partition with a 32 character password. Would it be more secure by nesting 3 more encrypted LUKS partitions inside of that one, with each having different 32 character passwords? Yeah sure, but you're already pretty secure with just one as long as the password is good.
In the case I mentioned, adding TLS certificates to something that is already signed in a similar way that TLS would do, would add nothing in terms of security, but would add additional privacy.
I see your point, and I repeat I'm not arguing with you, I don't have the knowledge you clearly do, but onion layer security is I guess useful when mistakes are made -
> Lets say you create a encrypted LUKS partition with a 32 character password. Would it be [...]
Quite so, but if someone does a booboo and uses a 3 character password for one of them (well, imagine more sophisticated form of such a mistake) then the extra layers become valuable.
I guess it's about guarding against dumbness or accidents rather than correctly implemented best practice.
I don't have much yet, but I'll send you a link when I do.
The reason Gambit is required is that you pick characters by drawing from a deck. So you both know you can't have the same person. But if you let this knowledge affect your guesses then you leak information. So there's potentially some amount of bluff required.
https://github.com/gambit/gambit
https://gambitscheme.org/