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.
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.
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.
The only reason I took any position at all on this issue is because other partners in the Alpine / Cloud Native ecosystem requested that we clarify our position on mixing musl and glibc runtimes.
You ignore the point I am making: people are already fighting this issue for years, and Alpine has not taken a position on it until now.
We should have done so sooner, but unfortunately we did not, so a more theatric approach is sometimes needed to make a point.
We want to discourage bad practices in the creation of alpine-based images, so that our partners (such as the Docker library team) do not have to deal with user complaints with images, or feel like companies are bullying them into accepting images they know are built with bad practices.
If you call taking action to provide assistance requested by our ecosystem partners (who have been thrilled that we are putting our foot down by the way) toxic behavior I wouldn’t want to know what your idea of a party is to be blunt.
The issue is not the package. Obviously Sasha is allowed to publish whatever packages he wishes.
The problem is that third parties take his package and then describe the combination of Alpine with his package in such a way that people are led to believe is totally stock Alpine.
This then causes many people to complain in Alpine support channels, or on websites like this one, that Alpine is "buggy" in ways that cannot be reproduced on real Alpine.
You also assume that this is our first reaction.
Our first reaction was 6 years ago when it first came out: meh.
No, this is our first reaction to a large company trying to pass off their hackjob images combining Alpine, glibc and a glibc JDK as a certified JDK that is running on stock Alpine.
It is unfortunate that we have waited this long to put our foot down, honestly!
We need to support our friends in the Docker community who manage the Docker Library who also get to deal with the fallout of these hackjob images.
The person who makes the hackjob rarely faces the consequences of it breaking, that basically has always fallen on us, or on the Docker Library team, or on some other team in the ecosystem that has to deal with somebody who is mad because their application has failed due to some shoddy work done by somebody 2 years ago.
Stop assuming this is our "first" reaction. It isn't. I even said it wasn't to begin with -- a "first" reaction cannot logically be an escalation from a previous position, it must be an initial one.
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.
I was not aware that publicly setting boundaries on what is a supportable configuration and what wasn't one was somehow equivalent to white nationalist syndicalism, but thanks for letting me know.
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.
The `dnsfunnel` resolver has been added to Alpine to solve that issue. Additionally, musl will gain TCP support for situations like DANE where individual records may be very large.
We did not communicate with Sasha because bluntly, we have no objection to the existence of this package itself, but rather third parties distributing the combination to others without disclosing the many caveats about it.
Sasha's package is not the problem, it is the third-party distributors who distribute the final result as an "alpine" image, which leads people to believe that everything is legit about it.
I am proposing that we encode something that is already factually accurate: glibc and musl generally do not mix in any way that results in a stable system.
Do you not think that distributions should make even a little bit of effort to introduce friction toward scenarios known to break systems?
If apk-tools had a soft conflict option, where it printed a warning and required the user to acknowledge that warning somehow before continuing, that would also solve the issue as far as I am concerned, but it does not have such an option at this time, and we need to put our foot down sooner rather than later.
Edit: besides, nothing has been implemented. This is just one proposal, the point of having a conversation is to determine what the best option for solving this issue is.
correct: we do not want to get stuck with having to deal with angry people who have unstable environments caused by this.
and, the conflict option is one of a few options being considered. part of what lead up to this is the fact that we have not taken any public position on mixing glibc and musl runtimes until now.
no decision has been made, and won't be made until the TSC meeting next week...
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.