<Synthetica>
hexa-: Seems like it is possible to get early access
<hexa->
we have no real process to deal with embargos anyway
<Synthetica>
True, true, but the maintainer could see if they can get access so that they can test it in advance and push to master the moment the embargo lifts
<gchristensen>
I would rather we not do that, I would not want to start our process of handling embargoed releases without a cohesive strategy to do it properly
<Synthetica>
RFC time?
<gchristensen>
an RFC would be part of it, but to do the security work properly requires a fairly significant investment over a long time
<gchristensen>
well, actually, not sure an RFC does need to be part of it
<lukegb>
sketching things out mentally, I guess it would be a private fork of nixpkgs + modifying hydra to be better at private projects
<lukegb>
because realistically the main thing we struggle with is getting things built
<gchristensen>
the requirements for the embargoed list requires no telegraphing the fact that an embargoed patch exists
<gchristensen>
hydra has sequential IDs
<Synthetica>
Is there anything that actually uses these IDs sequentially rather than viewing them as an arbitrary identifier?
<gchristensen>
it depends
<gchristensen>
are you a person wanting to intuit if a embargoed patch exists?
<lukegb>
gchristensen: that just means we need even more private projects :p
<gchristensen>
lol
<gchristensen>
some work on hydra would need to be done, yeah
<lukegb>
So it's not possible to infer whether it's a security patch or some other random private evaluation
<Synthetica>
Aren't sequential IDs bad practice anyways?
<gchristensen>
only if sequential IDs pose problems for your domain
star_cloud has quit [Ping timeout: 240 seconds]
<gchristensen>
lukegb: I would prefer hydra.nixos.org not be used for private things :)
<lukegb>
It'd be interesting to see if we can expose UUIDs or something instead, but catching all the cases might be hard since so many things do ORDER BY id and we probably want to keep those; snowflake IDs might work instead I guess
<gchristensen>
UUIDs can be hard on indexes
<gchristensen>
anyway
<gchristensen>
yes, this is a super fun technical discussion
<gchristensen>
no, the technical part isn't the hard part :)
<Foxboron>
gchristensen: I haven't forgotten that you wanted a meeting fwiw :x just got lost in my todolist
<gchristensen>
me too :)
<gchristensen>
hell, I've started a company since we talked about that :P
<Foxboron>
D:
<Foxboron>
During COVID! You are a brave person
<gchristensen>
sometimes enough of the pieces fall in to place that you can't not do the thing :')
<Foxboron>
I hope it's working out well for you :)
<gchristensen>
Foxboron: maybe we could resurrect the meeting this week? :)
<Foxboron>
Might be hard for anthraxx. But if you are fine with me loosely explaining the distro-list as an outsider but part of a few embargos directly that is fine :p
<Foxboron>
among the other relevant security stuff
<red[evilred]>
I wrote that, but that wasn'tthe one I was thinking of
<red[evilred]>
it's about the same time period tho
<red[evilred]>
I'll dig around here, I suspect I have a local copy somewhere
<ajs124>
gchristensen: RE: the exim thing. We've already contacted the developers asking what kind of process they expect for a distribution to be granted early access, since we deploy exim and are maintainers of the package. Would definitely be helpful if NixOS had a policy and workflow for this kind of stuff.
<das_j>
gchristensen: The thing I was about to offer was to build and test it in our (internal) infrastructure and prepare a PR that can be merged and built by the upstream hydra once the code is released
<hexa->
how many people have access to your internal hydra though
<das_j>
It's company-internal, so... 6?
<hexa->
thats like 4-5 too many for embargoed stuff
<gchristensen>
yeah, it isessentially a nonstarter
<ajs124>
we wouldn't need to push it to our hydra, necessarily
<gchristensen>
hardware capacity isn't really the issue
<gchristensen>
the problems really aren't techhnical
<das_j>
Yeah, skipping our Hydra is probably a good idea for that
<simpson>
Some of the problems are technical, like sequential build IDs.
<simpson>
But really the problem is social; somebody has to consider one of us worthy to receive secret patches.
<gchristensen>
on a very high level, :)
<hexa->
and such a consideration usually isn't one off
<simpson>
Other distros don't really grok how we build stuff; recall that they usually will have somebody trusted do a rebuild of just the affected packages. Their way of handling embargoes is tightly tied to how they build packages.
<Synthetica>
simpson: And then they just ship that built package as a blob?
<simpson>
On the gripping hand, Nix end users can't receive channel updates without at least receiving hashes for the patches. The *most* that we can do for users is pre-build stuff in Hydra, and that will only help the users who pull the channel within the first X hours of the patch being released, where X is the time Hydra needs to advance.
<das_j>
Synthetica: Yes, I remember that from Arch
<simpson>
Synthetica: Yeah, the 90s were a wild time. You'd literally just download and run whatever Red Hat published~
<Synthetica>
D:
<das_j>
My solution to the Exim situation would be: We find somebody who retrieves the code, tests if it builds (which it probably will because I doubt they will change their build system in a security-relevant release), the person creates a draft PR against nixpkgs (with the final source path that will 404 for now) (ofborg skips that iirc), we merge once we are allowed. No Hydra or anything fancy involved in the process
<das_j>
Test process may be whatever. Run it in a shell, run the nixos test, Run a custom test, whatever
<qyliss>
that sounds to me like it would be even slower than just having it ready to push straight to master when it drops
<das_j>
qyliss: The PR would make it possible to make the change reviewable before it gets merged because once the fix is released we should merge ASAP
<qyliss>
well, if any changes are necessary beyond adding the patch
<qyliss>
given it's a security fix I think that's very unlikely
<qyliss>
(unless they've hinted at it in some way that I've missed?)
<das_j>
(they haven't)
<qyliss>
a major security update coming straight from a developer is not a change that needs to be reviewed in advance IMO
<hexa->
essentially you could save maybe an hour or so if you have the patch in advance
<qyliss>
commit to master first, review later
<hexa->
yeah
<qyliss>
it is highly unlikely that anything is going to go wrong as long as it's been tested to build
<das_j>
I agree on that, yes
<qyliss>
so even getting it in advance is going to save us minutes at best, assuming we can't start building dependents early (which is the case with our current infrastructure)
<qyliss>
and those minutes are totally irrelevant against the hours it takes between channel advances
<ajs124>
exim luckily also doesn't have too many dependents iirc
<qyliss>
yeah, so there's not even that to worry about really
<gchristensen>
distros aim to have critical patches released in 7 days
<ajs124>
as a side-note, 20.09 has the same exim release as master, so the backport should hopefully be trivial
<qyliss>
gchristensen: yeah, and we're most likely going to have it out in hours, despite only getting the patch when the public does
<gchristensen>
right
<gchristensen>
we very often beat distros which have early access to the embargoed patches
<hexa->
indeed
<hexa->
at least on unstable
<hexa->
backporting is a whole other beast, given that we need to notice the security impact
<hexa->
often stuff gets bumped automatically, hence our good track record
<qyliss>
the main blocker to getting fixes out to unstable is the channels getting stuck for unrelated reasons
<qyliss>
that happened with the recent sudo vuln
<qyliss>
but even then it was a few days, not 7
<qyliss>
IIRC
<Synthetica>
Having channels stuck less often should be a goal worth chasing regardless of whether it helps in this specific case
<hexa->
the primary improvement on our security process I can see would be consistency
<hexa->
centrally tracking the state of CVEs in our repos/channels
<hexa->
being able to collaborate on this kind of information
<hexa->
have reports if something is missing
<ajs124>
definitely. would be nice to have any or all of those.
<gchristensen>
https://monitoring.nixos.org/prometheus/graph?g0.expr=((time()%20-%20channel_update_time)%20*%20channel_current)%20%2F%20(60%20*%2060%20*%2024)&g0.tab=0&g0.stacked=0&g0.range_input=22w channel release age in days
<gchristensen>
for the last 22 weeks
<qyliss>
hexa-: repology probably gets us some of the way there?
<hexa->
maybe=
<hexa->
but ideally we would match NVD data with packages on different channels
<qyliss>
if I'm understanding you correctly, repology does that
<Foxboron>
I think "beating" distros in releases isn't a good metric fwiw.
<gchristensen>
Foxboron: I agree
<Foxboron>
A lot more goes into embargos then getting access to patches early. For boothole v2 there was substantial backporting work done by canonical/redhat which other distros collaborated on
<gchristensen>
no doubt
<Foxboron>
(that's more grub with poor releases problem then an embargo thing though :p)
<gchristensen>
Foxboron: I find people have a feeling in their head that we're not at all on top of things, and I mention it to say that we're usually quite fast. I'll find a different way to phrase it :)
<Foxboron>
Well, I haven't managed to do a single advisory this month for Arch :p
<hexa->
we are indeed fast, but lack precision and a clear view of things
<Foxboron>
your github issue stuff is also *very* hard to grok :)
<Foxboron>
speaking from someone being curious if stuff where handle
<Foxboron>
handled*
<gchristensen>
Foxboron: for sure
<gchristensen>
hexa-: and for sure :)
<Foxboron>
Also, alpine came with a tracker yesterday
<lukegb>
Yeah, I'm trying my best to keep channels unstuck fwiw
<lukegb>
nixos-unstable is, unfortunately, wedged at the moment though :(
<simpson>
Foxboron: I would suggest that this is a Goodhart's Law situation: The pragmatic effect of having a small window of vulnerability, compared to other distros, is desirable; but we shouldn't optimize around it, or else we'll end up going down wrong paths in the name of being the fastest distro.
<gchristensen>
+100
<Foxboron>
You are better off having proper tracking and awareness of issues and optimize the few cases where a small window is important.
<Foxboron>
If Arch is lazy with 20 low severity CVEs it's not great, but not terrible. But as long as we handle the important ones properly it's all good. (especially for volunteer work)
<MichaelRaskin>
simpson: I think diversity of priorities in Nix* would save us from Goodhart's law in this instance! (translation: I have a guess which corners would be cut if this goal is pursued and on the balance I support cutting these corners)
<simpson>
Foxboron++ MichaelRaskin++ Yeah, solid.
<{^_^}>
Foxboron's karma got increased to 0b1
<{^_^}>
MichaelRaskin's karma got increased to 53
cole-h has joined #nixos-security
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
mcint has quit [Quit: just do it!!!]
mcint has joined #nixos-security
rajivr has quit [Quit: Connection closed for inactivity]
justan0theruser has quit [Ping timeout: 245 seconds]
supersandro2000 has quit [Quit: Ping timeout (120 seconds)]