Is signing worth it? #203
Comments
Wat? :D Not trying to mean. I just don't get it. It seems to me you started with some very confused assumptions.
Crev IDs are generated locally, and everything that is being stored in proof repositories is signed and verified.
As per the simplification ... For most serious users trusting/depending on github or crates.io or any third-party in general is a big no-no. Everything in |
Sure, but that's not the problematic part, it's other IDs where the trust of GitHub comes in, you fetch from a repository and trust the ID in it. Reviews from that user (or transitive users) are now verified against whatever ID you got from GitHub, it's not likely that people will verify out of band.
Yeah, my point there was that signing is unrelated to that scenario as it's already covered. Unless you either do not import any other reviewers, or verify IDs out of band. Crev currently has you trusting GitHub |
|
Ah. I see. It doesn't have to be github. Git repos can be self-hosted. Commits can be signed in it etc. And ID can be verified, though it's true it won't be most of the time, but for some use cases they will be. Jjust because something isn't theoretically perfect doesn't mean it's bad. And even architecturally, git repos are only a transport mechanism. The url of the repo can change (eg. people moving their repo gitlab/self-hosting). In the future I could imagine people fetching proofs from distributed sources like DHTs of some kind (IPFS, Dat) and so on. |
|
In the self hosted case it does absolutely remove the need to trust GitHub (or some other third party hosted git repository), but that also means the signature isn't protecting against anything anymore. Commit signing is the same sort of deal, if by using it we remove the trust in the repo host then crev's signatures are made redundant. Same again with IPFS/Dat. While I do believe it would be beneficial to remove the crev signatures that doesn't mean I think the authenticated use case should be ignored. I just believe it's better handled by the transport, e.g. in the case of git you could require all of a peers commits to be signed |
|
On implementation since I forgot to reply to that point: For wide adoption if something can be simplified enough to be easily re-implemented it's going to be easier to receive. libgit2 for example is decidedly complicated but even still many languages have re-implementations that are popular. JavaScript has several. They avoid the need to manage system dependencies.
Another simplification example: Without implementing signing in crev itself the file format no longer needs to be append only. To distrust a user or delete a review the entry/file can just be deleted. Individual files could be parsed with a regular yaml parser. There would no longer need to be a workaround for merge conflicts. e.g. picture something like |
|
Sure. But it's a trade-off on which I remain unconvinced. Signing might have a tiny, tactical problems, but is significantly increasing security and robustness and generality. With signing you can eg. download bunch of proofs using bittorrent and import them and so on. You can import proofs from other people into your own repositories. You can store review proofs into source code of the reviewed project itself. Plenty of possibilities and flexibility to evolve. Tying data representation, security and transport layer together is just meh in my book. And in practice I can't see how signing removal would benefit alternative implementations much. Signing is like 1% of complexity here. The signature is some standard ed25519 stuff, headers and such can be handled with a simple regular expression. It's going to be hard enough to get this idea to catch on and become practical anyway. Git got several implementations only years (decade?) after its conception, when it became super-popular. I am still hoping that crev could bootstrap itself by being used by security conscious organizations, that will appreciate cryptographic signing. The first reactions from groups like rust-bitcoin was: "when PGP signings". It is currently beyond my hope to get average programmer to care about source code attacks that |
|
I guess that's main the difference in viewpoint, I don't it as significantly increasing security. Unless I'm missing something the idea of the built in signatures is for it to be secure over a potentially malicious transport, but it relies on the very same transport being secure in the first place? |
It doesn't. How you obtain identity is not necessarily from the git repo hosting. And it's quite different scope of an attack to just insert a file/commit somewhere and to try totally impersonate somebodies identity. |
|
Trust is ultimately about trusting the person doing review, not any key. All the technicalities are about establishing the connection between the person and the review. And Crev ID IMHO is terrible at establishing this connection. I don't know people by their Crev IDs. Nobody's going to do PGP-like signing parties for their Crev IDs, so they aren't much better than self-signed certificates. In practice, we know each other by GitHub accounts, and despite that being owned by a centralized service and for-profit corporation, that's a stronger identity than Crev IDs. So the scenarios of "We don't need to trust GitHub, because we have Crev IDs" has it entirely backwards. It's actually "I trust these Crev IDs only because they're in GitHub repos of users I trust". |
|
I thought that the big loss of dropping identities would be loss of aggregation (it's quicker to fetch one repo that aggregates reviews from 100 users, than to fetch 100 repos). However, I've realized that the download-everything-upfront model is going to be a pain to scale anyway. If crates.io grows to the size of npm, and every crate has a review, that will be gigabytes of data to fetch. Offloading bandwidth to some p2p protocol may make it cheaper to host, but won't help users download less data. But there could be another way. There could be an "index server" that could be asked "who has reviews for crates x,y,z?" and it would reply with a list of URLs to fetch. This way the amount of data fetched would be more proportional to number of crates actually used, rather than all crates in existence. In this model the server doesn't have to be particularly trusted, because it's only used for optimization and discovery. The verification happens outside of it. If you're worried that the server would hide reviews from you, you can still fetch (some) repos directly, or ask a few different servers (they'd be cheap to ask). |
|
So overall, I think dumbing down identity to URL ownership is going to be good enough. If I trust a user I know by their GitHub account, I trust what I fetch from If I trust Example, Inc. and know they control Even if they used Crev IDs, it wouldn't benefit me, because I'd have to go to one of these sites to find what is their Crev ID. So just trusting the URLs only removes a step in the chain. The missing component here is ability to change the URL. This could be accomplished by putting the new URL somewhere in the old repo, so that the Crev client can find it and act accordingly. |
I totally agree. Making the UI to put more emphasis on the URLs than CrevIDs is an option, and I think it's the right way to go. But I don't see any value in dropping the actual signing. The user might not have to worry about signing and cryptographic identities at all, and all the integrity checks etc are going to happen under the hood.
"Open source developers - individual not knowing each other" is not the only world Thanks to cryptographic identity it's possible to not trust the proof store, transport layer, and possibly verify the ID on twitter, some personal/offiicial website and with all other available proofs. So I don't want to strip the system from important security properties, for very dubious benefits. I think such niceness and life-convenience things belong into UI, and not core data layer. If the user does
Exactly. I don't know how the scaling would work, but that's a great problem to have in the first place. By having cryptographic identity and signing in place anything can be potentially used without loosing security and robustness. |
|
The lots of URLs problem sounds very much similar to what the folks over in Go have been tackling recently with https://proxy.golang.org/ |
|
A while ago, when I just started toying with |
Could signing be made de-facto optional? So if you wanted to use it for real, you could, but users who just want to rubber-stamp a few crates they use, wouldn't have to feel the friction. To me key management is a real problem, and it adds friction. The problems I see are:
Basically, key management is a real cost. It's intimidating, it's hard to do right, it's annoying. So for solutions:
|
This should not be the case anymore. You can actually call a lot of commands without generating the id.
It would work, and your repo would just store two identities.
You don't have to. You can just:
I don't recommend it, but you can
There's currently no key rotation, expiration. While I like cryptography, I really, really dislike how PGP works, and all these key-managment hoops there serve no real purpose, and just confuse people. If you ever decide to nuke your own compromised ID, you are supposed to create a self-distrustrust proof (negative trust for your own self). The implementation of this is probably missing/not working, but in concept - this is a way to tell everyone, that you don't trust your own self-identity, so other shouldn't anymore either. No need for revocation certificates and other crap.
Sure. Key is easy. But what about the repo url? The biggest reason the explicit ID creation is there, is that the user has to provide us with the url of the identity.
I don't understand this. Repo definitely can store proofs from multiple identities. That's how I envision organizations will use it: all engineers will just push/PR the same repo. But I don't understand how would multiple IDs help with anything. You can already generate new ID before every review, and set the same url in there, and it will "just work". Except there's no implicit trust between them.
It might be a presupposition based on how terribly unusable GPG is? In
It is actually much easier for an attacker to snatch one file that is stored in a predefined place, than it is to lunch a full-blown keylogging/whatever attack to steal your passphrase. So I would not discount completely the additional security of even a lame passphrase. Sure - if you've system is compromised, the attacker can win, but a lot of attacks like this are not so sophisticated. And the defaults matter, so while I am happy to enable escape hatches, I would like the user to have to set up the passphrase by default. |
Oh, and I would be happy to implement features like this. :) |
I think @kornelski wants to just tell crev to trust If that is a common pattern, then there's little point in the keys because the URLs are the real roots of trust. Also, if I had to enter a potentially long passphrase every time I wanted to write a review, that would be annoying. I guess I would just alias crev to |
If so, I'm kind of fine with that. It would be like TOFU, which is reasonable for normal users. And there are still checks that I could have
That's not true. As long as it performs TOFU without automatic-updates etc. there's still plenty of difference, and a lot of checks that could be performed: eg. do we already have this ID + url in other known proofs? Do they match? Etc.
Passing secrets like that is not a good practice. It leaves them recorded in your Eventually support of all sorts of keyrings could make this inconvenience a non-issue. |
|
Note that if something has access to |
Sure. But the victim has to actually enter a passphrase, and secrets will need to be transmitted somewhere and everything has to go fine. Which is actually a lot more difficult, since such attack are often lunched widely, and not hand-tailored for each victim. A wide-net-phishing attack like this (as opposed to spear-type targeting an individual) can at very least by much more quickly noticed, helping people invalidate suspected IDs etc. |
|
The semantics are not TOFU if the number of keys in a repo changes (e.g.
user signs from several different devices) and @kornelski doesn't want to
be asked about that.
I sketched a design for something a bit like crev last year or the year
before and I think I imagined solving this similar to how riot does it now:
- On first use: get the user to give you a passphrase and ask them to
remember it; generate a key; encrypt it with their (expanded) passphrase;
upload it somewhere public (with riot, it's not so public).
- When the user uses a new device they just present their username and
passphrase and recover their old key. This also lets you handle key
rotation, etc easily.
Obviously you have to rely on the user picking a good passphrase. Other
software does that by not letting the user pick one.
Last time I looked into it, you can use quite a small number of bits for
this kind of thing: https://repl.it/repls/MiniatureSteepProfessional
And of course you can crank the work factor way up on your hash/key
derivation function to be safe.
keyloggers and stuff
I think this is a bit off topic.
…On Sun, 21 Jul 2019 at 23:53, Dawid Ciężarkiewicz ***@***.***> wrote:
You append a small function to .bashrc
Sure. But the user has to actually enter a passphrase, and secrets will
need to be transmitted somewhere and everything has to go fine. Which is
actually a lot more difficult, since such attack are often lunched widely,
and not hand-tailored for each individual. A wide-net-phishing attack like
this (as opposed to spear-type targeting an individual) can at very least
by much more quickly noticed, helping people invalidate suspected IDs etc.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#203>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABNZA6J433XUXMULRSK3O4LQATSE5ANCNFSM4IETLMOQ>
.
|
By start using, I've meant publishing a review (we need more of these, so that should be minimum friction). I don't think you can publish one without being introduced to crev's key management. Another way to look at the situation: There's some baseline level of (in)security: developers have SSH keys for their repos, crates-io token for publishing, and source sitting on their machine (that a malware running on their machine could modify directly, instead of hacking anything else). Some protect these better than others, but these are the major weak links. What I think you're concerned about is elevating security above the baseline. If the developer gets hacked, and someone injects malware or publishes rogue package under their name, you can still catch it. In this case Crev has to have stronger security than the baseline. What I'm concerned about is more trivial: I want to check that nobody intentionally publishes outright malware that would attack my machine and my projects. In this model baseline security is enough, because I'm only using Crev as a human-powered antivirus. |
I'm would not support that. Not only it seems like a lot of additional complexity, but also 99% of users would use only one key, and change it only in case it gettubg compromised. In such case manual intervention of other users might be neccessary/good idea anyway. My goal and agreement is only, that for a lot of users bothering with CrevIDs is unnecessary and they will not double check anything anyway. So in the typical case TOFU and using repo url as identitier is good enough. However for users that do care it must be possible to throurouglhy and carefully use and confirm all the underlying cryptographic identifiers.
Crev pretty much works like this, except it does not upload the encrypted key anywhere. It just asks user to back it up somewhere and provides
I'm looking at I'm going to slowly disengage from the discussion, because I don't have much more time to devote to it. To sum up my position:
|
I hope not to come off as overly critical, but this was something on my mind after tinkering about with crev locally. I think it would be valuable to reconsider the fact that the design uses signing, my reasons being:
From the security viewpoint, I can't personally see many scenarios the signing protects against. In practice it does not protect against GitHub going rogue (I think this is perfectly acceptable), as IDs to be trusted are
fetched from a GitHub repository and then likely copy-pasted from the output intotrust. That or they're copy-pasted from instructions hosted on GitHub.A rogue/compromised user is caught out by testing crates directly from the package manager rather than the source. A rogue package manager is caught out by including a digest in the review.
Now for the main reason I opened this issue, I believe it would open up some benefits to adoption if there were no signing. Code review is a hard ask, and any barrier makes the ask harder still.
There would be no more need for key management. You don't have to worry about transferring it between devices in order to be able to review. You don't have to worry about losing it. You don't have to manage yet another password.
It would allow a simpler format and CLI. There would be no need for IDs, or to think of it another way the repo would be the ID. Trusting other users means just pointing at their repository. The file layout could be simplified to e.g.
crev-proofs/reviews/*, the current format gives off an air of being opaque to human readers which may be off-putting.It would be simpler to produce tools/integrations. Good integrations will be a massive benefit to the ecosystem: be it in the editor, GitHub bots to show if something lacks reviews on PRs, web UIs etc. Both the simpler format and lower complexity will increase the ease of creating any such tools.
It is of course a trade-off either way, the signing does provide trust on first use protection, my question would be is it worth the hit to usability?
The text was updated successfully, but these errors were encountered: