1. 27
  1.  

  2. 11

    No mention of the xpi direct link that was posted everywhere? That worked on e.g. Firefox for Android even when studies didn’t? Is there a reason we’re still not talking about this method? Why is it only studies or dot release upgrade?

    1. 3

      I agree that a mention of it would have been nice, but when working at Mozilla’s scale I think it makes sense to focus on only solutions that can be deployed automatically. I doubt even 1% of users clicked on that direct link, or read any of the mozilla communications about the bug.

      1. 10

        The initial communications included “if you’ve turned studies off, turn them back on and wait six hours” which would have been a great place to say “or click this link to install the intermediate cert xpi now”. There’s a peculiar fight club style silence bubble around it.

        1. 2

          I assume they don’t want to teach people to install XPIs from websites other than AMO?

          1. 1

            Although I did read that that xpi was signed by AMO, otherwise Firefox would have rejected it.

          2. 1

            That and how it happened in general as you said on HN. This is really weird for a web company with recent focus on privacy that has hundreds of millions of dollars depending on screw ups like this not happening. I previously speculated that their management barely invests in security vs what they could be doing. They don’t care enough. Adding this to the list.

        2. 1

          I read that solution wouldn’t work on vanilla Firefox, just the unstable nightly builds or something, so I didn’t even bother trying it. Did it work on vanilla Firefox for you?

          1. 1

            This is different then the about:config setting change to disable checking. This is the xpi that the study installed with the updated certs. (Yes, it worked fine.)

        3. 3

          Its more of the stubbon thinking that so many people complained about:

          We can’t really do anything about the last group — they should update to a new version of Firefox anyway because older versions typically have quite serious unfixed security vulnerabilities. We know that some people have stayed on older versions of Firefox because they want to run old-style add-ons, but many of these now work with newer versions of Firefox.

          many APIs still havent been fixed, for 2 years now:

          https://bugzilla.mozilla.org/show_bug.cgi?id=1411795

          leaving any addons based on or using those APIs totally broken with newer Firefox versions. So I will believe the rhetoric when the software backs it up. Until then, Firefox, dont tell me to upgrade when you broke my addons without implementing the API first.

          1. 1

            So the fix here is to build a SAO which does two things:

            • Install the new certificate we have made.

            • Force the browser to re-verify every add-on so that the ones which were disabled become active.

            But wait, you say. Add-ons don’t work so how do we get it to run? Well, we sign it with the new certificate!

            … Lemme make sure I’m not missing anything here…

            1. build an SAO (special add-on)
            2. the SAO installs the new certificate
            3. By the way, the SAO was signed with the new certificate

            Huh?

            1. 1

              The SAO, actually all add-ons, have an attached certificate chain. The root cert is in the browser. Every add-on has an intermediate cert, plus the leaf cert, attached to it.