Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 25 Sep 2015 23:55:18 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Release prep for 1.1.12

Rather than drag things out again and try to put a lot in this
release, I'd rather stick with a time-based release and just include
in 1.1.12 what's already done or practical to add quickly.

The main planned goal which is done is generic FDPIC work and FDPIC
support on at least one arch, SH2/J2. Build system overhaul and bits
and atomics deduplication were on the roadmap for this release cycle
as well but they're things that make a lot more sense to start early
in a release cycle with plenty of time to experiment.

One of the secondary goals for this release cycle is something I might
still do: removing all of the old hand-written crt1.s and Scrt1.s
files. At least the ARM version is known to be buggy (does not align
the stack) and while I plan to fix any known bugs before removing them
(just for the sake of history) I'd rather not have surprises like this
come up again and again.

I know there are a couple open issues that would also be nice to fix:

- The protected data warnings from recent binutils. These are benign
  but concerning to users, and for any data other than stdin, stdout,
  and stderr (the ones affected) they would actually be dangerous on
  old GCC versions. The reason they're getting marked protected at all
  is a workaround for a GCC 3 bug handling typedef (see commit
  b8dda24fe1caa901a99580f7a52defb95aedb67c). What I think I'd like to
  do is just update the vis.h configure test to detect the GCC 3 bug
  and fail so vis.h gets disabled. In the long term I'd like to
  rethink having vis.h at all (maybe just use some hidden aliases for
  the few functions that are actually called often from within libc).

- There's a bug with out-of-range fields passed to strftime that nsz
  reported and has patches for, but I still want to find a fix that's
  simple and not costly.

Is there anything else I'm missing in the way of open bugs or patch
proposals that could be quickly addressed?

Rich

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ