1. 23
  1.  

  2. 18

    I have a slight bit of pride knowing that I discovered a bug in SQLite. :) It’s a testament to the quality of their code that the DB engine detected the bug at runtime, safely shut down, corrupted no data, and had no security vulnerabilities despite basic assumptions being violated.

    It’s a truly amazing piece of software and really a very capable database, more powerful in some ways than engines like MySQL or Firebird.

    1. [Comment removed by author]

      1. 7

        http://www.sqlite.org/src/info/6bfb98dfc0c

        It was discovered during the creation of the Giles Production System Compiler, which targeted SQLite as its backend.

        The original bug was reported privately because the only way we could trigger it was with data sets with confidential information in them. :)

    2. 8

      I really enjoyed listening to this podcast. The various anecdotes, like how SQLite has been used in various places (like in the Airbus A350), or how Dr. Richard Hipp wants to create a very simple email system, or how he’s got some ideas around creating a git killing version control system, and how fossil isn’t one.

      1. 1

        Version control systems don’t kill each other. They each serve different use cases and preferences.

        1. 6

          His words, not mine.

      2. 8

        I greatly recommend that you take a look at How SQLite is Tested. Their test-to-code ratio is 745 (it reads 745, not 74.5, 7.45 or 0.745). Here’s a summary from the article:

        • Three independently developed test harnesses
        • 100% branch test coverage in an as-deployed configuration
        • Millions and millions of test cases
        • Out-of-memory tests
        • I/O error tests
        • Crash and power loss tests
        • Fuzz tests
        • Boundary value tests
        • Disabled optimization tests
        • Regression tests
        • Malformed database tests
        • Extensive use of assert() and run-time checks
        • Valgrind analysis
        • Undefined behavior checks
        • Checklists
        1. 5

          As a high-assurance engineer/researcher, I think that page is the only time I looked at QA on a FOSS project and was simply stunned at how impressive it was. I bookmarked it. Shared it plenty. It was then that I started getting ideas of shoe-horning other apps into SQLite as a backend just because I’d just have to worry about the integration. The SQLite part should work, keep working, and/or be easy to fix on failure. How most software should perform…

          1. 1

            Out of curiosity: what are the other projects whose QA you find impressive?

            1. 3

              I lost those when I lost my memory. SQLite was a reminder I got on Hacker News. OpenBSD team is well known for thorough code reviews & mitigations. Idk about their testing regiment. The sad thing is that FOSS development has been a bigger failure in high-assurance security or reliability than proprietary. The labor advantage and lack of perverse incentives means that FOSS should produce better stuff on high-end. Instead, the norm was very similar to proprietary with proprietary winning out on the high end many times over. Every solid project I found with FOSS license with medium to high assurance design/implementation was actually a cathedral-style project that was open-sourced after the fact. Usually done by a government organization, CompSci people, or small team of professionals. Basically the proprietary model.

              I ended up writing this in response when the “can’t trust closed-source products like FOSS” myth came up:

              https://www.schneier.com/blog/archives/2014/04/reverse_heartbl.html#c5581737

              Funding was often a key problem. Lack of talent. Plus a false belief that code has to be either totally FOSS or closed-source proprietary. Led me to post this analysis to help people explore more options:

              https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_424.html#c6051639

              Note: Memory loss made me forget OSS had a distinct definition that doesn’t allow proprietary. As you read that, just mentally substitute shared-source for open-source when I talk proprietary modifications. Idea is to approach OSS freedoms/benefits close as possible while still paid product.

              Since I stayed broke with low demand, I eventually published a summary of my high-security framework on that blog. Cleaned it up a bit here:

              http://pastebin.com/y3PufJ0V

              If assessing strong QA & INFOSEC, just compare the practices any product or project describes to my list. There were things missing every time I did. Only exceptions… maybe exceptions since they give limited info… were some products certified to highest levels of safety & security regulations. A lot of things on my list come straight from certification requirements that mainstream INFOSEC mock as purely red tape. Haha.

              1. 2

                Thanks! The discussions you linked to are very interesting.

                The topic of incentives in FOSS is an interesting one. I think the problem with open source in general is that incentives are non-existent but this is a topic for another discussion.

        2. 3

          So.. If I want to build a small SQLite clone, for learning purposes, how do I go about it?

          Has anyone here done it, build a toy database?

          1. 3

            Depends on what level you want to work at. If you want to write a SQL parser, and are willing to use go, you could build something on top of BoltDB. I’m sure other Key/Value stores exist for C and the the like. You could also create a B-Tree store, and then try to tie it into an existing SQL parser.

            But I have yet to do any of that.