Date: Sun, 15 May 2022 18:27:40 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: linux-distros list policy and Linux kernel Hi, This is a lengthy and belated message, yet I think is something we need to discuss in here. Context: (linux-)distros list policy is generally to treat as public issues for which a fix is public. For issues that haven't yet been brought to (linux-)distros, this means they shouldn't be - and instead should be brought to oss-security right away. For issues that have been on (linux-)distros, this means an oss-security posting is to be made as soon as a fix is made public. This works well for most distros (where releasing a package update generally implies documenting the update's known security relevance at the same time) and for (linux-)distros list interactions with most projects, with the major exception being the Linux kernel. For Linux kernel maintainers, it is customary to post a fix technically publicly but without indication of its security relevance, then work on getting it merged into the various trees, and expect that its security relevance wouldn't be clearly indicated publicly for a while. I didn't keep track of statistics, but my impression was that in the last few years for issues handled with linux-distros involved, the maintainers usually reluctantly accepted linux-distros' way of handling them - didn't insist that the reporter would post e.g. to netdev before a "final" patch is ready, agreed on and honored coordinated release dates, and didn't object to linux-distros members asking the reporter to post about the issue to oss-security on the same day that a posting to a Linux kernel list is made. I was grateful for that, especially knowing that some of this is an inconvenience/overhead for the maintainers. The handling was still often problematic (somehow way worse than for other projects, in my impression), but that appeared to be because discoverers/reporters were not familiar with the procedure and with our expectations, or/and because our policy and thus expectations were counter-intuitive for them (I admit this could mean that we were wrong in having such unexpected policy). This also suggested that many didn't fully read or didn't understand our published policy before posting to linux-distros, which I tried to address by adding clarifications, some emphasized in bold and eventually even in ALL CAPS (not as shouting, but to make these parts less likely overlooked). Somehow it seems to have gotten worse this year. In handling of an issue in February, a reporter planned to ignore our policy after having already shared an issue with linux-distros, and a list member from a major distro tried to enforce the policy. In discussion that followed, a kernel maintainer (someone I have a lot of respect for, and who I think is also on the kernel security team?) said he had directed the reporter to share the issue with linux-distros despite of the reporter's explicit concerns and non-acceptance of the policy, expecting that linux-distros members would be "reasonable" and won't actually enforce the "unreasonable" policy (I don't recall the exact wording used, but that's the gist of it). So it was not a case of something unexpected being overlooked by someone new - it was a case of the policy being deliberately violated by someone very experienced. (Moreover, we also got accused of shouting with the ALL CAPS.) linux-distros members and Linux kernel security team didn't arrive at an agreement on how to handle further issues, planning to bring this up for discussion on oss-security - which I am finally doing now. Meanwhile, the handling was hectic - indeed, people felt discouraged from enforcing the policy. Another kernel maintainer also mentioned he's no longer directing people to linux-distros (which I find more reasonable than coercing/expecting linux-distros not to enforce a published policy). Question: Should we address this incompatibility in desired handling of issues by the distros vs. kernel teams, and how? Options: Off the top of my head, we can do one of: 0. Do nothing specific - let things work or fail on their own. 1. Adjust linux-distros policy to allow "embargoes" on publicly fixed Linux kernel issues. (Only for Linux kernel, not for other projects.) However, besides not posting to oss-security this probably means also not releasing distro kernel updates until the "embargo" is over (when the changes hit a stable tree maybe?), thus exposing most Linux users to vulnerabilities that some attackers can infer from Linux kernel mailing lists and git commits. The current policy: https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters already includes an exception in: "Please note that in case a fix for an issue is already in a publicly accessible source code repository, we generally consider the issue public (and thus you should post to oss-security right away, not report the issue to (linux-)distros as we'd merely redirect you to oss-security anyway and insist that you make the required posting ASAP). There can be occasional (rare) exceptions to this, such as if the publicly accessible fix doesn't look like it's for a security issue (e.g., if the corresponding changes were initially made for unrelated reasons and were only later realized to have fixed a non-public security issue) and not revealing this publicly right away is somehow desirable. You'd have to have very sound reasoning to claim an exception like this and be prepared to lose your argument and if so to post to oss-security ASAP anyway." This currently talks about fixes that are already public at the time of reporting to (linux-)distros, it requires "very sound reasoning", and it allows (linux-)distros to insist that the issue be made public ASAP. In my understanding, the Linux kernel folks want an exception like this also for publicly fixing issues already being handled with linux-distros involved, and to have the exception granted unconditionally with no way for linux-distros not to agree to it in a given case. (Please correct me if I misunderstand.) 2. Strictly enforce the policy as it is - and be in conflict with Linux kernel security team, and handle fewer issues via linux-distros. As a sub-option, also suggest that if a reporter or/and upstream does not accept the policy, they can nevertheless use the list to establish direct communication with interested distros - post a vague message like "I found a [type, impact] vulnerability in the Linux kernel [versions, subsystem], but I don't accept the list policy - please contact me directly if you'd like to receive the details on my terms anyway." Maybe with or without the clarifications I put in square brackets there. 3. Ask that Linux kernel issues not be reported to linux-distros at all. This is unnecessarily limiting compared to option 2 above, but maybe not so conflicting (just not using this specific medium for communication). However, I think it won't work consistently - it would be too unexpected by many (indeed, out of context it sounds plain ridiculous), and linux-distros is referenced in older Linux kernel release trees. More importantly, both teams actually want to communicate on issues somewhere, and there isn't a good alternative currently. 4. Shut down the list. (What about the non-Linux distros list, then?) I need to migrate the setup soon and ideally also update it later, so shutting it down is as simple as not putting more effort into it. It's been around for 11 years. I don't like any of these options. Any other ideas? Any ways to make option 1 more reasonable? Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.