Hi!

I was redirected here to discuss things. I've made some PRs, some merged, some stalled, some pending, some closed. I'm happy to follow process, but I'd also like to be able to productively use my time and Github issues seems like a perfectly reasonable way of working out in the open (and discoverability for Matrix is suboptimal for discussion and decisonmaking when compared with forge tooling).

The PRs in question I'd like feedback on on pushing forward:

• https://github.com/NixOS/nixos-homepage/pull/1587 -- This one is about closing 1511, a pretty straightforward request by somebody ( fricklerhandwerk I think?) to start debloating the community page.
• https://github.com/NixOS/nixos-homepage/pull/1573 -- This one is about trying to figure out how to make security front-and-center on the site as something the NixOS distribution cares about. Currently, it's kinda buried in the community security team page--and working on this has shown that the email alias for security@nixos.org seems to be either busted or have spotty connectivity to the folks on the security team (based on testing). The thing here is that I don't actually know what the security policy should be (though I have guesses) and I'm trying to avoid telling the security folks how to do their job. I was kinda hoping we could workshop the PR and get to a good place with stakeholders (as has happened successfully with, for example, the extensive work on the immich PR).

Thanks!

There's another philosophical question which is: would it be a good idea to put security right on the navbar? My personal bet is yes, because:

• there was a semi-high-profile kerfluffle earlier this year and not having an obvious single touchpoint seems to have hurt there.
• more generally (outside of internal NixOS stuff), one of the hugely useful things about using NixOS is supply chain integrity and other things of interest to security-conscious users.

there was a semi-high-profile kerfluffle earlier this year and not having an obvious single touchpoint seems to have hurt there.

Uh … what?

• download seems important since it's where you get nixos
• values seems important given the last year...after things settle down maybe it could be moved
• community...lots of important stuff there but it's all bunched together (and another PR I put out there to answer somebody's idea would split it into yet another tab, teams)
• blog refers to something that changes...maybe every couple of months?
• donate is important because money
• explore...is a whole thing and I'm not sure learn doesn't already encompass it

back to the security thing, my issues with the current team page are basically:

• it currently reads as "here's information about the security thing", instead of a more directly actionable "if you want to do x, go to y; if you want report z, email w"
• it currently suggests that private reports should go directly to humans (instead of an email alias), which has the obvious problems of "what happens if the human selected is slow to respond for whatever reason?", "what happens if the second person is slow to respond?", "what record exists outside of their email account that yes, indeed, somebody did report an issue?"
• having three different places to look for security is suboptimal--security tends not to be partition tolerant, and if I can't find what I need in the first two places why am I going to spend time on a third?

Of these, the easiest fix is the first--the second requires a bit more coordination and the third would be a big change over on the security team I think. So, I was just trying to pull on the first thread mainly.

I was thinking of a very specific workflow:

• Every incoming initial report goes to security@
• security@ forwards the messages to the currently active team
• security@ forwards the messages to an archive account (or indeed, perhaps could just be the archive account itself)
• team reaches back out over normal channels, cc'ing security

I'm not sure how that would interact with the GPG thing, but I'm also not really sure that GPG is as important as a redundant and auditable comms.