[20.09] traefik: add patch for CVE-2021-27375

[risicle]

Motivation for this change

https://nvd.nist.gov/vuln/detail/CVE-2021-27375

Alternative to the bump proposed in #116942, fixing #116928

Sorry @Pamplemousse not meaning to tread on you...

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[SuperSandro2000]

I would prefer the bump instead of the backport because traefik is a security related software and you probably always want to run the latest version. Also see https://doc.traefik.io/traefik/migration/v2/#v22-to-v23 which are very minor.

[risicle]

security related software and you probably always want to run the latest version

I'm not sure I agree with that.

[r-rmcgibbo]

Result of nixpkgs-review pr 117536 at 3e38bab run on aarch64-linux 1

1 package built successfully:

• traefik

1 suggestion:

• warning: missing-patch-comment

  Please add a comment on the line above, explaining the purpose of this patch.
  Near pkgs/servers/traefik/default.nix:17:5:

     |
  17 |     (fetchpatch {
     |     ^
  

---

Result of nixpkgs-review pr 117536 at 3e38bab run on x86_64-linux 1

1 package built successfully:

• traefik

1 suggestion:

• warning: missing-patch-comment

  Please add a comment on the line above, explaining the purpose of this patch.
  Near pkgs/servers/traefik/default.nix:17:5:

     |
  17 |     (fetchpatch {
     |     ^
  

[SuperSandro2000]

I'm not sure I agree with that.

It is a reverse proxy like nginx, apache or haproxy and you don't want to be on some ancient version.

[risicle]

Because ...why? Without specific evidence of flaws, the assumption that a newer version is inherently more secure doesn't hold water. New versions fix issues, but also introduce them. Just today OpenSSL dropped their vulnerability which was only introduced in October.

I also hardly think it's realistic calling 6 month old software "ancient". This may mark me as old fashioned but I still consider Debian's approach to be pretty much the gold standard for dependability, and they are still backporting fixes to apache httpd 2.4.38 as their stable offering. And half the world is running on it without significant issue.

Really, I think we should do our best to respect the user's decision to run a branch that we call "stable" and allow those users that are of the opinion that newer = automatically better run from master.

[grahamc]

Yes for things like this we typically prefer backporting patches or very minor version updates.

[SuperSandro2000]

Really, I think we should do our best to respect the user's decision to run a branch that we call "stable" and allow those users that are of the opinion that newer = automatically better run from master.

The truth is that we lack lots of important backports which does not make stable more stable.

This may mark me as old fashioned but I still consider Debian's approach to be pretty much the gold standard for dependability, and they are still backporting fixes to apache httpd 2.4.38 as their stable offering.

This can be a dangerous practice if patches depend on other commits to fully fix a security issue and the patch was not fully validated.

Just today OpenSSL dropped their vulnerability which was only introduced in October.

You don't really have a choice for openssl. 1.1.0 does no longer receive any support and 1.0.2 is paid only.

[risicle]

This can be a dangerous practice if patches depend on other commits to fully fix a security issue and the patch was not fully validated.

If you're uncomfortable with that you shouldn't run Debian or Ubuntu.

I don't tend to blindly apply patches without a good attempt to understand them, and in ideal cases like this one, the patch itself includes tests which would fail if the issue were not fixed. In many cases, the CVE description links to the patch for the fix, with this being the presumed intention. And of course, packages with tests enabled (that pass) go to increase my confidence further. Without sufficient confidence, I won't propose a backport.

As for openssl, it's merely an example from today where an issue was introduced quite recently. Someone upgrading from the g release to h back in October with the idea that it would be more secure would have actually opened themselves up to a new flaw.

[SuperSandro2000]

If you're uncomfortable with that you shouldn't run Debian or Ubuntu.

I am running Debian Sid which does not receive many backports.

As for openssl, it's merely an example from today where an issue was introduced quite recently. Someone upgrading from the g release to h back in October with the idea that it would be more secure would have actually opened themselves up to a new flaw.

but back in October probably no one knew the bug. If you do that right now everyone knows it and you are way more vurnable.

[risicle]

That might me ok for you, but I don't think it would be much appreciated if I started running my production systems on debian sid.