-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add tutorial and "danger: experimental" banner to README. #433
Conversation
Looks like a good start. You could add, "this library has known cryptographic weaknesses that have not been addressed and a security model that has not been fully specified." |
Also @lvh. |
Updated with additional links to not yet addressed issues. |
I am not entirely sure why am I mentioned here :) but I am all for it |
Warning text looks good to me. :) The "use this library at your own risk." comment could be decoupled from the conditional "Until it has received a clean bill of health" clause, as it feels like something which could be kept on all the time. In that case, the "use this library" standalone sentence could be preceded with a stronger statement, maybe something like "Until it has received a clean bill of health from independent computer security experts, it should not be deemed production-ready." (But maybe you can think of something better than "production-ready"). This is probably nitpicking, though - overall looks good! |
LGTM :) |
Reviewed 1 of 1 files at r1. Comments from Reviewable |
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed. Comments from Reviewable |
be72578
to
9779f56
Compare
Reviewed 1 of 1 files at r2. Comments from Reviewable |
I'm strongly opposed to this pull. It's a mistake for obvious reasons. In addition to the fact that it's demonstrably false. It's only going to confuse users, and serves only to spread FUD |
Review status: all files reviewed at latest revision, 2 unresolved discussions, all commit checks successful. README.md, line 18 at r2 (raw file):
There is nothing inherently dangerous about using Tox as far as I know. The word "warning" would be more accurate. README.md, line 25 at r2 (raw file):
There is no "until". No software is risk-free whether or not it's experimental and whether or not an audit has been done. Comments from Reviewable |
Exactly. As far as we know. Now, since we aren't audited, don't have a thread model, and have a huge codebase that we only partially understand, I think the word "dangerous" is completely and absolutely warranted here. |
Reviewed 1 of 1 files at r2. Comments from Reviewable |
It's not. Dangerous is a sticker you'd apply to a table saw. Not a pair of safety glasses. |
@iphydf tl;dr, i think we can do without the big annoying banner |
Why are you arguing such nitty semantics here? Of course, nothing is risk-free, but this is a matter of risk-management. An audit severely reduces the risks associated with using such a piece of software.
Yes, but the point is that it kind of can. The vulnerability that sparked this discussion works as follows: If you steal Alice's long-term secret key, you can not only pretend that you are Alice to everyone else. You can also pretend to Alice that you are everyone else. Personally, I was unaware this vulnerability existed. And, according to that issue's reporter, this was discovered at what was merely a cursory glance, and with beneficial intent! Someone who analyzes the Tox protocol with malicious intent may be significantly more rigorous and not share those problems with us. So until we have a proper threat model, I think this eyesore should stay. When we come to a point where we actually have a properly defined threat model, and have assessed (without external audit) that we actually protect against the threats in that model, we can think about using a less-flashy warning. When we have assessed it (with external audit), we can think about removing it completely. |
Right, we knew you would be fucked if someone stole your secret key. That was an intentional design decision by irungentoo. His intent was never to have tox protect you from that. (Let's not forget that the original design of tox was supposed to be anonymous and semi transient, with a key never really living too long)
Sure, they know that secret key auth can allow you to mitm if you don't use ephemeral keys. That's not hard to work out, so it says nothing about the work it would take to find a real security bug. Per irungentoo "That's it, I thought someone had found an actual security issue". In other news your car's air bags wont protect you if your car catches on fire. |
2a4f1d7
to
eb85364
Compare
Reviewed 1 of 1 files at r3. README.md, line 18 at r2 (raw file): Previously, JFreegman wrote…
Fully agree, that sign is ridiculous, there is no nuclear radiation in tox, it may just not fit for all purposes. Remove this sign and I'm okay with merging it for now. README.md, line 25 at r2 (raw file):
this is already given by the license, using open source software is always "at your own risk". We may state that here again but not "until" but just "use this library at your own risk." Comments from Reviewable |
53acb62
to
026babb
Compare
44bfa64
to
dac159d
Compare
Reviewed 2 of 2 files at r4. Comments from Reviewable |
Reviewed 2 of 2 files at r4. Comments from Reviewable |
Reviewed 2 of 2 files at r4. README.md, line 18 at r2 (raw file): Previously, cebe (Carsten Brandt) wrote…
Updated with a nicer banner with the text "warning" instead of "danger" and with a more appropriate symbol. Comments from Reviewable |
It will always be "as far as we know". An audit and a threat model is not a guarantee of anything, and neither is understanding the code base. All we're arguing here is the degree of risk, and I have no reason to believe that Tox as it stands puts users in danger.
It's not nitty. It's a false and misleading statement. |
Comments from Reviewable |
Review status: all files reviewed at latest revision, 2 unresolved discussions. Comments from Reviewable |
fuck |
Acting on suggestions in #426.
@paragonie-scott @zx2c4 @Runn1ng @DebugReport @wfn
This change is