<ekleog>
I was closing the 18.09 reports, and two things jumped to mind. First, we really shouldn't have let https://nvd.nist.gov/vuln/detail/CVE-2018-11236 live its “still open” life since *end of september*. Second is, how to change that and help us fix most important CVEs first? I'm thinking adding the CVSS scores to the vuln roundups might help, by being one less click to access. What do you think?
<ekleog>
(if you agree then please try with me to remember to raise that idea while ckauhaus is here :))
<gchristensen>
yeah this sort of thing is one reason github issues is a bit weak for this use case
<gchristensen>
adding to the title would almost definitely help
<ekleog>
(on a similar topic, https://nvd.nist.gov/vuln/detail/CVE-2018-11499 is also 9.8, but… am I the only one wondering what a reasonable attack vector for a sass engine might be? I kind of feel like that should be a 8 at most… anyway, just to say that even if we add them [and I'd like to], CVSS are not a perfect score)
<pie_>
well, supply chain attacks are all the rage right? :V
<pie_>
(yeah ok idk :P)
<samueldr>
I don't know how they got to 9.8
<ekleog>
I think it's the Attack Vector: Network that has been… maybe a bit too quickly assessed
<samueldr>
I don't see how it's "network", other than users of the library could be using it in a server
<samueldr>
it's the error handler AFAIUI
<ekleog>
well, my guess is something like wordpress plugins that allow end-user to set their own sass or something
<ekleog>
but it's (hopefully?) so unlikely that… :/
<samueldr>
I can ssh into a box and run hello, is hello now networked?
<samueldr>
kinda fallacious, but kinda not at the same time :/
prometheus_falli has joined #nixos-security
hmpffff has joined #nixos-security
hmpffff has quit [Quit: nchrrrr…]
prometheus_falli has quit [Ping timeout: 246 seconds]
justanotheruser has quit [Ping timeout: 268 seconds]
justanotheruser has joined #nixos-security
<andi->
In response to the discussion about documenting fixes: Please do not just include random meta attributes just yet or non-sensical package version suffixes that just *some change*. I would agree with meta attributes if we had the tooling to clean them up. In general I would prefer annotating patches/changes to the packaging that will then be collected into such a meta atttribute. In contrast to the
<andi->
(currently) common pratice to have the CVE ID in the patch name we could possible also have an (passthru) attribute on each patch that has a list of identifier. In the case the patch doesn't apply anymore (and thus gets removed) we would also remove the hint that we patched something..
<gchristensen>
andi-++
<{^_^}>
andi-'s karma got increased to 16
<andi->
I also second qyliss' request to *not* become debian :)
<gchristensen>
what aspects would you like to avoid?
<andi->
The version number madness. E.g. going with a bazillion backports managed by us whereas as port of the version with fixes and would be more sensible. We do not have to deal (that much) with ABI compat or other packages specifying pkg-foo2.1 as dependency when it can happily use pkg-foo2.3.. So the version string is probably only relevant for nix-env or humans
<gchristensen>
+1
<ekleog>
andi-: OTOH having said bazillion backports is what makes debian one of the leaders on the stability market
<ekleog>
(because every patch has some likelihood of introducing bugs or vulnerabilities)
<ekleog>
(not saying we have the human bandwidth needed to become debian, though)
<gchristensen>
my theory is the power of Nix makes that less valuable
<gchristensen>
keep rolling forward. when you find a problem, isolate & pin, or isolate & fix
hmpffff has joined #nixos-security
<MichaelRaskin>
gchristensen: depends on the package. If the same package needs security fixes and likes to break old configs…
<ekleog>
gchristensen: having to actually act when there is a problem means you need someone to handle stuff, which is exactly what stability avoids the need of
<ekleog>
(there being a problem being the thing stability avoids)
<andi->
Backports require intimate knowledge of the specific application. Would you port random security patches for ghostscript? I am not so sure we have someone with the knowledge and bandwidth to deal with figuring out if the fix would be complete
<MichaelRaskin>
For ghostscript, I have some empirical heuristics to find out whether the fix is complete
<ekleog>
As stated above, I don't think we have the human bandwidth needed to become debian, indeed
<MichaelRaskin>
Constant «No» has pretty good precision
<gchristensen>
MichaelRaskin++
<{^_^}>
MichaelRaskin's karma got increased to 14
hmpffff has quit [Quit: nchrrrr…]
hmpffff has joined #nixos-security
<samueldr>
outside the realm of security, when we are denaturing a package, like grub, with a bunch of backports and fixes upstream won't pick, what strategy should be applied?
<samueldr>
it's "not" vX.Y, it becaus vX.Y+so much more
<samueldr>
it becames*
<pie_>
the fundamental problem is that its hashing an arbitrary set to a single value yeah?
<andi->
samueldr: I have seen people do option version suffixes in nixpkgs. E.g .if a specific feature is activated append that to the version string. It isn't idea and probably could require a bit of tooling to reduce the boilerplate. It is probably better then not documenting those things.
<andi->
The question is if those should in the "default" attribute of a package anyway or if they should be mostly opt-in
<pie_>
random thought since i didnt think about this too much: compressing stuff into a version string based on what you guys said seems ill advised if your goal is to glean any sort of detailed information out of it
<pie_>
seems like the way to go would indeed be some metadata file?
<pie_>
if you want to signal to a user that the package has been modified, a flag in the version sounds like it might be ok? past that it sounds like a mismatch
<pie_>
you could get that information by the presence of the meta file regardless, but a flag in the version string sounds like it would make it more discoverable? alternatively dont put it in the version string but anywhere else thats also clearly visible
* pie_
checks the logs to see how much he missed
<pie_>
ok i guess i didnt miss anything
<pie_>
on a related note, i do think we should work on more expansive metadata conventions and facilities, along with all the other stuff that needs work :P
<pie_>
theres a lot of metadata that we dont have that would be good to have (i didnt collect anything), that we dont have nailed down conventions for including, so we cant really do it
<pie_>
we have .meta, but its theres only a few specified fields
<pie_>
but its an arbirary key value store right? :P could we just put stuff in there and serialize it to a json in nix-support?
<pie_>
i dont know why that would be a bad idea, but if its not, we would have a flexible (?) base convention for storing arbitrary data at that point, and could start standardizing more fields
<pie_>
(Well we could standardize more fields regardless
<samueldr>
other than the module system, we don't have a way to tack a schema, right?
<pie_>
can you rephrase? (comprehension failure)
<samueldr>
if we wanted to better police the `meta` attributes, other than the module system, I don't think there is anything to set types and such
<pie_>
ah
<pie_>
well, i suppose something integrated like the module system would be nice, but merge tooling would also be...a start
<pie_>
samueldr, id be happy if we just started nailing down semantics, the actual implementation cant be so bad?
<pie_>
or rather, what im trying to say is we could just work it manually in the beginning yeah?
<pie_>
provide the means, and then we can work from there
<pie_>
raw fields as an escape hatch and we can build on that
<MichaelRaskin>
I think there already is a module-system-based types definition for meta
<pie_>
i think the licenses field might use something, but idk off the top of my head
<pie_>
(or there was some separate tooling that looked at it?)
<pie_>
im talking a lot - what do you guys think we could do to start some process going?
<MichaelRaskin>
An issue with [RFC] tag in the beginning of the caption, I guess?
<pie_>
ive done that before and something close, and nothing happened :D
<pie_>
though it probably helps to have a concrete implementation idea
<MichaelRaskin>
Well, once you know the opinions of everyone who cared to reply, you can start an RFC…
<pie_>
I should edit this a bit...it's very verbose.
<pie_>
check out these zero replies yo :P
<MichaelRaskin>
If you have no replies, you are justified in writing an RFC as you wish! And then look at the reaction…
<pie_>
i usually want replies because im nearly a blank slate on a given topic and dont know what would be a good direction to go in :/
<pie_>
wanting input from more experienced and smarter people
<pie_>
or just people with different views on the system
<andi->
The amount of text that is preoduced in here /o\ I would like to follow but whenever I open the window there is 30 new lines :/
<MichaelRaskin>
Don't worry, the RFC will have to be rewritten a few times anyway
<pie_>
andi-, sorry, im defnitely noisy :D
<gchristensen>
andi-: I agree
<pie_>
MichaelRaskin, oh no :p
<pie_>
andi-, tl;dr: hashing changes into a version number is not useful for gleaning information from the version. have a "is changed" flag in the version, and expose all metadata via a separate mechanism.
<pie_>
andi-, continued: proposal: we could (finally) start expanding the semantics .meta and just serialize to a json file in nix-support
<andi->
pie creating a desktop notification for each line doesn't help me focus on the topic but thanks :-)