($ORIGIN not ignored for setuid programs) and CVE-2010-3856
(arbitrary DSO loading via LD_AUDIT).
svn path=/nixpkgs/branches/cve-2010-3856/; revision=24755
If a build expressions has set "enableParallelBuilding = true", then the
generic builder may utilize more than one CPU core to build that particular
expression. This feature works out of the box for GNU Make. Expressions that
use other build drivers like Boost.Jam or SCons have to specify appropriate
flags such as "-j${NIX_BUILD_CORES}" themselves.
svn path=/nixpkgs/trunk/; revision=23042
but on a nix-store path only having the cross-built gcc libraries.
This trims down a lot the runtime dependency tree for cross-built packages.
I also remove the glibc dependency on the native bash.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23040
found before:
- programs linked with this glibc, will be able to find its locale-archive
at LOCALE_ARCHIVE_2_11
- for any problem we forgot to mention, we also add the LOCALE_ARCHIVE
variable, checked after LOCALE_ARCHIVE_2_11. I don't know a strong reason to
have it though.
- setuid programs will expect the locale-archive in
/var/run/current-system/sw/lib/locale, usual path of the locale-archive in
nixos, and a path that a sysadmin can set pointing to the locale-archive in
case of non-nixos. setuid programs don't receive the LOCALE_ARCHIVE
variables.
- non-nixos systems will have a check for the locale-archive in /usr/lib/locale
- the glibc programs 'locale' and 'localedef' may be able to find the proper
locale-archive too.
We were also considering getting rid of the locale-archive, and using
locale files directly (like Ubuntu seems to do [1]), maybe using the LOCPATH
variable. But this would not solve the problem of localized setuid programs.
All this came after a 'meeting' with niksnut on irc about this.
[1] http://lwn.net/Articles/244204/
svn path=/nixpkgs/branches/stdenv-updates/; revision=22977
I tried to fix some trivial conflicts.
I don't know if I merged well some more difficult conflicts on openssl/darwin_patch
or haskell-platform.
svn path=/nixpkgs/branches/stdenv-updates/; revision=22878
setting glibc to look for the locale-archive in the usual nixos
/var/run/current-system/sw/lib/locale path.
This solution may give us less problems.
The last problem involved was the lack of locale-archive in setuid/setgid
programs, due to the risk of letting them take the LOCALE_ARCHIVE variable
contents from the caller.
svn path=/nixpkgs/branches/stdenv-updates/; revision=21249
Then, next updates of glibc versions should involve also a change in the LOCALE_ARCHIVE_X_XX variable name, and this way nixos would deal properly with locales and old-glibc packages.
I welcome other solutions. This looks simple enough, so that's why I go on it.
svn path=/nixpkgs/branches/stdenv-updates/; revision=20944
Updating the cross-build expressions, adding some flexibility.
Updated the linux headers used cross building, as 2.6.28 had bugs on endianness in
sparc64.
There were, as usual some bugs in gcc. Maybe not many make a cross compiler to
ultrasparc.
For the record, I could build an ultrasparc kernel with this base nix:
import /etc/nixos/nixpkgs/default.nix # The root nixpkgs default.nix
{
crossSystem = {
config = "sparc64-unknown-linux";
bigEndian = true;
arch = "sparc64";
float = "soft";
withTLS = true;
cpu = "ultrasparc";
};
config = pkgs: {
packageOverrides = pkgs : {
platform = {
name = "sparc64";
kernelHeadersBaseConfig = "sparc64_defconfig";
kernelBaseConfig = "sparc64_defconfig";
kernelArch = "sparc";
kernelAutoModules = false;
kernelTarget = "zImage";
uboot = null;
};
};
};
}
Although it did not boot directly in qemu-system-sparc64:
[sparc64] Kernel already loaded
Unhandled Exception 0x0000000000000020
PC = 0x0000000000404000 NPC = 0x0000000000404004
svn path=/nixpkgs/trunk/; revision=20269
builder.sh already sets postInstall. As a result Glibc had a
retained dependency on bootstrap-tools. Added the "rm" to
builder.sh.
* localesbuilder.sh -> locales-builder.sh.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19516
I also set the 'glibcLocales' top-level attribute point to 2.11 instead of
2.10, to match that of the 'glibc' top-level attribute.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18746
native strip. So we now distinguish dontStrip and dontCrossStrip. I updated
the expressions for glibc-2.9 and glibc-2.11 accordingly.
I could get rid of the cross-glibc depending on the cross-gcc-stage-static.
Enabling nls in the final cross-gcc.
I still have problems on wint_t/wchar_t not working on cross build. Gettext
does not build.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18562
- Disabling guile test, because one fails. I commented on that in the source.
On cross builds:
- Adding stripping
- Updating the glibc-2.11 expression to match the parameters of glibc-2.9,
which I was updating more.
- Renaming from selfNativeBuildInput to selfBuildNativeInput, so this matches
better the pattern buildNativeInputs.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18550
- Stating better the guile dependencies (native/host) for guile to build
- Fixing cross-linking, through --rpath-link (ld(1) explains well about it
- Made gcc call the linker and the assembler through the gcc wrapper instead of
directly. I thought this was the source of missing -rpath's, but the source
of the problem ended up being the lack of --rpath-link. But I think the
native gcc calls the wrapped ld and as, so let's do the same cross
compiling.
- Removed the binutilsCross from the glibc expressions. Now they are built
using the gcc-cross-wrapper, and they were built with the direct gcc and
binutils before this change.
- I think patchelf and strip don't break the cross-compiled binaries, so I
reallow them on cross compilation.
- I disable the checkPhase on cross compilation. This made gmp and libtool
fail when cross compiled, iirc.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18498
arguments for the ncurses expression.
We should find a way to express a dependency in cross compilation of the style
"cross-ncurses depends on having the native-ncurses".
svn path=/nixpkgs/branches/stdenv-updates/; revision=18479
