Announcing Determinate Nix

Announcements
100

This post was flagged by the community and is temporarily hidden.

6 Likes
101

You (and others) keep ignoring the actual problem, despite it having been pointed out a million times.

The problem is conflict of interest. You can’t hold actual power in organisation A (e.g. the NixOS foundation), while being financially invested in organisation B (e.g. Determinate Systems), when B is benefiting from A being held back.

Also, please go read Domen’s reply.

11 Likes
102

I don’t think B is benefitting of A being held back , that is at best an illusion, and I don’t think B (DetSys in this example) see it that way either. At the contrary.

Nix mindshare is currently a small, small fraction of what it could be, if adoption was increased as much as the technology deserves.

Do we not all want to see Nix becoming more mainstream, more popular, more successful? The way I see it, interests align much more than they conflict. And therefore it makes me surprised how often I see “conflict of interest” invoked as argument in this community.

8 Likes
103

detsys wants to make money while reducing the reach of the original project. I don’t see much alignment there. That’s also different from just about every other company I know that uses or builds on nix.

Besides, I am personally not a software religionist or evangelist, I care to see the software that I use get better, not just inflate numbers for venture capitalist investors or so on. I am sure various members of the community each have their own vision here. If there was a unified vision, I didn’t hear about it yet.

6 Likes
104

In the case of the installer, the DetSys installer is open source and the same license as the Nix install script, and it has already been noted that there is an effort to upstream it, if the community wants it. It’s hard to see how NixOS is being “held back” by being offered, free of charge or license encumberment, a better solution to a problem, that has already been field-tested with real users.

12 Likes
105

I don’t think this is accurate. Their business model presumably is aided by nix adoption.

Can you unpack this more?

7 Likes
106

The use of the subjunctive tense here seems premature to me! Devenv is already useful and pleasant to work with, plus easy to contribute to. As you mention, it’s also unencumbered by any unattractive attempts to lock users and contributors into proprietary tools. I don’t see any compelling reason why it can’t yet become the premier way to define and manage Nix-based, per-project development environments. Its universal availability might make it attractive even to customers of other Nix-centric platforms! (You don’t even need devenv-the-binary to use devenv-the-library. Devenv’s official docs make clear how you can use it with a flake.nix file and no special tooling, and presumably thus any Nixlang implementation you like, although devenv-the-binary does add nice functionality around garbage collection and speedups for direnv integration, etc.)

And I think this is a strategy that can pay off regardless of anything these other Nix startups do or don’t do. My team at work uses devenv for our own projects, and I know there is some interest in Nix adoption on other teams. Cachix will doubtless be the first option I push to evaluate when we come to need private binary caches, because our pleasant experiences working with Devenv have set our expectations for Cachix high.

That’s all. Just wanted to butt in to say that I remain optimistic about Devenv’s place in the ecosystem. :slight_smile:

8 Likes
107

This seems kind of circular reasoning to me. “I’m not happy that DetSys is trying to make flakes standard instead of being experimental because right now flakes are experimental.”

It’s like…okay, I guess? Sorry you don’t like them? There’s not a sound argument here that I can see for not doing flakes (I know some of those exist, but again, I haven’t seen any that seem to be true dealbreakers to me and which would preclude other people from using non-flake workflows).

(FWIW, the biggest coup Lix could’ve pulled off at launch would’ve been making flakes non-experimental in their fork, but alas…)

This is an oft-repeated talking point but I never really see any substantiation of it. Open-core means a particular thing, for example with Redis or Canonical or various other examples. Corporate-controlled means something else still, and with the licensing currently in place there’s nothing stopping a fork if it’s deemed needed.

If “worried about open-core” is being used as shorthand for “I don’t like the people involved and they made my friends angry so I don’t want them to make any money or benefit from the ecosystem” that’s a different thing altogether.

I’ll make the grim observation here: the community-controlled model has been bumpy, slow, and not particularly helpful, and has been set upon by various factions with grievances.

Open-source isn’t an aesthetic, it’s an organizational structure that gets picked to solve some set of needs–and if you fail to meet those needs, other structures exist. Open-source projects are not magically exempt from having to display competence and deliver on value, and similarly they are not magically morally better than a closed-source project that ships on time and solves real problems. Claiming otherwise is just fanboyism.

The other thing to note that gets glossed over: the ecosystem as it exists now requires lots of corporate handouts from companies that do not even pretend to otherwise care about it. The S3 bill, because reasons, is absurdly large.

There is no future in which we can both eschew corporate support and continue to be slow getting things done (say, slapfighting about governance and who is being othered by who instead of solving the technical problems that keep us existing on AWS’ largesse) and survive long-term. Pick 2.

21 Likes
108

It seems like you’re missing a lot of detail. Flakes are an annoyance in the community because:

  1. They were added without going through an RFC process, then hidden behind the experimental flag
  2. While the nix team is making progress now, that is relatively recent, it seems like they’ve sat at “experimental” for a long time without direction
  3. DetSys pushed them because it drivers their product, but don’t seem to be doing much to address technical flaws and finalize them, it looks like DetSys has gotten what they need out of it and are on to other things.
10 Likes
109

Flake adoption is so vast that arguably whatever the current technical issues are, it seems most people arent bothered by them. Calling flakes experimental at this point is misleading.

Generally when you say experimental it means “going to change a lot and rapidly”.

Flakes have been stable for a long time now. It stopped being experimental when people stopped changing it and started using it.

This is just my opinion but RFCs are really only useful in so far as creating standards that many different groups need to agree on. Like TCP, UART, DNS, etc.

A single product with a feature being developed does not need an RFC, in fact thats probably why flakes became so widely adopted. It skipped the beaurocratic BS stage and went directly into problem solving stage.

5 Likes
110

An RFC gives people the structure, place, and time to discuss things and RFCs help build community consensus and buy in.

That’s fine for your opinion, but not what the community at large has agreed on.

That’s pure speculation.

And all the features that have gone thru the RFC process, been agreed upon, and have been successful are what, exactly?

8 Likes
111

I’d just like to quote @hraban from Nix team member suggests removing flakes; data suggest it isn't a good idea, please remove the experimental flag instead - #87 by hraban on this:

I’m in that dataset yet I dislike flakes. I agree with Infinisil’s objections (and more), I wish we would redesign them completely. Yet I add a flake.nix to all my new projects. Why? Because what alternative is there right now? Flakes have sucked all the oxygen out of the room for any alternatives.

21 Likes
112

This cuts to the heart of it right here.

I think useful follow-on questions from here that might help shed light are:

  • How long do various things take to wend their way through approval in the ecosystem?
  • Is there actually a technical benefit in that additional consensus?
  • Who actually is responsible for saying “okay, this is good, fuck it ship it”?
  • To what degree is the community willing to avoid technical iteration in favor of consensus-building?
  • To what degree is the RFC process a good or a bad fit for innovation work? For maintenance work?
  • What RFCs actually have been “widely successful” versus “thoroughly solving particular issues” versus “creating useful discussion” versus “massive dumpsterfire in the guise of discussion”?
  • To what extent does the “bureaucracy” serve the various stakeholders–e.g., hobbyists, academics, industry adopters, industry users, industry vendors of nix?
  • Who actually makes up “the bureaucracy”? What are there backgrounds/tendencies?
  • Where is “the bureaucracy” most clearly felt? Is it evenly applied? When it isn’t applied, does it help or hurt get things shipped?

I think reflecting on those questions–and mods, maybe this would be a good forking point to a new discussion–might yield some interesting information.

4 Likes
113

It sounds like we’re arguing de jure vs. de facto standardization. De jure is when a standards body presents a standard; de facto is when the community adopts one technology over another.

It seems that flakes are a de facto standard in their current form, albeit with competing packages adding structure on top. It’s not unheard of for de facto choices to become a formal standard, just look at how many of the web standards came about. (Concurrent competing proposals and implementations happen all the time to get real-world experience before formalizing standards.)

Personally, I think a standards process that acknowledges flakes as they stand (at least from the DX perspective) and builds on that would benefit us all.

2 Likes
114

Hi @cafkafk,

I thought it might be useful for me to clarify the timeline of this security incident. Especially since this has come up and evolved into other bizarre claims in this thread and across the internet/mastodon/etc. My hope is that it may demonstrate that it was neither an oopsie or impropriety.

The timeline is as follows:

In summary, our communication to our users was over eight hours after the full details of the vulnerability was made public, and over two hours after the upstream Nix release was completed. As far as I can tell, the contents of our advisories did not include any information that wasn’t otherwise completely public.

Why didn’t the Nix team publish the advisory right away? They said weren’t done with it yet: Nix 2.24.8 released fixing builtin:fetchurl credentials leak, severity 5.9 (moderate) - #6 by fricklerhandwerk. I wish it had been, but I also don’t blame them for it. We would be glad to help support the Nix team on this, if that is wanted.

How were we able to act so quickly? We have internal policies and procedures that describes how we handle security incidents. Our procedure documentation includes specific instructions on monitoring for vulnerabilities, our expedited release process, and how and when we communicate to our users. As you have seen, the communication steps include issuing advisories through our general communication channels.

In other words, this is by no means an oopsie, accident, or leak. It is also not part of an effort to delegitimize the Nix project that we are so attached to. It is careful following of procedures.

It isn’t our responsibility to choose to withhold totally public information from our users, especially regarding security issues. Attackers and malicious actors don’t, and communicating actionable information promptly to our customers is part of our responsibility to those customers.

Hopefully this is less scary than it seemed at first blush.

7 Likes
115

We don’t see anything wrong with using our resources to (a) create a completely free and liberally licensed Nix installer and information source that both make it easier for people to get started with Nix and (b) raise awareness of those projects. It’s perfectly legal, of course, and it’s hard for me to think of an emergent norm in the open source world that ads like that—which we ran only for a short while—would violate. At the time, we at DetSys didn’t have any kind of paid product; all we were doing was trying to grow the Nix pie for all of us. And we think we’ve succeeded in bringing many new folks into the Nix fold with the installer, Zero to Nix, our blog posts, FlakeHub, Magic Nix Cache, and many other things, and we’re quite proud of that. As for the search results, it’s not terribly surprising that a “nix installer” query on Google would bring up results like that, even without sponsoring. The official installation script on nixos.org isn’t referred to as an “installer” anywhere in any official Nix docs (I could be wrong, but I can’t find an instance of this).

5 Likes
116

Was the information really all public? I don’t see mention of the attack being specifically about netrc credentials anywhere prior to the tweet, but I could very well be missing something. To some people familiar with the Nix codebase maybe the fact that that is where the attack would happen is obvious, but after that tweet it’s apparent to everyone.

It seems to me that even having been as explicit as mentioning impure derivations in the original PR could have been avoided and would have been a better security practice, but at least it seems to have been worded to downplay the immediate threat and emphasize the fact that it’s just become easier to do proper TLS so why not. But that does bring up the question of getting releases ready before the PR can be seen publicly.

How were we able to act so quickly?

I don’t think this is what anyone is asking. The question is not how you were able to do it (it seems pretty easy, especially when your cofounder wrote the patch) but whether it was in the best interest of the widest group of people, as opposed to your followers on Twitter. This wording almost feels like an ad sneaked in?

(I do also for my own part feel gratitude for the work that went in to the fix, to be clear. And I don’t want to minimize that. Buy sadly other feelings, such as distrust, too.)

5 Likes
117

Yes. Third sentence of the changelog:

However, this can expose authentication data from netrc and URLs to man-in-the-middle attackers.

…

I think it is useful to communicate that we do have a very specific, documented, and semi-automatic process for identifying and responding to security vulnerabilities. That this is specifically part of what our customers and security auditors expect from us. That it is not motivated by wanting to hurt the upstream project.

And, again, I stand by the fact that public information is public, and that it isn’t our responsibility to withhold public information from our customers and users just because we wish the upstream project had a more rigorous process around security vulnerabilities (something that, again, we’re willing, able, and interested in helping improve.)

3 Likes
118

For educational purposes would you be willing to share the runbook for that here? It might be instructive or informative to the community to see how it’s approached by a company in the space; there may be lessons there for us as we formalize and revamp our own security handling procedures.

4 Likes
119

But GitHub - NixOS/nix: Nix, the purely functional package manager is not a Determinate Systems product, and you’re treating it like it is.

Your users here being determinate systems users, and not Nix/NixOS users. That’s the ones I’m talking about. You’re not on the Nix team Nix Team | Nix & NixOS, yet you’re made aware of privileged information (a leak) and tweeting it because your DetSys users are home safe, while security mitigations have yet reached the wider NixOS community, exposing them.

I hope you can see how that can appear as sabotage, someone that isn’t on the Nix team disclosing vulnerabilities they should never have known about, before the Nix team has had time to even publish their security advisor.

And further, seemed that the NixOS contributors where completely unaware of this vulnerability, until around the time determinate systems had rolled out their installer, so it’s equally problematic that you get early security advisors directly from Eelco because you employ him, while nixpkgs is left in the dark and has to react to the public disclosures.

So reiterating:

  • You’re not on the Nix team, but you get priveleged information from your employees.
  • You use this information to patch security issues, and then post it on twitter before nixpkgs has had time to react.
  • You also post priveleged security information you should have never had ahead of the actual security advisor.
  • You and Eelco are aware of security information and will patch your own products without even making nixpkgs aware.

And it’s not surprising you’d be so willing to act in such a irresponsible and frankly hobbyist way, we’ve seen this before with your employee Eelco Dolstra’s undisclosed conflict of interest while being on the board of the foundation. You’ve always put your own business interests over those of the community, while still being in position of power that you have exploited to reach your own financial goals.

At the end of the day, I am a enterprise user, and I feel more safe going with a Nix variant that isn’t compromised by a bunch of opportunists. We are already, somehow, at a point where Lix seems like the more reasonable choice, specially considering how damaging determinate systems influence is to the wider nix projects security efforts, and how you’ve somehow managed to compromise the security of Nix to elevate your own products.

There is also other enterprise users of Nix than determinate systems, and they all gotta exist under similar terms. No one should have an unfair advantage like this.

As I’ve said, terrible open source citizenship all around.

16 Likes