Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical Details on the Recent Firefox Add-On Outage

hacks.mozilla.org

Post reply on HN
Print view View original

121–130 of 279 posts

Re: Technical Details on the Recent Firefox Add-On Outage

#121

Post by SAI_Peregrinus »

johncolanduoni wrote: post #102
StavrosK wrote: post #79

Earlier quoted context omitted.

Can you explain why you need the current time anywhere in this? Say I download a ten-year-old addon, it's signed by a valid signature from that root, with a valid signing date. What's the problem? Are we worried that someone will steal an old/expired cert and have control over a user's clock?

Not current time, but time of signing of the executable (not signing of the code sign certificate itself). If you (as the OP suggested) use time of signing instead of current time, the whole point is you’re not using the user’s clock anymore.

Mozilla is already packaging the executable inside an archive. That archive contains the executable, manifest, and any other needed files. The signer can add a timestamp, either as a new file or as a part of the manifest. Then the timestamp is signed along with everything else, and can be checked for validity.

Re: Technical Details on the Recent Firefox Add-On Outage

#122

Post by silversconfused »

ghostly_s wrote: post #73

If anyone's wondering if this answers the Actual Question of why the cert was allowed to expired, don't waste your time, it doesn't. I guess implicitly that's a "social detail"?

I really don't get why everyone thought putting dead-man-switches ON EVERYTHING was a good idea. Boils my blood thinking about it. So wasteful. Such disrespect for the future. But hey, security. Can't argue with that!

Re: Technical Details on the Recent Firefox Add-On Outage

#123

Post by silversconfused »

kbrosnan wrote: post #120
drtillberg wrote: post #101

The Firefox update required an administrative login in my windows system at work, which I don't have have. Normal updates haven't required that. So far I've just left it broken and it keeps prompting me for an administrative login on launch. The article doesn't explain why elevated privileges are required to apply the update.

Does the current user have rights to write to the Firefox install location? If not then elevation is required to overwrite the files.

If normal updates do not require admin perms then it must not have been installed in a system location, and they must be doing something system-level with this particular update.

Re: Technical Details on the Recent Firefox Add-On Outage

#124

Post by bpfrh »

tedunangst wrote: post #93
Someone1234 wrote: post #74

Earlier quoted context omitted.

What are you after? This clearly says they screwed up and that internal procedures need to be changed so it cannot recur. If this was in fact an oversight/accident, what other kind of explanation can they give? > This was due to an error on our end: we let one of the certificates used to sign add-ons expire And: > We clearly need to adjust our processes both to make this and similar incidents it less likely to happen…

Well, they could tell us what the previous process was. Was the cert renewer on vacation, or was the wrong date entered on the calendar, or? How was it supposed to work? I think a lot of people are curious about that.

They said they will make a formal post-mortem investigation as well as make a post about what they will change. I think the information will be contained in one of the two posts?

Re: Technical Details on the Recent Firefox Add-On Outage

#125

Post by silversconfused »

yellowapple wrote: post #96
tedunangst wrote: post #34

> For the other groups we are developing a patch to Firefox that will install the new certificate once people update. This was released as a “dot release” so people will get it — and probably have already — through the ordinary update channel. If you have a downstream build, you’ll need to wait for your build maintainer to update. Why not link to the xpi that can be installed now?

> Why not link to the xpi that can be installed now? This is the crux of my remaining frustration with how Mozilla handled this issue. That XPI should've been front-and-center in all the articles that detailed the fix. And yet, instead of something like... "If you have Studies enabled, a fix should apply automatically. If it hasn't yet, or if you have Studies turned off (or are using a version which does not support…

We used to call this "botnetting".

Re: Technical Details on the Recent Firefox Add-On Outage

#126

Post by throw7 »

i lost all my custom multi-account containers after getting a version that has the cert fixes (firefox is still broken on fedora; i had to download the testing version today to get it back working).

either today's engineers are sub-standard or the foxes rule the henhouse.

Re: Technical Details on the Recent Firefox Add-On Outage

#127

Post by johncolanduoni »

SAI_Peregrinus wrote: post #121
johncolanduoni wrote: post #102

Earlier quoted context omitted.

Not current time, but time of signing of the executable (not signing of the code sign certificate itself). If you (as the OP suggested) use time of signing instead of current time, the whole point is you’re not using the user’s clock anymore.

Mozilla is already packaging the executable inside an archive. That archive contains the executable, manifest, and any other needed files. The signer can add a timestamp, either as a new file or as a part of the manifest. Then the timestamp is signed along with everything else, and can be checked for validity.

If all extensions are signed by Mozilla’s own certificate, then adding a timestamp won’t do anything for the reason I outlined above and they should just turn off expiration validation altogether. The time of code signing check is only useful if you want to trust one certificate (the developers) to sign things only within the duration noted in the cert, but are willing to trust another certificate (e.g. Microsoft’s timestamp cert) forever. If there’s only one certificate in play owned by the authority for the whole system, then there’s no point in the timestamp at all (for validation purposes).

Re: Technical Details on the Recent Firefox Add-On Outage

#128

Post by silversconfused »

callahad wrote: post #115
yellowapple wrote: post #96

Earlier quoted context omitted.

> Why not link to the xpi that can be installed now? This is the crux of my remaining frustration with how Mozilla handled this issue. That XPI should've been front-and-center in all the articles that detailed the fix. And yet, instead of something like... "If you have Studies enabled, a fix should apply automatically. If it hasn't yet, or if you have Studies turned off (or are using a version which does not support…

> The notion that this was a deliberate ploy to get more people to turn on Studies is surely conspiracy-theorist mumbo-jumbo, but nonsense like this makes me wonder. This is not the case. Please see my response downthread: https://news.ycombinator.com/item?id=19872490

Your intentions are fine, but your methods scare the hell out of us. Thanks for deleting the data, but I'm mad you were collecting it at all. I've clicked "opt out" hundreds of times now. It's not fun anymore.

Re: Technical Details on the Recent Firefox Add-On Outage

#129

Post by SECProto »

yellowapple wrote: post #119
SECProto wrote: post #92

Earlier quoted context omitted.

I view using nightly to be as much of a barrier to entry that I might as well switch to a totally different browser. If the issue had lasted longer, I would have found (someone on the internet who had found) a solution like that.

I use Firefox Nightly as my primary browser on Android. It works fine. You can get it on the Play Store right alongside where you'd get non-Nightly Firefox for Android. I'd hardly call that a "barrier to entry" at all (certainly no more than there would be for, you know, normal Firefox).

> I'd hardly call that a "barrier to entry" at all

Would I have to sign in to sync again to access my bookmarks, logins, etc? Are there ever issues with syncing between phone and computer (nightly to stable) or would I have to change my desktop browser as well? Does anything ever break at all?

Even if the answer to these questions is "no", the fact that I'm asking them is the barrier to entry. And if any of the answers are yes, there's no reason to change from stable branch - avoiding one issue to get different one(s) isn't a solution.

> certainly no more than there would be for, you know, normal Firefox

Yes, indeed, switching to Firefox from Chrome a couple years ago did have a significant barrier to entry

Re: Technical Details on the Recent Firefox Add-On Outage

#130

Post by callahad »

yellowapple wrote: post #117
callahad wrote: post #115

Earlier quoted context omitted.

> The notion that this was a deliberate ploy to get more people to turn on Studies is surely conspiracy-theorist mumbo-jumbo, but nonsense like this makes me wonder. This is not the case. Please see my response downthread: https://news.ycombinator.com/item?id=19872490

I know full well it's not actually the case, but that doesn't make it not feel like it could be the case. It feels scummy, and I'd expect Mozilla to be above that scumminess. Like, just link to the XPI. Not that hard. The unexplained reluctance to do so is suspicious.

Gotcha. Manually installing the hotfix XPI makes cleanup a bit harder now that we have a proper fix. E.g., without coming from Studies, there's no study to ever end. Direct installation also makes it harder to quickly respond to any bugs we might discover in the initial revision of the hotfix.

Now that we have a stable fix, we will publish an XPI with the option of direct installation for users of older, unsupported versions of Firefox (all the way back to 52) who have opted out of automatic updates.

Post reply on HN