tealdeer: rustls -> native-tls

[newAM]

Things done

The recent tealdeer v1.7.0 release added support for the native-tls crate which dynamically links libssl on Linux instead of the rustls crate.

This change reduces the tldr binary size:

• x86_64-linux: 2097k -> 1433k (assuming libssl already exists for other purposes)
• aarch64-darwin: 3620k -> 2620k

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[emilazy]

It seems like Rustls is the upstream default and what they build their own releases with. I think sticking with the memory‐safe implementation makes more sense without a strong reason to diverge from that.

[NickCao]

Suggested change

	cargoBuildFlags = [
	# use OpenSSL for the TLS backend instead of the default rustls
	"--no-default-features"
	"--features=native-tls"
	];
	buildNoDefaultFeatures = true;
	buildFeatures = [ "native-tls" ];

[newAM]

Thanks! Updated.

[newAM]

It seems like Rustls is the upstream default and what they build their own releases with. I think sticking with the memory‐safe implementation makes more sense without a strong reason to diverge from that.

I do not think it's fair to call rustls memory safe, it depends on the ring crate which is largely ASM on x86_64 for performance reasons.

The rationale is that the binary sizes are substantially smaller with libssl, which is almost always already on the system since nix itself links it. Measurements are in the original post.

[emilazy]

Well, it’s memory safe in the sense that all Rust is: the bulk of the code involving gnarly and vulnerability‐prone stuff like X.509 parsing etc. is written in a memory‐safe dialect, but at the bottom there are of course primitives that need to be trusted. Cryptography primitives are usually not especially high‐risk for memory safety, since they tend to operate on fixed blocks with known bounds. I don’t think that shaving off a megabyte is worth the sacrifice here without another reason to diverge from upstream to use something less safe.

[h7x4]

Would a flag in the package args be a possible solution? There's still the need to agree on whether it should be opt-in or opt-out, but at least it would leave the choice in the hands of the users who care enough to look for it

[emilazy]

If there’s a meaningful functionality difference for users (e.g. more protocol versions supported with OpenSSL?), then that could be reasonable. I don’t think we should just delegate every packaging decision to users, though, especially ones trading off memory safety for a megabyte of storage.

The upstream change that added native-tls support justifies it with support for architectures like PowerPC and MIPS. We can’t compile Rust code for MIPS at present. Maybe we can for PowerPC? I’m not sure if there are any NixOS‐on‐PowerPC users (it’s certainly not a platform we support in any official capacity).