Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 4 Aug 2012 21:00:49 -0400 (EDT)
From: idunham@...abit.com
To: musl@...ts.openwall.com
Subject: Re: musl 0.9.3 released

> Hi all,
>
> After a few days' delay, here is the next release, 0.9.3, as promised:
>
>     New experimental MIPS port (32-bit, o32 ABI, static-linked-only at
>     this point). Various dynamic linker/loader bugs fixed. Network
>     service name lookup support from /etc/services. Wrappers for more
>     non-POSIX Linux syscalls. Overhauled crypt() with drastic
>     reductions in memory usage and run time. Fixes for several
>     important thread bugs including internal lock corruption, spurious
>     ...
Nice to see all of these!

> A few pending issues that will be addressed after the release are
> fixing the ARM setjmp/longjmp code not to break callers that are using
> the fpu, improving memcpy (and other string functions) performance on
> x86 with asm, and getting dynamic-linking support into the mips port.
> I'd also like to finish and integrate the rest of rdp's porting work
> (mips64, ppc, and microblaze) and possibly get an x32 (32-bit ABI on
> x86_64) port underway, and integrate additional hash function support
> (blowfish, sha, md5) for crypt.

All of these sound good.
I'm not sure about whether many people would be interested in x32, though?...

Something other than standard crypt (isn't that DES, which can be cracked
in a day on the right machine?) would be one of the more interesting ones
from my perspective.  Remembering the recent test results, I'd be hoping
for bcrypt as well (it's where OpenCL cracking gets the least benefit).


> Priority scheduling and related realtime issues are something I
> haven't really touched yet, but it's also on the table for later in
> the 0.9.x series.

I may be sending a patch or two to adjust io.h / io*.c as well.
(move to per-architecture, perhaps; add bits/io.h based on klibc's
sys/io.h (?) )
Also, once I figure out how syscall.list* maps to the syscall() interface
in musl, I may send a patch to support syscalls 113 & 166
(vm86(old)/vm86(plus))
*glibc and some other libc versions just have a list describing the
calling convention, name, and so on for each syscall. This somehow gets
converted to  functions.


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.