On Thu, Mar 05, 2015 at 09:20:23PM +0100, Jan Stary wrote: > Ingo, > > On Mar 05 18:11:31, schwa...@usta.de wrote: > > By the way, lynx(1) removal doesn't really hurt that much. > > Rotten code that will hurt more when it will finally be deleted > > includes, for example, the sqlite3(1) library and file(1). > > can you please elaborate on what's rotten in sqlite?
It is partly a cultural thingy, and a question of priorities. The guy (guys?) who writes sqlite is a very good developer, but he does not have security as a top priority. His top priorities are speed and portability. As far as I can gather, he mostly gets away with it because he is very very good at writing algorithmic code. Of course, when you look at his code with the mindset of the typical openbsd developer, things appear different. - he has lots of compatibility cruft which makes us cringe (utility functions that supplement the libc, but without any specific concerns to use secure apis). - he uses idioms that we do know to be somewhat dangerous unless one is very careful (manual length computations) - he uses idims that somewhat negate some of the mitigation techniques the OS provides (memory management). All of that is the first thing people like Theo notice... So sqlite has a basis for improvement. I haven't the faintest idea how to go about educating its main author. Especially since there is a lot of work to improve this code, and also because this includes breaking the API. Note that the same thing can be said for over 90% of the code base that didn't originate in OpenBSD. Having spent more than enough time looking at external code (I'm bliiiiind! such horrible, horrible code), I can say that sqlite is less worse than most of the code out there (compare with glib2/3, for instance, as a case of code where you can't figure out what goes wrong when things go wrong). You also have to keep in mind that it's mostly a one-man team doing the development... but yeah, it's not perfect. if some guys with people skills want to talk to sqlite's author about changing his ways, feel free to do so. I guess it's mostly a question of educating him, which definitely doesn't start by saying his code is crap. :)
