Couldn't they release an updated certificate? I suppose if you had some critical infrastructure that needed it, you could grab the certificate from a newer version of Firefox.
crote 3 days ago [-]
The certificate is hardcoded in the executable, and Firefox updates with the new certificate were released quite a while ago.
If you run into this issue you're either running Firefox at least nine(!) releases behind current, or you haven't bothered to install any patch updates for the LTS release in over half a year.
Even if they were to release a way to update the certificate in-place, the people who would need it aren't going to bother installing it. They are the same kind of people running Windows Vista in 2025.
hulitu 1 days ago [-]
> If you run into this issue you're either running Firefox at least nine(!) releases behind current
So a 2 day old release is vulnerable. /s
throwaway2016a 3 days ago [-]
This is a certificate used to sign and verify add-ons and (I think based on the reading) some DRM features. They did, in fact, release a new one. This is a warning to the people who haven't run their browser updates and don't have the new one.
There is no point in pulling down the certificate, it's only used by Firefox and there shouldn't be any valid use case to patch an old version to use the new certificate, you would just update your whole browser (it would be easier and safer).
Edit: to whoever downvoted me. I was trying to be helpful with an actual interpretation of the article that this story linked to. I was also answering what was a question in good faith, respectfully. So if my reply is factually inaccurate I would love to know how I misinterpreted it as a matter of curiosity.
trod1234 2 days ago [-]
> its only used by Firefox and there shouldn't be any valid use case to patch an old version to use the new certificate.
While I'm not the person you commented on I can somewhat provide insight into why it may have happened. In short, the sentiment and statement you made is misplaced and false, and neglects two critical things that are common knowledge at a professional level, which you may not be aware of. I'll elaborate below:
First, customized versions of firefox that have been non-insignificantly patched or may have been rebased into a custom tree or fork. Having a certificate hard-coded, creates by design additional work for anyone not following anything except the mainline tree. From a design perspective its known-brittle and lacking any common resiliency feature normally included in such systems. There's a good chance this was intended, sufficient to treat this as malicious compliance. By those who may maintain repositories, this can be perceived as a resource drain attack on said projects that value privacy but who have limited resources to fix the inevitable failures caused by these design decisions.
Mullvad Browser, or Tor Browsers as examples, albeit they have more resources than some of the other browser projects.
Second, many recent updates have been user hostile by Mozilla. A slew of features supporting bulk data aggregation, while also removing toggles that would frequently disable such features has been growing.
Forcing an update removes user choice and agency which they previously had in older versions, with coercive influence. Most importantly at the professional level, a lot of code changes translates into a lot of bugs, failures, and crashes.
When you have many upstream changes, to control costs you generally keep a local or semi-local repository to manage time cost in support and keeping a foundation you can build upon while staying sane. The software having a kill-switch like this, that's part of your local repository guarantees breakages, and it may not be immediately clear what the problem is (since its hard-coded). Backported security fixes are not uncommon, but the maintainability and time-cost are nullified by a kill-switch. Many view this as a kill switch because its hard-coded. Certificates for security would as a baseline require features for revocation. To my knowledge this isn't possible with these particular certificates.
There's a general rule, the more LOCs you touch, the more likely something is to break, and they've touched quite a lot recently.
Generally speaking, there appears to be quite a lot of effort (which translates into money spent) to embed points of failure within the client, similar to what Google has done in the past with Chrome.
throwaway2016a 2 days ago [-]
While I appreciate your detailed answer it reads more like a inditement of Mozilla and doesn't actually address why my answer is wrong. I never said pinning coding the certificate is a good idea, you are attacking a straw man. I was simply answering the original commenters question which was:
> Why can't they release a new certificate?
And nothing in your reply indicates why my answer to the question that is actually asked is incorrect.
Also, Certificate Pinning, which is the technique used here is not exclusive to Mozilla. I agree it's brittle but it's not an unusual practice. They also appear to be using certificate chaining (which is often considered best practice for pinning) since they say it is the Root certificate that expired so it doesn't appear to be a naive implementation. And again, even if it was: that's a straw man, I was not arguing for the technical merits of what they did, only answering the question asked.
Do you not remember when Let's Encrypt had a similar issue when a CA Root certificate expired and the certificates stopped working on old devices?
> the sentiment and statement you made is misplaced and false
What "sentiment", I was not making a political statement, I was answering question. And your entire post is attacking the use of certificate pinning and an open source project, which is something I was not arguing for (hence, a straw man) and does not actually refute my answer to the question asked. Furthermore:
> common knowledge at a professional level, which you may not be aware of
ROTFL, this is an anonymous account but I've been in this industry for over 25 years. You are almost definitely running code on your computer that I wrote. Never make assumptions on who you're talking to and use it for a personal attack. It's not a good idea. Also, never make assumptions that something is "common knowledge" -- you must have never managed anyone and if you have a feel sorry for your reports. But regardless, not a single thing you said in your post was new information to me, except maybe that down stream projects may be using Mozilla code for certificate pinning to run Mozilla add-ons and DRM... and if they are, that's on them because a browser is an app not a library.
trod1234 1 days ago [-]
You asked why you may have been downvoted and I responded in good faith with my opinion based on what you communicated, that opinion is based on principle.
The statements I made are mostly an indictment of Mozilla, but it does include why your statement was wrong if you look carefully at what you wrote, its not about what you were responding to.
Here is the statement you made:
> There is no point in pulling down the certificate, it's only used by Firefox and there shouldn't be any valid use case to patch an old version to use the new certificate, you would just update your whole browser (it would be easier and safer).
Break this down. # AND #. One of the legs doesn't hold. Making this false.
There is no difference in meaning between "should not be" and "no" here aside from marking it as an opinion (should/ought) which can be contradicted by real use-cases.
A strawman argument is where you attack a lesser flawed argument than what was said with the implication or claim that it is the same as the first. This wasn't a strawman argument, it was about exactly what was said despite the gymnastics needed to parse your statements.
The quoted statement was your opinion, and opinion is "sentiment" you relayed. I don't see why you think opinion/sentiment here is associated with politics. It can be misplaced and false at the same time and unrelated to politics.
The information in the post was attacking the fact that Mozilla is attacking and removing resilient design, which is the first thing any operations person will look for. Single points of failure.
Nothing said aside from the fact that you were mistaken in that one small statement you made, can possibly be construed as attacking you.
Even then it is pretty wild to consider observations/statements that serve as basis for a proof by contradiction as a personal attack.
> ROTFL
You asked why, because you missed something. I answered and I really didn't have to.
There are SOP's in professions that are common knowledge. There is no assumption in these cases, and its standard practice to tag or preface statements that are common knowledge for those that may not have it.
On the developer side of the house, it is not unheard of to be siloed and not have common operational knowledge, what was said was reasonable.
Hopefully this sufficiently clarified for you why you may have been downvoted.
> if they are, that's on them because a browser is an app not a library.
The GPL has the intent and obligations spelled out. When you make and demonstrate a pattern of abuse through destructive or diminishing changes contrary to the GPL over time, you may risk violating it.
Taking actions that create the imposition of cost on legally protected rights within the GPL or inducing torturous interference through vexatious behavior is highly problematic and a question for the lawyers (IANAL).
Sentiment that its on the downstream maintainers to fix issues created upstream is highly problematic.
throwaway2016a 20 hours ago [-]
The fact you not once in your reply acknowledge that certificate pinning and bundling trusted root CA public keys is actually common knowledge in desktop and mobile app community makes me thing you didn't even consider my reply.
I was simply explaining why for a desktop app pulling down the new certificate doesn't make sense because updating an app to update the pinned certificates is SOP for apps that use pinning.
> A strawman argument is where you attack a lesser flawed argument than what was said with the implication or claim that it is the same as the first. This wasn't a strawman argument, it was about exactly what was said despite the gymnastics needed to parse your statements.
No it literally was not. It was so much not what I said I wonder if you are replying to a completely different post. And rather than acknowledge you may have misinterpreted me, you are doubling down.
Also, that definition of straw man is wrong. It can also be -- as it is in this case -- attacking an argument the person never even made in the hopes it will bring the debate onto your terms.
But, I'm not attacking the straw man back, once again, at no point did I advocate for certificate pinning in open source apps nor make any comment on GPL or Mozilla.
My post was simply a statement on how to update apps that use certificate pinning. Reading any more into it than that is you injecting context that is not there.
Have a good day. My post is net positive votes now. I will not be replying to this conversation further.
nofunsir 15 hours ago [-]
Cite your sources, please. So far you're incorrect.
throwaway2016a 13 hours ago [-]
rolls eyes sure bud
Tell me, how exactly else are you supposed to update an app with a pinned certificate without defeating the whole purpose of pinning?
But according to trod1234 it is "common knowledge" you shouldn't do that... so Google and Mozilla must both be idiots.
In fact, Google's Android network article has a section specifically on how to add it to their mobile apps[1].
Any app that follows that article and has a root key expire will need to push an update if they don't have backup pins. And the only way to do that is... as I said in my original reply up top... update the entire app the cert is pinned too.
There are literally hundreds of sources I can find. Including the other reply to the post I replied to... which says the same thing as me but for some reason isn't being trolled.
The links you provide do not properly support what you say, imply, or claim.
The three links I provide below contradict the claims that are objectively discern-able. The rest is ignored.
What I actually said is common knowledge in the field and best practice, more importantly its not just me saying it; it is well known in industry, see [1][2][3].
There is no need for any further correspondence here.
1. Most of those articles refer to Public Key Pinning (HPKP), which is not the type Mozilla used. There is more than one type of pinning.
2. Once again... and I'm tired of repeating this... that's a straw man because never once in my original comment did I say pinning as a good idea or advocate for it.
3. With #2 in mind, seeing as my position was not for or against pinning, sending me articles about how bad it is just proves it is common enough use to warrant mainstream articles. Though again, moot, because I wasn't arguing it is common so another straw man.
From your source:
> Certificate pinning, the practice of restricting the certificates that are considered valid for your app to those you have previously authorized, is not recommended for Android apps.
At no point did I say this is not the case. I am aware of the limitations of pinning. Doesn't change the fact of my original post -- which is correct and has not been refuted in a single one of these replies -- Mozilla distributes the root public keys with their app (as does Google as proven by my citation) and the way to upgrade it is to install the newest version.
That last sentence is ALL my original post said and one of your replies or the other persons once addressed that statement, you're all addressing these ridiculous straw men that I never actually said.
nolist_policy 5 hours ago [-]
Your links apply to public pki certificates.
Now, I didn't read the source code, but Mozillas wording implies they use a custom pki to sign extentions.
Given that most (all?) root programs only certify host names or email addresses (S/MIME), it is reasonable for Mozilla to run a custom pki for this. And that neccesarily requires shipping/pinning the root certificates.
Actually this whole discussion is moot, because Firefox uses (and ships with) the Mozilla Root Program. So it can not not pin certificates, because that is the whole point of a root program.
Looks like we all learned something today.
throwaway2016a 31 minutes ago [-]
You contradict your part here. I'm not sure if you meant to because the rest of your post sounds like it is saying Mozilla needs to pin if it's using a custom signing mechanism.
> Firefox uses (and ships with) the Mozilla Root Program
> can not not pin certificates
Shipping with a certificate store is by definition, pinning. So not only can it but your own post states it is when it says "and ships with".
57 minutes ago [-]
gruez 3 days ago [-]
ESR 128 and 115.13 was released 8 months ago, so if you had auto-updates enabled in all likelihood you don't need to do anything.
Am4TIfIsER0ppos 3 days ago [-]
Why does a remote resource disappearing mean I can no longer use my local software? Fuck mozilla and their DRM.
tialaramex 3 days ago [-]
Huh? You're asking why does time pass? I mean if you were asking about like a single player video game then I guess this makes sense, but the whole point of a web browser is like browsing the web. Tim's crap hypermedia thing for the Internet?
flohofwoe 3 days ago [-]
Since it's about addons (and not https connections) the same approach as with code-signing certificates could be used. For code signing it only matters that the certificate was valid at the time of signing, not when the signed resource is used.
E.g. when the certificate expires, any resource signed with that certificate while it still was valid continues to be usable, you just can't sign any new releases with the expired certificate.
LoganDark 3 days ago [-]
This requires a trusted timestamp, which is possible, you just have to think of it when you are designing the system.
dfawcus 3 days ago [-]
A "cunning plan" to force upgrades? :-)
merb 3 days ago [-]
That only works with a timestamp service
Am4TIfIsER0ppos 3 days ago [-]
I'm asking why my computer cares what time it is before it executes a piece of code. I put it there. Mozilla gave me permission at the time. I shouldn't need it again later. Code signing is DRM.
7 days ago [-]
Rendered at 14:26:39 GMT+0000 (Coordinated Universal Time) with Vercel.
If you run into this issue you're either running Firefox at least nine(!) releases behind current, or you haven't bothered to install any patch updates for the LTS release in over half a year.
Even if they were to release a way to update the certificate in-place, the people who would need it aren't going to bother installing it. They are the same kind of people running Windows Vista in 2025.
So a 2 day old release is vulnerable. /s
There is no point in pulling down the certificate, it's only used by Firefox and there shouldn't be any valid use case to patch an old version to use the new certificate, you would just update your whole browser (it would be easier and safer).
Edit: to whoever downvoted me. I was trying to be helpful with an actual interpretation of the article that this story linked to. I was also answering what was a question in good faith, respectfully. So if my reply is factually inaccurate I would love to know how I misinterpreted it as a matter of curiosity.
While I'm not the person you commented on I can somewhat provide insight into why it may have happened. In short, the sentiment and statement you made is misplaced and false, and neglects two critical things that are common knowledge at a professional level, which you may not be aware of. I'll elaborate below:
First, customized versions of firefox that have been non-insignificantly patched or may have been rebased into a custom tree or fork. Having a certificate hard-coded, creates by design additional work for anyone not following anything except the mainline tree. From a design perspective its known-brittle and lacking any common resiliency feature normally included in such systems. There's a good chance this was intended, sufficient to treat this as malicious compliance. By those who may maintain repositories, this can be perceived as a resource drain attack on said projects that value privacy but who have limited resources to fix the inevitable failures caused by these design decisions.
Mullvad Browser, or Tor Browsers as examples, albeit they have more resources than some of the other browser projects.
Second, many recent updates have been user hostile by Mozilla. A slew of features supporting bulk data aggregation, while also removing toggles that would frequently disable such features has been growing.
Forcing an update removes user choice and agency which they previously had in older versions, with coercive influence. Most importantly at the professional level, a lot of code changes translates into a lot of bugs, failures, and crashes.
When you have many upstream changes, to control costs you generally keep a local or semi-local repository to manage time cost in support and keeping a foundation you can build upon while staying sane. The software having a kill-switch like this, that's part of your local repository guarantees breakages, and it may not be immediately clear what the problem is (since its hard-coded). Backported security fixes are not uncommon, but the maintainability and time-cost are nullified by a kill-switch. Many view this as a kill switch because its hard-coded. Certificates for security would as a baseline require features for revocation. To my knowledge this isn't possible with these particular certificates.
There's a general rule, the more LOCs you touch, the more likely something is to break, and they've touched quite a lot recently.
Generally speaking, there appears to be quite a lot of effort (which translates into money spent) to embed points of failure within the client, similar to what Google has done in the past with Chrome.
> Why can't they release a new certificate?
And nothing in your reply indicates why my answer to the question that is actually asked is incorrect.
Also, Certificate Pinning, which is the technique used here is not exclusive to Mozilla. I agree it's brittle but it's not an unusual practice. They also appear to be using certificate chaining (which is often considered best practice for pinning) since they say it is the Root certificate that expired so it doesn't appear to be a naive implementation. And again, even if it was: that's a straw man, I was not arguing for the technical merits of what they did, only answering the question asked.
Do you not remember when Let's Encrypt had a similar issue when a CA Root certificate expired and the certificates stopped working on old devices?
> the sentiment and statement you made is misplaced and false
What "sentiment", I was not making a political statement, I was answering question. And your entire post is attacking the use of certificate pinning and an open source project, which is something I was not arguing for (hence, a straw man) and does not actually refute my answer to the question asked. Furthermore:
> common knowledge at a professional level, which you may not be aware of
ROTFL, this is an anonymous account but I've been in this industry for over 25 years. You are almost definitely running code on your computer that I wrote. Never make assumptions on who you're talking to and use it for a personal attack. It's not a good idea. Also, never make assumptions that something is "common knowledge" -- you must have never managed anyone and if you have a feel sorry for your reports. But regardless, not a single thing you said in your post was new information to me, except maybe that down stream projects may be using Mozilla code for certificate pinning to run Mozilla add-ons and DRM... and if they are, that's on them because a browser is an app not a library.
The statements I made are mostly an indictment of Mozilla, but it does include why your statement was wrong if you look carefully at what you wrote, its not about what you were responding to.
Here is the statement you made:
> There is no point in pulling down the certificate, it's only used by Firefox and there shouldn't be any valid use case to patch an old version to use the new certificate, you would just update your whole browser (it would be easier and safer).
Break this down. # AND #. One of the legs doesn't hold. Making this false.
There is no difference in meaning between "should not be" and "no" here aside from marking it as an opinion (should/ought) which can be contradicted by real use-cases.
A strawman argument is where you attack a lesser flawed argument than what was said with the implication or claim that it is the same as the first. This wasn't a strawman argument, it was about exactly what was said despite the gymnastics needed to parse your statements.
The quoted statement was your opinion, and opinion is "sentiment" you relayed. I don't see why you think opinion/sentiment here is associated with politics. It can be misplaced and false at the same time and unrelated to politics.
The information in the post was attacking the fact that Mozilla is attacking and removing resilient design, which is the first thing any operations person will look for. Single points of failure.
Nothing said aside from the fact that you were mistaken in that one small statement you made, can possibly be construed as attacking you.
Even then it is pretty wild to consider observations/statements that serve as basis for a proof by contradiction as a personal attack.
> ROTFL
You asked why, because you missed something. I answered and I really didn't have to.
There are SOP's in professions that are common knowledge. There is no assumption in these cases, and its standard practice to tag or preface statements that are common knowledge for those that may not have it.
On the developer side of the house, it is not unheard of to be siloed and not have common operational knowledge, what was said was reasonable.
Hopefully this sufficiently clarified for you why you may have been downvoted.
> if they are, that's on them because a browser is an app not a library.
The GPL has the intent and obligations spelled out. When you make and demonstrate a pattern of abuse through destructive or diminishing changes contrary to the GPL over time, you may risk violating it.
Taking actions that create the imposition of cost on legally protected rights within the GPL or inducing torturous interference through vexatious behavior is highly problematic and a question for the lawyers (IANAL).
Sentiment that its on the downstream maintainers to fix issues created upstream is highly problematic.
I was simply explaining why for a desktop app pulling down the new certificate doesn't make sense because updating an app to update the pinned certificates is SOP for apps that use pinning.
> A strawman argument is where you attack a lesser flawed argument than what was said with the implication or claim that it is the same as the first. This wasn't a strawman argument, it was about exactly what was said despite the gymnastics needed to parse your statements.
No it literally was not. It was so much not what I said I wonder if you are replying to a completely different post. And rather than acknowledge you may have misinterpreted me, you are doubling down.
Also, that definition of straw man is wrong. It can also be -- as it is in this case -- attacking an argument the person never even made in the hopes it will bring the debate onto your terms.
But, I'm not attacking the straw man back, once again, at no point did I advocate for certificate pinning in open source apps nor make any comment on GPL or Mozilla.
My post was simply a statement on how to update apps that use certificate pinning. Reading any more into it than that is you injecting context that is not there.
Have a good day. My post is net positive votes now. I will not be replying to this conversation further.
Tell me, how exactly else are you supposed to update an app with a pinned certificate without defeating the whole purpose of pinning?
How about Google?
https://chromium.googlesource.com/chromium/src/+/main/net/da...
> The Chrome Root Store contains the set of certificates Chrome trusts by default.
Google also bundles some certificate fingerprints with their browser.
You can see right here where they are in their source code:
https://chromium.googlesource.com/chromium/src/+/main/net/da...
But according to trod1234 it is "common knowledge" you shouldn't do that... so Google and Mozilla must both be idiots.
In fact, Google's Android network article has a section specifically on how to add it to their mobile apps[1].
Any app that follows that article and has a root key expire will need to push an update if they don't have backup pins. And the only way to do that is... as I said in my original reply up top... update the entire app the cert is pinned too.
There are literally hundreds of sources I can find. Including the other reply to the post I replied to... which says the same thing as me but for some reason isn't being trolled.
[1] https://developer.android.com/privacy-and-security/security-...
The three links I provide below contradict the claims that are objectively discern-able. The rest is ignored.
What I actually said is common knowledge in the field and best practice, more importantly its not just me saying it; it is well known in industry, see [1][2][3].
There is no need for any further correspondence here.
[1] https://www.ssl.com/blogs/what-is-certificate-pinning/
[2] https://blog.cloudflare.com/why-certificate-pinning-is-outda...
[3] https://developer.android.com/privacy-and-security/security-... (Restricting your App to Specific Certificates... Caution...)
2. Once again... and I'm tired of repeating this... that's a straw man because never once in my original comment did I say pinning as a good idea or advocate for it.
3. With #2 in mind, seeing as my position was not for or against pinning, sending me articles about how bad it is just proves it is common enough use to warrant mainstream articles. Though again, moot, because I wasn't arguing it is common so another straw man.
From your source:
> Certificate pinning, the practice of restricting the certificates that are considered valid for your app to those you have previously authorized, is not recommended for Android apps.
At no point did I say this is not the case. I am aware of the limitations of pinning. Doesn't change the fact of my original post -- which is correct and has not been refuted in a single one of these replies -- Mozilla distributes the root public keys with their app (as does Google as proven by my citation) and the way to upgrade it is to install the newest version.
That last sentence is ALL my original post said and one of your replies or the other persons once addressed that statement, you're all addressing these ridiculous straw men that I never actually said.
Now, I didn't read the source code, but Mozillas wording implies they use a custom pki to sign extentions.
Given that most (all?) root programs only certify host names or email addresses (S/MIME), it is reasonable for Mozilla to run a custom pki for this. And that neccesarily requires shipping/pinning the root certificates.
Actually this whole discussion is moot, because Firefox uses (and ships with) the Mozilla Root Program. So it can not not pin certificates, because that is the whole point of a root program.
Looks like we all learned something today.
> Firefox uses (and ships with) the Mozilla Root Program
> can not not pin certificates
Shipping with a certificate store is by definition, pinning. So not only can it but your own post states it is when it says "and ships with".
E.g. when the certificate expires, any resource signed with that certificate while it still was valid continues to be usable, you just can't sign any new releases with the expired certificate.