jiebi/CodeConvo huggingface dataset:
Code change:
connector-c = self; server = self; mysqlVersion = "5.7"; <ins> tests = nixosTests.mysql; </ins> }; meta = with lib; {

Related discussion:
text: , CVSSv3=5.5 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.3 (nixos-21.11, nixos-unstable) Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Compiling). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Federated). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Stored Procedure). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior.
Code change:
connector-c = self; server = self; mysqlVersion = "5.7"; <ins> tests = nixosTests.mysql; </ins> }; meta = with lib; {

Related discussion:
text: Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 4.3 (Integrity impacts).
Code change:
connector-c = self; server = self; mysqlVersion = "5.7"; <ins> tests = nixosTests.mysql; </ins> }; meta = with lib; {

Related discussion:
text: CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N). Scanned versions: nixos-21.11: ; nixos-unstable: .
See also: , , , , , ,
Fixed: nixos-21.11: mysql-5.7.37, mysql-8.0.28 nixos-unstable: mysql-5.7.39, mysql-8.0.30
Code change:
else "") + lib.optionalString targetPlatform.isAvr '' makeFlagsArray+=( <ins> '-s' # workaround for hitting hydra log limit </ins> 'LIMITS_H_TEST=false' ) '';

Related discussion:
text: and fail in this fashion: This seems to have started to happen in December of last year (see ). This effectively means that using the avr toolchain in nixpkgs means re-compiling gcc on every channel update. Not sure what is causing the log size, unfortunately there's no special hydra meta attr to change the log limit. cc Maintainer information:
From doing local rebuilds of this package and noting how much output it gives, the long logs are from echoing back the compiler commands from make when compiling all of the soft float routines for each different AVR chip. It started dumping all this output when we moved from GCC 9 to GCC 10. Looking at the logs prior to that version bump, make must have been quiet because I see no compiler commands getting echoed back. Is it possible to add something like here?
may be worth a try:
Code change:
<ins> { lib , rustPlatform , fetchFromGitHub , cmake , pkg-config , openssl , fontconfig , nasm , libX11 , libXcursor , libXrandr , libXi , libGL , stdenv , gtk3 , darwin }: rustPlatform.buildRustPackage rec { pname = "oculante"; version = "0.6.38"; src = fetchFromGitHub { owner = "woelper"; repo = pname; rev = version; sha256 = "sha256-0msPeW0FoBzHBDfX2iFH4HzAknaGPNThuCLi2vhdK08="; }; cargoSha256 = "sha256-eKRn8MC4/jjPRoajhwrtXsa8n9bGO5MAKjDuwHWs7Oc="; nativeBuildInputs = [ cmake pkg-config nasm ]; checkFlagsArray = [ "--skip=tests::net" ]; # requires network access buildInputs = [ openssl fontconfig ] ++ lib.optionals stdenv.isLinux [ libX11 libXcursor libXi libXrandr libGL gtk3 ] ++ lib.optionals stdenv.isDarwin [ darwin.libobjc ]; postFixup = lib.optionalString stdenv.isLinux '' patchelf $out/bin/oculante --add-rpath ${lib.makeLibraryPath [ libGL ]} ''; meta = with lib; { broken = stdenv.isDarwin; description = "A minimalistic crossplatform image viewer written in Rust"; homepage = "https://github.com/woelper/oculante"; changelog = "https://github.com/woelper/oculante/blob/${version}/CHANGELOG.md"; license = licenses.mit; maintainers = with maintainers; [ dit7ya ]; }; } </ins>

Related discussion:
text: Project description Oculante's vision is to be a fast, unobtrusive, portable image viewer with wide image format support, offering image analysis and basic editing tools. Metadata homepage URL: source URL: license: MIT platforms: cross
Code change:
pwdsafety = callPackage ../tools/security/pwdsafety { }; <ins> pwvucontrol = callPackage ../applications/audio/pwvucontrol { }; </ins> pyload-ng = callPackage ../applications/networking/pyload-ng {}; pyrosimple = callPackage ../applications/networking/p2p/pyrosimple { };

Related discussion:
text: Project description Volume control applet for Pipewire, written in Rust. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...
Code change:
++ stdenv.lib.optional perlBindings perl ++ stdenv.lib.optional saslSupport sasl; <ins> patches = [ ./apr-1.patch ]; </ins> configureFlags = '' ${if bdbSupport then "--with-berkeley-db" else "--without-berkeley-db"} ${if httpServer then "--with-apxs=${apacheHttpd}/bin/apxs" else "--without-apxs"}

Related discussion:
text: When is installed with , works fine. When is installed with , then prints an error message. When installing with , I get this log: So, it might be that git-with-svn-2.6.3 is fine but not . System: NixOS: = () Nix: = Nixpkgs version: () /cc
I think you have nixpkgs and nixos channel. One might be coming from root. So on one channel it works, on the other it doesn't.
This is a bug in the Perl bindings generated as a part of our Subversion build. The library depends on , but it has no RPATH set that allows it to find library. Curiously enough, is the only dependency with that problem: other library like are found properly using a full path into the Nix store. Cc: and
and it was working fine in :
As I said, this as nothing to do with Git. It's that provides broken Perl bindings.
Ran into same problem. git bisect log of checking ldd /nix/store/-subversion-1.9.3/lib/perl5/siteperl//x8664-linux-thread- follows. there's some big binutils related changes in the middle yet.
Code change:
sha256 = "sha256-kHirHG/bfsU6tKyQ0khNSTyChhzHfzib+HyA3LOtBI8="; }; <del> nativeBuildInputs = [ pkgs.makeWrapper ]; </del> <ins> nativeBuildInputs = [ makeWrapper ]; </ins> preBuild = '' makeFlagsArray+=(prefix="$out")

Related discussion:
text: Describe the bug I need to list the out paths of cross compiled packages beforehand which causes an eval error. To Reproduce Steps to reproduce the behavior: Expected behavior List all out paths like `. Additional context I need this feature for nixpkgs-review when cross compiling. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(user): nixpkgs: Maintainer information:
I think its because of the lack of splicing for perl-packages. Note however, that when that is fixed, other package sets will fail with the same issue. cc
Probably multiple issues. Have seen that problem with building xwayland for aarch64 too. Removing makeWrapper helps but probably breaks it :(. But the deps don't cross-build anyway so never got that far for now. Was thinking about opening an issue but got caught up trying to find the issue -- to no avail. Not currently at my machine, might post it later.
I marked this as stale due to inactivity. &rarr;
still important to me
Fix in
Code change:
# substitute environment variables if [ -f "${configFile}" ]; then ${pkgs.gawk}/bin/awk '{ <del> for(varname in ENVIRON) gsub("@"varname"@", ENVIRON[varname]) </del> <ins> for(varname in ENVIRON) { find = "@"varname"@" repl = ENVIRON[varname] if (i = index($0, find)) $0 = substr($0, 1, i-1) repl substr($0, i+length(find)) } </ins> print }' "${configFile}" > "${finalConfig}" else

Related discussion:
text: Using the NixOS option to specify the configuration, I noticed that if an ampersand () is present, the password field of isn't generated correctly. the option along with the option. The environment file should contain . the field "password= the content of . The password is decrypted to . The password shuld be decrypted to . The global variable's name shouldn't show. Here are some nix code that is tested to trigger this issue instead. The environment file: Generated in the aforementioned path, note how the field is erroneous. A hack to get around this is to split your password in two halves, and put the & in plain text. . Of course I would still like to see this get fixed :p Thank you for maintaining this module and reading this issue ! Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It looks like a missed a metacharacter: I don't know if escaping it as works, or it interacts somehow with other systemd/shell/nix metacharacters. I lost counts of how many level of escaping we are in. I hope to get rid of all of this nonsense with , but next release of wpasupplicant is taking forever.
Done in The fix should be in NixOS 24.05.
Code change:
</listitem> <listitem> <para> <del> <literal>iptables</literal> now uses <literal>nf_tables</literal> backend. </del> <ins> <literal>iptables</literal> is now using <literal>nf_tables</literal> under the hood, by using <literal>iptables-nft</literal>, similar to <link xlink:href="https://wiki.debian.org/nftables#Current_status">Debian</link> and <link xlink:href="https://fedoraproject.org/wiki/Changes/iptables-nft-default">Fedora</link>. This means, <literal>ip[6]tables</literal>, <literal>arptables</literal> and <literal>ebtables</literal> commands will actually show rules from some specific tables in the <literal>nf_tables</literal> kernel subsystem. </para> </listitem> <listitem> <para> systemd got an <literal>nftables</literal> backend, and configures (networkd) rules in their own <literal>io.systemd.*</literal> tables. Check <literal>nft list ruleset</literal> to see these rules, not <literal>iptables-save</literal> (which only shows <literal>iptables</literal>-created rules. </ins> </para> </listitem> <listitem>

Related discussion:
text: On NixOS 21.05, when setting , I could see the result of this settings by running: Since NixOS 21.11 however, altought the masquerade works, I cannot see anything with iptables commands: As discussed on the Discourse topic , I suspect this is linked to the following change in NixOS 21.11 (PR ): Steps to reproduce the behavior: an interface with on a system running NixOS 21.11 the lack of information about the IP masquerade The IP masquerade should be visible like in NixOS 21.05:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Actually, this is due to systemd since v248 preferring to use nftables if available, see Systemd does not use the iptables binaries and but a separate library that creates iptables rules directly without translation to nft by iptables-nft. So even without using the legacy iptables tools, these rules in nftables by networkd would not be visible. Other services that need to add firewall rules like libvirtd, docker or podman are likely getting proper nftables support soon and users still using iptables will run into the same issues. Since we are not the only distribution dealing with this, this should either be solved in systemd (can rules be generated that are compatible to and can be parsed by iptables-nft?) or in iptables-nft by displaying a warning that other nftables rules are active. The only related problem remaining in NixOS is that since our module is heavily based around iptables, our users assume NixOS is using iptables when in fact it is using nftables with iptables compatibility. cc
This particular issue is also giving me issues running docker on NixOS 21.11 in WSL2 on Windows 10. It requires iptables and the docker service fails to start due to docker trying to issue iptables a command and the nftables reply throws docker as an error. Same configuration using systemd v247 via 21.05 works fine
What you're seeing is directly caused by and has nothing to with this issue since the problem described here is that not all active rules are visible. Are we even supporting WSL officially?
Code change:
</listitem> <listitem> <para> <del> <literal>iptables</literal> now uses <literal>nf_tables</literal> backend. </del> <ins> <literal>iptables</literal> is now using <literal>nf_tables</literal> under the hood, by using <literal>iptables-nft</literal>, similar to <link xlink:href="https://wiki.debian.org/nftables#Current_status">Debian</link> and <link xlink:href="https://fedoraproject.org/wiki/Changes/iptables-nft-default">Fedora</link>. This means, <literal>ip[6]tables</literal>, <literal>arptables</literal> and <literal>ebtables</literal> commands will actually show rules from some specific tables in the <literal>nf_tables</literal> kernel subsystem. </para> </listitem> <listitem> <para> systemd got an <literal>nftables</literal> backend, and configures (networkd) rules in their own <literal>io.systemd.*</literal> tables. Check <literal>nft list ruleset</literal> to see these rules, not <literal>iptables-save</literal> (which only shows <literal>iptables</literal>-created rules. </ins> </para> </listitem> <listitem>

Related discussion:
text: You might want to open a separate issue for this if you're interested in seeing support or getting this fixed. We would need to detect if nftables support is available and use the correct iptables package everywhere. Not sure if it's worth it, though.
this seems to also cause problems when upgrading systems from before the nftables bump. In my case, these were fixed after a reboot, but it's still a pretty annoying thing, for which we probably should at least make sure there's a release note entry. cc
Hmmh, I'm also a bit baffled about how to interpret defaulting to false. ~It seems and are mutually exclusive, but since we now configure nftables in other places, the firewall module is just broken?~
It seems only supports defining all rules exclusively, which doesn't play very nicely together with other things invoking iptables, or managing rules by themselves (like networkd , libvirt and other programs invoking iptables). Maybe that module needs a bit of a re-vamp - with merged we might want to configure most of what the module was doing, except managing the ruleset by default. However, that's a bit offtopic from the original issue.
you should see nftable tables when invoking , which is where systemd keeps its nft rules. iptables rules configured with the command are in . I think this is mostly a matter of updating the release notes, and raising awareness, that nftables is used, the command is only managing some tables in the nft system, and that there's more rules than what you can see with . I'll try to come up with a PR updating the release notes in that regard. It might not be possible to translate some nftable rules to a iptables syntax - I'm not sure if logging a warning breaks backwards compat with some tools relying on iptables output…
I improved the docs in , PTAL. Fixing the nftables module, and using less iptables in the firewall module should probably be left to another PR.
I opened to track the nftables NixOS module improvements.
Code change:
preConfigure = (concatMapStringsSep "n" (mod: mod.preConfigure or "") modules); <del> patches = stdenv.lib.optionals (stdenv.hostPlatform != stdenv.buildPlatform) [ </del> <ins> patches = stdenv.lib.singleton (substituteAll { src = ./nix-etag-1.15.4.patch; preInstall = '' export nixStoreDir="$NIX_STORE" nixStoreDirLen="''${#NIX_STORE}" ''; }) ++ stdenv.lib.optionals (stdenv.hostPlatform != stdenv.buildPlatform) [ </ins> (fetchpatch { url = "https://raw.githubusercontent.com/openwrt/packages/master/net/nginx/patches/102-sizeof_test_fix.patch"; sha256 = "0i2k30ac8d7inj9l6bl0684kjglam2f68z8lf3xggcc2i5wzhh8a";

Related discussion:
text: If you serve files from , nginx will set last-modified header to unix timestamp 1. The result is that browser will cache indefinitely. Not sure what we should do about it really, following nginx configuration helps:
Why do you need to turn etag off?
Ah, I see. nginx's etags aren't hashes.
I wonder if we could find a way to pull the hash out of the nix store path and put it into an etag header.
Thanks for finding this. I've been having issues with broken caching on my nginx/nixos server. Even when the files on the server were updated (files in the nix store), the browser was told that no change had happened. If I'm understanding this correctly, since nginx's etags are based on filesystem modification time; you can't have proper cache invalidation (ie. it will always send 304 not modified). Or is there a workaround?
+1 this is a problem. And turning off etag seems like overkill. Is there some way to 1) set the date on a file so that Nginx can pick it up, or 2) do something else awesome?
Is the zero-timestamp rule set in stone in Nix, or is there some way to override it if you really want a file in /nix/store to have a particular timestamp?
I think we could get away with: It's not perfect, as it will change on each Nix evaluation instead of being content addressed. Another way would be to turn the store path passed to nginx directive to translate into an etag.
The etag function is at called from and . Making it dependent on the realpath of the file seems doable.
Explanation how to configure nginx to use the hash from the nix path:
In my testing, this sends the correct etag, but does not send the 304 not modified, when the etag matches. Also, the header gets stripped out when compression is enabled.
It's working perfectly for me. I've gzip compression enabled, the etag header is sent and the browser gets a 304 when querying the header.
Nice! An example with a directory would be more common:
I've to correct what I said. your statement seems to be correct. What happens in my case is that Cloudflare is actually handling the caching of the ETag correctly, not nginx.
Code change:
preConfigure = (concatMapStringsSep "n" (mod: mod.preConfigure or "") modules); <del> patches = stdenv.lib.optionals (stdenv.hostPlatform != stdenv.buildPlatform) [ </del> <ins> patches = stdenv.lib.singleton (substituteAll { src = ./nix-etag-1.15.4.patch; preInstall = '' export nixStoreDir="$NIX_STORE" nixStoreDirLen="''${#NIX_STORE}" ''; }) ++ stdenv.lib.optionals (stdenv.hostPlatform != stdenv.buildPlatform) [ </ins> (fetchpatch { url = "https://raw.githubusercontent.com/openwrt/packages/master/net/nginx/patches/102-sizeof_test_fix.patch"; sha256 = "0i2k30ac8d7inj9l6bl0684kjglam2f68z8lf3xggcc2i5wzhh8a";

Related discussion:
text: So this approach is completely useless without external caching. I'll investigate further and see if I can come up with a solution.
Here is a patch: If real path (after dereferencing symlinks) of is in Nix store, it will use path's hash as ETag. For example: I'll take some time to double check everything and only then send a PR. However, feel free to test: nix { pkgs, ... }: { = { enable = true; package = with pkgs; nginx.overrideAttrs (super: { patches = (super.patches or []) ++ [(fetchpatch { url = ; sha256 = "16pa1vwcm7kibkjsxpk3szaa2vnxdinml6v0fp4038i2qaav113k"; })]; }); }; }
This is really great! or anyone, do you have a moment to write an explanation of this new feature and its practical ramifications for anyone configuring an nginx server? Since it isn't typical nginx behavior, I think the nixos manual should explain it somewhere so it doesn't catch people by surprise.
I think is a good explanation, just needs to be put into the manual.
Cool, submitted .