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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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".
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.
You show a troubling self-referential incoherence in the things you claim and communicate in your responses that belies your credibility entirely.
This has not gone unnoticed, I gave you quite a bit of rope and you did not disappoint.
You have at some point willfully blinded yourself, and you missed and by extension failed to comprehend the conversation subject matter, or you are doing this intentionally with malice to extract cost on volunteers.
Your choice to ignore salient points, dissemble, improper use or comprehension of working practice and vernacular, and the fact that you communicate incoherently communicates to those watching that you are doing so with intention, the longer and more frequently you do it.
We communicate all the time whether we know it or not. Communicating incoherently and ambiguously communicates another message altogether since human beings are consistent psychologically; unless they are extremely unwell in which case they shouldn't be talking about extraneous things at all.
Negligence is inconsistent. Malice and malevolence are not. Loss with Negligence is intent, and given sufficient activity shows malevolence.
There are consequences for doing such things, none immediate. The main consequence is when you do this sufficiently broadly open societies become closed societies as they become destabilized. They become destabilized because you attack the underpinning of open society creating dynamics extracting cost, its an overt act.
Toleration disappears, and this is how Hitler came to power.
The Bolsheviks tried to capitalize on a distressed Germany following many of the same tactics you demonstrated to impose cost and move the masses, which gave Hitler all he needed to come to power and do horrifying things. There are a growing number of parallels between Hitler and Trumps actions.
The rule of law, broke down to rule by law overnight. Society ceased protecting anyone. What did Hitler do? The first thing he did was killed the Socialist and Communists by political leftist affiliation. The instigators. Millions of them and their families, and children. Then he went on as history shows dwarfing this to a mere footnote.
They had no warning, the lists were made in advance based on actions and participation following Machiavelli. Hitler rose to power because the Bolsheviks tried to impose cost to try and takeover, in the process paving the way to their own destruction (and many others). They were not alone in that but they gave him everything he wanted.
We live in a surveillance society. Acting like an enemy of society by committing subversive overt acts whether you recognize it or not is going to endanger you later.
This is an earnest warning. It should be clear that tolerance has just about completely dried up for this behavior, as evidenced by DOGE, and the fact that approval ratings for democrats are at an all time low, while the exact opposite is at an all time high. DEI is a form of Maoism, and they are stripping it out of government. These type of things change overnight, and the perceptual blindness that made you unable to follow the conversations here will disadvantage you whether you know it or not.
It won't be up to you to decide when it gets to that point. Its decided for you based on your past actions, and fueled by surveillance that are beyond the pale of the STASI's wettest dreams, targeting guilt by association.
This is why you should strive to be clear and concise in what you mean without engaging in many of the fallacy based methodology linked most recently to communism like you did.
You might think its inconsequential, but you won't know that's not the case until its too late, and this is a public forum that is archived. AI could be trained to look for this. Think about it.
There are several ways to upgrade Root CA signed PKI issued certs on all endpoint devices that become expired seemlessly notouch without reinstallation of a bundle in design. Mozilla and Google don't do this not because they are idiots but because it benefits them at the loss of the user.
The best practice is to have a pool of several PKIs that are each signed at the top by a different root CA and using CT Logs, Domain Check Validation, etc to migrate them as needed without reinstall or outage. This was included in material I linked that you say you read but didn't comprehend or address.
You aren't a professional. The support that you link does not support what you say which itself is impossibly ambiguous; intentionally so.
It is a conversation that started with a simple post that was just pointing out that you had to download a new version the way Mozilla implemented the pinning.
I never said it was a good idea, I never made a political statement, I never said there wasn't a better way to do it with current PKI technology. I simply explained the way it had to be done the way Mozilla implemented it and I have to deal with rants talking about Hitler. And you call me unprofessional?
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?
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.
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.
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.
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.
> 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
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.
> 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.
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.
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.
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.
Cite your sources, please. So far you're incorrect.
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?
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 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] 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...)
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.
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".
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.
You show a troubling self-referential incoherence in the things you claim and communicate in your responses that belies your credibility entirely.
This has not gone unnoticed, I gave you quite a bit of rope and you did not disappoint.
You have at some point willfully blinded yourself, and you missed and by extension failed to comprehend the conversation subject matter, or you are doing this intentionally with malice to extract cost on volunteers.
Your choice to ignore salient points, dissemble, improper use or comprehension of working practice and vernacular, and the fact that you communicate incoherently communicates to those watching that you are doing so with intention, the longer and more frequently you do it.
We communicate all the time whether we know it or not. Communicating incoherently and ambiguously communicates another message altogether since human beings are consistent psychologically; unless they are extremely unwell in which case they shouldn't be talking about extraneous things at all.
Negligence is inconsistent. Malice and malevolence are not. Loss with Negligence is intent, and given sufficient activity shows malevolence.
There are consequences for doing such things, none immediate. The main consequence is when you do this sufficiently broadly open societies become closed societies as they become destabilized. They become destabilized because you attack the underpinning of open society creating dynamics extracting cost, its an overt act.
Toleration disappears, and this is how Hitler came to power.
The Bolsheviks tried to capitalize on a distressed Germany following many of the same tactics you demonstrated to impose cost and move the masses, which gave Hitler all he needed to come to power and do horrifying things. There are a growing number of parallels between Hitler and Trumps actions.
The rule of law, broke down to rule by law overnight. Society ceased protecting anyone. What did Hitler do? The first thing he did was killed the Socialist and Communists by political leftist affiliation. The instigators. Millions of them and their families, and children. Then he went on as history shows dwarfing this to a mere footnote.
They had no warning, the lists were made in advance based on actions and participation following Machiavelli. Hitler rose to power because the Bolsheviks tried to impose cost to try and takeover, in the process paving the way to their own destruction (and many others). They were not alone in that but they gave him everything he wanted.
We live in a surveillance society. Acting like an enemy of society by committing subversive overt acts whether you recognize it or not is going to endanger you later.
This is an earnest warning. It should be clear that tolerance has just about completely dried up for this behavior, as evidenced by DOGE, and the fact that approval ratings for democrats are at an all time low, while the exact opposite is at an all time high. DEI is a form of Maoism, and they are stripping it out of government. These type of things change overnight, and the perceptual blindness that made you unable to follow the conversations here will disadvantage you whether you know it or not.
It won't be up to you to decide when it gets to that point. Its decided for you based on your past actions, and fueled by surveillance that are beyond the pale of the STASI's wettest dreams, targeting guilt by association.
This is why you should strive to be clear and concise in what you mean without engaging in many of the fallacy based methodology linked most recently to communism like you did.
You might think its inconsequential, but you won't know that's not the case until its too late, and this is a public forum that is archived. AI could be trained to look for this. Think about it.
There are several ways to upgrade Root CA signed PKI issued certs on all endpoint devices that become expired seemlessly notouch without reinstallation of a bundle in design. Mozilla and Google don't do this not because they are idiots but because it benefits them at the loss of the user.
The best practice is to have a pool of several PKIs that are each signed at the top by a different root CA and using CT Logs, Domain Check Validation, etc to migrate them as needed without reinstall or outage. This was included in material I linked that you say you read but didn't comprehend or address.
You aren't a professional. The support that you link does not support what you say which itself is impossibly ambiguous; intentionally so.
It is a conversation that started with a simple post that was just pointing out that you had to download a new version the way Mozilla implemented the pinning.
I never said it was a good idea, I never made a political statement, I never said there wasn't a better way to do it with current PKI technology. I simply explained the way it had to be done the way Mozilla implemented it and I have to deal with rants talking about Hitler. And you call me unprofessional?
This conversation is over.
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.
Why does a remote resource disappearing mean I can no longer use my local software? Fuck mozilla and their DRM.
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?
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.
This requires a trusted timestamp, which is possible, you just have to think of it when you are designing the system.
A "cunning plan" to force upgrades? :-)
That only works with a timestamp service
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.