2021-07-03 21:28:25 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12811
2021-07-04 00:03:23 <Ariadne> will check it when at computer
2021-07-04 00:26:42 <Ariadne> requested CVE for it
2021-07-04 00:26:50 <Ariadne> will update once i have the number
2021-07-04 00:26:57 <Ariadne> maybe alpine should become a CNA
2021-07-04 00:57:28 <danieli> I don't think alpine has the resources for that, and either way, I'm not sure there's much to gain from that for alpine or the public
2021-07-04 00:57:58 <Ariadne> the CNA program is “we give you a block of CVE numbers” that’s it
2021-07-06 15:48:54 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22648
2021-07-06 16:48:47 <ikke> merged
2021-07-19 08:17:26 <Ariadne> i wish security people understood data science :(
2021-07-19 08:39:28 <Foxboron> 
ACTION understands data science :)

2021-07-19 08:40:01 <Foxboron> One of my small projects during my masters was doing an updated ontology of CVE+CVSS, there are a lot of misc stuff out there
2021-07-19 08:46:04 <Ariadne> Foxboron: i mean, i wish that these security database people understood data science :)
2021-07-19 08:46:15 <Ariadne> they haven't "gotten it" yet
2021-07-19 08:46:40 <Foxboron> Indeed
2021-07-19 08:46:48 <Foxboron> But it's also due to the lack of movement from MITRE (IMO)
2021-07-19 08:46:51 <Ariadne> my goal is to leverage JSON-LD (which you don't actually have to use, as long as you do apply the principles behind it) to turn all of this into a global database of databases
2021-07-19 08:47:01 <ikke> I guess they are not paid to "get it?
2021-07-19 08:47:05 <Foxboron> But OpenSSF is having a meeting with MTRE/CVE people next week I believe. It's going to be an interesting discussion
2021-07-19 08:47:13 <Ariadne> yes, OpenSSF gets it
2021-07-19 08:47:16 <Ariadne> because I taught them :P
2021-07-19 08:47:31 <Ariadne> but the OSV folks
2021-07-19 08:47:38 <Ariadne> it hasn't clicked with them yet
2021-07-19 08:47:42 <Ariadne> why URIs need to be first-class
2021-07-19 08:47:52 <Ariadne> I just shared an example that I hope is compelling :)
2021-07-19 08:48:08 <Foxboron> The OSV stuff is annoying. I told them to not make a new schema when they approached the vulndisclosure WG in OpenSSF like... november
2021-07-19 08:48:13 <Foxboron> Contribute to some existing
2021-07-19 08:48:15 <Foxboron> But nooooooo
2021-07-19 08:49:09 <Foxboron> (but then the googlewashing of these efforts enters and suddenly it's the Best Thing Since Sliced Bread™️)
2021-07-19 08:49:45 <Ariadne> the OSV schema is less offensive
2021-07-19 08:49:48 <Ariadne> but still awful
2021-07-19 08:49:55 <Ariadne> because they don't get why URIs need to be first-class
2021-07-19 08:50:05 <Ariadne> and they want to have all semantic nouns in ALLCAPS
2021-07-19 08:50:17 <Foxboron> ._.
2021-07-19 08:50:22 <Ariadne> i really don't get it
2021-07-19 08:50:29 <Ariadne> there's lots of very smart data science people at google
2021-07-19 08:50:35 <Ariadne> i even tried to introduce Oliver to some of them
2021-07-19 08:51:18 <Ariadne> and Oliver is pitching his schema to MITRE as part of that OpenSSF meeting
2021-07-19 08:51:42 <Ariadne> ironically, the CVE board *immediately* got where I was going with the URI-first design concept
2021-07-19 08:51:54 <Ariadne> because the CVE database basically, if you think about it, is just a collection of URLs
2021-07-19 08:52:53 <Ariadne> and kseifried gets it, but at the same time, it hasn't fully clicked over in UVI land yet
2021-07-19 08:53:06 <Ariadne> and thats despite his buddy being a data science person
2021-07-19 08:53:13 <Foxboron> Didn't they discontinue the UVI/DWF stuff now? rebranded again?
2021-07-19 08:53:36 <Ariadne> no, DWF is dead, and UVI is basically "kseifried tries to fix the security industry with JSON-LD"
2021-07-19 08:53:44 <Ariadne> as far as i can tell
2021-07-19 08:53:50 <Foxboron> Yes, but they joined the Cloud Security Allience thingie
2021-07-19 08:53:59 <Ariadne> yeah
2021-07-19 08:54:08 <Ariadne> i mean, basically at the end of the day
2021-07-19 08:54:09 <Ariadne> what i want
2021-07-19 08:54:17 <Ariadne> is a schema that is actually good
2021-07-19 08:54:32 <Foxboron> Ah, the UVI stuff is because of the CSA stuff. Right
2021-07-19 08:54:37 <Ariadne> which basically depends on the OSV team
2021-07-19 08:54:44 <Ariadne> understanding why linked data is good
2021-07-19 08:55:13 <Ariadne> in my ideal world, a security researcher could simply have a list of URIs under an `exploitation_vectors` field
2021-07-19 08:55:26 <Ariadne> and then people looking at her data, could just follow those URIs
2021-07-19 08:55:28 <Ariadne> and find more data
2021-07-19 08:55:40 <Ariadne> all in JSON, all consumable by whatever tooling they use
2021-07-19 08:55:51 <Ariadne> kind of like SBOM
2021-07-19 08:55:57 <Ariadne> but for vulnerabilities and malware
2021-07-19 08:56:23 <Ariadne> and like, SPDX itself is linked data
2021-07-19 08:56:34 <Ariadne> anyway, thanks for entertaining my rant :P
2021-07-19 08:56:58 <Foxboron> ¯\_(ツ)_/¯
2021-07-19 08:57:10 <Foxboron> In my eyes we are just getting more CVE schemas with 0 chance of being standardized
2021-07-19 08:57:25 <Ariadne> i agree
2021-07-19 08:57:40 <Foxboron> Oliver pitching it to MITRE during next weeks OpenSSF meeting is a bit meh since we agreed we'd rather contribute to existing standards, which OSV is not (in practise)
2021-07-19 08:58:10 <danieli> reminds me of that xkcd about competing standards
2021-07-19 08:58:20 <Foxboron> I was contemplating if I should link it or not
2021-07-19 08:58:24 <Foxboron> but we all had it in our minds :p
2021-07-19 08:58:24 <Ariadne> i mean, i'm fine with using an existing standard if it supports linked data :)
2021-07-19 08:58:34 <Ariadne> its the linked data part that is important here
2021-07-19 08:58:36 <Ariadne> not the vocabulary
2021-07-19 08:58:51 <Foxboron> Ariadne: There are N number of standards which could very well be worked with to include it. Now we have another one
2021-07-19 08:59:23 <Ariadne> everyone is talking about vocabulary, when the real thing we need is JSON-LD workflow
2021-07-19 08:59:29 <Ariadne> though
2021-07-19 08:59:37 <Ariadne> i will say the current standards are shit :P
2021-07-19 08:59:49 <Ariadne> or at least, whatever NVD uses
2021-07-19 08:59:51 <Ariadne> is shit
2021-07-19 09:00:03 <Foxboron> And someone is going to claim OSV is shit, work on a new standard
2021-07-19 09:00:09 <Foxboron> It's a neverending cycle, sadly
2021-07-19 09:00:38 <Ariadne> there are others involved in OpenSSF that want to just move forward and get to the linked data part
2021-07-19 09:00:39 <Ariadne> i know
2021-07-19 09:00:42 <Ariadne> i've talked to them :D
2021-07-19 09:01:06 <Foxboron> A lot of people hover around the OpenSSF, not many that actually participates
2021-07-19 09:01:07 <Ariadne> there are far more that have adopted linked data as a buzzword while still wanting to push the same crap we have now :(
2021-07-19 09:01:36 <Foxboron> the buzzword game :p I was suppose to write a rant how "reproducible" have become a poorly defined word because of becomming a buzzword
2021-07-19 09:01:40 <Foxboron> which makes a lot of stuff confusing
2021-07-19 09:02:37 <Ariadne> i agree with ikke btw, i think a lot of these people understand that having proprietary databases are good for their employers
2021-07-19 09:03:13 <Foxboron> Yes, CVE scanners hoarding data and enriching them. But never contribute back to the main sources (read distro security teams)
2021-07-19 09:03:24 <Ariadne> but for us to have truly 'open' security data that is competitive to those proprietary databases, we need to think of the world as a database of databases
2021-07-19 09:03:35 <Ariadne> and that requires something like JSON-LD
2021-07-19 09:04:20 <Ariadne> Foxboron: i have had proprietary security vendors tell me that they use alpine's secdb as a training corpus for their CPE matching :D
2021-07-19 09:04:33 <Ariadne> which is like
2021-07-19 09:04:34 <Ariadne> well
2021-07-19 09:04:36 <Ariadne> that's cool
2021-07-19 09:04:39 <Ariadne> can you give us your model?
2021-07-19 09:05:02 <Foxboron> Nono, you provided it for free! Why should we give you anything?!
2021-07-19 09:05:06 <Foxboron> >:c
2021-07-19 09:05:37 <danieli> if their salary depends on not understanding $thing, they just won't
2021-07-19 09:06:03 <Ariadne> well they should understand that sharing data with us makes them more money
2021-07-19 09:06:12 <Ariadne> since the sooner we patch packages
2021-07-19 09:06:23 <Ariadne> the sooner their CVE scanner can report them as requiring update
2021-07-19 09:06:48 <Foxboron> Extremely silly proposition. Then every CVE scanner would be better, and we'd loose market value as a result!
2021-07-19 09:06:49 <Ariadne> which means their customers will see more value in their CVE scanner
2021-07-19 09:06:55 <danieli> to some, it's not about patching, it's about having better information about vulnerabilities
2021-07-19 09:07:20 <Ariadne> i'm not asking for their information about vulnerabilities, i'm asking for the CPE match data :P
2021-07-19 09:07:40 <Ariadne> though our matcher is not bad
2021-07-19 09:07:48 <Ariadne> better than anchore's ^_^
2021-07-19 09:08:00 <Ariadne> anchore's does not even parse alpine version numbers correctly
2021-07-19 09:09:08 <Ariadne> there's basically two security vendors who have approached Alpine in terms of giving data back
2021-07-19 09:09:20 <Ariadne> Aqua (trivy) and Snyk
2021-07-19 09:10:15 <danieli> that's awesome, i pointed snyk in the direction of alpine a while back, glad they found it at least somewhat interesting
2021-07-19 09:10:50 <danieli> or was it someone else? can't remember the nick off the top of my head
2021-07-19 09:10:55 <Foxboron> Alpine is in a weird position where CVE scanners depend on container scanning thus explicitly depending on Alpine.
2021-07-19 09:11:08 <Foxboron> On the Arch we don't really care about CVE scanners, they are not really relevant
2021-07-19 09:11:12 <danieli> if that's snyk as in snyk.io then nevermind me, but it's still cool
2021-07-19 09:11:21 <Foxboron> or well, container scanning depends on CVE scanning*
2021-07-19 09:11:43 <Foxboron> On the Arch side*
2021-07-19 09:13:11 <Ariadne> well
2021-07-19 09:13:13 <Ariadne> apk-tools 3
2021-07-19 09:13:23 <Ariadne> will have its own CVE awareness
2021-07-19 09:13:25 <Ariadne> :p
2021-07-19 09:13:28 <Foxboron> nice
2021-07-19 09:13:48 <Ariadne> one of the big reasons why we are pushing for structured data as part of apk3 format
2021-07-19 09:15:04 <Ariadne> my goal with apk-tools 3 is that you can do
2021-07-19 09:15:08 <Ariadne> apk list --upgradable --security
2021-07-19 09:15:13 <Ariadne> and get the CVE fixes
2021-07-19 09:15:19 <Ariadne> that you haven't applied yet
2021-07-19 09:15:39 <danieli> so apk will track fixes and not the vulnerabilities themselves?
2021-07-19 09:15:58 <danieli> i was just about to ask about that, just displaying CVEs for package name and version combinations would be somewhat useless
2021-07-19 09:16:26 <Ariadne> yep
2021-07-19 09:16:42 <Ariadne> the plan is to make secdb available as structured data for apk3 to consume
2021-07-19 09:16:50 <danieli> neat
2021-07-19 09:17:02 <danieli> something like a sqlite db and a loadable extension to read it?
2021-07-19 09:18:43 <Ariadne> no
2021-07-19 09:18:50 <Ariadne> apk3 has its own database format
2021-07-19 09:18:57 <Ariadne> designed for structured data
2021-07-19 09:19:05 <danieli> I see
2021-07-19 09:19:06 <Ariadne> it can store any kind of graph
2021-07-19 09:19:16 <Ariadne> so, structured data, filesystems, etc
2021-07-19 09:19:26 <Ariadne> you can also mmap it (mostly useful for indices)
2021-07-19 09:20:36 <ikke> How will that work for other languages that want to read apk data?
2021-07-19 09:20:52 <danieli> hopefully a libapk of sorts that third parties can use
2021-07-19 09:20:58 <Ariadne> libapk is stable now
2021-07-19 09:21:08 <Ariadne> once it comes along a little more, i'll write a python binding
2021-07-19 09:21:20 <Ariadne> there is already a rust binding
2021-07-19 09:21:29 <ikke> Didn't Timo want to prevent others from depending on the internals of libapk?
2021-07-19 09:21:30 <danieli> i already wrote one for the current apk, but didn't polish it enough
2021-07-19 09:21:39 <danieli> (python bindings)
2021-07-19 09:21:56 <Ariadne> ikke: yes, but the ADB stuff will be usable
2021-07-19 09:22:01 <Ariadne> i think
2021-07-19 09:22:22 <Ariadne> so far, anyway :)
2021-07-19 09:24:00 <ikke> And if it's mmapped data, I guess it differs per arch?
2021-07-19 09:24:10 <Ariadne> no :)
2021-07-19 09:24:13 <ikke> ok
2021-07-19 09:24:38 <Ariadne> ADB is endian-safe and type-safe
2021-07-19 09:24:57 <Ariadne> i started to document the format a few weeks ago, i should finish doing so and get that MR to fabled
2021-07-21 13:13:04 <ikke> A nasty linux privilege escalation: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33909
2021-07-21 13:31:16 <danieli> yeah, it's pretty nasty, reminds me a little of the recent netfilter one
2021-07-21 13:31:28 <danieli> pretty sure Ariadne is also aware of that one, it got some attention recently
2021-07-21 13:31:38 <danieli> especially since the associated -33910 is a systemd attack
2021-07-21 13:34:37 <Ariadne> watch the rust people use it as a talking point :)))
2021-07-21 13:37:17 <Ariadne> ok, stupid car is almost done charging, so going to walk around a bit and finish driving to where my grandparents are
2021-07-21 14:04:57 <fcolista> Oh you have an electric car, Ariadne ?
2021-07-21 14:44:27 <danieli> inb4 nobody can compile linux at all because rust can't be bootstrapped
2021-07-21 17:02:36 <kpcyrd> danieli: https://github.com/thepowersgang/mrustc is specifically to bootstrap rustc :)
2021-07-21 17:19:59 <danieli> looks like that's in progress, and i question the maturity and supported targets
2021-07-21 17:20:17 <danieli> right, looks like only x86_64 windows and linux are supported for now
2021-07-21 17:21:53 <kpcyrd> do people actually compile a mips kernel on mips? :)
2021-07-21 17:23:05 <ikke> we do
2021-07-21 17:23:13 <ikke> mips64
2021-07-21 21:03:59 <ikke> proposed new suid program: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23437
2021-07-21 21:04:39 <ericonr1> ikke: fwiw he also just pinged his Void PR for it
2021-07-22 10:45:05 <jvoisin> `please` looks like a bad idea.
2021-07-22 10:48:58 <danieli> I would recommend not changing to `please` as the default sudo/doas alternative - and yeah, I saw the list of CVEs a few months ago after someone had poked around in it
2021-07-22 10:51:33 <danieli> since there are no known vulnerabilities right now (the issues were patched), i wouldn't be against including it as a package, only making it the default escalation/pivoting tool
2021-07-22 11:01:46 <clandmeter> as long we do not have rust on all arches, I guess its not possible at all.
2021-07-23 05:04:21 <Ariadne> we will not switch to `please` as sudo replacement
2021-07-23 05:04:44 <Ariadne> as an aside, "it's X, but memory safe" is not sufficient justification to pass security review for a new SUID package imo
2021-07-23 05:05:17 <Ariadne> i have asked the package maintainer to describe `please` without mentioning memory safety or `sudo`
2021-07-23 05:05:49 <Ariadne> memory safety is not even the main threat for these kinds of programs
2021-07-23 05:05:51 <Ariadne> it is logic error
2021-07-23 05:06:06 <Ariadne> e.g. tricking the state machine into accepting authorization when it should not
2021-07-23 05:06:47 <ikke> nod
2021-07-23 05:07:14 <ericonr-> (though egregious memory safety errors are also costly)
2021-07-23 05:07:31 <Ariadne> anyway, assuming that the maintainer can describe why `please` has advantages over other software, without mentioning "memory safety" (a now largely useless buzzword heavily pushed by the rust team)
2021-07-23 05:07:36 <Ariadne> then i guess we will ACK it
2021-07-23 05:07:47 <Ariadne> but "memory-safe replacement for sudo" is not that
2021-07-23 05:08:45 <Ariadne> last time an informal discussion about this happened, i think `doas` was the preferred pivot tool
2021-07-23 05:08:50 <Ariadne> because it is the simplest one
2021-07-23 05:12:48 <Ariadne> > I am very appreciative of Matthias Gerstner's review. Afterwards the code was clean in SUSE's view.
2021-07-23 05:12:50 <Ariadne> terrifying
2021-07-23 05:15:24 <ericonr> Ariadne: given that the conclusion there was that it wasn't written as suid aware at all, I don't think it was quite a glowing review
2021-07-23 05:15:40 <Ariadne> indeed
2021-07-23 05:17:38 <Ariadne> i am uhh, very not in favor of acking this at the moment
2021-07-23 05:18:00 <Ariadne> https://gitlab.com/edneville/please/-/blob/master/src/lib.rs#L632-637
2021-07-23 05:18:02 <Ariadne> wut
2021-07-23 05:18:40 <Ariadne> if your please config file is more than 10KB it errors out?
2021-07-23 05:18:48 <Ariadne> what if you want to comment things
2021-07-23 05:19:02 <ericonr> lol
2021-07-23 05:19:22 <ericonr> well, that isn't security relevant, just UX
2021-07-23 05:19:22 <Ariadne> oh, 10MB
2021-07-23 05:19:36 <Ariadne> but still
2021-07-23 05:19:37 <Ariadne> why?
2021-07-23 05:19:50 <Ariadne> that itself, no, not security relevant
2021-07-23 05:20:00 <Ariadne> but stupid things like this are not confidence inspiring
2021-07-23 05:20:14 <ericonr> right
2021-07-23 05:20:18 <Ariadne> there's some stage of "being a dev" that people go through where they are overly defensive, but about the wrong things
2021-07-23 05:21:45 <ericonr> we have discussed please in void a bit (https://github.com/void-linux/void-packages/pull/31430 and another PR before that); one conclusion was that shipping someone's very first suid tool wasn't a great idea
2021-07-23 05:21:57 <Ariadne> https://gitlab.com/edneville/please/-/blob/master/src/lib.rs#L918-941 this is just wrong
2021-07-23 05:22:02 <Ariadne> linux-pam is not "linux"
2021-07-23 05:22:07 <ericonr> discussion happened off band, not in the PR itsellf
2021-07-23 05:22:37 <Ariadne> if we used a different PAM, then this code would compile wrong
2021-07-23 05:29:49 <Ariadne> i should ask sheila how her PPA service for alpine and adelie users is going
2021-07-23 05:29:59 <Ariadne> that service seems more appropriate for crap like this :D
2021-07-23 05:42:07 <Ariadne> oh, that file size check is his attempt to mitigate CVE-2021-31153
2021-07-23 05:42:08 <Ariadne> cute
2021-07-23 05:42:11 <Ariadne> but also wrong
2021-07-23 05:43:35 <ikke> How does a file size check prevent file existence disclosure?
2021-07-23 05:45:31 <Ariadne> theres multiple issues under CVE-2021-31153
2021-07-23 05:45:45 <Ariadne> part of the issue is "can run the system out of memory by reading too much data"
2021-07-23 05:45:56 <ikke> ah ok
2021-07-23 05:46:07 <Ariadne> but...
2021-07-23 05:46:11 <Ariadne> its not even fixed anyway
2021-07-23 05:46:18 <Ariadne> Segmentation fault
2021-07-23 05:46:18 <Ariadne> perdition:~$ please -c /dev/vda 
2021-07-23 05:46:46 <Ariadne> please learn how to use stat(2)
2021-07-23 05:52:36 <ericonr> isn't there some rust idiom for reading from a buffer but settig
2021-07-23 05:52:51 <ericonr> ... setting a maximum read size
2021-07-23 05:54:44 <Ariadne> dunno, all i know is
2021-07-23 05:54:54 <Ariadne> asking please to validate my config file /dev/vda makes it crash
2021-07-23 05:55:04 <Ariadne> with overcommit disabled :D
2021-07-23 06:09:13 <ericonr> Ariadne: idk how to read rust, isn't that code always checking if 0 >= bytes_limit?
2021-07-23 06:09:31 <ericonr> bytes is set to 0 before the function is called ...
2021-07-23 06:09:39 <Ariadne> haha even better
2021-07-23 06:09:43 <Ariadne> i think you are right
2021-07-23 06:12:35 <ericonr> and L645 should be using == unless .take(byte_limit) somehow takes more than byte_limit, but that's a minor nit
2021-07-23 06:13:04 <ericonr> unless it can actually do that and it's what caused your segfault?
2021-07-23 06:13:28 <ericonr> that would make rust stdlib "very bad"
2021-07-23 06:24:28 <Ariadne> no, it crashes before it gets to that code
2021-07-23 06:24:42 <Ariadne> it checks bytes >= byte_limit after already reading i think
2021-07-23 06:24:52 <Ariadne> but to read 50GB at once, you need to store 50GB
2021-07-23 06:24:57 <Ariadne> rust can't "solve" that
2021-07-23 06:32:53 <Ariadne> whatever i don't really care about this :D
2021-07-23 06:32:58 <Ariadne> i told him to fix this correctly
2021-07-23 06:33:03 <Ariadne> and then we can re-review
2021-07-23 10:08:38 <ikke> Ariadne: Maybe we should formalize security review policies 
2021-07-23 10:08:48 <Ariadne> probably
2021-07-23 10:10:13 <Ariadne> but either way, those policies should be formalized in a way that does not favor the inclusion of new SUID packages
2021-07-23 10:11:10 <Ariadne> and, AFAIK, the conclusion prior to formation of the security team was that we wanted to prefer `doas` for pivot tool
2021-07-23 10:12:37 <ikke> yes, absolutely, but that does not necessarily preclude alternatives 
2021-07-23 10:13:14 <Ariadne> it does when the author clearly doesn't know what they're doing :p
2021-07-23 10:13:42 <ikke> yes, but that's a separate issue :)
2021-07-23 10:13:44 <Ariadne> i think we should have some level of confidence in SUID programs
2021-07-23 10:14:15 <Ariadne> but, yes, we should work on an actual SUID policy
2021-07-23 10:14:48 <Ariadne> that way, there's something to point to
2021-07-23 10:14:59 <Ariadne> instead of "your program sucks lol"
2021-07-23 10:15:58 <ikke> I'm also thinking we should move sudo to community
2021-07-23 10:16:19 <Ariadne> yes, seems reasonable, but i think we should refer that issue to the TSC as a system change
2021-07-23 10:16:34 <ikke> ahuh
2021-07-23 10:16:34 <Ariadne> because that one is going to be one that people complain about
2021-07-23 10:16:54 <ikke> But sudo does not get 2 years support
2021-07-23 10:17:02 <Ariadne> yes
2021-07-23 10:17:17 <Ariadne> but if we move it, people will complain
2021-07-23 10:17:23 <ikke> I know
2021-07-23 10:17:28 <ikke> But we can at least propose it
2021-07-23 10:17:36 <Ariadne> so i think "the TSC decided it" looks better
2021-07-23 10:17:43 <Ariadne> yes
2021-07-23 10:18:02 <ikke> Reminds me, I should commit the minutes of the last meeting and create issues
2021-07-23 10:19:58 <Ariadne> should we file system change proposals in the TSC repo, or maybe make one specific for system change proposals?
2021-07-23 10:20:21 <ikke> New issue for each change is easier to handle
2021-07-23 10:20:59 <ikke> Otherwise we would need to look into issues to see if there are new proposals
2021-07-23 10:26:11 <Ariadne> done: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/1
2021-07-23 10:26:15 <Ariadne> can you tag it etc
2021-07-23 10:26:21 <ikke> yes
2021-07-23 10:29:04 <ikke> Only community dependencies, so that's good
2021-07-24 07:23:52 <ikke> libxml2 still lacks backports to CVE-2021-3541
2021-07-24 07:24:06 <ikke> I tried to upgrade it, but there is ftbfs
2021-07-24 07:25:23 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/444733
2021-07-24 07:25:52 <ikke> Seems autoconf related:  fatal error: fuzz.h: No such file or directory
2021-07-24 07:47:40 <Ariadne> make V=1
2021-07-24 07:55:59 <ikke> huh, it build if I run it manually, let me try it with abuild again
2021-07-24 07:56:46 <ikke> or is V=1 supposed to fix it?
2021-07-24 07:56:57 <ikke> I thought it's just to give verbose output
2021-07-24 07:57:49 <ikke> ohh, it's check that's failing
2021-07-24 07:59:32 <ikke> seems like it's trying to build the python part in the check phase
2021-07-24 08:02:50 <ikke> gcc -DHAVE_CONFIG_H -I. -I..  -I../include -Os -fomit-frame-pointer  -Os -fomit-frame-pointer -g -MT genSeed.o -MD -MP -MF .deps/genSeed.Tpo -c -o genSeed.o genSeed.c
2021-07-24 08:02:55 <ikke> -I.. is there
2021-07-24 08:03:30 <ikke> why does it still not find fuzz.h
2021-07-24 08:04:48 <ikke> oh, there _is_ no fuz.h, I thought I saw it
2021-07-24 08:10:15 <ikke> fuzz.h is in the source here https://gitlab.gnome.org/GNOME/libxml2/-/tree/v2.9.11/fuzz
2021-07-24 08:19:30 <ikke> so why would fuzz.h be missing from the archive :/
2021-07-24 08:37:19 <Ariadne> weird
2021-07-24 08:39:12 <ikke> ahuh
2021-07-24 08:39:28 <ikke> I'm not trying to just disable these fuzz tests 
2021-07-24 08:39:39 <ikke> but in a way that I don't need autoconf/make/libtoolize
2021-07-24 08:40:09 <ikke> not sure if possible
2021-07-24 08:41:20 <Ariadne> you'll need them
2021-07-24 08:41:23 <ikke> ok
2021-07-24 08:41:26 <Ariadne> automake will want to rebuild
2021-07-24 08:41:56 <ikke> yes
2021-07-24 08:44:21 <ikke> still managed it :D
2021-07-24 08:51:13 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23512/diffs?commit_id=0dae013ba4ef9c727fca55bcd932a0569c905fbc
2021-07-24 10:12:59 <ikke> apparently they fixed it in .12, which I missed
2021-07-24 11:13:45 <Ariadne> in other news, a ton of new CVEs have been found in please ^_^
2021-07-24 11:14:20 <ikke> 🤔
2021-07-24 11:15:23 <Ariadne> what can i say, other people looked at it too because they were curious
2021-07-24 11:15:57 <ikke> Is it anounced somewhere?
2021-07-24 11:16:47 <ikke> Ariadne: why did 3.13-stable disappear from https://security.alpinelinux.org/vuln/CVE-2021-3541 
2021-07-24 11:16:57 <Ariadne> soon :D
2021-07-24 11:17:05 <ikke> Ariadne: ok :)
2021-07-24 11:17:14 <Ariadne> no idea why 3.13-stable disappeared
2021-07-24 11:17:23 <Ariadne> is the secfixes data present
2021-07-24 11:17:25 <ikke> yes
2021-07-24 11:17:47 <Ariadne> weird
2021-07-24 11:17:54 <Ariadne> i'll see if i can reproduce on my local instance
2021-07-24 23:38:36 <Ariadne> “this is a terrible package” — friend of mine at NSA on please
2021-07-25 00:42:33 <danieli> let people shoot themselves in the foot if they want to, as long as it isn't made the default privilege escalation/pivoting tool
2021-07-25 10:08:36 <Ariadne> danieli: oh i was just remarking that everyone who looks at it finds it to be awful
2021-07-25 10:08:37 <Ariadne> :D
2021-07-26 13:20:27 <ikke> I guess we need to still backport the apk-tools secfix?
2021-07-26 14:02:59 <fabled> ikke: i have made apk-tools releases for old stable branch too. i was just thinking to wait a bit before abumping the stable aports
2021-07-26 14:03:11 <ikke> fabled: makes sense
2021-07-26 15:55:55 <ikke> Ariadne: what should we do with secfixes for vulnerabilities that were never in aports?
2021-07-26 15:56:07 <ikke> I bet security scanners would still flag it
2021-07-26 15:56:35 <ikke> although, if it has an up-to-date version, it should not matter
2021-07-26 15:56:41 <ikke> n/m
2021-07-26 23:24:26 <Ariadne> ikke: https://gitlab.alpinelinux.org/kaniini/security-rejections
2021-07-27 10:54:04 <Ariadne> re #12874, i think that there is not any serious security problem
2021-07-27 10:54:16 <Ariadne> we will just wait for upstream to fix it
2021-07-27 10:54:22 <Ariadne> and then maribu can upgrade
2021-07-27 10:55:22 <ikke> ahuh
2021-07-27 10:55:44 <ikke> I did wonder about the redistributed jars, though
2021-07-27 10:56:45 <Ariadne> i'm not a fan of that
2021-07-27 10:56:50 <ikke> right
2021-07-27 10:56:54 <Ariadne> but, any battle involving the TeX community is, well
2021-07-27 10:56:59 <Ariadne> not really worth having tbh
2021-07-27 10:57:01 <ikke> heh
2021-07-27 11:19:43 <danieli> christ, that's far too warm for me
2021-07-27 11:19:49 <danieli> oops, wrong channel hahaha, my bad
2021-07-27 17:42:59 <ikke> I don't think this is correct: https://git.alpinelinux.org/aports/commit/?id=6712e09e0f7d
2021-07-27 17:43:07 <ikke> That's what I mentioned earlier
2021-07-27 19:45:35 <Ariadne> well
2021-07-27 19:45:44 <Ariadne> thankfully,
2021-07-27 19:45:48 <Ariadne> we can ask powerdns :P
2021-07-27 19:46:05 <Ariadne> but secfixes is supposed to be the version in which we fixed it
2021-07-27 19:47:18 <ikke> > 4.5.1 is a security release, fixing a bug present only in 4.5.0. 4.5.0 was never in aports, so I did not update the secfixes list.
2021-07-27 19:47:31 <ikke> from Peter van Dijk
2021-07-27 19:47:37 <Ariadne> in this case, i don't think that we need to record it
2021-07-27 19:47:50 <ikke> yeah, me neither
2021-07-27 19:47:56 <ikke> but I guess it's not clear to everyone
2021-07-27 19:48:05 <Ariadne> but i don't think it harms anything to record it
2021-07-27 19:48:06 <ikke> It seems btw that CVE is still classified
2021-07-27 19:48:59 <ikke> No external references
2021-07-27 19:50:09 <Ariadne> :D
2021-07-27 19:50:22 <Ariadne> i enquired about alpine becoming a CNA btw
2021-07-27 19:50:27 <Ariadne> we will see what they say
2021-07-27 19:50:30 <ikke> Yeah, I read it
2021-07-28 11:49:29 <ncopa> seems like alpine 3.14 does not show up in this list: https://security.alpinelinux.org/vuln/CVE-2021-31535
2021-07-28 11:57:38 <ikke> <=1.7.1
2021-07-28 11:57:43 <ikke> seems like 3.14 is not vulnerable
2021-07-28 12:07:02 <ncopa> i'd like to see 3.14 in the "fixed" list
2021-07-28 12:09:03 <ikke> It would show up if you add secfixes to 3.14, but that also implies that 3.14 was vulnerable, which is not the case
2021-07-28 12:26:52 <danieli> yeah, usually those vulnerable are listed, not the versions that aren't
2021-07-28 12:45:58 <ncopa> the reason im interested in it is that we relatively frequent get issues from someone claiming that alpine is vulnerable to a given CVE. for example: https://github.com/alpinelinux/docker-alpine/issues/187
2021-07-28 12:46:15 <ncopa> https://github.com/alpinelinux/docker-alpine/issues/191
2021-07-28 12:46:33 <ncopa> https://github.com/alpinelinux/docker-alpine/issues/190
2021-07-28 12:46:57 <ncopa> would be great to be able to point them to some url that shows that we have fixed them or are not vulnerable
2021-07-28 17:32:19 <Ariadne> we can add not-vulnerable state
2021-07-28 17:33:01 <ikke> yeah, I was thinking the same
2021-07-28 17:33:17 <ikke> How would it know that's the case, though?
2021-07-28 17:55:14 <Ariadne> if the CPE rule does not match
2021-07-28 17:55:30 <Ariadne> sorry i was carefully composing an email :P
2021-07-28 19:51:11 <ikke> "The Linux kernel for powerpc since v3.10 has a bug which allows a malicious KVM guest to corrupt host memory."
2021-07-28 19:52:58 <Ariadne> :D
2021-07-28 19:53:13 <Ariadne> quick!  while we're still on cloud
2021-07-28 19:53:17 <Ariadne> haha just kidding
2021-07-28 19:53:19 <ikke> hehe