Bug 13009

(maybe) related article: https://developer.mozilla.org/en-US/docs/NSS/NSS_Tech_Notes/nss_tech_note6. Though my installed NSS is lib64nss3-3.15.4-1.mga4, and the aforementioned URL may not have fully up-to-date info for NSS > 3.11...

Tried a workaround as in URL provided in Comment 1:
# #quit any instance of Firefox
# cd /usr/lib64
# shlibsign -v -i libsoftokn3.so
# shlibsign -v -i libfreebl3.so
# ls -Alh *.chk
# #I can confirm the date of both "libfreebl3.chk" and "libsoftokn3.so" has been updated so I presume they are updated.
# #launch firefox. Try the "Enable FIPS". Same wrong result - nothing happens.

Don't know why it fails currently - is it due to my .chk files still containing wrong checksums for the corresponding .so files (less likely now that I tried the shlibsign operation). In any case the aforementioned workaround, even if it worked, would not be good as it means self-signing the file which may have been corrupt since. Having a correct chk installed by the RPM from start would be better but still not good without integrity verification at filesystem level (XATTR) on the concerned files (requires kernel support etc).

It may well be that the problem is completely different though and the incorrect .chk file hypothesis is wrong.

Tried a workaround as in URL provided in Comment 1:
# #quit any instance of Firefox
# cd /usr/lib64
# shlibsign -v -i libsoftokn3.so
# shlibsign -v -i libfreebl3.so
# ls -Alh *.chk
# #I can confirm the date of both "libfreebl3.chk" and "libsoftokn3.so" has been updated so I presume they are updated.
# #launch firefox. Try the "Enable FIPS". Same wrong result - nothing happens.

Don't know why it fails currently - is it due to my .chk files still containing wrong checksums for the corresponding .so files (less likely now that I tried the shlibsign operation). In any case the aforementioned workaround, even if it worked, would not be good as it means self-signing the file which may have been corrupt since. Having a correct chk installed by the RPM from start would be better but still not good without integrity verification at filesystem level (XATTR) on the concerned files (requires kernel support etc).

It may well be that the problem is completely different though and the incorrect .chk file hypothesis is wrong.

Summary: Can't enable fips mode => Can't enable fips mode in firefox-24.3.0-1.mga4 (lib64nss3-3.15.4-1.mga4)

Reading bug at link: https://bugzilla.redhat.com/show_bug.cgi?id=230545, it seems that the issue could come from prelink operation further modifying the .so files even after RPM installation. I have no clue what can trigger a prelink operation outside of the RPM install but I tried the (wrong) workaround from comments 2-3 (sorry for double post) several times anyway, with short time between the shlibsign and launch firefox operations and it fails everytime. So any prelink is very unlikely to be the cause of my issue and I have no clue what could be the cause. Unless of course something went wrong in the shlibsign operations from start...

Is this bug still relevant with current updates of Firefox in mga4?

CC: (none) => olivier

Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer 
maintained, which means that it will not receive any further security or bug 
fix updates.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version.

Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't 
able to fix it before Mageia 4's end of life. If you are able to reproduce it 
against a later version of Mageia, you are encouraged to click on "Version" and 
change it against that version of Mageia. If it's valid in several versions, 
select the highest and add MGAxTOO in whiteboard for each other valid release.
Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

If you would like to help fixing bugs in the future, don't hesitate to join the
packager team via our mentoring program [1] or join the teams that fit you 
most [2].

[1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
[2] http://www.mageia.org/contribute/

As announced over a month ago, Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates.

This issue may have been fixed in a later Mageia release, so, if you still see it and didn't already do so: please upgrade to Mageia 5 (or, if you read this much later than this is written: make sure you run a currently maintained Mageia version)

If you are able to reproduce it against a maintained version of Mageia, you are encouraged to 
1. reopen this bug report, by changing the "Status" from "RESOLVED - OLD" to "REOPENED"
2. click on "Version" and change it against that version of Mageia. If you know it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release.
Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO.
3. give as much relevant information as possible. If you're not an experienced bug reporter and have some time: please read this page:
https://wiki.mageia.org/en/How_to_report_a_bug_properly

If you see a similar issue, but are _not_sure_ it is the same, with the same cause, then please file a new bug report and mention this one in it (please include the bug number, too). 


If you would like to help fixing bugs in the future, don't hesitate to join the
packager team via our mentoring program [1] or join the teams that fit you 
most [2].
[1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
[2] http://www.mageia.org/contribute/

Status: NEW => RESOLVED
Resolution: (none) => OLD