corrupting browser profile digital signature
Since FF version 50 was released, I have been experiencing periodic corrupted profile notices from the AVG security suite for downloads via the browser. This has occurred for all downloads since December 2016 from various software vendors eg, Corel, AVG and Adobe, supplying their code via compressed exe files. Downloads from those sites using specialist stub installers did not have this issue. I attach a screen shot of that latest notice regarding an Adobe flashplayer update yesterday
One of the notices was about an AVG download. so, I've referred that AVG notice to AVG and they confirmed that there was no corruption in the related file, and there's been no evidence of any mal-operation for the other items affected over the last 4 months. So it seems clear that the profile stored in the FF browser folder (see image) is the one which has the broken signature.
In January when this issue was really noticeable, I found a discussion regarding a changed method of computing the digital signature in FF version 51 - coinciding with these events. Unfortunately, that discussion thread has been removed or otherwise lost in the changes to the website, because I cannot find it now.
Looking for that discussion page, I've just noticed that there is a 64bit version of FF available. And (since I ran 32bit FF for years before upgrading to a 64bit motherboard, and after the upgrade just restored the various files from backup), the code differences arising from running a 32bit version of FF (now 52.0.2) on a 64bit cpu might be the cause of this.
So, before I lodge an issue regarding this tell me how I upgrade the 32bit version of FF to a 64bit version without a complete re-installation and all the pain re user interfaces that entails
Davidk03
Усі відповіді (13)
If I may suggest, totally remove AVG from your system. Then install a new updated version.
That is a meta file in the Firefox disk cache. Files in the disk cache store the actual file, but also stores additional meta data like the HTTP response headers. The presence of the meta data might confuse AVG. It is possibly better to exclude the two location that Firefox uses for profile data to avoid corruption and dataloss.
Firefox uses two locations for the Firefox profile folder, so make sure to look in the correct location. Location used for the main profile in "AppData\Roaming" that keeps your personal data.
- C:\Users\<user>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile>\
Location used for the disk cache and other temporary files in "AppData\Local".
- C:\Users\<user>\AppData\Local\Mozilla\Firefox\Profiles\<profile>\
Fred, The licensed version of AVG on the machine is kept up to date daily, including software upgrades when AVG requires. So, uninstalling and re-installing it is not a realistic option to fix when this is the only "issue" with the AVG suite.
Cor-el, The file reported has a complete path in the supplied image. Every occasion has been in that folder, and every file in it is a hexadecimal string as the name.
Right now, ignoring it is the only reasonable option - finding the right file to delete in that sea of hex numbers is a nightmare, but ignoring it just degrades confidence in the browser when the security support team says there's nothing wrong with the files.
And neither of you has addressed the basic question I posed - about how to upgrade FF from 342bit to 64bit without a painful reinstall.
Firefox comes in two or more folders on all computers. They are;
Maintenance: (Programs Folder) <Windows Only> Firefox itself: (Programs Folder) And at least one folder in the profile of each user on the computer.
If you remove the Firefox folder, the user folders would not be affected.
Just run the installer for whatever you want to load.
Hi Fred,
Thanks. The pain I was referring to involved all the bookmarks, options, program settings etc that build up over time and one is used to. In particular, I like the classic FF UI, and when it changed for one that had the same 'look' on a desktop and on smartphones a year or so ago, without asking, the pissing around to get it back to one I was used to took time and was a serious annoyance. I don't use a smartphone - one of those dinosaurs for whom a phone is a phone, not an addiction in the form of a mobile computer access terminal.
I am assuming that from what you've said, I can download the stub installed for the latest version, run it, and it determine the platform (32bit or 64bit presumably based on hardware it sees), will install over the current one and in the process update the program to 64bit and import all the prior bookmarks, settings etc. Would you confirm that please.
Davidk03
Змінено
You can clear the disk cache if you are worried or otherwise concerned. You can either delete all content in the cache2 folder or do this in Firefox. "Clear the cache":
- Firefox/Options/Preferences -> Advanced -> Network -> Cached Web Content: "Clear Now"
If the file is signed by Adobe then it could be a Flash file. See also the about:cache page.
Started this process by getting the stub installer for v53, which (according to the release notes on it, will autodetect the 32bit or64bit platform and get the version to suit).
However, what I got is an example (images attached) of what I've been experiencing, using Firefox itself. 1st - I upgraded in place the current v52.0.1 browser to version 53 (after update help about image attached) 2nd - after the browser was re-started, I went to the Mozilla firefox site and downloaded/saved the stub installer, Firefox Setup Stub 53.0.exe, at 241Kb.
3rd - suspecting what happened, I scanned the users\..\mozilla profiles folder with AVG and there was a notification there - that stub download had a broken digital signature. The screenshot of the scan notice is attached.
Now, this is your software, it is up to date with the latest version and supposedly running OK, yet it's delivering broken digital signature notices as have all the previous versions I've been using since Nov 2016. You should have access to the stub itself at your end, and be able to determine - using the 32bit version of FF - just what the issue about calculating digital signatures of downloaded exe files is, and what the fix may be.
Davidk03
Some protection programs don't like the update/install stubs http://www.mozilla.org/en-US/firefox/all/ Download Firefox For All languages And Systems
Well, I've installed the 64bit version. Before doing that, I cleared the cache (so anything in there is for the post 64bit install), unpinned the icon from the task bar, and renamed the 32bit version icon with a '32' suffix to the desktop icon name.
The install used the v53 stub (previously saved in the downloads folder) that the broken signature I reported and attached an image of, above, related to. The actual process was remarkably pain-free (contrary to my expectations). Now there's 2 version 53 copies on the PC - one 32bit (which generated the broken signature notices I've been bitching about), and a new 64bit one.
As a test, I downloaded a service pack from the Corel site, and then ran a scan on the FF cache entries folder. No broken signature or any other notices. And then as a second test I downloaded the v53 stub again, using the 64bit browser. And today the regular whole of PC scan report listed that v53 file profile in the cache as having a broken signature, but the Corel one did not. A mixed bag of good and still bad.
Frustrating and mystifying.
So is everything all set now? If so,
That was very good work. Well done. Please flag your last post as Solved Problem so others will know.
Hi Fred, No, not solved, but alleviated somewhat. Before I upgraded the browser to 64bit, since Nov 2016 I had a 100% fail on the download profiles (of executables) generated by FF and stored in the FF profiles tree. That was the 32bit version running on a 64bit motherboard and 64bit OS. The actual downloaded software itself stored in the downloads folder all seemed to work OK - no detectable issues.
Since the upgrade to the browser FF 64bit running on 64bit motherboard and OS 2 days ago, I've run 3 test downloads of executables from Corel, AVG and Mozilla. As I indicated as part of the browser upgrade process, I cleared the profile cache so anything in it later was a result of the 64bit browser. And after the test downloads, running scans on the profile folder, I still get a 33% failure - a broken signature detection notice. And that failure is for the stub installer v53 from mozilla. The Corel and AVG downloads are good - no detection of broken signatures from them.
A better result on a 'thin' data test set, but still not what it should be. And the failing one is the FF install stub. As I said, frustrating.
Some protection programs don't like the update/install stubs http://www.mozilla.org/en-US/firefox/all/ Download Firefox For All languages And Systems
So, if that's the case, one has to wonder why mozilla is being different? Especially, different since Nov 2016, which is when I and others noticed what was happening after v50 was released. The digital signature process is externally standardised, all the security suites use it of necessity.
One does not normally expect that a browser, in the act of download, will change the signature of the profile (the location path page and file name where that item was obtained) of it's own program, when others are fine. What that does is discredit the browser, not the program it is obtaining.