From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3043 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Pending issues for next release Date: Thu, 4 Apr 2013 19:37:42 -0400 Message-ID: <20130404233742.GC20323@brightrain.aerifal.cx> References: <20130401233144.GA29587@brightrain.aerifal.cx> <20130402111116.GL30576@port70.net> 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 1365118673 6643 80.91.229.3 (4 Apr 2013 23:37:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Apr 2013 23:37:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3044-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 05 01:38:21 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 1UNtjX-0002dD-UO for gllmg-musl@plane.gmane.org; Fri, 05 Apr 2013 01:38:20 +0200 Original-Received: (qmail 15656 invoked by uid 550); 4 Apr 2013 23:37:54 -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 15647 invoked from network); 4 Apr 2013 23:37:54 -0000 Content-Disposition: inline In-Reply-To: <20130402111116.GL30576@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3043 Archived-At: On Tue, Apr 02, 2013 at 01:11:16PM +0200, Szabolcs Nagy wrote: > * Rich Felker [2013-04-01 19:31:44 -0400]: > > Here's a quick list of open issues that we might want to take care of > > before another release: > > > > - ARM-optimized memcpy, etc. > > - put*ent functions in pwd/shadow/etc. > > - program_invocation_name > > - Posssible misaligned access bugs in mbsrtowcs (?) > > - [u]intmax_t underlying type mismatches ABI on 64-bit systems (?) > > and fix [u]intmax_t and wchar_t limits in stdint.h etc. (U,L,LL suffix) For [u]intmax_t, assuming all archs use the lowest-rank type that can hold the value, wouldn't it suffice to just omit the suffix entirely? Then the compiler would give it the right type. Or will this break in c89 mode or something obscure like that? > and fix printf fmt in inttypes.h (otherwise gcc will warn) Yes.. > other pending things from my todo: > arpa/tftp.h (inetutils http://www.openwall.com/lists/musl/2012/11/26/2 ) OK I'll look at this. > fgetspent, putpwent (pam_unix http://www.openwall.com/lists/musl/2013/02/27/4 ) Just added, but the shadow stuff is stubbed still. > inb, outb,.. (xorg, grub, lmsensors,..?) These have been present on x86 for a long time. Are there other archs that need versions of them? > mkostemp (better rand and stack address hiding) Any specific recommendations? As temp filename generation is not really security-critical (at worst you can slow down or cause tempfile-creation errors in a target program), I think we should probably avoid using the stack address at all. Leaking the stack address to an attacker is too great a risk. > struct ntptimeval (glibc vs musl abi http://www.openwall.com/lists/musl/2013/03/04/3 ) Uhg this issue again. > random_r (used by mesa?) Bleh, the API is pretty ugly. Thoughts on what we should do? Do they actually care about having a thread-local PRNG state, or are they only using it on the misguided idea that random might not be thread-safe? Rich