diff options
Diffstat (limited to 'nixpkgs/doc')
| -rw-r--r-- | nixpkgs/doc/builders/packages/steam.section.md | 11 | ||||
| -rw-r--r-- | nixpkgs/doc/languages-frameworks/beam.section.md | 2 | ||||
| -rw-r--r-- | nixpkgs/doc/languages-frameworks/hy.section.md | 31 | ||||
| -rw-r--r-- | nixpkgs/doc/languages-frameworks/index.xml | 1 | ||||
| -rw-r--r-- | nixpkgs/doc/languages-frameworks/python.section.md | 6 | ||||
| -rw-r--r-- | nixpkgs/doc/stdenv/stdenv.chapter.md | 27 |
6 files changed, 55 insertions, 23 deletions
diff --git a/nixpkgs/doc/builders/packages/steam.section.md b/nixpkgs/doc/builders/packages/steam.section.md index d7bb6e69d7d9..0cfc1a2c2458 100644 --- a/nixpkgs/doc/builders/packages/steam.section.md +++ b/nixpkgs/doc/builders/packages/steam.section.md @@ -56,16 +56,7 @@ Use `programs.steam.enable = true;` if you want to add steam to systemPackages a ## steam-run {#sec-steam-run} -The FHS-compatible chroot used for steam can also be used to run other linux games that expect a FHS environment. To do it, add - -```nix -pkgs.steam.override ({ - nativeOnly = true; - newStdcpp = true; -}).run -``` - -to your configuration, rebuild, and run the game with +The FHS-compatible chroot used for Steam can also be used to run other Linux games that expect a FHS environment. To use it, install the `steam-run-native` package and run the game with ``` steam-run ./foo diff --git a/nixpkgs/doc/languages-frameworks/beam.section.md b/nixpkgs/doc/languages-frameworks/beam.section.md index 348f66d42791..934e6cdca121 100644 --- a/nixpkgs/doc/languages-frameworks/beam.section.md +++ b/nixpkgs/doc/languages-frameworks/beam.section.md @@ -241,7 +241,7 @@ let git # replace with beam.packages.erlang.elixir_1_11 if you need beam.packages.erlang.elixir - nodejs-15_x + nodejs postgresql_13 # only used for frontend dependencies # you are free to use yarn2nix as well diff --git a/nixpkgs/doc/languages-frameworks/hy.section.md b/nixpkgs/doc/languages-frameworks/hy.section.md new file mode 100644 index 000000000000..a851ff24dfc2 --- /dev/null +++ b/nixpkgs/doc/languages-frameworks/hy.section.md @@ -0,0 +1,31 @@ +# Hy {#sec-language-hy} + +## Installation {#ssec-hy-installation} + +### Installation without packages {#installation-without-packages} + +You can install `hy` via nix-env or by adding it to `configuration.nix` by reffering to it as a `hy` attribute. This kind of installation adds `hy` to your environment and it succesfully works with `python3`. + +::: {.caution} +Packages that are installed with your python derivation, are not accesible by `hy` this way. +::: + +### Installation with packages {#installation-with-packages} + +Creating `hy` derivation with custom `python` packages is really simple and similar to the way that python does it. Attribute `hy` provides function `withPackages` that creates custom `hy` derivation with specified packages. + +For example if you want to create shell with `matplotlib` and `numpy`, you can do it like so: + +```ShellSession +$ nix-shell -p "hy.withPackages (ps: with ps; [ numpy matplotlib ])" +``` + +Or if you want to extend your `configuration.nix`: +```nix +{ # ... + + environment.systemPackages = with pkgs; [ + (hy.withPackages (py-packages: with py-packages; [ numpy matplotlib ])) + ]; +} +``` diff --git a/nixpkgs/doc/languages-frameworks/index.xml b/nixpkgs/doc/languages-frameworks/index.xml index 791afce6f5c6..516bddf67fd4 100644 --- a/nixpkgs/doc/languages-frameworks/index.xml +++ b/nixpkgs/doc/languages-frameworks/index.xml @@ -16,6 +16,7 @@ <xi:include href="gnome.section.xml" /> <xi:include href="go.section.xml" /> <xi:include href="haskell.section.xml" /> + <xi:include href="hy.section.xml" /> <xi:include href="idris.section.xml" /> <xi:include href="ios.section.xml" /> <xi:include href="java.section.xml" /> diff --git a/nixpkgs/doc/languages-frameworks/python.section.md b/nixpkgs/doc/languages-frameworks/python.section.md index 54face47d1ed..847a41cf23c3 100644 --- a/nixpkgs/doc/languages-frameworks/python.section.md +++ b/nixpkgs/doc/languages-frameworks/python.section.md @@ -439,7 +439,7 @@ The following example shows which arguments are given to `buildPythonPackage` in order to build [`datashape`](https://github.com/blaze/datashape). ```nix -{ lib, buildPythonPackage, fetchPypi, numpy, multipledispatch, dateutil, pytest }: +{ lib, buildPythonPackage, fetchPypi, numpy, multipledispatch, python-dateutil, pytest }: buildPythonPackage rec { pname = "datashape"; @@ -451,7 +451,7 @@ buildPythonPackage rec { }; checkInputs = [ pytest ]; - propagatedBuildInputs = [ numpy multipledispatch dateutil ]; + propagatedBuildInputs = [ numpy multipledispatch python-dateutil ]; meta = with lib; { homepage = "https://github.com/ContinuumIO/datashape"; @@ -463,7 +463,7 @@ buildPythonPackage rec { ``` We can see several runtime dependencies, `numpy`, `multipledispatch`, and -`dateutil`. Furthermore, we have one `checkInputs`, i.e. `pytest`. `pytest` is a +`python-dateutil`. Furthermore, we have one `checkInputs`, i.e. `pytest`. `pytest` is a test runner and is only used during the `checkPhase` and is therefore not added to `propagatedBuildInputs`. diff --git a/nixpkgs/doc/stdenv/stdenv.chapter.md b/nixpkgs/doc/stdenv/stdenv.chapter.md index 7219b5e80f7e..e3e7b4c850be 100644 --- a/nixpkgs/doc/stdenv/stdenv.chapter.md +++ b/nixpkgs/doc/stdenv/stdenv.chapter.md @@ -1125,9 +1125,13 @@ There are flags available to harden packages at compile or link-time. These can Both parameters take a list of flags as strings. The special `"all"` flag can be passed to `hardeningDisable` to turn off all hardening. These flags can also be used as environment variables for testing or development purposes. +For more in-depth information on these hardening flags and hardening in general, refer to the [Debian Wiki](https://wiki.debian.org/Hardening), [Ubuntu Wiki](https://wiki.ubuntu.com/Security/Features), [Gentoo Wiki](https://wiki.gentoo.org/wiki/Project:Hardened), and the [Arch Wiki](https://wiki.archlinux.org/title/Security). + +### Hardening flags enabled by default {#sec-hardening-flags-enabled-by-default} + The following flags are enabled by default and might require disabling with `hardeningDisable` if the program to package is incompatible. -### `format` {#format} +#### `format` {#format} Adds the `-Wformat -Wformat-security -Werror=format-security` compiler options. At present, this warns about calls to `printf` and `scanf` functions where the format string is not a string literal and there are no format arguments, as in `printf(foo);`. This may be a security hole if the format string came from untrusted input and contains `%n`. @@ -1140,7 +1144,7 @@ This needs to be turned off or fixed for errors similar to: cc1plus: some warnings being treated as errors ``` -### `stackprotector` {#stackprotector} +#### `stackprotector` {#stackprotector} Adds the `-fstack-protector-strong --param ssp-buffer-size=4` compiler options. This adds safety checks against stack overwrites rendering many potential code injection attacks into aborting situations. In the best case this turns code injection vulnerabilities into denial of service or into non-issues (depending on the application). @@ -1151,7 +1155,7 @@ bin/blib.a(bios_console.o): In function `bios_handle_cup': /tmp/nix-build-ipxe-20141124-5cbdc41.drv-0/ipxe-5cbdc41/src/arch/i386/firmware/pcbios/bios_console.c:86: undefined reference to `__stack_chk_fail' ``` -### `fortify` {#fortify} +#### `fortify` {#fortify} Adds the `-O2 -D_FORTIFY_SOURCE=2` compiler options. During code generation the compiler knows a great deal of information about buffer sizes (where possible), and attempts to replace insecure unlimited length buffer function calls with length-limited ones. This is especially useful for old, crufty code. Additionally, format strings in writable memory that contain `%n` are blocked. If an application depends on such a format string, it will need to be worked around. @@ -1172,7 +1176,7 @@ installwatch.c:3751:5: error: conflicting types for '__open_2' fcntl2.h:50:4: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT or O_TMPFILE in second argument needs 3 arguments ``` -### `pic` {#pic} +#### `pic` {#pic} Adds the `-fPIC` compiler options. This options adds support for position independent code in shared libraries and thus making ASLR possible. @@ -1185,19 +1189,19 @@ ccbLfRgg.s: Assembler messages: ccbLfRgg.s:33: Error: missing or invalid displacement expression `private_key_len@GOTOFF' ``` -### `strictoverflow` {#strictoverflow} +#### `strictoverflow` {#strictoverflow} Signed integer overflow is undefined behaviour according to the C standard. If it happens, it is an error in the program as it should check for overflow before it can happen, not afterwards. GCC provides built-in functions to perform arithmetic with overflow checking, which are correct and faster than any custom implementation. As a workaround, the option `-fno-strict-overflow` makes gcc behave as if signed integer overflows were defined. This flag should not trigger any build or runtime errors. -### `relro` {#relro} +#### `relro` {#relro} Adds the `-z relro` linker option. During program load, several ELF memory sections need to be written to by the linker, but can be turned read-only before turning over control to the program. This prevents some GOT (and .dtors) overwrite attacks, but at least the part of the GOT used by the dynamic linker (.got.plt) is still vulnerable. This flag can break dynamic shared object loading. For instance, the module systems of Xorg and OpenCV are incompatible with this flag. In almost all cases the `bindnow` flag must also be disabled and incompatible programs typically fail with similar errors at runtime. -### `bindnow` {#bindnow} +#### `bindnow` {#bindnow} Adds the `-z bindnow` linker option. During program load, all dynamic symbols are resolved, allowing for the complete GOT to be marked read-only (due to `relro`). This prevents GOT overwrite attacks. For very large applications, this can incur some performance loss during initial load while symbols are resolved, but this shouldn’t be an issue for daemons. @@ -1207,13 +1211,18 @@ This flag can break dynamic shared object loading. For instance, the module syst intel_drv.so: undefined symbol: vgaHWFreeHWRec ``` +### Hardening flags disabled by default {#sec-hardening-flags-disabled-by-default} + The following flags are disabled by default and should be enabled with `hardeningEnable` for packages that take untrusted input like network services. -### `pie` {#pie} +#### `pie` {#pie} + +This flag is disabled by default for normal `glibc` based NixOS package builds, but enabled by default for `musl` based package builds. Adds the `-fPIE` compiler and `-pie` linker options. Position Independent Executables are needed to take advantage of Address Space Layout Randomization, supported by modern kernel versions. While ASLR can already be enforced for data areas in the stack and heap (brk and mmap), the code areas must be compiled as position-independent. Shared libraries already do this with the `pic` flag, so they gain ASLR automatically, but binary .text regions need to be build with `pie` to gain ASLR. When this happens, ROP attacks are much harder since there are no static locations to bounce off of during a memory corruption attack. -For more in-depth information on these hardening flags and hardening in general, refer to the [Debian Wiki](https://wiki.debian.org/Hardening), [Ubuntu Wiki](https://wiki.ubuntu.com/Security/Features), [Gentoo Wiki](https://wiki.gentoo.org/wiki/Project:Hardened), and the [Arch Wiki](https://wiki.archlinux.org/index.php/DeveloperWiki:Security). +Static libraries need to be compiled with `-fPIE` so that executables can link them in with the `-pie` linker option. +If the libraries lack `-fPIE`, you will get the error `recompile with -fPIE`. [^footnote-stdenv-ignored-build-platform]: The build platform is ignored because it is a mere implementation detail of the package satisfying the dependency: As a general programming principle, dependencies are always *specified* as interfaces, not concrete implementation. [^footnote-stdenv-native-dependencies-in-path]: Currently, this means for native builds all dependencies are put on the `PATH`. But in the future that may not be the case for sake of matching cross: the platforms would be assumed to be unique for native and cross builds alike, so only the `depsBuild*` and `nativeBuildInputs` would be added to the `PATH`. |