Microsoft employee:

Hi, This is a high priority ticket and the FFmpeg version is currently used in a highly visible product in Microsoft. We have customers experience issues with Caption during Teams Live Event. Please help

Maintainer’s comment on twitter:

After politely requesting a support contract from Microsoft for long term maintenance, they offered a one-time payment of a few thousand dollars instead.

This is unacceptable.

And further:

The lesson from the xz fiasco is that investments in maintenance and sustainability are unsexy and probably won’t get a middle manager their promotion but pay off a thousandfold over many years.

But try selling that to a bean counter

  • NauticalNoodle@lemmy.ml
    link
    fedilink
    arrow-up
    111
    arrow-down
    1
    ·
    7 months ago

    “A failure to plan on your part does not constitute an emergency on my part.” -Someone hopefully working on ffmpeg.

    • Oliver Lowe@apubtest2.srcbeat.com
      link
      fedilink
      arrow-up
      23
      ·
      7 months ago

      “A failure to plan on your part does not constitute an emergency on my part.”

      Wow now that is a quote I’m going to steal. Wondering if “A failure to understand on your part does not constitute an emergency on my part.” has the same punch or is as relevant… anyway, thanks for sharing!

    • milicent_bystandr
      link
      fedilink
      arrow-up
      4
      arrow-down
      10
      ·
      7 months ago

      Does that go for the xz vulnerability too? Wasn’t it a Microsoft dev who discovered that?

      • duviobaz@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        15
        ·
        7 months ago

        In this case, it’s actually Microsofts fault. There is no bug in ffmpeg, Microsoft just didn’t properly use it

      • smb@lemmy.ml
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        2
        ·
        7 months ago

        the xz vulnerability was done through a superflous dependency to systemd, xz was only the library that was abused to use systemd’s superflous dependency hell. sshd does not use xz, but systemd does depend on it. sshd does not need systemd, but it was attacked through its library dependency.

        we should remove any pointless dependencies that can be found on a system to prevent such attacks in future by reducing dependency based attack vectors to a minimum.

        also we should increase the overall level of privilege separation where systemd is a good bad example, just look at the init binary and its capability zoo.

        The company who hired “the” systemd developer should IMHO start to really fix these issues !

        so please hold your “$they have fixed it” back until the the root cause that made the xz dependency level attack possible in the first place has been really fixed =)

        Of course pointing it out was good, but now the root cause should be fixed, not just a random symptom that happened to be the first visible atrack that used this attack vector introduced by systemd.