jiebi/CodeConvo huggingface dataset:
Code change:
<del> { stdenv, fetchFromGitHub, autoconf, automake, libtool, ... }: </del> <ins> { stdenv, fetchFromGitHub, autoreconfHook, jdk # Enable ECDSA pubkey recovery module , enableRecovery ? true # Enable ECDH shared secret computation (disabled by default because it is # experimental) , enableECDH ? false # Enable libsecp256k1_jni (disabled by default because it requires a jdk, # which is a large dependency) , enableJNI ? false }: let inherit (stdenv.lib) optionals; in </ins> stdenv.mkDerivation rec { name = "secp256k1-${version}"; <del> # I can't find any version numbers, so we're just using the date # of the last commit. version = "2016-05-30"; </del> <ins> # I can't find any version numbers, so we're just using the date of the # last commit. version = "2016-11-27"; </ins> src = fetchFromGitHub { owner = "bitcoin-core"; repo = "secp256k1"; <del> rev = "b3be8521e694eaf45dd29baea035055183c42fe2"; sha256 = "1pgsy72w87yxbiqn96hnm8alsfx3rj7d9jlzdsypyf6i1rf6w4bq"; </del> <ins> rev = "2928420c1b8e1feee8c20dff4e3cc41a0de2fc22"; sha256 = "1djsr2vrhh88353czlwb8bwlyabf008w1f7xg0fs3q33rf42w5gm"; </ins> }; <del> buildInputs = [ autoconf automake libtool ]; </del> <ins> buildInputs = optionals enableJNI [ jdk ]; </ins> <del> configureFlags = [ "--enable-module-recovery" ]; </del> <ins> nativeBuildInputs = [ autoreconfHook ]; </ins> <del> preConfigure = "./autogen.sh"; </del> <ins> configureFlags = optionals enableECDH [ "--enable-module-ecdh" "--enable-experimental" ] ++ optionals enableRecovery [ "--enable-module-recovery" ] ++ optionals enableJNI [ "--enable-jni" ]; </ins> meta = with stdenv.lib; { description = "Optimized C library for EC operations on curve secp256k1"; longDescription = '' <del> Optimized C library for EC operations on curve secp256k1. Part of Bitcoin Core. This library is a work in progress and is being used to research best practices. Use at your own risk. </del> <ins> Optimized C library for EC operations on curve secp256k1. Part of Bitcoin Core. This library is a work in progress and is being used to research best practices. Use at your own risk. </ins> ''; homepage = https://github.com/bitcoin-core/secp256k1; license = with licenses; [ mit ];

Related discussion:
text: There are a few more flags we should enable on : - (I had to add these flags for the sake of something that depends on secp256k1 - I don't remember for sure, but I think it's bitcoinj.)
The schnorr flag appears to be gone in the latest version.
Code change:
(fetchNuGet { pname = "ppy.Veldrid.MetalBindings"; version = "4.9.5-gc8dfc5ca19"; sha256 = "0i6bb79kprrmsfphjq26rgxqfvvf12pxr7dfwcq448dw2xgq6rpy"; }) (fetchNuGet { pname = "ppy.Veldrid.OpenGLBindings"; version = "4.9.5-gc8dfc5ca19"; sha256 = "06a4kkfidr7yj60xl3k4yfawz4wzwkkjpaki8fmsanif1yhz69l8"; }) (fetchNuGet { pname = "ppy.Veldrid.SPIRV"; version = "1.0.15-gca6cec7843"; sha256 = "09pi4c91ljavilw9kx7kzhcax7ar4zk7zy1qwvqfrqsgxznvyxa1"; }) <del> (fetchNuGet { pname = "Realm"; version = "11.7.0"; sha256 = "1vp8rparpcv7rbqx7m55xcji941a6qjamxhb943fgfkjf196z69w"; }) (fetchNuGet { pname = "Realm.PlatformHelpers"; version = "11.7.0"; sha256 = "1a7kaap5ad3n7cgf07xa9yc4c1qi7cf2zj3f5hdv7fp84bdzmysg"; }) </del> <ins> (fetchNuGet { pname = "Realm"; version = "11.5.0"; sha256 = "0r7j5si3n4ncq8xnnjk1q5jjqbj0s1w3ps124y8pgqd14dzvch6a"; }) (fetchNuGet { pname = "Realm.PlatformHelpers"; version = "11.5.0"; sha256 = "1ggbmlsf04pxnh1k86hs0wxnvcw0ja2xnn6358qmrp826km0w1g9"; }) </ins> (fetchNuGet { pname = "Remotion.Linq"; version = "2.2.0"; sha256 = "1y46ni0xswmmiryp8sydjgryafwn458dr91f9xn653w73kdyk4xf"; }) (fetchNuGet { pname = "runtime.any.System.Collections"; version = "4.3.0"; sha256 = "0bv5qgm6vr47ynxqbnkc7i797fdi8gbjjxii173syrx14nmrkwg0"; }) (fetchNuGet { pname = "runtime.any.System.Diagnostics.Tools"; version = "4.3.0"; sha256 = "1wl76vk12zhdh66vmagni66h5xbhgqq7zkdpgw21jhxhvlbcl8pk"; })

Related discussion:
text: Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
rustPlatform.buildRustPackage rec { pname = "gping"; <del> version = "1.2.1"; </del> <ins> version = "1.2.6"; </ins> src = fetchFromGitHub { owner = "orf"; repo = "gping"; <del> rev = "v${version}"; sha256 = "sha256-lApm1JLXNjDKLj6zj25OaZDVp7lLW3qyrDsvJrudl8I="; </del> <ins> rev = "gping-v${version}"; sha256 = "sha256-Sxmwuf+iTBTlpfMFCEUp6JyEaoHgmLIKB/gws2KY/xc="; </ins> }; <del> cargoSha256 = "sha256-d1NjPwT3YDp1U9JWeUejpWDbJonFlt5lYbUf7p3jVT0="; </del> <ins> cargoSha256 = "sha256-xEASs6r5zxYJXS+at6aX5n0whGp5qwuNwq6Jh0GM+/4="; </ins> buildInputs = lib.optional stdenv.isDarwin libiconv;

Related discussion:
text: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: gping <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.2.1 desired version: 1.2.6 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Code change:
<ins> { rustPlatform, lib, fetchFromGitHub, nix-update-script, nixosTests, }: rustPlatform.buildRustPackage rec { pname = "turn-rs"; version = "3.1.0"; src = fetchFromGitHub { owner = "mycrl"; repo = "turn-rs"; rev = "refs/tags/v${version}"; hash = "sha256-uXMRDgSHrwT6+kejWRSE1WjXO8LaOR+fnffIXcL3A4I="; }; cargoHash = "sha256-gO2vuOQMvl6KYp529k3CYDyma5ECzOr/lcSvP4OpUUo="; passthru = { updateScript = nix-update-script { }; tests.nixos = nixosTests.turn-rs; }; meta = { description = "Pure rust implemented turn server"; homepage = "https://github.com/mycrl/turn-rs"; changelog = "https://github.com/mycrl/turn-rs/releases/tag/v${version}"; license = lib.licenses.gpl3Only; mainProgram = "turn-server"; maintainers = with lib.maintainers; [ bot-wxt1221 ]; platforms = lib.platforms.linux; }; } </ins>

Related discussion:
text: Project description A pure rust implemented turn server. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: gpl-3.0 platforms: linux, windows Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
{ lib , stdenv <del> , fetchFromGitHub </del> <ins> , fetchFromGitea , substituteAll </ins> , testers , gummy , cmake

Related discussion:
text: Package name: gummy Latest released version: 0.6.0 <!-- Search your package here: --- Current version on the unstable channel: 0.3 Current version on the stable/release channel: 0.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- There is an open pull request () by from October 2023, but it has not been merged and later versions of the program have been released since then. I think it is also worth noting that the source code repository of the is no longer available on GitHub. as the repository has moved to Codeberg (see ). Notify maintainers (last updated the package) <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I updated my linked PR to the latest version.
Thank you for updating it so quickly! Is there a time frame in which we can expect the pull request to be merged by someone?
Code change:
{ lib , stdenv <del> , fetchFromGitHub </del> <ins> , fetchFromGitea , substituteAll </ins> , testers , gummy , cmake

Related discussion:
text: Package name: gummy Latest released version: 0.5.4 <!-- Search your package here: --- Current version on the unstable channel: 0.3 Current version on the stable/release channel: 0.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers I've tried to bump the version to 0.5.4. <details<summaryThe build fails when downloading json-poputlate</summary</details<!-- If the result shows no maintainers, tag the person that last updated the package. --
Code change:
<ins> { fetchFromGitHub, }: { qmplay2 = let self = { pname = "qmplay2"; version = "24.06.16"; src = fetchFromGitHub { owner = "zaps166"; repo = "QMPlay2"; rev = self.version; hash = "sha256-HoFyC/OFmthUYfyo6//+KmBIq06MPb5GmDekJbnsz5o="; }; }; in self; qmvk = { pname = "qmvk"; version = "0-unstable-2024-04-19"; src = fetchFromGitHub { owner = "zaps166"; repo = "QmVk"; rev = "5c5c2942255820b6343afdfeea0405cd3b36870e"; hash = "sha256-viFM9N5PiSCgkGlxtrLFCVDIML/QyPiaPRX77RW2NNw="; }; }; } </ins>

Related discussion:
text: Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
Code change:
} <ins> sub cpuManufacturer { my $id = shift; return $cpuinfo =~ /^vendor_ids*:.* $id$/m; } </ins> # Determine CPU governor to use if (-e "/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors") {

Related discussion:
text: It would be nice if generated and options (only ). Processors without microcode update might run with misbehaving flashed microcode: /cc
Do you mean like setting it to or just mentioning it? It's a good thing for sure to have working hardware as opposed to not working, but OTOH it pulls non free code...
Of course setting it to true (actually to ), mentioning it would have no effect. First, already pulls in literal unfree code, e.g. Wi-Fi drivers on MacBook Air 6,x, not even redistributable. Second, non-free code is already running on Intel processors, I don't see any difference whether it's flashed or not (I know this is controversial). Third, for purposes of Nixpkgs, is free. And of course the kernel contains a whole lot of firmware blobs.
Strongly disagree here as its an equivalent of setting = true; thus will taint every installation by default, which is a reverse policy of the current nixos from optin to optout. That said, being complete new user, I have myself figured and found these options myself. My system booted without them likewise fine. In general, AMD patches CPUs with AGEISA BIOS updates, so does Intel - however these updates are optional and up to the user. This is should be mentioned on a) Installation page b) NIxos wiki - not be made default option, because this action is in conflict with policy.
I disagree that this is equivalent. CPU comes preflashed with microcode, BIOS comes with updated microcode for the processor to boot correctly (microcode that comes with CPU is very buggy and usually can't go through boot sequence correctly). It's not clear how it would add to the problem if we were to load an up-to-date microcode image. This is equivalent to shipping firmware to users that haven't set flag, which is current NixOS policy. Intel microcode is freely redistributable AFAIK.
The default state for these two switches is very clearly "disabled", plus they have no affect on non-AMD/intel CPUs. Flipping the switch in hardware-, is basically flipping the default state in the backstage, which is much worse than setting the defaults to "enabled", as it creates distrust and inconsistency cases. Further, firmware updates can cause real issues, not only solve them.
Code change:
} <ins> sub cpuManufacturer { my $id = shift; return $cpuinfo =~ /^vendor_ids*:.* $id$/m; } </ins> # Determine CPU governor to use if (-e "/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors") {

Related discussion:
text: It is irresponsible to think that they only solve issues. AMD AGEISA updates on 785G on has actually been broken for over a year for me, refusing to react to USB events on boot until I manually bypassed the tier 1&2 support (which is hell of a job for Linux user) to get to actual support for testing. About Intel, I have only encountered issues with gen3 PCIe cards in Intel motherboard for 2nd gen Core CPUs, but fixing this also required a year of waiting and UEFI reflash. Also speaking as an owner of HP() and Epson(sx525wd) printers - updating ucode actually caused hardware reflash and made legally purchased cartridges worthless. I am yet to encounter a CPU that can't pass boot sequence due to buggy ucode, but I doubt hot-loading it on OS stage would fix it, because it needs first to get to this stage. However I can clearly imagine the unpredictability if these switches are properly enabled.
Microcode is essentially a firmware for the CPU. NixOS, more specifically, the Linux kernel, will load firmwares for any device with support for that without asking the user. Loading microcode updates does not require a policy change, if anything, this would make the policy more consistent across the board. On a tangent, I don't understand why anyone would tolerate a blob flashed on CPU, and in BIOS, but would not tolerate the same blob being loaded by the kernel. That can be said about any software. Usually, the opposite is true. What I mean is that every BIOS except Libreboot contains microcode blobs that it loads onto the processor early in the boot sequence. Without that blob, boot sequence will most likely fail somewhere along the way. That's the reason why Libreboot doesn't support modern Intel/AMD CPUs, and why there is Coreboot/Libreboot split in the first place.
You are mixing very different cases into one bottle. Some hardware requires ucode to be loaded to function and won't function without. Some hardware has optional ucode updates. For this hardware, some classes load firmware update and then flash themselves - some lock the possibility to install previous revision, and some classes load the ucode as temporary override (which is case with AMD/Intel). Some hardware has open firmware (sources), but majority does not offer source.
Code change:
} <ins> sub cpuManufacturer { my $id = shift; return $cpuinfo =~ /^vendor_ids*:.* $id$/m; } </ins> # Determine CPU governor to use if (-e "/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors") {

Related discussion:
text: In essence, ucode is a blackbox and live-updating ucode is unpredictable black box. For some devices, ucode loading is a must, for others its optional. I suggest that we limit ourselves to specific case of Intel/AMD ucode, for which ucode updates are optional and crucial updates are applied only via hardware flashing. I am pretty sure that the reason why Libreboot supports less hardware has to do purely with acceptance criteria for how tainted ("blackboxed") the firmware is, and that both support little of x86, because Intel refused to provide specifications and AMD was open to some extent, but then closed up the AGESA after Phenom II because they most possibly implemented TPM in firmware(fTPM). About EULA-d + encrypted software, we are talking about closed-source hardware. For manufacturers of such software, surely opposite is true and the updates are usually used to keep their policy consistent and enforced, for users it means giving up and restricting all rights. That said, I found those options myself easily as a new user (yet my hardware functioned without issues without them) and I see a problem if they default to one value, but change "automatically" and unnoticed at run-time. Either way, this option should be documented better - and this includes places where its flipped.
It's not clear what difference does it make. Say, from freedom perspective, it would not be OK to use Windows even if I were to ignore any updates for it. If we ship updated microcode, which includes security fixes foremost, how would that taint installs any more than they currently are, with in-kernel blobs and such?
It has to do with blobs for the most part. See:
It replaces non-free code with a more up2date non-free code. Given Meltdown and Spectre this should be the default. Especially since it would be generated at installation time. Accompanied with the right comment, users who really want to have outdated CPUs will be notified and can delete one line. (well two with the comment).
I would like this to default to (microcode essentially is firmware). isn't supposed to be edited, it should just use so that user can override it in their config.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days.
Code change:
} <ins> sub cpuManufacturer { my $id = shift; return $cpuinfo =~ /^vendor_ids*:.* $id$/m; } </ins> # Determine CPU governor to use if (-e "/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors") {

Related discussion:
text: If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
still think this should be done, as new users probably don't know this option exists at all and that you have to enable it by yourself in NixOS. With concerns on, this should at least be generated as commented out, with a hint "while you will probably want this, note that it is unfree software".
I marked this as stale due to inactivity. &rarr;
Why is this no longer in discussion? As someone new to the NixOS universe and coming from Ubuntu I wasn't aware that I had to explicitely include this in my hardware configuration on NixOS until I stumbled across other people's configuration files. I definitely think it should at least be prominently featured in the installation manual or even better be enabled by default, as mentioned.
One way or another, needs to be enabled by default. These updates fix security issues, there are probably a lot of NixOS users now that don't even know that they're running insecure microcode. See also the discussion in
I've never replied to the first comment! While I still support the open hardware movement (and thus free software firmware) I also believe that having QEMU misbehave because of a missing update is not really a good default option. If the user is concerned about the microcode updates or about managing security at this level then they will probably read the auto-generated configuration and immediately spot an and will comment it out :-) So thanks for the PR, I can't review because I don't know perl :-p
Code change:
{ lib, fetchFromGitHub, cmake, curl, xorg, avahi, qtbase, mkDerivation, openssl, wrapGAppsHook, <del> avahiWithLibdnssdCompat ? avahi.override { withLibdnssdCompat = true; } </del> <ins> avahiWithLibdnssdCompat ? avahi.override { withLibdnssdCompat = true; }, fetchpatch </ins> }: mkDerivation rec {

Related discussion:
text: The package is failing to build Steps to reproduce the behavior: The package to build successfully without errors
I'm sorry, I haven't used in years - but also nothing with that package has changed in some while. I'd assume an upstream problem?
I don't use but took a look out of curiosity. It was an upstream problem that is fixed by a few commits after the latest 2.4.0 release. There hasn't been a new release since then. Is the best thing to do here pull down that commit as an isolated patch or to bump the revision that's pulled down to that (untagged) revision?
Can we use in the meantime?
Code change:
if ($copyKernels == 0) { $grubStore = GrubFs($storePath); } <del> my $extraInitrdPath; if ($extraInitrd) { if (! -f $extraInitrd) { print STDERR "Warning: the specified extraInitrd " . $extraInitrd . " doesn't exist. Your system won't boot without it.n"; } $extraInitrdPath = GrubFs($extraInitrd); } </del> # Generate the header. my $conf .= "# Automatically generated.  DO NOT EDIT THIS FILE!n";

Related discussion:
text: Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.
Code change:
<ins> Fetched from https://blog.sonarsource.com/rainloop-emails-at-risk-due-to-code-flaw/ --- a/rainloop/rainloop/v/1.16.0/app/libraries/MailSo/Base/HtmlUtils.php +++ b/rainloop/rainloop/v/1.16.0/app/libraries/MailSo/Base/HtmlUtils.php @@ -239,7 +239,8 @@ class HtmlUtils $oWrapHtml->setAttribute($sKey, $sValue); } -			$oWrapDom = $oDom->createElement('div', '___xxx___'); +			$rand_str = base64_encode(random_bytes(32)); +			$oWrapDom = $oDom->createElement('div', $rand_str); $oWrapDom->setAttribute('data-x-div-type', 'body'); foreach ($aBodylAttrs as $sKey => $sValue) { @@ -250,7 +251,7 @@ class HtmlUtils $sWrp = $oDom->saveHTML($oWrapHtml); -			$sResult = str_replace('___xxx___', $sResult, $sWrp); +			$sResult = str_replace($rand_str, $sResult, $sWrp); } $sResult = str_replace(MailSoBaseHtmlUtils::$KOS, ':', $sResult); </ins>

Related discussion:
text: via In short: rainloop, a php-based webmail client, features a trivially exploitable stored xss vulnerability. Upstream is unresponsive, and seem to have ceased development. This page explains how the XSS works and proposes an unofficial patch: Example of an other distro applying this very patch: