2021-11-01 12:25:44 <Ariadne> i would not be opposed to doing that.
2021-11-01 12:25:52 <Ariadne> we need also to finish the move of sudo to community.
2021-11-01 13:05:03 <jvoisin> https://english.ncsc.nl/latest/news/2021/october/29/upcoming-announcement-of-rpki-cvd-procedure ← this is hilarious, security-wise. Since OpenBSD practises full-disclosure, they're excluded from the embargo, about vulns in their software
2021-11-01 13:07:27 <ikke> Similar to our stance
2021-11-01 13:12:59 <Ariadne> not that it matters, anything juicy from those lists always seems to appear in my inbox
2021-11-02 17:33:05 <clandmeter> Ariadne: do you think a security scanner would use rsync protocol to scan packages?
2021-11-02 17:33:28 <Ariadne> most of these scanners
2021-11-02 17:33:33 <Ariadne> just ask apk what is installed
2021-11-02 17:35:08 <clandmeter> we have a host that is using a lot of traffic over rsync over multiple repos
2021-11-02 17:35:25 <clandmeter> doesnt look like normal mirroring
2021-11-03 19:10:12 <ikke> CVE-2021-41174 XSS vulnerability in grafana >=8.0.0 https://www.openwall.com/lists/oss-security/2021/11/03/1
2021-11-03 21:26:57 <Ariadne> exciting
2021-11-03 21:28:37 <ikke> They still happen in 2021
2021-11-04 19:06:03 <Ariadne> clandmeter: weird
2021-11-08 19:30:26 <ikke> https://security.alpinelinux.org/vuln/CVE-2021-32803 seems to only affect the nodejs version of tar
2021-11-08 19:30:39 <ikke> But not sure if we can fix this with a rewrite rule?
2021-11-08 19:45:25 <ikke> I see there is a language rewriter that looks at field 10
2021-11-09 02:13:57 <Ariadne> uhh
2021-11-09 02:14:02 <Ariadne> should be able to
2021-11-10 17:22:57 <ikke> Multiple CVEs: Samba 4.15.2, 4.14.10, 4.13.14 Security Releases are available for Download (https://www.openwall.com/lists/oss-security/2021/11/10/3)
2021-11-10 17:26:09 <ikke> !27321
2021-11-10 17:53:17 <ikke> https://thehackernews.com/2021/11/14-new-security-flaws-found-in-busybox.html
2021-11-10 17:55:08 <ikke> oh, fixed already in 1.34.0
2021-11-10 17:58:20 <ikke> The CVE's have not been made public yet apparently
2021-11-11 08:22:00 <ikke> https://jfrog.com/blog/unboxing-busybox-14-new-vulnerabilities-uncovered-by-claroty-and-jfrog/
2021-11-11 10:44:09 <ncopa> I'm sending an email to busybox about that. I need help identifying the exact commits.
2021-11-11 10:51:07 <ncopa> http://lists.busybox.net/pipermail/busybox/2021-November/089317.html
2021-11-11 15:40:00 <ncopa> so there are 61 patches from busybox 1.33.0 -> 1.34.0. If we cherry-pick them all we should have covered all awk CVEs
2021-11-11 15:40:10 <ncopa> but we also get some new features
2021-11-11 15:40:31 <ikke> as long as they do not break things
2021-11-11 15:40:51 <ncopa> that we dont know. the awk tests passes
2021-11-11 15:41:21 <Ariadne> we could just upgrade everything to 1.34.0
2021-11-11 15:41:40 <ncopa> thats even riskier
2021-11-11 15:41:47 <Ariadne> true
2021-11-11 15:42:08 <ncopa> the 61 patches applies just fine on 1.33 branch
2021-11-11 15:42:31 <ncopa> and from 1.31 -> 1.33 there are only a handful patches
2021-11-11 15:42:43 <ncopa> they also dont touch things outside awk.c
2021-11-11 15:42:49 <ncopa> so its absolutely doable
2021-11-11 15:43:08 <ncopa> (with one exception, with 2 hunks of a function name change)
2021-11-11 15:43:44 <ncopa> what i'm saying is that we can probably upgrade awk up to 1.34.0 level for every supported branch
2021-11-11 15:46:26 <Ariadne> yes, i think that makes most sense
2021-11-11 15:46:35 <Ariadne> but do we want to carry such a large patchset in aports git?
2021-11-11 15:47:08 <Ariadne> maybe we would be better off pulling busybox into gitlab and doing it that way, like i do with gcc
2021-11-11 15:47:33 <ncopa> 245462 bytes patch
2021-11-11 15:48:18 <Ariadne> yes, could do it as a monolithic patch i guess
2021-11-11 15:48:19 <ncopa> even better: we ask upstream busybox to cherry-pick those, and tag new releases
2021-11-11 15:51:08 <ncopa> I'll continue tomorrow
2021-11-12 11:21:07 <ncopa> ok i have backport paches for all busybox versions that we have in our supported branches
2021-11-12 11:23:08 <ikke> Nice!
2021-11-12 11:35:22 <ncopa> only need to cherry-pick for our 3.11-stable branch, and maybe tag new alpine releases
2021-11-12 17:23:53 <jvoisin> https://lists.alpinelinux.org/~alpine/security-announcements ← will this be used at some point?
2021-11-12 17:43:21 <Ariadne> yes
2021-11-16 15:49:09 <minimal> more great news: https://www.theregister.com/2021/11/16/intels_chip_flaw/
2021-11-16 17:28:23 <lzsaver> interesting... are alder lake E-cores affected or not...
2021-11-16 17:29:33 <ikke> It mentions atom, celeron and petium, so I assume not
2021-11-16 17:30:12 <lzsaver> they're atom-based
2021-11-16 17:31:12 <lzsaver> so I cant be sure
2021-11-16 17:31:16 <ikke> hmm
2021-11-16 17:42:29 <minimal> in case you didn't notice, that article links to another AMD + Intel set of issues from last week: https://www.theregister.com/2021/11/12/amd_and_intel_flaws/
2021-11-16 17:43:04 <minimal> and I saw another rowhammer-derivative article today as well :-(
2021-11-16 17:52:55 <lzsaver> https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00528.html
2021-11-16 17:53:45 <lzsaver> well, seems alder lake cpus are not affected
2021-11-17 01:42:40 <minimal> https://www.theregister.com/2021/11/16/github_npm_flaw/
2021-11-17 01:46:21 <ericonr> lol
2021-11-17 05:35:19 <ikke> big oof
2021-11-22 10:31:50 <Ariadne> i wonder if openpam would be a better PAM for alpine than linuxpam
2021-11-24 14:01:30 <jvoisin> Ariadne: https://www.openssl.org/blog/blog/2021/11/24/hiring-manager-and-developer/ "Advantageous, but not required are: […] an ability to write secure code;"
2021-11-24 14:02:54 <ikke> 🤦
2021-11-24 17:40:37 <ikke> !27728 !27729 !27730 !27731 !27732
2021-11-24 20:36:34 <Ariadne> jvoisin: oh they’ve fired another one!
2021-11-24 20:43:43 <Ariadne> jvoisin: in all seriousness, i wonder if they fired their current manager and are planning to do a 180 due to openssl 3.0 being a disaster