From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3156 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Best place to discuss other lightweight libraries? Date: Tue, 23 Apr 2013 09:47:24 -0400 Message-ID: <20130423134724.GY20323@brightrain.aerifal.cx> References: <20130422233110.GU20323@brightrain.aerifal.cx> <1366678495.18069.154@driftwood> <20130423014639.GW20323@brightrain.aerifal.cx> <20130422220430.53d0b1a5.idunham@lavabit.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1366724853 30365 80.91.229.3 (23 Apr 2013 13:47:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Apr 2013 13:47:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3160-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 23 15:47:37 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 1UUdZJ-0005SX-55 for gllmg-musl@plane.gmane.org; Tue, 23 Apr 2013 15:47:37 +0200 Original-Received: (qmail 11357 invoked by uid 550); 23 Apr 2013 13:47:36 -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 11349 invoked from network); 23 Apr 2013 13:47:36 -0000 Content-Disposition: inline In-Reply-To: <20130422220430.53d0b1a5.idunham@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3156 Archived-At: On Mon, Apr 22, 2013 at 10:04:30PM -0700, Isaac Dunham wrote: > On Mon, 22 Apr 2013 21:46:40 -0400 > Rich Felker wrote: > > > > > > "There's always room for dropbear". And polarssl, and so on. > > > > cyassl looked promising too. I would probably mention tomcrypt too > > even though it's not sufficient to do SSL; it has the most slim, > > clean, portable implementations of crypto algorithms I've seen. > > wpa_supplicant can use tomcrypt (external or internal) as fallback > if no other encryption method (ie, openssl/gnutls) is configured, so > I'd say it merits a mention. In that case I don't even see why they bother including the code to use openssl/gnutls... > I wonder if some notes should be put somewhere to point out that a > network mangler on top of wpa_supplicant is not needed (the learning > curve for configuring it is pretty steep, due to the need to find > and understand the docs, but wpa_supplicant + wpa_cli -a script + > wpa_cli in command mode can handle most situations, including dhcp). > I mention this because it seems to be "accepted wisdom" (but false) > that you need wpa_supplicant as a tool and a network manager to make > it useable. And most of the network managers I've encountered are > bloat of the highest order: NetworkManager, wicd, wifiradar... But > this might be better put somewhere else. Well the accepted wisdom is "almost true": for practical use of mobile wifi, you need not just wpa_supplicant but also some controlling process that's capable of: 1. Choosing which network to connect to. 2. Managing keys. 3. Logic for what to do when signal is lost. 4. Automating nonsense click-through agreements on public wifi. ... The existing solutions all manage the above very poorly. Respectively, they have: 1. No way to manage network priority/preference order. 2. Annoying popups to ask for key rather than having it be part of the configuration of the network, and storing the keys in obscure places. 3. Annoying network-hopping. 4. Minimal or no auto-click-through; even when it does work, you can get burned if your web browser happens to attempt a load before it succeeds. A correct one needs to encapsulate the connection somehow so that no connection is exposed to the user at all until the click-through succeeds. Rich