From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3197 Path: news.gmane.org!not-for-mail From: Hal Clark Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Thu, 25 Apr 2013 00:21:12 -0700 Message-ID: References: <20130425041553.GA13951@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1366874486 24781 80.91.229.3 (25 Apr 2013 07:21:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Apr 2013 07:21:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3201-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 25 09:21:31 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UVGUf-0000pR-7N for gllmg-musl@plane.gmane.org; Thu, 25 Apr 2013 09:21:25 +0200 Original-Received: (qmail 28598 invoked by uid 550); 25 Apr 2013 07:21:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28590 invoked from network); 25 Apr 2013 07:21:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=cVMVWpSv3mbMoYwswscn4o9QEE5KXw8Ra16atDfi5oQ=; b=UuAsfUgUl3JOriXkGwBkqBhfsKPpdWnBWi+NKKAakcxPSC9wktZ4+Vms1VPd8QuHyg F598UuQlOONWpc6veUflvKbbcCj8/wV5vNBJ+Tsw9HgX/hH2KtWpHw8QmzN5Puubh0T3 chFgDbgi7FrtUbStDKDzMd3P2lwnb00q6zvJh1BggVkEhxHIJAyubHqRU9KzrLuFBnAt 7kIQtArX89ww3gADVV8QPUuKns8nfokTXphpnybsVnIpqnPAWL6PTfCtdTUqSaVPGSni zy4IKrcGn38vJa7rSbn1lsxGo/uLKSBFjliaRFFMT/EW0RFvjfWn8mhXtU2RUesNpfWW akGg== X-Received: by 10.194.3.14 with SMTP id 14mr68964107wjy.2.1366874472160; Thu, 25 Apr 2013 00:21:12 -0700 (PDT) In-Reply-To: <20130425041553.GA13951@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:3197 Archived-At: On 4/24/13, Rich Felker 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