41–50 of 161 posts
An RCE in a non-networked component is interesting (in other words, obvious hyperbole). Either this is your usual corruption bug/vuln triggerable in some/many programs using SQLite, or an actual bug in SQLite itself, e.g. query preparation (a fix/workaround being committed to SQLite doesn't necessarily imply one or the other). Whether the RCE hyperbole is justified remains to be seen. Edit: Apparently the exploit vec…
SQLite is the most thoroughly tested codebase I'm aware of [1]. It has seven times more test code than non-test code. 100% branch coverage. If even SQLite can have a RCE vulnerability, I'm convinced that it is not feasible for anybody to write safe C code. [1] https://www.sqlite.org/testing.html
100% branch, line coverage means nothing. It's about logical coverage. What are you testing for? You are not testing lines of code, but logic.
SQLite is the most thoroughly tested codebase I'm aware of [1]. It has seven times more test code than non-test code. 100% branch coverage. If even SQLite can have a RCE vulnerability, I'm convinced that it is not feasible for anybody to write safe C code. [1] https://www.sqlite.org/testing.html
SQLite can by principle not suffer from a RCE.
SQLite is the most thoroughly tested codebase I'm aware of [1]. It has seven times more test code than non-test code. 100% branch coverage. If even SQLite can have a RCE vulnerability, I'm convinced that it is not feasible for anybody to write safe C code. [1] https://www.sqlite.org/testing.html
100% branch, line coverage means nothing. It's about logical coverage. What are you testing for? You are not testing lines of code, but logic.
Earlier quoted context omitted.
100% branch, line coverage means nothing. It's about logical coverage. What are you testing for? You are not testing lines of code, but logic.
This is exactly why I don't find code coverage tools useful. Now, a tool that can show what the tests assert against? THAT would be useful.
Earlier quoted context omitted.
They mention the example of browsing to a web page. Not quite a fully fledged remote execution bug but close enough. I think what they're really saying is they're aware of remote execution cases. An example of that might be a web services that's backed by a SQLite query.
JavaScript code has access to SQLite. So any webpage where the attacker controls/can inject JavaScript is vulnerable.
Earlier quoted context omitted.
100% branch, line coverage means nothing. It's about logical coverage. What are you testing for? You are not testing lines of code, but logic.
Isn't that the definition of branch testing, to test all possible branches within code and also testing the logic in all of those branches?
value = 1 / input;
Earlier quoted context omitted.
100% branch, line coverage means nothing. It's about logical coverage. What are you testing for? You are not testing lines of code, but logic.
Isn't that the definition of branch testing, to test all possible branches within code and also testing the logic in all of those branches?
Remote implies it can be accessed remotely, is that true, or did they mean “remote if an attacker can remotely send data to SQLite”?
SQLite is the most thoroughly tested codebase I'm aware of [1]. It has seven times more test code than non-test code. 100% branch coverage. If even SQLite can have a RCE vulnerability, I'm convinced that it is not feasible for anybody to write safe C code. [1] https://www.sqlite.org/testing.html