On Fri, Mar 06, 2015 at 10:15:30AM GMT, Marc Espie wrote: > 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).
I think this is the info Jan and myself were looking for :^) > All of that is the first thing people like Theo notice... Well, most of us don't - hence the very existence of misc@ ;^) > 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. :) I guess it's not only the people skills but a combination of both that *and* great coding skills - the two do not necessarily go hand in hand :^P Marc, thank you for taking the time to elaborate. Best regards, Raf
