andi- changed the topic of #nixos-security to: Vulnerability Roundup Issues: + | Currently supported releases: unstable (master), 20.09, 20.03 (until 27th of November)
justan0theruser is now known as justanotheruser
rajivr has joined #nixos-security
tilpner_ has joined #nixos-security
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
ris has quit [Ping timeout: 240 seconds]
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #nixos-security
<pie_> guix did some security stuff in the new release xlinked from -chat
<pie_> something about channel authentication, downgrade detection, "authenticating arbitrary git repos" (?), "Another important change from a security perspective that we’re proud of is the reduction of binary seeds to 60 MiB on x86_64 and i686, thanks to tireless work on GNU Mes, Gash, and related software.", "On the same security theme, the build daemon and origin programming interface now accept new cryptographic hash functions (in
<pie_> particular SHA-3 and BLAKE2s) for “fixed-output derivations”—so far we were unconditionally using SHA256 hashes for source code."
<lukegb> pie_: the "arbitrary" part of "authenticating arbitrary git repos" is "where every commit to the git repo is gpg-signed"
<lukegb> it's neat though, it checks commit N-1 for a .guix-authorizations file that contains commit N's signing key
<pie_> ok i figured something like that @ pgp auth, i think git also has some verification stuff built in, i would imagine they base off that, but its nice that they built it into the system
red[evilred] has joined #nixos-security
<red[evilred]> heh, my automation is broken somehow
<red[evilred]> that'll learn me for not sanitizing my inputs ;-)
tilpner_ has joined #nixos-security
tilpner has quit [Remote host closed the connection]
<red[evilred]> found it I think
tilpner_ is now known as tilpner
<red[evilred]> apparently 2090 is problematic: CVE-2090-13584
<red[evilred]> ;-)
pie_ has quit [Ping timeout: 272 seconds]
pie_ has joined #nixos-security
pie_ has quit [Ping timeout: 246 seconds]
pie_ has joined #nixos-security
<andi-> I like how guix manages to write release notes for their package manager :)
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #nixos-security
lassulus has quit [Ping timeout: 256 seconds]
lassulus has joined #nixos-security
justanotheruser has quit [Ping timeout: 272 seconds]
FRidh has joined #nixos-security
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #nixos-security
red[evilred] has joined #nixos-security
<red[evilred]> Well, apparently vcunat thinks I was trying to get something past him. Oh well, RIP that relationship :-/
<red[evilred]> le sigh
<red[evilred]> back to work
<gchristensen> I doubt it
<red[evilred]> I hope you're right. I just forgot to tag something...
<red[evilred]> I'm probably just reading too much into it - his point is fair tho.
<gchristensen> he's surely not going to judge you in to oblivion
<red[evilred]> Good 'nuff
<red[evilred]> you haveing a good day thus far?
<gchristensen> ehhh it is a day :P
<gchristensen> wishing I had a whole team of people! you?
<red[evilred]> I keep telling myself only 4-6 months to normalcy
<red[evilred]> I need to find a way to parse nixexpr in some way
<red[evilred]> so I can extract the list of patches so I can know if patches have already been applied
<red[evilred]> I can't think of an example right now, but when I find a vuln like in zip - repology tells me that version 3.0 is the highest version and what we're currently set at.
<red[evilred]> checking for whether there's a patch that's named after the cve would help speed things up
<red[evilred]> anyways - bbiab - going to put some time into this vuln queue and see what I can find.
<hexa-> how do we handle security for webkitgtk on 20.09?
<hexa-> i'm inclined to update it from 2.28.4 -> 2.30.3
<red[evilred]> I'm scared to ask about the dependency tree on that one
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-security
<red[evilred]> Okay - policy question
<red[evilred]> We have a library
<red[evilred]> botan
<red[evilred]> (1)
<red[evilred]> with 5 CVEs
<red[evilred]> 1.10 series
<red[evilred]> there's a 1.11.x series that will fix 4 of the 5
<red[evilred]> but there is no way to fix the last one (which is of course the nastiest)
<red[evilred]> unless the user moves to 2.x
<simpson> Since the major versions are different, I'm guessing that it's a non-trival port?
<red[evilred]> right
<red[evilred]> its unfixable
<red[evilred]> because - in the words of the project themselves:
<red[evilred]> "Until 2.15.0 there was no API to access these alternative name DNs so it is unlikely that any application would make incorrect access control decisions on the basis of an incorrect DN"
<red[evilred]> So...
<red[evilred]> that "unlikely" is the key word
<red[evilred]> they didn't say "won't"
<simpson> So you're probably thinking of both packaging the 2.x series and also bumping the 1.x series to 1.11.x, because that represents a maximum of options for downstream packages and because fixing 4/5 is pretty decent.
<red[evilred]> 2.x is already packaged as botan2
<red[evilred]> and agreed
<red[evilred]> I'll push that to master
<red[evilred]> for 20.09 - is a move from 1.10.x to 1.11.x acceptable or am I going to be pulling patches?
<red[evilred]> because that;s a long way to go
<gchristensen> seems fine to e
<gchristensen> how much dependn on 1.x?
<red[evilred]> I don't know
<red[evilred]> what's the nix command to list all packages that depend on another?
<gchristensen> just monotone, from a simple grep
<red[evilred]> wait - is there not a cli tool for navigating / querying the dependency tree in nixpkgs?
<red[evilred]> Oh - this is not awesome
<red[evilred]> it looks like the 1.11 branch is the dev version
<red[evilred]> and 1.10 was stable
<red[evilred]> so 1.11 may have been what changed the API and got promoted to 2.x
<red[evilred]> I'm reading the changelogs to verify
<red[evilred]> "Botan 1.10.X is supported for security patches until 2017-12-31" (from the changelog)
<red[evilred]> This may be one of those candidate packages for using the vulnerabilty metadata
<red[evilred]> where it throws an error on compilation unless you specifically accept the CVEs in your configuration
<IdleBot_4fae1f80> I wonder if things covered by CVEs are even used by Monotone… it is annoying that there is still no better VCS (have not looked at Pijul reboot yet)
<red[evilred]> I don't know
<red[evilred]> but since we have... many open vulns
<red[evilred]> a way to prioritize against number of downstream packages might be a useful metric
<red[evilred]> for triage
<hexa-> monotone is essentially dead
<hexa-> last release in 2014, last news in 2011
<gchristensen> don't tell michaelraskin
<hexa-> I deleted the last monotone repo when dn42 moved to git in 2018 ish :D
<hexa-> haha
<IdleBot_4fae1f80> I cannot say there are any changes I was waiting for in Monotone. it is just a thing done right. Well, OK, lack of migration from SHA-1 would be disappointing if «clearly not dead» Git would have completed the same by now
ris has joined #nixos-security
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-security
rajivr has quit [Quit: Connection closed for inactivity]
FRidh has quit [Ping timeout: 240 seconds]
<red[evilred]> I dunno..
<red[evilred]> They don't mention us as a way to get it so ...
<red[evilred]> ;-)
* red[evilred] exercises his playful 'pettiness' gland ;-)
<red[evilred]> (with no element of seriosity)
<red[evilred]> do we know michaelraskin's github id?
<red[evilred]> oh - I guess I can look in maintainers.nix
<red[evilred]> that's a githubid and a half there...
<red[evilred]> hexa- (IRC): Please let me know if #104458 is what you're looking for.
<{^_^}> (by redvers, 3 days ago, open): botan2: update 2.7.0 -> 2.9.0
<IdleBot_4fae1f80> (this is my idling ii instance, I am 7c6f434c)
<hexa-> red[evilred]: same requirements as with the glibc commit message
<hexa-> also I think the commit message is ambiguous
<red[evilred]> Can you help me craft something less so then?
<red[evilred]> the glibc thing I thought was different as I was explicitly pulling a patch
<red[evilred]> oh
<red[evilred]> unless you mean explicitly enumerate what each CVE in the commit message
<hexa-> if you're mentioning them, yeah a quick sentence what the are would go a long way
<red[evilred]> Okay - In the updated on I mentioned each CVE and the versions required to fix it
<red[evilred]> which explained why I chose that version
<red[evilred]> but I can also include what the vuln is more specifically.
<hexa-> CVE-2018-12435: requires > 2.7.0
<hexa-> not sure what requires is supposed to mean
<hexa-> and not sure how that is a description of the cve :)
<red[evilred]> Oh, so instead:
<red[evilred]> to fix the following CVEs:
<red[evilred]> CVE-YYYY-XXXX requires > a.b.c
<red[evilred]> ?
<hexa-> this one looks to be already fixed in 2.7.0
<red[evilred]> one moment... - lemme pull it up
<hexa-> > Bug introduced in 2.5.0, fixed in 2.7.0. The 1.10 branch is not affected.
<{^_^}> error: syntax error, unexpected IN, expecting ')', at (string):435:16
<red[evilred]> I followed what the NVD said
<red[evilred]> it said that 2.7.0 was vuln
<hexa-> can you link that source?
<hexa-> because my nvd link clearly says otherwise
<red[evilred]> cpe:2.3:a:botan_project:botan:2.7.0:::::::*
<red[evilred]> the one you just linked
<hexa-> oh, so mismatch between description and qualifiers
<hexa-> that's a > vs >= mismatch
<red[evilred]> its the word "including"
<hexa-> let's go with what the botan upstream says please
<red[evilred]> the second vuln says "excluding"
<red[evilred]> umm
<red[evilred]> I'm looking at botan's site and it also says 2.8
<hexa-> below 2018-06-13 (CVE-2018-12435): ECDSA side channel
<red[evilred]> oh wait
<red[evilred]> I'm wrong
<hexa-> Bug introduced in 2.5.0, fixed in 2.7.0. The 1.10 branch is not affected.
<red[evilred]> bleugh
<red[evilred]> what a mess
<red[evilred]> so I guess we need to not trust the information that NVD produces?
<hexa-> not distrust, but doublecheck
<red[evilred]> "trust, but verify"
<red[evilred]> ™
<red[evilred]> hah
<red[evilred]> NVD entry is incorrect on the second one too
<red[evilred]> so should I only bump to 2.8.0, or keep going to 2.9.0?
<red[evilred]> What's our bumpage policy?
<red[evilred]> Just to what is needed to fix?
<red[evilred]> or to the latest in the series?
<red[evilred]> I wish whole lot of this was written down
<hexa-> update it the whole way
<hexa-> at least on master
<hexa-> all … the … way!
<hexa-> there are two more security vulns in that thing otherwise
<red[evilred]> sounds good
<red[evilred]> I think I'm just going to focus on master for the next X weeks
<red[evilred]> and let others worry about backporting
<red[evilred]> until I get back around.
<red[evilred]> Okay Hexa - take 76 :-)
justanotheruser has joined #nixos-security
red[evilred] has quit [Quit: Idle timeout reached: 10800s]