<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?)
<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
<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>
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>
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
<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