1. 26
    1. 7

      Here’s their policy: https://oss-security.openwall.org/wiki/mailing-lists/distros

      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 exceptions to this, such as if the publicly accessible fix doesn’t look like it’s for a security issue and not revealing this publicly right away is somehow deemed desirable. In particular, we grant such exceptions to Linux kernel issues concurrently or very recently handled by the Linux kernel security team. In all other cases, 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.

      Definitely sounds like the spirit of the policy allows curl’s practice, but only “occasionally”.

      This is why all the policies I write include the “why”. The rest of that policy has a lot of “why” stuff, like why you need to put something special in your subject line (to combat spam) or why you shouldn’t repost on oss-security (because people are double-subscribed). Seems an agreement could be reached easier if the rules against embargoes on public commits had a “why”, like “because people abuse embargoes which require significant extra work on our part, including hiding our commits” or something like that.

      1. 6

        Sure, but it still sort of sounds like they think they have authority or leverage here. They exist so that software maintainers can do a voluntary thing that helps distros. Also this “we grant such exceptions to Linux kernel issues” kinda sounds like “we realize that if we stuck to this in Linus’s face, he’d have enough pull to just go elsewhere and then we’d be totally irrelevant.” If you have to make an exemption for your biggest user, maybe it’s bad policy.

      2. 2

        I find it weird this article doesn’t mention

        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

        When I initially read it, I was unaware they were redirecting him to a different mailing list. Definitely changes my perspective.

        1. 7

          That’s one that anyone can subscribe to, so there’s no embargo. Posting there would defeat the purpose of hiding security-sensitive commits in plain sight, that’s why Daniel doesn’t want to post there.

    2. 3

      Ok so basically the problem is as follows: fixing security flaws can require patches that are non-trivial, so it’s generally best to have them (unless extremely obvious) in the main repo, so they can be included in all testing infra, fuzzing infra, multiple reviewers, etc. It’s also needed for downstream projects, ports, etc to avoid favoritism issues and similar.

      As a result many OSS projects will commit security fixes to their public repos, maybe with some explicit obfuscation of what is being done, but often times the patches just go through (possibly with neutered test cases). This is not unusual, and is pretty much a requirement for any project that’s primary distribution model is not direct (e.g. people don’t generally download and install curl directly, they get it through their distro, brew, or whatever) in order to avoid distributing patch sets silently and hoping every distro manages them correctly.

      Curl quite reasonably switched to this model, for the above reasons, but when they informed their downstream distro security mailing list a bunch of the distros decided “screw common practice, if a patch for a security fix is available publicly we will publish any vulnerability details you provide us whether or not those details are publicly available, and whether or not updates are available for our users”. So curl now has the option of zero-daying all users, or just those distros that have decided they would like to zero-day everyone. Curl has reasonably decided that they won’t risk these arrogant distros zero daying folk prior to a release actually being available. The result of course is that users of these distros will now be zerodayed, but that is strictly a subset of the user base.

      It’s amazing and bizarre to me that there are distros that apparently decided that making it possible to notify them of upcoming security releases was a benefit for the project, not the distro. The arrogance of their attitude is astounding, as is the incompetence that goes “if there is a patch fixing a flaw in the open, that is the same as full details of a vulnerability”.

    3. 3

      I guess I’m the weirdo who thinks the distros aren’t in the wrong here.

      The curl project seems to want to have security-through-obscurity patches, which I guess, OK, curl can do that if they want to, but it feels like it’s taking a risk. But more importantly, nobody else has any obligation, that I can see, to help them keep the “secret”.

      Or to flip it around and hopefully make the point as clear as possible: if curl wants to notify packagers that a given public patch in the public curl repository was actually secretly a security fix, I think the packagers would be within their rights to handle it publicly, including in ways that disclose to the general public that it was a security fix.

      But my understanding is that curl would not be happy if that occurred, which feels like they want to have their cake (do the patch in public) and eat it too (but bind everyone else to secrecy on what the patch actually did). And curl is basically being told that if they want to have coordinated patching/fixing in private they can have it, or if they want to have public patching/fixing they can have it, but they can’t have the weird “it’s public but also private” neither-one-nor-the-other hybrid they seem to be asking for.