jiebi/CodeConvo huggingface dataset:
Code change:
, CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

Related discussion:
text: let pname = "zammad"; <del> version = "5.1.0"; </del> <ins> version = "5.1.1"; </ins> src = applyPatches {
Code change:
, CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

Related discussion:
text: platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "04vxmjr200akcil9fqxc9ghbb9q0lyrh2q03xxncycd5vln910fi"; </del> <ins> sha256 = "1pfk942d6qwhw151hxaz7n4knk6whyxqvvywdx2cdw9yhykyaqzq"; </ins> type = "gem"; }; <del> version = "6.2.0"; </del> <ins> version = "6.2.1"; </ins> }; factory_bot_rails = { dependencies = ["factory_bot" "railties"];
Code change:
, CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

Related discussion:
text: platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "1p6b3q411h2mw4dsvhjrp1hh66hha5cm69fqg85vn2lizz71n6xz"; </del> <ins> sha256 = "1g43ii497cwdqhfnaxfl500bq5yfc5hfv5df1lvf6wcjnd708ihd"; </ins> type = "gem"; }; <del> version = "1.13.3"; </del> <ins> version = "1.13.4"; </ins> }; nori = { groups = ["default"];
Code change:
, CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

Related discussion:
text: platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "19mf9f5zx23cjjn0p77wz1igzpfr22mxhljgavffl8fwqq74v4ih"; </del> <ins> sha256 = "01ldw5ba6xfn2k97n75n52qs4f0fy8xmn58c4247xf476nfvg035"; </ins> type = "gem"; }; <del> version = "3.2.5"; </del> <ins> version = "3.2.6"; </ins> }; power_assert = { groups = ["default" "development" "test"];
Code change:
, CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

Related discussion:
text: platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "1xvkz9xrd1cqnlm0qac1iwwxzndx3cc17zrjncpa4lzjfwbxhsnm"; </del> <ins> sha256 = "0df9bknc2dllk8v9fhgidzbvbryaxa8fgifrk40cdz9csjsphbky"; </ins> type = "gem"; }; <del> version = "4.3.11"; </del> <ins> version = "4.3.12"; </ins> }; pundit = { dependencies = ["activesupport"];
Code change:
, CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

Related discussion:
text: }; version = "2.2.3"; }; <ins> rack-attack = { dependencies = ["rack"]; groups = ["default"]; platforms = []; source = { remotes = ["https://rubygems.org"]; sha256 = "1rc6simyql7ax5zzp667x6krl0xxxh3asc1av6gcn8j6cyl86wsx"; type = "gem"; }; version = "6.6.0"; }; </ins> rack-livereload = { dependencies = ["rack"]; groups = ["development" "test"];
Code change:
, CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

Related discussion:
text: platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "134zg0dzd7216lyczkhv01v27ikkmipjihcy2bzi0qv72p1i923i"; </del> <ins> sha256 = "1wybcipkfawg4pragmayiig03xc084x3hbwywsh1dr9x9pa8f9hj"; </ins> type = "gem"; }; <del> version = "1.1.5"; </del> <ins> version = "1.1.6"; </ins> }; slack-notifier = { groups = ["default"];
Code change:
, CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

Related discussion:
text: "stylelint-prettier": "^2.0.0" }, "name": "Zammad", <del> "version": "5.1.0" </del> <ins> "version": "5.1.1" </ins> }
Code change:
, CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc

Related discussion:
text: { "owner": "zammad", "repo": "zammad", <del> "rev": "eefae45c2ad6e6a96b8df631d2f50f290ecbd27d", "sha256": "EjowvM//+UsAfEH9/0jgLkiD7EWH34M1NQ9U2DotBqc=", </del> <ins> "rev": "d71bd90ef964426230664cdfbaa2572325bfed4f", "sha256": "yzDTkjnRBl71REtSKRblkanJWhj7gp/+exhWjxGCFWw=", </ins> "fetchSubmodules": true }
Code change:
Project description KDiskMark is an HDD and SSD benchmark tool with a very friendly graphical user interface. KDiskMark with its presets and powerful GUI calls and handles the output to provide an easy to view and interpret comprehensive benchmark result. The application is written in C++ with Qt and doesn't have any KDE dependencies. Metadata homepage URL: source URL: license: GPL 3.0 platforms: Linux
I am currently trying to work on this. It builds and runs, sometimes I run into a Kauth error
see , please review

Related discussion:
text: <ins> { stdenv , lib , wrapQtAppsHook , qtbase , qttools , fio , cmake , kauth , extra-cmake-modules , fetchFromGitHub }: stdenv.mkDerivation rec { name = "kdiskmark"; version = "2.3.0"; src = fetchFromGitHub { owner = "jonmagon"; repo = "kdiskmark"; rev = version; sha256 = "sha256-9ufRxEbqwcRs+m/YW8D3+1USCJNZEaOUZRec7gvgmtA="; }; nativeBuildInputs = [ cmake wrapQtAppsHook ]; buildInputs = [ qtbase qttools extra-cmake-modules kauth ]; postInstall = '' # so that kdiskmark can be used as unpriviledged user even on non-kde # (where kauth is not in environment.systemPackages) ln -s ${kauth}/share/dbus-1/system.d/org.kde.kf5auth.conf $out/share/dbus-1/system.d/00-kdiskmark-needs-org.kde.kf5auth.conf ''; qtWrapperArgs = [ "--prefix" "PATH" ":" (lib.makeBinPath [ fio ]) ]; meta = with lib; { description = "HDD and SSD benchmark tool with a friendly graphical user interface"; longDescription = '' If kdiskmark is not run as root it can rely on polkit to get the necessary privileges. In this case you must install it with `environment.systemPackages` on NixOS, nix-env will not work. ''; homepage = "https://github.com/JonMagon/KDiskMark"; maintainers = [ maintainers.symphorien ]; license = licenses.gpl3Only; platforms = platforms.linux; }; } </ins>
Code change:
Project description KDiskMark is an HDD and SSD benchmark tool with a very friendly graphical user interface. KDiskMark with its presets and powerful GUI calls and handles the output to provide an easy to view and interpret comprehensive benchmark result. The application is written in C++ with Qt and doesn't have any KDE dependencies. Metadata homepage URL: source URL: license: GPL 3.0 platforms: Linux
I am currently trying to work on this. It builds and runs, sometimes I run into a Kauth error
see , please review

Related discussion:
text: buildGoModule = buildGo118Module; }; <ins> kdiskmark = libsForQt5.callPackage ../tools/filesystems/kdiskmark { }; </ins> keepalived = callPackage ../tools/networking/keepalived { }; kexec-tools = callPackage ../os-specific/linux/kexec-tools { };
Code change:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

Related discussion:
text: packages = [ (with dotnetCorePackages; combinePackages [ sdk_3_1 <del> sdk_5_0 </del> <ins> sdk_6_0 </ins> ]) ]; } ``` <del> This will produce a dotnet installation that has the dotnet 3.1, 3.0, and 2.1 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output: </del> <ins> This will produce a dotnet installation that has the dotnet 3.1 6.0 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output: </ins> ```ShellSession $ dotnet --info
Code change:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

Related discussion:
text: projectReferences = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure. dotnet-sdk = dotnetCorePackages.sdk_3_1; <del> dotnet-runtime = dotnetCorePackages.net_5_0; </del> <ins> dotnet-runtime = dotnetCorePackages.net_6_0; </ins> executables = [ "foo" ]; # This wraps "$out/lib/$pname/foo" to `$out/bin/foo`. executables = []; # Don't install any executables.
Code change:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

Related discussion:
text: <literal>freetype</literal> and others. </para> </listitem> <ins> <listitem> <para> .NET 5.0 was removed due to being end-of-life, use a newer, supported .NET version - https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core </para> </listitem> </ins> </itemizedlist> </section> <section xml:id="sec-release-23.05-notable-changes">
Code change:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

Related discussion:
text: - Deprecated `xlibsWrapper` transitional package has been removed in favour of direct use of its constitutents: `xorg.libX11`, `freetype` and others. <ins> - .NET 5.0 was removed due to being end-of-life, use a newer, supported .NET version - https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core </ins> ## Other Notable Changes {#sec-release-23.05-notable-changes} <!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
Code change:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

Related discussion:
text: ## Files in versions/ are generated automatically by update.sh ## dotnet_3_1 = import ./versions/3.1.nix (buildAttrs // { icu = icu70; }); <del> dotnet_5_0 = import ./versions/5.0.nix (buildAttrs // { inherit icu; }); </del> dotnet_6_0 = import ./versions/6.0.nix (buildAttrs // { inherit icu; }); dotnet_7_0 = import ./versions/7.0.nix (buildAttrs // { inherit icu; }); in
Code change:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

Related discussion:
text: combinePackages = attrs: callPackage (import ./combine-packages.nix attrs) {}; # EOL <del> sdk_2_1 = throw "Dotnet SDK 2.1 is EOL, please use 3.1 (LTS), 5.0 (Current) or 6.0 (LTS)"; sdk_2_2 = throw "Dotnet SDK 2.2 is EOL, please use 3.1 (LTS), 5.0 (Current) or 6.0 (LTS)"; sdk_3_0 = throw "Dotnet SDK 3.0 is EOL, please use 3.1 (LTS), 5.0 (Current) or 6.0 (LTS)"; } // dotnet_3_1 // dotnet_5_0 // dotnet_6_0 // dotnet_7_0 </del> <ins> sdk_2_1 = throw "Dotnet SDK 2.1 is EOL, please use 6.0 (LTS) or 7.0 (Current)"; sdk_2_2 = throw "Dotnet SDK 2.2 is EOL, please use 6.0 (LTS) or 7.0 (Current)"; sdk_3_0 = throw "Dotnet SDK 3.0 is EOL, please use 6.0 (LTS) or 7.0 (Current)"; sdk_5_0 = throw "Dotnet SDK 5.0 is EOL, please use 6.0 (LTS) or 7.0 (Current)"; } // dotnet_3_1 // dotnet_6_0 // dotnet_7_0 </ins>