gchristensen changed the topic of #nixos-security to: Vulnerability Roundup Issues: https://github.com/NixOS/nixpkgs/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+Vulnerability+roundup + https://broken.sh
tokudan has quit [Quit: Dunno.]
tokudan has joined #nixos-security
ris has quit [Ping timeout: 240 seconds]
justanotheruser has quit [Ping timeout: 248 seconds]
ivan has quit [Quit: lp0 on fire]
justanotheruser has joined #nixos-security
justanotheruser has quit [Read error: Connection reset by peer]
andi- has quit [Ping timeout: 260 seconds]
ivan` has joined #nixos-security
justanotheruser has joined #nixos-security
justanotheruser has quit [Read error: Connection reset by peer]
andi- has joined #nixos-security
justanotheruser has joined #nixos-security
ivan` is now known as ivan
justanotheruser has quit [Ping timeout: 260 seconds]
justanotheruser has joined #nixos-security
tilpner has quit [Ping timeout: 258 seconds]
tilpner_ has joined #nixos-security
tilpner has joined #nixos-security
tilpner_ has quit [Ping timeout: 258 seconds]
FRidh has joined #nixos-security
zarel has quit [Ping timeout: 258 seconds]
zarel has joined #nixos-security
<flokli> hmm, found https://github.com/NixOS/nixpkgs/pull/77340 and the backport to 19.09. However, the non-binary bundles are still vulnerable
<{^_^}> #77340 (by dtzWill, 1 day ago, merged): tor-browser-bundle-bin: 9.0.2 -> 9.0.3
<andi-> the -bin are oaky, I am always tempted to remove the other ones as nobody seems to really care about them. The SLNOS people sometimes push a change but very irregulary
<flokli> I'd rather ship only the -bin derivation instead of vulnerable outdated ones…
<andi-> If we would drop them I could finally stop adding more hacks to the firefox derivation and remove old stuff...
<gchristensen> anyone have a link to that security vulnerability where a bug in parsing gpg's output caused email clients to email unencrypted mail, whic the user thought was encrypted? (or something like that?)
Synthetica has joined #nixos-security
<qyliss> gchristensen: https://efail.de
tilpner_ has joined #nixos-security
tilpner has quit [Ping timeout: 240 seconds]
zarel has quit [Quit: ZNC 1.7.4 - https://znc.in]
zarel has joined #nixos-security
tilpner_ is now known as tilpner
<flokli> andi-: kill it with fire
<qyliss> The SLNOS ones should definitely go
<qyliss> (firefoxPackages.tor-browser)
<qyliss> they're misleadingly named and I doubt more than one person uses them
<gchristensen> please, somebody
<gchristensen> should I do it and bear the wrath?
<qyliss> I'm not sure about tor-browser-bundle, though. It would be nice if we could provide that from source. And Tor is supposed to be reproducible.
<qyliss> Maybe we can make a commit with 5 people listed as co-authors :P
<gchristensen> hehehe
<gchristensen> sounds good actually
<qyliss> Yeah. Feel free to put me on a commit that drops firefoxPackages.tor-browser.
<qyliss> I think you'd also have to update tor-browser-bundle's longDescription, which tries to clarify the difference.
<gchristensen> it would be a shame to lose a tor-browser, though, right?
<gchristensen> like shouldn't we drop it and re-add it with proper upstream?
<flokli> gchristensen: well, the problem is that we use the firefox expression to build it, and it has a lot of hacks
<qyliss> That's tor-browser-bundle, in theory
<gchristensen> oh I see
<gchristensen> I guess I don't know the scope well enough to author it myself
<gchristensen> :|
<qyliss> I guess I can do it with a co-author
<qyliss> Although it would probably be better coming from somebody who did things with the Firefox expressions
FRidh has quit [Quit: Konversation terminated!]
<flokli> wow, the tor browser situation is even more fucked than I assumed: https://github.com/NixOS/nixpkgs/pull/45787#issuecomment-573119589
<flokli> please, let's not have this that insecure in nixpkgs. These kind of experiments belong to an overlay.
<flokli> ^ andi-, as a firefox maintainer, wdyt?
<gchristensen> ditch *clap* it *clap*
<andi-> nuke it with fire.
<flokli> so, remove for master, mark as insecure for 19.09?
<flokli> who wants to be co-authors? hands up :-D
<gchristensen> ✋
<andi-> firefox-52 is so old we should remove it.. last time I tried to remove an old version someone complained and added it back because $CRAP_IPMI still required it
<andi-> flokli: o/
<gchristensen> ditch *clap* it *clap*e
<{^_^}> #77452 (by flokli, 18 seconds ago, open): firefoxPackages.tor-browser*, tor-browser-bundle: remove
<flokli> if that's in, I'll do a backport PR marking things as insecure there
<flokli> I propose to do the iceweasel and old firefox cleanups in a followup PR
<gchristensen> +1
<flokli> qyliss: gchristensen: adressed your remarks
<flokli> PTAL
justanotheruser has quit [Ping timeout: 258 seconds]
justanotheruser has joined #nixos-security
<flokli> so, with all the torbrowser stuff out of the way, there's still vulnerable firefox-esr-52 and firefox-esr-60 available. some people might want to have an ancient firefox to access crappy IPMI devices, so I understand why they want ONE of them. But what's the deal about firefox-esr-60?
<gchristensen> ditch both
<gchristensen> need an ancient firefox? go get it from 18.09, 17.03, 16.04
<flokli> what's our recommendation for older firefoxes? older nixpkgs checkout?
<flokli> well
<flokli> okay then
<flokli> hmm
<gchristensen> especially since there are ways to get at it, we shouldn't be a dumping ground for ancient and vulnerable software just because for some ill defined, obscure use case
ris has joined #nixos-security
<flokli> icecat is also pretty sad. I understand it's useful, and people like it, but given how badly maintained it currently is (only v52 and v60), it's also bad
<gchristensen> I have less firm opinions on icecat since it is a bit unique, but yeah it isn't great
<flokli> well, I wouldn't complain if it'd somehow track firefox releases and would be somewhat well-maintained
<flokli> as in, being almost on-par with official firefox
<flokli> but `nix-build -A icecat` shouldn't silently give me a v60 one
<gchristensen> yeah
<flokli> (while still not throwing any warning)
<gchristensen> do we have any firm evidence of CVEs against it?
<gchristensen> if yes, let's mark it insecure
<flokli> knownVulnerabilities = [ "Support ended around October 2019." ];
<gchristensen> :)
<flokli> that's what should be there, too
<andi-> I woudl guess it is v60 since they only do ESR releases? Ocotober 2019 was the last day
<gchristensen> do it
<flokli> I mean, fine with building (esr,non-esr) x (firefox,icecat)
<flokli> but for all the other legacy insecure stuff, please just import from an ancient nixpkgs…
<flokli> lol, icecat's latest release is 60.7.0, from 2019-06-02
<flokli> icecat doesn't exist in the debian package database, iceweasel redirects to firefox-esr, ubuntu states there once was a repository, which is unmaintained and gone, and encourage users to just download prebuilt binaries from ftp.gnu.org
<flokli> I'm inclined to mark it as insecure on 19.09 and remove for master.
<gchristensen> maybe start with insecure on both for now
<gchristensen> and revisit in a month
<gchristensen> a bit more politically gentle :P
<gchristensen> (ie: users might notice the insecurity and switch away!)
<flokli> yup, it is most likely affected by CVE-2019-17026 too. icecat is mostly created by running a shellscript patching the latest esr source code release: https://git.savannah.gnu.org/cgit/gnuzilla.git/tree/makeicecat
<gchristensen> cool...
<flokli> and as there's no icecat 68.4.1, it's vulnerable too
<flokli> good grief
<gchristensen> one sec ...
<flokli> last bump on icecat master happened to 60.7.0esr
<flokli> 7months ago
<andi-> do those have a formal maintainer?
<gchristensen> oh yikes, I thought this vuln was specific to much morerecentbugs
<gchristensen> much more recent FFs versions* like it was a regression introduced recently
<flokli> gchristensen: the other firefoxes are out of support as well, and the latest ff releases basically all have been security fixes (including backports for the esr releases)
<gchristensen> yeah
<gchristensen> just saying I didn't realize a FF from 6mo ago (like icecat) was also vulnerable to this specific bug
<flokli> I'd say the formal icecat maintainer is Ruben Rodriguez: https://git.savannah.gnu.org/cgit/gnuzilla.git/log/
<andi-> in nixpkgs?
<flokli> no, "upstream"
<flokli> there are no icecat-specific maintainers in nixpkgs
<andi-> lets just mark all those as insecure
<flokli> yes, will do.
<andi-> we need to clean that up, nixpkgs isn't a dumpster for half-maintained /cared for packages
<gchristensen> preach
<flokli> full ack
<andi-> Now that I can produce firefox{,-esr} in ~25min on my workstation I might also do more work cleaning up the build... remote builders aren't always the best option (-K has to work remotely)
<flokli> andi-: If we agree on directing users for ancient firefoxes because of $reasons to import from an older nixpkgs
<flokli> and can clean up the firefox derivation
<flokli> things might get much more maintainable :-)
<andi-> yes!
<andi-> let me know once you are done with the deprecations, I'll wave them through
<flokli> I also think having a `makeIcecat` boolean on the firefox derivation should be possible
<andi-> please don't
<andi-> not more switches
<flokli> well, not for now ;-)
<flokli> let's first get the number of switches down
<flokli> icecat insecure master: https://github.com/NixOS/nixpkgs/pull/77463
<{^_^}> #77463 (by flokli, 14 seconds ago, open): firefoxPackages.icecat: mark as insecure
<{^_^}> #77464 (by flokli, 9 seconds ago, open): [19.09] firefoxPackages.icecat: mark as insecure
<gchristensen> y'all are doing the good work today
<flokli> gchristensen: I need vacation!
<flokli> :-D
<gchristensen> no kidding!
tazjin has joined #nixos-security
tokudan has quit [Quit: Dunno.]
Synthetica has quit [Quit: Connection closed for inactivity]
tokudan has joined #nixos-security
tokudan has quit [Remote host closed the connection]
tokudan has joined #nixos-security
kleisli_ has quit [Ping timeout: 265 seconds]
<gchristensen> is pango one of those projects which is horendously insecure?
<andi-> why do you think so?
<gchristensen> it is just a feeling
<gchristensen> I don't know or think so, I'm curious if anybody else knows so
<andi-> I think it is insecure in the sense of limited manpower... at least I had the feeling when looking at the contributors a while back
<andi-> and speaking about font foo: https://broken.sh/issues/CVE-2016-5384
<gchristensen> what made me ask is noticing that sway supports <b>...</b> and other pango things in title bars
<andi-> my IRC backlog suggested these for pango: CVE-2018-15120 CVE-2019-1010238
<andi-> > libpango in Pango 1.40.8 through 1.42.3, as used in hexchat and other products, allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via crafted text with invalid Unicode sequences.
<{^_^}> error: syntax error, unexpected IN, expecting ')', at (string):273:10
<gchristensen> ahh
<gchristensen> okay
<gchristensen> pretty good!
<andi-> the other:
<andi-> > Gnome Pango 1.42 and later is affected by: Buffer Overflow. The impact is: The heap based buffer overflow can be used to get code execution. The component is: function name: pango_log2vis_get_embedding_levels, assignment of nchars and the loop condition. The attack vector is: Bug can be used when application pass invalid utf-8 strings to functions like pango_itemize.
<{^_^}> error: syntax error, unexpected ':', expecting ')', at (string):273:42
<andi-> best downgrade to ascii only
<gchristensen> great.
<pie_[bnc]> it does things with strings
<pie_[bnc]> its probably insecure? :P
kleisli has joined #nixos-security
<andi-> does that generalize for all computers?
kleisli has quit [Ping timeout: 258 seconds]