I think we need less finger-pointing - in this thread, and in the wider Nix communities in general, tbh.
While the behavior of the reporter may not have been ideal, we cannot control how reporters behave. We can try to influence it, though. The best way to influence it, IMHO, is not to dissect and point out everything they did Wrong™ on a thread they’re not even active in*, or publicly shame them for ‘uncoordinated’ behavior (esp. when it seems there is room for improvement all around). Instead we should see what led to that behavior and see if ‘we’ could have done anything differently to increase the chance of a better outcome. In this case, making sure their concerns are heard and taken seriously, also following up on that earlier GHSA-wf4c-57rh-9pjg report?
(possibly that is already happening, I have no insight in internal communication on either the reporters’ or the Nix teams’ side, this is just based on the information in the linked threads)
*(I appreciate @jade chiming in here, but many posts seem to be commenting on @puckipedia)
We talked a lot to @puckipedia about this in one of our meetings, and what was equally frustrating was Puck’s seeming inability to consider that this was possibly a xkcd: Workflow situation. I insist that empathy around “is it a bug or feature?” ambiguous cases should be extended in both directions.
I apologise, I realise that the Lix teams have users best interests in mind and there was no malicious intent. It’s good to see (from the Fediverse (?) thread) that the two teams are willing to extend co-operation to avoid this happening again.
There’s a difference between “language that is deprecated by industry” and “language used to more clearly differentiate a package manager and a language that otherwise have the same name”
The communication issues in the post-mortem seem identified, and let’s set aside the rabbithole of politics for a moment (regardless of how much it informs threat modeling).
My questions:
What plan, if any, exists for doing another pass through the reported vulnerabilities and making sure nothing slipped through the cracks?
What’s the new policy, if any, around suggested timelines for disclosure?
What’s the new policy, if any, around communication channels? What are the backups, if any, for those channels?
What’s the plan, if any, for coordinating (including public visibility of status if not details) work on vulnerabilities?
Sorry for the Q&A format, but I find it can help with distillation.
I’m not here to point fingers. I can see a lot of places where the ball was dropped and communication broke down between many volunteers (btw thanks volunteers). I want to know, for the next disclosure, do we have processes in place that people can follow so we don’t repeat this again? Do we have something like this? → Vulnerability Disclosure - OWASP Cheat Sheet Series
What I could find is starting from the nixos/nix repo in CONTRIBUTING.md, it points to this policy page, which points back to the security team page on the nixos hompage. And that’s all I could find. Is there anything written somewhere about: what should go into a report, what we ask of reporters, how to keep communication open and ongoing, etc? Can we lift any literature from the OWASP cheatsheet? It seems like a good basepoint.
We’re currently revisiting the two pending reports. I regularly prod those knowledgeable with the technicalities so we don’t lose track.
As of the current state of the update to the procedure, we mainly want to make sure it’s communicated clearly at all. Our availability varies widely, and making predictions of any sort in a volunteer setting doesn’t make much sense.
Unsolicited opinion on volunteering
Where someone gets paid, people from different orgs can’t tell each other what to do, so the result is roughly the same. A volunteer running out of steam trying to convince professionals about something they’re not economically incentivised to do may as well treat the professional like another volunteer. A professional who is not paid to convince a professional from a different org of something may also treat them as a volunteer.
Also in the procedure update PR: Essentially open a common Matrix room instantly. @Mic92 from the infra team volunteered to help with adding a nixos.org email forwarder to the maintainer team as a fallback. But that got stuck at some limitation by the provider – what’s the status there?
We haven’t figured that one out yet, but I think merely being more thorough when communicating with reporters and contributors will do it for now.
Not yet, but I intend to work on that once I get to it. No promises on the timeline though (cf. volunteering).
Regarding Matrix: Yeah, Matrix is not great, but it’s complicated and the issues with Matrix don’t seem central to me here. I don’t know whether the final message by Tom before the disclosure arrived in time or at all, so I can’t tell if that part of the communication breakdown was for technical reasons.
Can’t speak for others, but for better or worse almost all of my Nix-related communication goes through Matrix, so due to network effects it’s convenient enough to suffer the downsides. Being able to instantly talk to almost anyone in the ecosystem is very valuable. So much that using email feels like a downgrade. That said, I had never wanted to use Matrix and still don’t particularly like the experience.
At risk of getting off-topic: the name of the language and the name of the implementation are different things, surely? I don’t think anyone’s proposing forking the language definition or referring to it as anything other than Nix. But regardless of what anyone feels about Lix or any related ‘drama’, tvix has been in the works for ages, so naming things a bit more precisely seems like a reasonable thing to do.
In the event the actual language implemented by alternative runtimes starts to seriously diverge, that would be a reasonable point to get concerned about naming. We’re not there yet though and hopefully won’t ever be.
This actually seems kind of off topic. When people focused on the postmortem stuff (which is currently happening again) everything was slightly more civil. It may be a valid point, but probably not worth interrupting for another one of these prolonged discussions.
I don’t know what happened to the message, and it’s impossible to reconstruct with what I have.
We already have redundant communication channels: Matrix and GitHub Security Advisories. Soon we’ll also have an email forwarder for the whole team. I think that’s alright for now, and there was no discussion to make further changes.
