justanotheruser has quit [Ping timeout: 246 seconds]
Synthetica has quit [Quit: Connection closed for inactivity]
justanotheruser has joined #nixos-security
justanotheruser has quit [Ping timeout: 246 seconds]
justanotheruser has joined #nixos-security
hmpffff has joined #nixos-security
hmpffff has joined #nixos-security
kalbasit has quit [Ping timeout: 276 seconds]
kalbasit has joined #nixos-security
{^_^} is now known as Guest7513
nix-build has joined #nixos-security
Guest7513 has quit [Ping timeout: 252 seconds]
nix-build has quit [Ping timeout: 252 seconds]
pie_ has quit [Ping timeout: 252 seconds]
justanotheruser has quit [Ping timeout: 272 seconds]
justanotheruser has joined #nixos-security
pie_ has joined #nixos-security
tilpner has quit [Quit: WeeChat 2.4]
tilpner has joined #nixos-security
<pie_>
aminechikhaoui, so this vulnix stuff only knows something is insecure if its marked in nixpkgs right? how do you make sure you arent missing tons of vulns on old versions of nixpkgs or somethiing?
<pie_>
just ensuring youre up to date i guess?
<pie_>
im probably misunderstanding how vulnix works. i thought it only shows cves people have added to its database
<pie_>
which sounds kind of limited
<andi->
pie_: vulnix gets a list of derivations, parses them and tells you which of those package versions have known vulnerabilities in the CVE database. (high level)
<andi->
I think it even only checks on derivation of a running system or something like that.
<pie_>
but how does it know what CVEs to look at for a package
<andi->
the NVD XML and JSON files have different classifieres. They list package names and version constraints (<=, ==, >=, …)
<pie_>
(well, i ran vulnix on my system for the first time, "34 derivations with active advisories" ohno.jpg)
<pie_>
aha
<andi->
you basically lookup each package in the XML files and check if any of the classifiers matches
<andi->
afterwards you remove all those issues that have a patch which carries the CVE identifier in it's name.
<pie_>
makes sense
<pie_>
should i be worried that i have 34 results from vulnix
<andi->
it really is very simple.. I was thinking about annotating nixpkgs a few times already. All annotations that you do will be outdates and not very helpful in a short while. They'll give you a list of potential issues that are there. Not a complete list. Also with the automated package version bumps you'll have to check if any of the linked identifiers are still relevant..
<andi->
pie_: well which ones are those? There are many issues that only affect a certain aspect. Making them no less relevant in general but they might not matter for you.
<pie_>
sounds reasonable.
<andi->
ever since I fixed the classification code in broken.sh I am worried about the number of issues on our channels.. I hope I wrote buggy software that flags false-positives.. Unstable has about 1185 issues :/
<pie_>
shouldnt that be solved by the classifiers though? "Also with the automated package version bumps you'll have to check if any of the linked identifiers are still relevant.."
<andi->
18.03 2449
<andi->
pie_: yes but you will have to incorporate that into the automated package updates. I think ryantm is working on that or at lesat trying.. No idea if that work ever started.
<pie_>
i dont see why thats additional work, ..oh do you mean removing patches for things that have been fixed in an update?
<andi->
pie_: well removing patches is usually easy since they do not apply anymore
<andi->
if you start listing issues that are results of current scans then you will also have to "rescan" each package on every bump. Totally doable but not done right now.
<pie_>
ok it probably makes sense i just havent played with this stuff enough to "get" it /o/
<pie_>
bbiab
<andi->
I would totatlly like to see things like the automated package upgrade infrastructure to be less one-man things and more distributed and pluggable.. E.g. providing additional information to the upgrade system without having to move every little piece of code in there. IN a way we have that since we can subscribe to GitHub events... It just takes lots of work and probably some thought. Maybe I'll give
<andi->
it a shot after my current projects are done... Like in never..
<infinisil>
andi-: what do you mean by "providing additional information to the upgrade system"?
<andi->
infinisil: like ask some services for known vulnerabilities (&issues) and annotate/act on thar
<andi->
So if you do an upgrade for a package and there is a bug filed against it it could ask the author to see if the issue is fixed. Or it could cross link them so others see a potential resolution.
<andi->
With the current issue tracker we are severely limited. No way to assign it to a package/subsystem/..
<andi->
So not sure how we would implement that
hmpffff has quit [Quit: nchrrrr…]
justanotheruser has quit [Ping timeout: 258 seconds]
{^_^} has joined #nixos-security
justanotheruser has joined #nixos-security
pie_ has quit [Ping timeout: 252 seconds]
MichaelRaskin has joined #nixos-security
hmpffff has joined #nixos-security
hmpffff has quit [Quit: nchrrrr…]
hmpffff has joined #nixos-security
ma27 has quit [Quit: WeeChat 2.4]
qyliss^work has quit [Ping timeout: 252 seconds]
ma27 has joined #nixos-security
qyliss has quit [Ping timeout: 258 seconds]
qyliss has joined #nixos-security
qyliss^work has joined #nixos-security
pie_ has joined #nixos-security
hmpffff has quit [Quit: nchrrrr…]
copumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
hmpffff has joined #nixos-security
hmpffff has quit [Quit: nchrrrr…]
justan0theruser has joined #nixos-security
justanotheruser has quit [Ping timeout: 268 seconds]