... so it can be used in `perl.withPackages`
A bit tricky though, because rrdtool is not in `perlPackages`
```nix
perl.withPackages(p: [ (rrdtool.override{ inherit (p) perl; }) ])
```
Since 03eaa48 added perl.withPackages, there is a canonical way to
create a perl interpreter from a list of libraries, for use in script
shebangs or generic build inputs. This method is declarative (what we
are doing is clear), produces short shebangs[1] and needs not to wrap
existing scripts.
Unfortunately there are a few exceptions that I've found:
1. Scripts that are calling perl with the -T switch. This makes perl
ignore PERL5LIB, which is what perl.withPackages is using to inform
the interpreter of the library paths.
2. Perl packages that depends on libraries in their own path. This
is not possible because perl.withPackages works at build time. The
workaround is to add `-I $out/${perl.libPrefix}` to the shebang.
In all other cases I propose to switch to perl.withPackages.
[1]: https://lwn.net/Articles/779997/
Since the upstream graylogctl script will prefer finding its java
executable based on JAVA_HOME, we now set this instead of PATH in
order to allow it to find the JRE. By setting it conditionally on it
not already being set, we allow selecting a different JRE at runtime.
We also explicitly use openjdk11, which supports the
UseConcMarkSweepGC option which graylog insists on using.
Quoting from
https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00007.html:
*******************************************************************************
CVE-2020-14372 grub2: The acpi command allows privileged user to load crafted
ACPI tables when Secure Boot is enabled
CWE-184
7.5/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
GRUB2 enables the use of the command acpi even when Secure Boot is signaled by
the firmware. An attacker with local root privileges to can drop a small SSDT
in /boot/efi and modify grub.cfg to instruct grub to load said SSDT. The SSDT
then gets run by the kernel and it overwrites the kernel lock down configuration
enabling the attacker to load unsigned kernel modules and kexec unsigned code.
Reported-by: Máté Kukri
*******************************************************************************
CVE-2020-25632 grub2: Use-after-free in rmmod command
CWE-416
7.5/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
The rmmod implementation for GRUB2 is flawed, allowing an attacker to unload
a module used as dependency without checking if any other dependent module is
still loaded. This leads to an use-after-free scenario possibly allowing an
attacker to execute arbitrary code and by-pass Secure Boot protections.
Reported-by: Chris Coulson (Canonical)
*******************************************************************************
CVE-2020-25647 grub2: Out-of-bound write in grub_usb_device_initialize()
CWE-787
6.9/CVSS:3.1/AV:P/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
grub_usb_device_initialize() is called to handle USB device initialization. It
reads out the descriptors it needs from the USB device and uses that data to
fill in some USB data structures. grub_usb_device_initialize() performs very
little bounds checking and simply assumes the USB device provides sane values.
This behavior can trigger memory corruption. If properly exploited, this would
lead to arbitrary code execution allowing the attacker to by-pass Secure Boot
mechanism.
Reported-by: Joseph Tartaro (IOActive) and Ilja van Sprundel (IOActive)
*******************************************************************************
CVE-2020-27749 grub2: Stack buffer overflow in grub_parser_split_cmdline
CWE-121
7.5/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
grub_parser_split_cmdline() expands variable names present in the supplied
command line in to their corresponding variable contents and uses a 1kB stack
buffer for temporary storage without sufficient bounds checking. If the
function is called with a command line that references a variable with a
sufficiently large payload, it is possible to overflow the stack buffer,
corrupt the stack frame and control execution. An attacker may use this to
circumvent Secure Boot protections.
Reported-by: Chris Coulson (Canonical)
*******************************************************************************
CVE-2020-27779 grub2: The cutmem command allows privileged user to remove
memory regions when Secure Boot is enabled
CWE-285
7.5/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
The GRUB2's cutmem command does not honor Secure Boot locking. This allows an
privileged attacker to remove address ranges from memory creating an
opportunity to circumvent Secure Boot protections after proper triage about
grub's memory layout.
Reported-by: Teddy Reed
*******************************************************************************
CVE-2021-3418 - grub2: GRUB 2.05 reintroduced CVE-2020-15705
CWE-281
6.4/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
The GRUB2 upstream reintroduced the CVE-2020-15705. This refers to a distro
specific flaw which made upstream in the mentioned version.
If certificates that signed GRUB2 are installed into db, GRUB2 can be booted
directly. It will then boot any kernel without signature validation. The booted
kernel will think it was booted in Secure Boot mode and will implement lock
down, yet it could have been tampered.
This flaw only affects upstream and distributions using the shim_lock verifier.
Reported-by: Dimitri John Ledkov (Canonical)
*******************************************************************************
CVE-2021-20225 grub2: Heap out-of-bounds write in short form option parser
CWE-787
7.5/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
The option parser in GRUB2 allows an attacker to write past the end of
a heap-allocated buffer by calling certain commands with a large number
of specific short forms of options.
Reported-by: Daniel Axtens (IBM)
*******************************************************************************
CVE-2021-20233 grub2: Heap out-of-bound write due to mis-calculation of
space required for quoting
CWE-787
7.5/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
There's a flaw on GRUB2 menu rendering code setparam_prefix() in the menu
rendering code performs a length calculation on the assumption that expressing
a quoted single quote will require 3 characters, while it actually requires
4 characters. This allow an attacker to corrupt memory by one byte for each
quote in the input.
Reported-by: Daniel Axtens (IBM)
Includes the following version changes:
- skalibs: 2.10.0.1 -> 2.10.0.2
- execline: 2.7.0.0 -> 2.8.0.0
- s6-networking: 2.4.0.0 -> 2.4.1.0
- s6-linux-init: 1.0.6.0 -> 1.0.6.1
- s6: 2.10.0.0 -> 2.10.0.2
Upstream maintainer notes:
------------------------------------------------------------
Mon, 15 Feb 2021 19:50:14 +0000
Hello,
New versions of some of the skarnet.org packages are available.
skalibs-2.10.0.2: bugfixes
execline-2.8.0.0: major version bump, but few and low-impact changes
s6-2.10.0.2: bugfixes
s6-linux-init-1.0.6.1: bugfixes
s6-networking-2.4.1.0: minor version bump
Some details:
* execline-2.8.0.0
----------------
- The if program now propagates its child's exit code by default if it
exits.
- The backtick program's -i behaviour (exit on child failure or
presence of a null character in its output) is now the default. Other
behaviours in case of child failure can be obtained via -I, -x or -D
options; -x is the new one.
- These changes are compatible with all the common uses of if and
backtick, but break compatibility in edge cases, which is why a
major version bump is required. This has nothing in common with the
previous major version bump, which had massive changes all over the
place; this one should go smoothly, and will only impact very specific
uses of backtick.
execline now has man pages, thanks to the untiring flexibeast!
The repository can be found here:
https://github.com/flexibeast/execline-man-pages
Please allow some time for the man pages to be updated to reflect
the current HTML documentation. Currently, the man pages document
execline-2.7.0.1; they are accurate for 2.8.0.0 except for the if and
backtick changes.
* s6-linux-init-1.0.6.1
---------------------
- Bugfixes.
- When s6-linux-init is built with utmps, the default utmp user for
s6-linux-init-maker was set to "utmp". That was a bug: now, by default,
s6-linux-init-maker does not create the utmp services if the -U option
is not given. If you used s6-linux-init-maker without the -U option
and still need the utmps services, you should explicitly set "-U utmp".
https://skarnet.org/software/s6-linux-init/
git://git.skarnet.org/s6-linux-init
* s6-networking-2.4.1.0
---------------------
- Bugfixes (nothing security-related).
- It is now possible to define a maximum amount of time spent in the
TLS handshake no matter how s6-networking has been built. (The -K
option has been implemented for the libtls backend.)
- When SNI has been required, the TLS-related binaries now export
the SSL TLS SNI SERVERNAME option to their application; the variable
contains the relevant server name.
https://skarnet.org/software/s6-networking/
git://git.skarnet.org/s6-networking
s6-networking has man pages as well:
https://github.com/flexibeast/s6-networking-man-pages
Enjoy,
Bug-reports welcome.
--
Laurent
------------------------------------------------------------
Copied from: http://skarnet.org/cgi-bin/archive.cgi?1:mss:1535:202102:lpehbljhhcpaopbnkkbf
Seems like there is portability trouble preventing it from working on
darwin and likely also BSDs. The website says:
> On some systems (currently only Linux, as far as I know) they can
> also allocate, lock, and switch virtual consoles.
Prevent ytfzf from installing its own updates.
Add all programs that are possibly used in the script to $PATH.
A 10M increase in closure size seems very acceptable.
Reverted https://github.com/NixOS/nixpkgs/pull/115228 for kodi to avoid conflict.
It does not look like unzip would be used but not investigating now to speed up merge conflict resolution.
As a minor regression, LevelDB support is currently compiled out. This
is due to a few changes in the build infrastructure that now causes
leveldb to be vendored when it shouldn't be.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Fix `lorri direnv` triggering an unconditional rebuild every time it is run.
After fixing up the build loop people suddenly started noticing that
lorri was evaluating every time something ran `lorri direnv`, which
could potentially be every time the user switched between buffers in
the editor.
This is not the intended behaviour, since we should run an
unconditional build only the first time the project is added to the
watcher, and after rely on the watcher to notify us of any file
changes (or the user running `lorri internal ping` to force a
rebuild).
