Matrix entry from manual does not work due to nginx' add_header restrictions

[wucke13]

Describe the bug This manual section does not work on my 21.05 system. The reason is that the nginx config check does not pass, due to nested add_header directives overriding external add_header directives. This error output is generated:

==================== Results ===================

>> Problem: [add_header_redefinition] Nested "add_header" drops parent headers.
Description: "add_header" replaces ALL parent headers. See documentation: http://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header
Additional info: https://github.com/yandex/gixy/blob/master/docs/en/plugins/addheaderredefinition.md
Reason: Parent headers "x-frame-options", "x-xss-protection", "x-content-type-options" was dropped in current level
Pseudo config:

server {
        server_name tu-clausthal.de;

        location = /.well-known/matrix/client {
                add_header Content-Type application/json;
                add_header Access-Control-Allow-Origin *;
        }

        location = /.well-known/matrix/server {
                add_header Content-Type application/json;
        }
}
add_header Strict-Transport-Security max-age=63072000; includeSubdomains; preload;
add_header Feature-Policy fullscreen  'self'; notifications 'self'; push 'self'; sync-xhr 'self';;
add_header Referrer-Policy same-origin;
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;
add_header X-XSS-Protection 1; mode=block;

==================== Summary ===================
Total issues:
    Unspecified: 0
    Low: 0
    Medium: 2
    High: 0

To Reproduce Follow the manual entry while simultaneously setting any sane and recommended add_header setting in nginx, like services.nginx.appendHttpConfig = "add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

Expected behavior The configuration can be build

Additional context For good measure, a bunch of add_header directives should be in place on any nginx. It would be good to allow this kind of "problem" in the nginx config.

Notify maintainers @globin , @fpletz

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

[Mic92]

cc @Ma27 @mweinelt

[stale[bot]]

I marked this as stale due to inactivity. → More info

[tilpner]

still a problem, and not just for matrix

[robx]

I ran into a related issue. It would be good if the nginx module allowed overriding the gixy check in some straightforward way. (Incidentally, it's a bit confusing that writeNginxConfig also runs a linter over it -- wouldbe nicer if that were a separate checkNginxConfig call.)

Anyway, my hacky work-around (in a flake-based nixos config):

  outputs = {
    self,
    nixpkgs,
  }: let
    system = "x86_64-linux";
    rawpkgs = import nixpkgs {inherit system;};
    pkgs =
      rawpkgs
      // {
        writers.writeNginxConfig = name: text:
          rawpkgs.runCommandLocal name {
            inherit text;
            passAsFile = ["text"];
            nativeBuildInputs = [pkgs.gixy];
          }
          ''
            awk -f ${rawpkgs.writers.awkFormatNginx} "$textPath" | sed '/^\s*$/d' > $out
            gixy --skips host_spoofing $out
          '';
      });
  in {
    nixosConfigurations.myhost = nixpkgs.lib.nixosSystem {
      inherit system pkgs;
      modules = [
      ...

This patches the writeNginxConfig function to call gixy while skipping a particular test.

[RyanGibb]

Just ran into this. It seems like a flag configure, or at least disable, gixy would be a good idea.

[xieve]

Just ran into gixy's origins rule, which is meant for Referer validation. Except what I'm doing is not validating the Referer, I do not care if it is invalid, I just need to tweak some behaviour depending on the Referer.

Gixy's documentation does not state a way to fix this "medium" severity issue, and after a lot of trial-and-error, I could not figure it out. It makes up lots of strings that are not even valid URLs in the first place, and also ones that do not match the given regex, then complains about these matching. It even complains about the regex if it matches only the intended URL. I don't understand what the issue with that would be, even if I were validating the Referer.

In my opinion,

• The fact that Gixy is run on the nginx config should be clearly stated in every docstring for extraConfig. This was not easy for me to find out in the first place.
• Failing builds on "medium" severity issues is not something I would expect. I think this should be a warning instead.
• Gixy is not meant to be used like this, especially in its unconfigured/(kind of) unconfigurable state. It seems to be less of a validator and more of a vulnerability scanner.
• Gixy's validation seems lackluster at best and counter-productive at worst. Is there really no possibility to "dry-run" nginx over the config instead?