xen-light was dropped in favour of xen and xen-slim
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
Reviewed-by: Matei Dibu <contact@mateidibu.dev>
it's been unmaintained for several years now, so there's no reason to
continue maintaining it at this point. Users should migrate to compose
v2, which is maintained in-tree as just docker-compose
Upstream Changes:
* Wi-Fi Easy Connect
- add support for DPP release 3
- allow Configurator parameters to be provided during config exchange
* MACsec
- add support for GCM-AES-256 cipher suite
- remove incorrect EAP Session-Id length constraint
- add hardware offload support for additional drivers
* HE/IEEE 802.11ax/Wi-Fi 6
- support BSS color updates
- various fixes
* EHT/IEEE 802.11be/Wi-Fi 7
- add preliminary support
* support OpenSSL 3.0 API changes
* improve EAP-TLS support for TLSv1.3
* EAP-SIM/AKA: support IMSI privacy
* improve mitigation against DoS attacks when PMF is used
* improve 4-way handshake operations
- discard unencrypted EAPOL frames in additional cases
- use Secure=1 in message 2 during PTK rekeying
* OCV: do not check Frequency Segment 1 Channel Number for 160 MHz cases
to avoid interoperability issues
* support new SAE AKM suites with variable length keys
* support new AKM for 802.1X/EAP with SHA384
* improve cross-AKM roaming with driver-based SME/BSS selection
* PASN
- extend support for secure ranging
- allow PASN implementation to be used with external programs for
Wi-Fi Aware
* FT: Use SHA256 to derive PMKID for AKM 00-0F-AC:3 (FT-EAP)
- this is based on additional details being added in the IEEE 802.11
standard
- the new implementation is not backwards compatible, but PMKSA
caching with FT-EAP was, and still is, disabled by default
* support a pregenerated MAC (mac_addr=3) as an alternative mechanism
for using per-network random MAC addresses
* EAP-PEAP: require Phase 2 authentication by default (phase2_auth=1)
to improve security for still unfortunately common invalid
configurations that do not set ca_cert
* extend SCS support for QoS Characteristics
* extend MSCS support
* support unsynchronized service discovery (USD)
* add support for explicit SSID protection in 4-way handshake
(a mitigation for CVE-2023-52424; disabled by default for now, can be
enabled with ssid_protection=1)
- in addition, verify SSID after key setup when beacon protection is
used
* fix SAE H2E rejected groups validation to avoid downgrade attacks
* a large number of other fixes, cleanup, and extensions
Changelog:
http://w1.fi/cgit/hostap/tree/wpa_supplicant/ChangeLog?id=d945ddd368085f255e68328f2d3b020ceea359af
Signed-off-by: Markus Theil <theil.markus@gmail.com>
The last oficial release of rapidjson is 8 years old, development has
continued without releases since then. The old version is affected
by CVE-2024-38517.
https://www.opencve.io/cve/CVE-2024-38517
The repository moved out of the openai org, so it doesn't make sense to
prefix the package with it.
(cherry picked from commit af13bb4513647eec3c3790c5272dbd4aa190d208)
Upstream released several versions after 13.0.0, but none of them were
updated accordingly in Nixpkgs. Upstream made it clear about a year ago
that this project was not actively maintained and recommended other
related projects.
The iverilog project is commonly known as ... iverilog, not verilog.
The package name `verilog` so far has been confusing, rename to `iverilog`.
While doing so, move the package to the new by-name/ convention directory.
Fix all the fall-out of packages that referred to the old name.
Dead cryptocurrency; last release was in 2019, last commit was in
2022. This is broken with miniupnpc 2.2.8; I reached out to the
maintainer and we agreed that it’s fine to just drop the package
rather than waste time patching it.
AdoptOpenJDK is a long-deprecated project, having been superceded by
Eclipse Temurin quite a while ago. Additionally, after running the
generate sources command, many of its subpackages fail to evaluate due
to missing binaries for versions the package expects. Because everything
provided by AdoptOpenJDK is either long-deprecated or also provided by
Temurin, its removal should not cause many problems.
By the same token, OpenJDK 12, 13, 14, 15, and 16 have also all been long
deemed EOL, and 13/14 are both actively broken and fail to build. These
packages, and their associated (and unnecessary) bootstrap chain are a
major factor in the tech debt of OpenJDK as an ecosystem in Nixpkgs.
OpenJDK 16 was the only user of OpenJFX 15, so it has also been removed.
By removing these packages, OpenJDK should hopefully be more
maintainable into the future.
This was removed in 329081dc4b, but
since I find this package useful, I'll make an attempt to maintain it.
Fortunately someone had forked the repo before it was deleted.
The derivation has been modified slightly to reflect PR feedback.
I am the singular maintainer for these packages. They are difficult to
maintain and are going to start to bitrot pretty much as soon as BMD
releases new software versions. Therefore, I am not only removing myself
as the maintainer but dropping them entirely.
I realized what rhelmot did in 61202561d9
(specify what packages just need `stdenvNoLibc`) is definitely the right
approach for this, and adjusted NetBSD and OpenBSD to likewise use it.
With that change, we don't need these confusing and ugly `*bsdCross`
package sets at all!
We can get rid of a lot more libc-related `*Cross`, and I will do so
soon, but this is the first step.
(adapted from commit 51f1ecaa59)
sandboxfs was an experiment to increase sandboxing performance in bazel,
but it never reached a stable release.
The author of sandboxfs left Google in 2020 and there have been no
updates to it since then.
bazel dropped sandboxfs in the bazel 7 release. To quote their release
notes:
The sandboxfs sandboxing strategy is removed. It hadn't been
maintained for a long time, it didn't work for most users and it was
not consistently faster while being complex to set up. sandboxfs
performance is heavily dependent on the specific setup (setup costs
are lower, but you have to pay a penalty for the use of each input)
and there are scenarios where it is faster and scenarios where it is
slower. Overall it is not worth its weight.
- 217fafe2b4
For a long time, we've had `crossLibcStdenv`, `*Cross` libc attributes,
and `*bsdCross` pre-libc package sets. This was always bad because
having "cross" things is "not declarative": the naming doesn't reflect
what packages *need* but rather how we *provide* something. This is
ugly, and creates needless friction between cross and native building.
Now, almost all of these `*Cross` attributes are gone: just these are
kept:
- Glibc's and Musl's are kept, because those packages are widely used
and I didn't want to risk changing the native builds of those at this
time.
- generic `libcCross`, `theadsCross`, and friends, because these relate
to the convolulted GCC bootstrap which still needs to be redone.
The BSD and obscure Linux or freestnanding libcs have conversely all
been made to use a new `stdenvNoLibc`, which is like the old
`crossLibcStdenv` except:
1. It usable for native and cross alike
2. It named according to what it *is* ("a standard environment without
libc but with a C compiler"), rather than some non-compositional
jargon ("the stdenv used for building libc when cross compiling",
yuck).
I should have done this change long ago, but I was stymied because of
"infinite recursions". The problem was that in too many cases we are
overriding `stdenv` to *remove* things we don't need, and this risks
cyles since those more minimal stdenvs are used to build things in the
more maximal stdenvs.
The solution is to pass `stage.nix` `stdenvNoCC`, so we can override to
*build up* rather than *tear down*. For now, the full `stdenv` is also
passed, so I don't need to change the native bootstraps, but I can see
this changing as we make things more uniform and clean those up.
Finally, the BSDs also had to be cleaned up, since they have a few
pre-libc dependencies, demanding a systematic approach. I realized what
rhelmot did in 61202561d9 (specify what
packages just need `stdenvNoLibc`) is definitely the right approach for
this, and adjusted NetBSD and OpenBSD to likewise use it.
General cleanup -- following the logic that NixOS 23.11 contains Kafka
3.5, so there is a sensible upgrade path for everyone as long as we keep
that around until after the next release.
