[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+vfKE+CrhRG-basaVqLE4Bc6X5T1CbftJmBurrhwAxFTPc3jA@mail.gmail.com>
Date: Thu, 25 Apr 2013 00:21:12 -0700
From: Hal Clark <hdeanclark@...il.com>
To: musl@...ts.openwall.com
Subject: Re: High-priority library replacements?
On 4/24/13, Rich Felker <dalias@...ifal.cx> wrote:
> Hi all,
>
> The recent thread "Best place to discuss other lightweight libraries"
> had me thinking we should really put together a list of high-priority
> library replacements that need to be done. I don't think I'll be the
> one to do them, but I wouldn't mind overseeing/mentoring someone
> working on them, or just getting somebody else interested in these
> projects.
>
> A few initial ideas:
>
> 1. A light, C, UTF-8-only Unicode library. The most important things
> it should implement are things needed by any application that presents
> text to the user, specifically line-breaking (UAX#14), bidi (UAX#9),
> identifying grapheme clusters, etc. Things like case- and
> normalization-insensitive comparison, application of Unicode-format
> collation rules, etc. would also possibly be useful.
>
> 2. SSL. The modern internet basically requires using SSL everywhere.
> We should be aiming/expecting to transition to a world where even
> non-login-based sites are 100% https; the threats of malicious http
> injection attacks from rogue or advertising-based access points has
> gotten too great. Unfortunately, all of the existing SSL
> implementations are bloated, buggy, and fail even the most basic
> robustness requirements. A good solution would be based on tomcrypt
> and would expose a minimal, simple API suited for event-loop-based or
> threaded use. It may also be useful to have an optional wrapper layer
> to expose an API that mimics openssl or gnutls. It should also be able
> to keep up with the changing demands of how to determine which
> certificate authorities are to be trusted.
>
I saw earlier that Cyassl was briefly mentioned. Now, in general I am
interested in your idea of a "minimal, simple API", but I've had great
experiences with Cyassl. IMO it is exactly what you're looking for.
Could you comment on what parts of it are unsuitable for your intended
purposes? I'm curious what would need to be changed or replaced.
(I'm not affiliated with Cyassl - I have just had (really) good
experiences with it after trying the GnuTLS/OpenSSL route.)
> 3. Image format and compression (libpng, zlib, etc.). The existing
> libraries are full of atrociously bad error-handling practices, and
> quite bloated. These libraries should be well-factored so that
> programs that just want to read (the majority of use cases) don't have
> to pull in code for writing. Unfortunately the interfaces might not be
> so simple, since an important usage case is progressive rendering of
> partially-loaded images, both for the purpose of loading over slow
> network connections and for rendering thumbnails quickly.
>
> All of these libraries should:
>
> - Avoid namespace pollution. Only external symbols should be the
> public API and internal-use stuff prefixed with an ugly prefix
> that's extremely unlikely to clash with anything.
> - Avoid unnecessary allocation. Use caller-provided objects where
> possible or provide both options.
> - Have absolutely zero global state.
>
> That's all I can think of at the moment but I'm sure there are other
> needs I've come across and forgotten. Please feel free to supplement
> this list.
>
> Rich
>
-hal clark
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
