Most active commenters

    ←back to thread

    1318 points xvector | 13 comments | | HN request time: 0.842s | source | bottom
    1. Grue3 ◴[] No.19825053[source]
    What kind of idiot thought that the add-ons I have personally installed on my browser need to have a capability to be remotely disabled despite literally nothing being changed.

    This is absolutely inexcusable. I want to see everyone being responsible for this "verified add-ons" fiasco fired from the team (after they roll it back of course).

    replies(7): >>19825074 #>>19825084 #>>19825094 #>>19825120 #>>19825147 #>>19825255 #>>19825358 #
    2. swalladge ◴[] No.19825074[source]
    Exactly. If me/firefox has verified the signature (or approved the download) when downloading or updating the addon, that should be all that's necessary. Why does firefox have to check signatures constantly?
    replies(2): >>19825114 #>>19825160 #
    3. founderling ◴[] No.19825084[source]

        remotely disabled
    
    Were they really remotely disabled? That would mean somebody out there pushed a button and made your add-ons go poof.

    As I understand it, the browser checks the certificate of add-ons at some point (on startup? on an interval?) and only uses signed ones. And since signatures are date restricted, previously valid signatures can become invalid.

    I'm not 100% sure if this really is the mechanism. Would be interesting to hear from someone in the know.

    4. ◴[] No.19825094[source]
    5. egwor ◴[] No.19825114[source]
    in case it was revoked? Seems fairly reasonable approach
    replies(1): >>19825148 #
    6. matthewmacleod ◴[] No.19825120[source]
    How do you verify that nothing has been changed, if not by checking signatures?

    Your call for everyone to be fired is very much in vogue but perhaps not at all useful. This isn’t a great thing to have happened, but the important outcome is, as always, knowledge and process that can prevent similar mistakes in the future.

    replies(1): >>19825231 #
    7. jackewiehose ◴[] No.19825147[source]
    Yes. I mean bugs can happen but this wouldn't be so bad if they had provided a simple way to allow unsigned add-ons in the first place. You can't even create a simple personal add-on for yourself without uploading it to mozilla first. That sucks. Please let me use my computer how I want.
    8. TeMPOraL ◴[] No.19825148{3}[source]
    Disabling with no option of user override is not reasonable. It only creates unnecessary dependency on third parties.

    When product recalls happen, the manufacturer isn't taking your product away by force.

    9. hinkley ◴[] No.19825160[source]
    I worked on a code signing system a number of years ago and it was surprising the degree to which I had to rearrange the logic and the tool chain in order to get high code coverage on all the failure modes.

    IIRC one of the tools wouldn’t let me work with expired certs. I can’t recall now whether I fixed that or made carts that expire in ten seconds and just waited it out.

    Anyway, a number of people weren’t even sure why I was going through the trouble. It’s easier to get something wrong than it should be (super obtuse APIs) and you don’t always get enough support or pushback to get everything absolutely right.

    10. mk89 ◴[] No.19825231[source]
    Standard answer from a person that didn't understand the issue - "who is this bunch of idiots? Fire them all". Sounds like a C*O. :)
    11. mk89 ◴[] No.19825255[source]
    I disagree. Probably what they need is a better monitoring an alerting system that triggers when these certs are expiring. The software did what it was supposed to do -> prevent MITM attacks, fake extensions, etc. What they could have done better is give users the possibility to say "keep using the extensions despite the certificate expiration".
    replies(1): >>19825282 #
    12. ubercow13 ◴[] No.19825282[source]
    The downloaded extensions already passed verification when they were installed before the expiration. Disabling them now makes absolutely no sense. Even if the cert was compromised the moment it expired, previously installed extensions can't have become vulnerable without being updated.
    13. ◴[] No.19825358[source]