We have contributed the majority of our improvements in such a way that other APK distributions, including Alpine, can make use of them, and the original plan was to just leverage Alpine for all of this. Indeed, we even sponsored the refactoring of musl's DNS implementation that allows it to support DNS over TCP now.

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.

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 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.

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 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.

We do provide the data for vulnerabilities, at secdb.alpinelinux.org.

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.

that is why the article mentions it as an honorable mention :P

I was only evaluating hardware I actually own. I don’t own any of the PINE64 SBCs or laptops. And while I have a PinePhone, I rarely use it, it sits in my junk drawer basically.

Strictly from a hardware POV. That wasn’t intended to be praise for Apple, but rather an indictment of the industry at large that Apple designed hardware that is easier to extend trust to.

It would, but I don’t have an Unmatched board so I didn’t evaluate it.

Same reason why I did not mention the Pine64 stuff: I don’t own any of it.

Yes, there's several of them. The problem isn't your package, but the distribution of "alpine" images that integrate the package. Those images should describe themselves more appropriately.

+1 for a glibc-based Alpine-ish distribution. a few Alpine folks have made them over the years, but they never gained traction.

Not the same argument. Combining musl and glibc runtimes into a single system is known to result in instability.

Whether it gets documented as part of a "don't do weird things" system or this update gets accepted, it needs to be addressed, as people have erroneously expected this configuration to have the same stability guarantees as stock Alpine.

The problem is the people who use Docker but don't know anything about it. Or don't know that mixing libcs is a problem. They use this glibc package, break their containers and then blame Alpine for the breakage.