[k32]

> Except that your anecdote is completely misleading given that the patched version was intended for creating Nix packages. You could've just used the unmodified version instead.

The package was called rebar3, not rebar3-nix or something. If the fork was called differently then no one would complain. Also this fork was based on hacks, like patching rebar3's internal files and messing with caches. If you don't see anything wrong about this, then this way of thinking just proves what I said in the parent.

But forking rebar3 wasn't needed at all, because rebar3 _already_ had all the features needed for Nix. Namely, it has get-deps command producing fixed output derivation, and it supports _checkouts directory, needed for hermetic build.

> Then use the unmodified rebar3 for your project instead. But anyways, if your threat model involves not trusting SHA256, you likely have a problem with your said cryptographic chain of custody too.

There's no reason to use SHA256, if you just replace it with a different SHA256 whenever it doesn't match with the upstream.

> Nix even alleviates some of the problems because you can use different versions of the same software, meaning that different packages don't have to share dependencies as aggressively as other distros do.

Docker exists. Although it's not perfect by any means, it doesn't require reinventing the entire world. I extrapolated my experience with Erlang to the rest of NixOS reinventions, which in theory could be wrong, but it was convincing enough for me.

> That's an outright lie. NixOS doesn't prevent you from storing secrets in a file and applying your usual UNIX permissions. FHS has absolutely nothing to do with it.

I was not talking about "storing secrets in a file", but rather about the whole live cycle of the secrets, including transferring them between parties, storing, provisioning, rotation, etc (imagine you have to solve a problem of changing some secret on 100 machines securely and reproducibly via blue/green deployment). As far as I know, Nix doesn't provide facilities for solving this problem at scale. I would be happy to be proven wrong.

> FHS has absolutely nothing to do with it.

It absolutely does. Some pieces of software look for secrets in /etc/ (Kafka, for example). When etc (or its analogue in /nix) is world-readable hilarity ensues.

[soraminazuki]

> The package was called rebar3, not rebar3-nix or something. If the fork was called differently then no one would complain.

First of all, the fork obviously isn't there for general consumption. You made it sound like unsuspecting users would use it and have unverified code downloaded on their machines, which is borderline false when it doesn't have the ability to download code from online sources. This attempt to mislead is what I'm having problems with.

Second, it would've been nice if you've raised an issue on GitHub and helped improve Nix instead of complaining and spreading borderline falsehoods on HN. Erlang isn't exactly a widely used language, so design choices would be made by the few who actually uses it. It would always help to have more productive input by actual users.

> Also this fork was based on hacks, like patching rebar3's internal files and messing with caches. If you don't see anything wrong about this, then this way of thinking just proves what I said in the parent.

Ranting about how "it's a hack!" based on cherry-picked implementation details isn't convincing at all. The intent here is to have a copy of rebar3 that builds packages from local sources only, for consumption by package maintainers. That's not by any means unreasonable.

> But forking rebar3 wasn't needed at all, because rebar3 _already_ had all the features needed for Nix.

Tell me a single major distro where it's okay to essentially redistribute packages from language-specific package managers without making huge adjustments in the way packaging is handled. I know of none. For countless software, distros just give up on packaging altogether because the effort required to make that adjustment can easily get out of hand. This is the major reason many Maven packages aren't packaged on Debian.

To make matters worse, many packages from languages-specific package managers won't even compile on major traditional FHS compliant distros. Changes to upstream packaging aren't unwarranted, however much you'd prefer to believe otherwise.

> There's no reason to use SHA256, if you just replace it with a different SHA256 whenever it doesn't match with the upstream.

The SHA256 would be verified by package maintainers, reviewers, and the hydra CI instance.

> Docker exists.

If you're against the concept of distro-provided packages, why didn't you say so upfront instead of making baseless accusations about what a horrible security disaster Nix is?

Also let me remind you that almost all Docker container images rely heavily on distro-provided packages. What are you going to do now?

> As far as I know, Nix doesn't provide facilities for solving this problem at scale.

Neither do other distros, though Nix is a close to having a built-in solution as I've just shown you.

> When etc (or its analogue in /nix) is world-readable hilarity ensues.

Why are you repeating this when I just told you it's not true? /etc in Nix is not world-readable, plain and simple. This works perfectly fine on my NixOS system:

    $ echo secret | sudo tee -a /etc/secret > /dev/null && sudo chmod 600 /etc/secret    
    $ cat /etc/secret
    cat: /etc/secret: Permission denied
    $ sudo cat /etc/secret
    secret

[k32]

> First of all, the fork obviously isn't there for general consumption.

I didn't know that when I installed a package called "rebar3" and spend some time trying to understand what's wrong with my build. Oh, my bad, should've known better that "rebar3" was for internal consumption, and I need to install "rebar3-open" instead.

> Second, it would've been nice if you've raised an issue on GitHub and helped improve Nix instead of complaining and spreading borderline falsehoods on HN.

Thanks for suggestion. I did exactly that, and I fixed this entire mess. In fact, the current NixOS Erlang infra is partially based on that work.

> Ranting about how "it's a hack!" based on cherry-picked implementation details isn't convincing at all.

I professionally work with Erlang, and I know what is hack and what is not.

> Tell me a single major distro where it's okay to essentially redistribute packages from language-specific package managers without making huge adjustments in the way packaging is handled. I know of none. For countless software, distros just give up on packaging altogether because the effort required to make that adjustment can easily get out of hand.

Language-specific packaging should be left to language-specific package managers, they have more domain knowledge. Nix doesn't solve this dilemma in any better way.

> Also let me remind you that almost all Docker container images rely heavily on distro-provided packages. What are you going to do now?

Keep on using it? Take systems software from the distro-provided packages, add my own stuff on top. Building RPM is a nobrainer. I was considering Nix as an alternative to our deploy process, but realized that it would introduce more problems than solve.

> /etc in Nix is not world-readable, plain and simple.

Please take a closer look at what you're quoting. You missed a very important part:

> (or its analogue in /nix)

You see, if I want to utilize Nix to full extend and use its main "reproducibility" feature, I need to put all my configuration in a derivation. Configuration includes secrets. Derivations are world-readable.

> Neither do other distros

Distros maybe don't, but "bug-ridden kludge that is Ansible" (according to Nix user) does.