• Solemarc@lemmy.world
    link
    fedilink
    arrow-up
    17
    ·
    2 months ago

    Maybe this is a case of hindsight being 20/20 but wouldn’t they have caught this if they tried pushing the file to a test machine first?

      • JackbyDev@programming.dev
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        1
        ·
        2 months ago

        Well, it is hindsight 20/20… But also, it’s a lesson many people have already learned. There’s a reason people use canary deployments lol. Learning from other people’s failures is important. So I agree, they should’ve seen the possibility.

    • Gsus4@programming.dev
      link
      fedilink
      arrow-up
      13
      arrow-down
      1
      ·
      2 months ago

      I saw one rumor where they uploaded a gibberish file for some reason. In another, there was a Windows update that shipped just before they uploaded their well-tested update. The first is easy to avoid with a checksum. The second…I’m not sure…maybe only allow the installation if the windows update versions match (checksum again) :D

    • undu@lemmy.world
      link
      fedilink
      arrow-up
      6
      ·
      2 months ago

      It’s a sequence of problems that lead to this:

      • The kernel driver should have parsed the update, or at a minimum it should have validated a signature, before trying to load it.
      • There should not have been a mechanism to bypass Microsoft’s certification.
      • Microsoft should never have certified and signed a kernel driver that loads code without any kind signature verification, probably not at all.

      Many people say Microsoft are not at fault here, but I believe they share the blame, they are responsible when they actually certify the kernel drivers that get shipped to customers.