<ckauhaus>
Good morning - I'm about to prepare another vulnerability roundup
<ckauhaus>
wondering if I should continue to cover 17.09 - devs seem not to be particularly eager to fix stuff there anymore, but I know quite a few people who are still using this version
<andi->
mhm, I remember a statement by vcunat that we only provide one(?) month of fixes after a new release. For me it is fine to continue covering it. The problem is probably that people might become lazy and not upgrade anymore ;)
<ckauhaus>
I don't think it would be worth to support more than one release back
<ckauhaus>
lazyness is only one of several reasons not to upgrade quickly
<ckauhaus>
another, possibly more important, is corporate inertness
<andi->
but would you always support one release back and during stabilization of a new release support also the new one? That means up to 4 branches to take care of.
<ckauhaus>
at least I'm sure that it shouldn't be the same people doing all of it
<ckauhaus>
I see that the Hydra build for 17.099 is stuck for more than a month
<ckauhaus>
trying to get it unblocked so that we see at least the fixes which are already present to appear in the channel
fractalcat has quit [Quit: WeeChat 2.1]
ckauhaus has quit [Quit: Leaving.]
<gchristensen>
we shouldn't kill ourselves keeping something up to date for a long time just because
<gchristensen>
some corp or group of corps wants to pay $$$,$$$ to keep it up to date? cool
<andi->
yeah, unfortunately ckauhaus is already gone again :/
<andi->
He never sticks around long (enough)
<gchristensen>
yeao
<joepie91>
gchristensen: perhaps explicitly state this somewhere, alongside "if you'd like to fund longer maintenance, contact us"
<gchristensen>
I think I did, somewhere, at some point, haha :P
<gchristensen>
but yeah that'd be good
<joepie91>
gchristensen: right, I mean in a prominent place like the manual :P
<andi->
Even with fundind I'd try to not advertise that we need funding for OLD releases ;)
<gchristensen>
right, there are higher priority things I'm looking to fund first :D
<andi->
Yep, if there is funding and (those) people need it there can still be an LTSish relesae cycle if they need/fund that
<gchristensen>
just picking a number but I'm not sure we'd want to do an LTS for less than $1M
<gchristensen>
to be able to pay a sufficient # of people for 4 years to maintain some old stuff like that
<gchristensen>
(to be clear, that is a made-up graham-is-cooking-breakfast number)
<andi->
yes, I was also thinking in terms of sponsored people not just money
<gchristensen>
(it could be higher or lower)
<gchristensen>
yeah that would help
<ekleog>
I guess for a lower amount there could be a LTS supporting fewer packages
<gchristensen>
but I think it is important to be guaranteed we finish out the LTS for the entire time
<ekleog>
Like, a LTS without all the graphical packages, for server use
__Sander__ has joined #nixos-security
<gchristensen>
I think the worst outcome is we start a N-year-LTS and then fail to actually do it at any point
<ekleog>
Indeed, NixOS is still not ripe enough to do it imo too
<gchristensen>
yeah
<andi->
ype
<gchristensen>
so we get $1M contractually obligated, and we can probably get it done :)
<gchristensen>
* through multiple co's ideally, so if one pulls out we're probably still ok)
<andi->
I was also thinking about the reduces package set a while back.. not sure how that could potentially work. If someone wnats grafana or whatever that also pulls in lots of X dependencies since whatever feature is able to create PNGs which needs some other lib that needs ...
<ekleog>
Ugh. IMO that's a problem with the way these are packaged, a server shouldn't end up pulling in an X dependency… That's something gentoo got right with use flags (modulo the fact they're quite complex), but I don't really get how eg. debian did it… potentially duplicating relevant libraries into lib-minimal and lib-x?
<gchristensen>
something we will hopefully solve as we grow :D
<ekleog>
If so we could just add (or use?) a parameter to the derivation of the library and set it to “no X” when built as a dependency of grafana, and hydra would end up compiling it twice, but that's the same as debian does
<ekleog>
Do we have a policy currently, about depending on “reduced” versions of the packages, like a reduced dependencies / increased build time ratio?
<andi->
we might also need more versions of various packages with multiple falvors for multiple use cases.. As someone that tries to get some s&*t to build that might not be on your radar and thus slip through.. Maybe an indicator of closure sizes / list of implicit dependencies would be helpful in a PR:
the_real_plumps has quit [Quit: No Ping reply in 180 seconds.]
the_real_plumps has joined #nixos-security
the_real_plumps has quit [Quit: No Ping reply in 180 seconds.]
<joepie91>
ekleog: judging by the crap that apt pulls in when installing mtr, Debian hasn't really "solved" it
<joepie91>
:p
<joepie91>
also, afaik use flags are global?
<joepie91>
(to the system)
<andi->
mtr-nox
<andi->
;)
<ekleog>
On gentoo that depends
<ekleog>
There are global use flags and per-package use flags
<ekleog>
Global use flags are basically a subset of the per-package use flags that have been standardized as “this means that”
spacefrogg has quit [Ping timeout: 245 seconds]
<ekleog>
ISTR some discussion for bringing the same mechanism to NixOS, but it went nowhere (IIRC that was coming from SLNOS, so maybe that's the reason it went nowhere? 😇)
<joepie91>
andi-: that's not really a generalizable solution :P
<andi->
yeah, I see that
<joepie91>
ekleog: I don't really like global settings, but I also don't really like the hard distinction between global and local :)
<andi->
but they are dealing with it that way. THere isn't much they can do about it
<joepie91>
I'd like some sort of scope-esque mechanism
<ekleog>
joepie91: The use of global settings (in gentoo) is to decrease rebuild times
<ekleog>
Like, when you depend on a package, you depend on the package plus some logical function of its use flags
<ekleog>
And if the currently-installed package doesn't match the requested use flags, install of the new package fails
<ekleog>
That's something nix could improve on, by making it possible but hard to duplicate packages with different use flags
<ekleog>
But that starts requiring things that look like SMT solvers at least from far away, so… maybe the simple solution would be better :°
<joepie91>
ekleog: dunno, I'd rather see good introspection tools
<joepie91>
that's really lacking right now
<andi->
it is not the exact match is it a required feature list (as well as anti-features)
<joepie91>
"why is X not like Y" is a question that's difficult to answer in Nix for too many values of X and Y :)
spacefrogg has joined #nixos-security
the_real_plumps has joined #nixos-security
<ekleog>
andi-: Yeah, that's what I called “some logical function of its use flags”, though I don't think that requires a full-fledged SAT solver, because IIRC emerge just spits at your face when the things don't match up, and lets you solve the problem yourself
<andi->
also gentoo thinks on system-level while we can have a multiple packages of the same insatlled
<andi->
"installed" => referenced
<andi->
so for us it is really not the thing to solve "is the currently installed version sufficient" it is more along the lines of "give me a version that is sufficient"
<gchristensen>
+1
<ekleog>
Indeed, I was mostly thinking of this as a way of reducing the rebuilds, because if I have to build two versions of firefox that's going to soon be painful :° (firefox + marionette, for the current instance, I guess this kind of problems would just propagate everywhere)
<andi->
firefox really isn't that bad after you did it 100 times ;)
<gchristensen>
yeah that is something Nixpkgs is explicitly not interested in having -- a massive divergence of package variations
<ekleog>
Oh indeed, if it was possible to look through all the installed packages and figure out a sufficiently featureful version for all the local packages, that'd be great
<andi->
I could really think of "global" (or local for groups) USE flag kind of things that disable say (lib)X11
<ekleog>
gchristensen: IMO the problem is already present at the nixpkgs level, not only at the nixos level, and the fact that environment.noXLibs needs a list of packages with their associated “with*” names shows a lack of support for the feature :/
<gchristensen>
yeah I know
<ekleog>
Just having a nixpkgs-wide “x11Support = *” that sets x11Support through all nixpkgs would already be great (in addition to the proposal by, iirc, ryantm, for standardizing argument names)
<gchristensen>
oy andi- can you ping 2a02:768:2208:ed02::da4 ?
<andi->
gchristensen: no
<gchristensen>
guhhhhhhh
<ckauhaus>
same here
<gchristensen>
that is adding confusion to the routing problems
<andi->
From 2a02:768:2200:6f:da58:d7ff:fe00:7435 icmp_seq=1 Destination unreachable: Address unreachable
<ckauhaus>
8 starnet.peering.cz (2001:7f8:7f::46) 75.798 ms 21.421 ms 21.858 ms
<ckauhaus>
9 2a02:768:0:1979::2 (2a02:768:0:1979::2) 151.91 ms 25.927 ms 25.58 ms
<ckauhaus>
10 2a02:768:2200:6f::1 (2a02:768:2200:6f::1) 26.205 ms 26.162 ms 26.149 ms
<ckauhaus>
11 2a02:768:2200:6f:da58:d7ff:fe00:7435 (2a02:768:2200:6f:da58:d7ff:fe00:7435) 25.79 ms 27.256 ms 25.455 ms
<ckauhaus>
stops somewhere after that
pie_ has joined #nixos-security
__Sander__ has quit [Quit: Konversation terminated!]
pie_ has quit [Ping timeout: 240 seconds]
<andi->
After a bit of playing around with ideas and trying to come up with an simple implementation I finally got an example output out of my tool... https://github.com/andir/nixos-issue-db-example It is a very rough (& early) example.. Suffers from a lot of issues.. e.g. the symlinks are currently absolut and such trivial things.
ckauhaus has quit [Quit: Leaving.]
<ekleog>
Hmm, how would you go to easily see all CVEs for a given eval / to have the equivalent of “nodsa” (ie. “this CVE doesn't deserve the time that would be spent patching it”)? I guess an additional symlink from evals/[channel]/[eval]/[package]/[CVE] to issues/[CVE] could help for the first, and maybe a flat `wontfix` file with a list of CVE IDs for the second?