4 ms·

Except in this case, it's a VPN library built with Lua ontop of a Lua network library with nearly 6 times as many lines of code to hide bugs in: $ cloc WireGua

Except in this case, it's a VPN library built with Lua ontop of a Lua network library with nearly 6 times as many lines of code to hide bugs in: $ cloc WireGuard/ 214 text files. 199 unique files. 73 files ignored. http://cloc.sourceforge.net http://cloc.sourceforge.net v 1.58 T=0.5 s (358.0 files/s, 127864.0 lines/s) -------------------------------------------------------------------------------- Language files blank comment code -------------------------------------------------------------------------------- C 71 2632 1397 33397 Perl 7 1598 1084 10797 Assembly 5 215 218 3608 C/C++ Header 45 569 544 3159 Bourne Again Shell 6 183 52 1570 Bourne Shell 12 81 97 652 make 7 94 11 576 ASP.Net 14 1 0 254 Go 1 11 5 171 Haskell 3 50 6 170 Javascript 1 15 4 165 HTML 1 20 0 158 Rust 1 13 1 123 C++ 1 3 0 87 Python 1 22 8 64 YAML 2 5 0 37 IDL 1 0 0 5 -------------------------------------------------------------------------------- SUM: 179 5512 3427 54993 -------------------------------------------------------------------------------- $ cloc vita 2309 text files. 2150 unique files. 777 files ignored. http://cloc.sourceforge.net http://cloc.sourceforge.net v 1.58 T=4.0 s (387.5 files/s, 87054.8 lines/s) -------------------------------------------------------------------------------- Language files blank comment code -------------------------------------------------------------------------------- Lua 730 13869 10822 126870 C 265 6868 5197 72704 Bourne Shell 107 5310 5226 31016 C/C++ Header 218 3439 5976 22485 m4 16 1167 110 10958 Assembly 10 304 14 6802 HTML 14 334 8 5709 Pascal 25 961 54 3519 make 23 367 198 1835 Expect 56 4 0 1042 Python 13 219 174 919 Bourne Again Shell 43 131 72 761 XML 4 0 0 756 CSS 3 21 25 567 Teamcenter def 1 0 0 558 SQL 6 36 54 176 DOS Batch 5 16 4 138 C++ 1 14 0 115 ASP.Net 2 25 0 110 YAML 6 22 2 97 Perl 1 5 3 19 Visual Basic 1 1 0 11 -------------------------------------------------------------------------------- SUM: 1550 33113 27939 287167 --------------------------------------------------------------------------------

WrtCdEvrydy 8y ago
> nearly 6 times as many lines of code SQLite has 711 times more lines of tests as it does of code. Does that make it a worse software product?
- arghwhat 8y ago
  No, but if it has more lines of code (not tests) than a competing product, then it is more complex, and has a higher probability of defects. In security, defects have serious consequences, so it is in best interest of everyone to have the lowest possible complexity, much more so than for other types of software. The only "stricter" category would be software related to operation of equipment whose failure could cause direct physical harm.
- nickpsecurity 8y ago
  Based on empirical observation, the number of bugs goes up with lines of code on average. There's also some point where something is too big for the human mind to understand in its entirety, either developer or reviewers. To say something is secure, you have to understand everything it will and won't do. Those analysis grow exponentially with size due to input/output ranges and combinations of paths (i.e. combinatorial explosion). So, smaller is better. Ideally, small like Wireguard so the most thorough analysis possible. Lets look at your counter example. It's smaller than most databases as I advise. Following the other rule, it was untrustworthy by default with developers adding piles of tests to uncover bugs, increase confidence, and make changes with less breakage.. Nonetheless, CompSci papers I read on static analysis and fuzzing often test SQLite finding bugs. Even such a well-tested application still had plenty of bugs over time due to its complexity. Most of which might be just intrinsic to the kind of features they're developing. Back to VPN's, you want to know it will maintain security policy (esp correct info flows) under all inputs in all states, normal and failure. And if no progress can be made, you want it to fail-safe. So, making it six times larger without a need to is definitely worse than not making it six times larger. The larger product will, based on empirical data like SQLite, have more bugs with more code injections or data leaks following from that. I advise minimal, careful, rigorously-evaluated implementation of a formally-verified protocol. Wireguard is closest to that right now.
8y ago

WrtCdEvrydy 8y ago

> nearly 6 times as many lines of code SQLite has 711 times more lines of tests as it does of code. Does that make it a worse software product?

arghwhat 8y ago
No, but if it has more lines of code (not tests) than a competing product, then it is more complex, and has a higher probability of defects. In security, defects have serious consequences, so it is in best interest of everyone to have the lowest possible complexity, much more so than for other types of software. The only "stricter" category would be software related to operation of equipment whose failure could cause direct physical harm.
nickpsecurity 8y ago
Based on empirical observation, the number of bugs goes up with lines of code on average. There's also some point where something is too big for the human mind to understand in its entirety, either developer or reviewers. To say something is secure, you have to understand everything it will and won't do. Those analysis grow exponentially with size due to input/output ranges and combinations of paths (i.e. combinatorial explosion). So, smaller is better. Ideally, small like Wireguard so the most thorough analysis possible. Lets look at your counter example. It's smaller than most databases as I advise. Following the other rule, it was untrustworthy by default with developers adding piles of tests to uncover bugs, increase confidence, and make changes with less breakage.. Nonetheless, CompSci papers I read on static analysis and fuzzing often test SQLite finding bugs. Even such a well-tested application still had plenty of bugs over time due to its complexity. Most of which might be just intrinsic to the kind of features they're developing. Back to VPN's, you want to know it will maintain security policy (esp correct info flows) under all inputs in all states, normal and failure. And if no progress can be made, you want it to fail-safe. So, making it six times larger without a need to is definitely worse than not making it six times larger. The larger product will, based on empirical data like SQLite, have more bugs with more code injections or data leaks following from that. I advise minimal, careful, rigorously-evaluated implementation of a formally-verified protocol. Wireguard is closest to that right now.

8y ago