Skip to content
This repository has been archived by the owner on Apr 12, 2021. It is now read-only.
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: NixOS/nixpkgs-channels
base: 37d4e29f3319
Choose a base ref
...
head repository: NixOS/nixpkgs-channels
compare: 136e4c1fb0e2
Choose a head ref
  • 4 commits
  • 4 files changed
  • 3 contributors

Commits on May 24, 2020

  1. Merge #87237: gcc10, gfortran10: init at 10.1.0

    (cherry picked from commit 2e192dc)
    It's just adding new packages; they might be useful on 20.03 as well.
    We didn't have gnat backported to 20.03, so I didn't touch that.
    vcunat committed May 24, 2020
    Copy the full SHA
    81b7dad View commit details
    Browse the repository at this point in the history
  2. nixos/acme: change default keyType to ec256

    Previously, the NixOS ACME module defaulted to using P-384 for
    TLS certificates. I believe that this is a mistake, and that we
    should use P-256 instead, despite it being theoretically
    cryptographically weaker.
    
    The security margin of a 256-bit elliptic curve cipher is substantial;
    beyond a certain level, more bits in the key serve more to slow things
    down than add meaningful protection. It's much more likely that ECDSA
    will be broken entirely, or some fatal flaw will be found in the NIST
    curves that makes them all insecure, than that the security margin
    will be reduced enough to put P-256 at risk but not P-384. It's also
    inconsistent to target a curve with a 192-bit security margin when our
    recommended nginx TLS configuration allows 128-bit AES. [This Stack
    Exchange answer][pornin] by cryptographer Thomas Pornin conveys the
    general attitude among experts:
    
    > Use P-256 to minimize trouble. If you feel that your manhood is
    > threatened by using a 256-bit curve where a 384-bit curve is
    > available, then use P-384: it will increases your computational and
    > network costs (a factor of about 3 for CPU, a few extra dozen bytes
    > on the network) but this is likely to be negligible in practice (in a
    > SSL-powered Web server, the heavy cost is in "Web", not "SSL").
    
    [pornin]: https://security.stackexchange.com/a/78624
    
    While the NIST curves have many flaws (see [SafeCurves][safecurves]),
    P-256 and P-384 are no different in this respect; SafeCurves gives
    them the same rating. The only NIST curve Bernstein [thinks better of,
    P-521][bernstein] (see "Other standard primes"), isn't usable for Web
    PKI (it's [not supported by BoringSSL by default][boringssl] and hence
    [doesn't work in Chromium/Chrome][chromium], and Let's Encrypt [don't
    support it either][letsencrypt]).
    
    [safecurves]: https://safecurves.cr.yp.to/
    [bernstein]: https://blog.cr.yp.to/20140323-ecdsa.html
    [boringssl]: https://boringssl.googlesource.com/boringssl/+/e9fc3e547e557492316932b62881c3386973ceb2
    [chromium]: https://bugs.chromium.org/p/chromium/issues/detail?id=478225
    [letsencrypt]: https://letsencrypt.org/docs/integration-guide/#supported-key-algorithms
    
    So there's no real benefit to using P-384; what's the cost? In the
    Stack Exchange answer I linked, Pornin estimates a factor of 3×
    CPU usage, which wouldn't be so bad; unfortunately, this is wildly
    optimistic in practice, as P-256 is much more common and therefore
    much better optimized. [This GitHub comment][openssl] measures the
    performance differential for raw Diffie-Hellman operations with OpenSSL
    1.1.1 at a whopping 14× (even P-521 fares better!); [Caddy disables
    P-384 by default][caddy] due to Go's [lack of accelerated assembly
    implementations][crypto/elliptic] for it, and the difference there seems
    even more extreme: [this golang-nuts post][golang-nuts] measures the key
    generation performance differential at 275×. It's unlikely to be the
    bottleneck for anyone, but I still feel kind of bad for anyone having
    lego generate hundreds of certificates and sign challenges with them
    with performance like that...
    
    [openssl]: mozilla/server-side-tls#190 (comment)
    [caddy]: https://github.com/caddyserver/caddy/blob/2cab475ba516fa725d012f53ca417c3e039607de/modules/caddytls/values.go#L113-L124
    [crypto/elliptic]: https://github.com/golang/go/tree/2910c5b4a01a573ebc97744890a07c1a3122c67a/src/crypto/elliptic
    [golang-nuts]: https://groups.google.com/forum/#!topic/golang-nuts/nlnJkBMMyzk
    
    In conclusion, there's no real reason to use P-384 in general: if you
    don't care about Web PKI compatibility and want to use a nicer curve,
    then Ed25519 or P-521 are better options; if you're a NIST-fearing
    paranoiac, you should use good old RSA; but if you're a normal person
    running a web server, then you're best served by just using P-256. Right
    now, NixOS makes an arbitrary decision between two equally-mediocre
    curves that just so happens to slow down ECDH key agreement for every
    TLS connection by over an order of magnitude; this commit fixes that.
    
    Unfortunately, it seems like existing P-384 certificates won't get
    migrated automatically on renewal without manual intervention, but
    that's a more general problem with the existing ACME module (see #81634;
    I know @yegortimoshenko is working on this). To migrate your
    certificates manually, run:
    
        $ sudo find /var/lib/acme/.lego/certificates -type f -delete
        $ sudo find /var/lib/acme -name '*.pem' -delete
        $ sudo systemctl restart 'acme-*.service' nginx.service
    
    (No warranty. If it breaks, you get to keep both pieces. But it worked
    for me.)
    
    (cherry picked from commit 62e34d1)
    emilazy committed May 24, 2020
    Copy the full SHA
    8cc8fa1 View commit details
    Browse the repository at this point in the history

Commits on May 25, 2020

  1. Merge pull request #88829 from emilazy/acme-use-ec256-20.03

    [20.03] nixos/acme: change default keyType to ec256
    flokli committed May 25, 2020
    Copy the full SHA
    4068ae5 View commit details
    Browse the repository at this point in the history
  2. knot-dns: 2.9.4 -> 2.9.5

    There's a bugfix important for some auto-signer setups.
    https://gitlab.labs.nic.cz/knot/knot-dns/-/tags/v2.9.5
    
    (cherry picked from commit da75290)
    $ nix build -f nixos/release-combined.nix nixos.tests.knot.x86_64-linux
    vcunat committed May 25, 2020
    Copy the full SHA
    136e4c1 View commit details
    Browse the repository at this point in the history