referenced nowhere
and i mean just look at these files and their commit history
furthermore:
- .NET 4.0 was EOL in 2016
- .NET 3.5 is still supported, but the package was created in
970ce3a878 (2010) as part Sander van der
Burg's "experimental Visual C# build function for brave people" and since
never touched except treewide refactors. That experimental build function
has also been removed in 45c64ab798 (2025).
As observed in #484155, it was possible for broken meta information to
slip its way into the NixOS modules system. It looks like that data was
never checked. At this point I wonder if it ever was *used* in a
programmatic manner, given how long it took for it to get noticed.
This simple check causes the results to be evaluated in a format that
isn't "Nix-brained". Not using `--json` *could* allow `<LAMBDA>` to be
in the output, which is AFAICT undesirable.
```
$ nix-instantiate --strict --eval --expr '{ x = a: a; }'
{ x = <LAMBDA>; }
$ nix-instantiate --strict --eval --expr --json '{ x = a: a; }'
error:
… while evaluating attribute 'x'
at «string»:1:3:
1| { x = a: a; }
| ^
error: cannot convert a function to JSON
at «string»:1:3:
1| { x = a: a; }
| ^
```
This reverts commit 3d9cb9f355.
In 3d9cb9f355 (#436171), the two check
commands were combined in the same step, and backgrounded, `wait`ing on
their completion.
`help wait` states the following:
> If ID is not given, waits for all currently active child processes,
> and the return status is zero.
The result was that this check's misc check results were accidentally
thrown away. Oops.
Xen Security Advisory CVE-2026-23553 / XSA-479
x86: incomplete IBPB for vCPU isolation
In the context switch logic Xen attempts to skip an IBPB in the case of
a vCPU returning to a CPU on which it was the previous vCPU to run.
While safe for Xen's isolation between vCPUs, this prevents the guest
kernel correctly isolating between tasks. Consider:
1) vCPU runs on CPU A, running task 1.
2) vCPU moves to CPU B, idle gets scheduled on A. Xen skips IBPB.
3) On CPU B, guest kernel switches from task 1 to 2, issuing IBPB.
4) vCPU moves back to CPU A. Xen skips IBPB again.
Now, task 2 is running on CPU A with task 1's training still in the BTB.
Guest processes may leverage information leaks to obtain information
intended to be private to other entities in a guest.
Xen versions which had the XSA-254 fixes backported are vulnerable.
Upstream, that is 4.6 and newer.
Only x86 systems are vulnerable. Arm systems are not vulerable.
Systems vulnerable to SRSO (see XSA-434) with default settings use
IBPB-on-entry to protect against SRSO. This is a rather more aggressive
form of flushing than only on context switch, and is believed to be
sufficient to avoid the vulnerability.
Using "spec-ctrl=ibpb-entry=hvm,ibpb-entry=pv" on the Xen command line
will activate the SRSO mitigation on non-SRSO-vulnerable hardware, but
it is a large overhead.
This issue was discovered by David Kaplan of AMD.
https://xenbits.xenproject.org/xsa/advisory-479.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
Xen Security Advisory CVE-2025-58150 / XSA-477
x86: buffer overrun with shadow paging + tracing
Shadow mode tracing code uses a set of per-CPU variables to avoid
cumbersome parameter passing. Some of these variables are written to
with guest controlled data, of guest controllable size. That size can
be larger than the variable, and bounding of the writes was missing.
The exact effects depend on what's adjacent to the variables in
question. The most likely effects are bogus trace data, but none of
privilege escalation, information leaks, or Denial of Service (DoS) can
be excluded without detailed analysis of the particular build of Xen.
Only x86 systems are vulnerable. Arm systems are not vulnerable.
Only HVM guests running in shadow paging mode and with tracing enabled
can leverage the vulnerability.
Running HVM guests in HAP mode only will avoid the vulnerability.
Not enabling tracing will also avoid the vulnerability. Tracing is
enabled by the "tbuf_size=" command line option, or by running tools
like xentrace or xenbaked in Dom0. Note that on a running system
stopping xentrace / xenbaked would disable tracing. For xentrace,
however, this additionally requires that it wasn't started with the -x
option. Stopping previously enabled tracing can of course only prevent
future damage; prior damage may have occurred and may manifest only
later.
This issue was discovered by Jan Beulich of SUSE.
https://xenbits.xenproject.org/xsa/advisory-477.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
Tristan Ross