81–89 of 89 posts
I like the idea of having an SBOM as a standard, baked-in feature from the outset. That kind of thing is becoming critical in software supply chain management.
Earlier quoted context omitted.
Do you provide an OVAL feed? Alpine is out of the picture for us because the guy that works on their security tracker just doesn't care, and responds half a year after filing an issue. The tracker itself is broken for over a year and the response was to basically rebuild our own package index and host our own security tracker. So I would not say that Alpine has security as a high priority, even though in theory there…
Probably because "the guy" is not a guy, but who cares, it's easier to just be salty on HN and spread lies about the project.
https://gitlab.alpinelinux.org/ariadne/secfixes-tracker/-/is...
Check response time (in months or years) and also closed issues.
What specifically was a lie in my comment?
Earlier quoted context omitted.
Probably because "the guy" is not a guy, but who cares, it's easier to just be salty on HN and spread lies about the project.
> it's easier to just be salty on HN and spread lies about the project. https://gitlab.alpinelinux.org/ariadne/secfixes-tracker/-/is... Check response time (in months or years) and also closed issues. What specifically was a lie in my comment?
Secondly, the issue you opened was against an internal project used by the security team to do continuous CVE triage of the distribution. It is not meant to be used for public security data. We are tired of security vendors scraping our internal tool, as generating those reports in real time is very expensive on resources.
For public security data, you can use the secdb: https://secdb.alpinelinux.org/
No, it's not OVAL, but we would accept patches to generate an OVAL feed as well.
They could've just improved Alpine's supply chain (or built on top of it) rather than making a new distro :( But they're a company, so pushing out new products faster is more important than the community.
But we heard overwhelming demand for glibc support from customers. So we built a companion distribution for customers who needed to run GNU/Linux workloads, but still wanted to leverage the advantages of Alpine.
Earlier quoted context omitted.
> it's easier to just be salty on HN and spread lies about the project. https://gitlab.alpinelinux.org/ariadne/secfixes-tracker/-/is... Check response time (in months or years) and also closed issues. What specifically was a lie in my comment?
For one, you refer to me as "a guy." I am, in fact, not a guy. Secondly, the issue you opened was against an internal project used by the security team to do continuous CVE triage of the distribution. It is not meant to be used for public security data. We are tired of security vendors scraping our internal tool, as generating those reports in real time is very expensive on resources. For public security data, you ca…
Earlier quoted context omitted.
> it's easier to just be salty on HN and spread lies about the project. https://gitlab.alpinelinux.org/ariadne/secfixes-tracker/-/is... Check response time (in months or years) and also closed issues. What specifically was a lie in my comment?
For one, you refer to me as "a guy." I am, in fact, not a guy. Secondly, the issue you opened was against an internal project used by the security team to do continuous CVE triage of the distribution. It is not meant to be used for public security data. We are tired of security vendors scraping our internal tool, as generating those reports in real time is very expensive on resources. For public security data, you ca…
Regarding the rest: don't call it a security focussed distro if you don't even care about providing the data for vulnerabilities.
If you can't see the constructive criticism I tried to provide in the issues (and pull requests) that I filed then I made a good choice avoiding your distribution ecosystem from now on.
Maybe @dang wants to chime in here to prevent more chan-level escalations.
Earlier quoted context omitted.
As mentioned correctly in [2], DNS issues with musl stem from the fact that it follows the DNS specs strictly and exposed bugs in certain DNS servers. For an HTTP server replying with 200 OK instead of an 404 Not Found upon ENOENT, the situation is clear that this is not a client-side bug. The same should be assumed of DNS/NXDOMAIN.
As much as I agree with your reasoning, I have experienced this kind of breakage first-hand due to cloudflare and DNSSEC and will continue using DNS resolving code that doesn't cause me pain and suffering (anything that isn't musl) because making this work with musl is quite literally out of my control.
[Previous comment](https://news.ycombinator.com/item?id=35058094): ---
My personal 'musl broke it' story comes from resolving domains from Cloudflare that use DNSSEC in a K8 cluster. Basically this:
- K8 sets container to use `ndot:5`, causing the search list to be used
- Musl walks that search list looking for domain
- Cloudflare does not set the NXDOMAIN flag on a DNSSEC domain but does include an NSEC record (if you query with the dnssec flag).
- Musl takes this 'NOERROR' reply and returns an EAI_NODATA.
The issue is that every other libc I tested will continue searching and actually resolve the domain. Musl is the odd one out, and _only_ in the case where the search list ends up with domain using Cloudflare and dnssec.
Even if Musl is 'right' here, when it disagrees with major implementations and a major DNS nameserver does it really matter?
Earlier quoted context omitted.
For one, you refer to me as "a guy." I am, in fact, not a guy. Secondly, the issue you opened was against an internal project used by the security team to do continuous CVE triage of the distribution. It is not meant to be used for public security data. We are tired of security vendors scraping our internal tool, as generating those reports in real time is very expensive on resources. For public security data, you ca…
I'm sorry I did not ask you beforehand about your preferred pronouns. If you want people to use the correct pronoun and it's such a big deal for you, add it to your profiles. Regarding the rest: don't call it a security focussed distro if you don't even care about providing the data for vulnerabilities. If you can't see the constructive criticism I tried to provide in the issues (and pull requests) that I filed then…
The security tracker is a tool for the security team to remediate vulnerabilities.
The data provided by it is not particularly useful nor intended for consumption by people other than the security team and alpine package maintainers: it generates reports for possible CVEs to review and possibly mitigate in the package collection. The presence of data in the tracker that is not present in the secdb (either as an ACK or NAK) is just an indication that there is a vulnerability to investigate, not that anything has been confirmed or denied. Really, the data is not relevant as a product for end users to consume.
The secdb outlines what package versions fix what CVEs, and what CVEs have been formally NAKed. Speculative data from a distribution-wide vulnerability scanning tool is not useful data to be making security-related decisions with.
Earlier quoted context omitted.
As much as I agree with your reasoning, I have experienced this kind of breakage first-hand due to cloudflare and DNSSEC and will continue using DNS resolving code that doesn't cause me pain and suffering (anything that isn't musl) because making this work with musl is quite literally out of my control.
Wait, are you me? I tried to convince musl to not break in this case ( https://www.openwall.com/lists/musl/2022/12/04/1 ), but mostly got a "we're right, cloudflare's wrong" answer. Tweeted at Cloudflare about the issue ( https://twitter.com/KennyMacDermid/status/160055878578481971... ) and never heard back. I really don't care who's right, and can't change who's using Cloudflare+DNSSEC, so instead I just don't use m…
If you hadn't made that HN post I would probably still be scratching my head as to why I have intermittent DNS resolution issues in my personal Kubernetes cluster. I've been having them for years only for some specific software (my mediaserver stack, packaged by linuxserver.io). Since this isn't mission critical stuff I just shrugged it off and dealt with it. Eventually I read your post and it all clicked. I can't find any maintained distributions for that software that don't use alpine/musl sadly so I added[1] dnsConfigs to all of my deployments using musl to force ndots to 1 and accept the fact that all of my cluster name resolution for those deployments will have to be fully qualified. It's a really frustrating situation and made me realize how badly musl plagues the container ecosystem due to its use in Alpine Linux and alpine's popularity because of the small images it produces. Alpine Linux and musl are on my shitlist for life.
1: https://github.com/starcraft66/infrastructure/commit/3b53bb0...