Download it now!
Bug 66158 - LO 4.1.0.1 doesn't save path to own certificates
Summary: LO 4.1.0.1 doesn't save path to own certificates
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.1.0.1 rc
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-25 12:38 UTC by Thomas Hackert
Modified: 2013-06-27 08:58 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Hackert 2013-06-25 12:38:20 UTC
Hello @ll,
I hope, I have chosen the right component. If not, feel free to change it ... ;)

To confirm this bug, you need your own certificates, be it one, that you have created via www.cacert.org, be it from somewhere else ... ;)

To reproduce:
0. Register at cacert and create a certificate (else jump to step 3)
1. Save your certificate in a directory like ~/certs (or like me, on a different partition ... ;) )
2. Open LO
3. Go to "Tools - Options - LibreOffice - Security" and click on "Certificate"
4. In the "Certificate Path" window click on "Add"
5. In the "Select Path" window scroll down to your ~/certs directory, otherwise change to it there.
6. Click on "Select"
7. Click on "OK", when you get the note, that you have to restart LO

If you have started LO from commandline, you should see "dir is ~/certs"

8. Close LO completely and start it again.
9. Do step 3 again

You should see your "$MOZILLA_CERTIFICATE_FOLDER /path/to/your/firefox/profile" (where this "$MOZILLA_CERTIFICATE_FOLDER" seems a different error, as it was not there with my parallel installed LO Version 4.0.4.2 (Build ID: 9e9821abd0ffdbc09cd8c52eaa574fa09eb08f2) w/installed Germanophone lang- as well as helppack ... :( ) marked instead of your newly added "manual ~/cert" there ... :( And you can change your certiicate path again, restart LO, but to no avail ... :(

Discovered with parallel installed LO Version: 4.1.0.1 Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155 and installed Germanophone help- as well as langpack under Debian Testing AMD64.

I am not sure, if I should set this as regression as well ... :( If someone else can confirm it, feel free to set the regression keyword. And I need someone to bibisect it (Thorsten has asked me to do it, but alas ... ), as I have not enough disc space to do it, sorry ... :(

Sorry for the inconvenience
Thomas.
Comment 1 Caolán McNamara 2013-06-26 16:22:57 UTC
so, do you have $MOZILLA_CERTIFICATE_FOLDER set in your environment ?, i.e. what's the output of echo $MOZILLA_CERTIFICATE_FOLDER ?

MOZILLA_CERTIFICATE_FOLDER was the "old" way to force setting the cert dir while the new way is to use these new gui settings, but the old way is still supported in the sense that setting the env variable MOZILLA_CERTIFICATE_FOLDER will override any user selected option.
Comment 2 Thomas Hackert 2013-06-26 17:49:29 UTC
Hello Caolán, *,
(In reply to comment #1)
> so, do you have $MOZILLA_CERTIFICATE_FOLDER set in your environment ?, i.e.
> what's the output of echo $MOZILLA_CERTIFICATE_FOLDER ?

it was set. I have not set it AFAICS ... ;) If I enter

<quote>
echo $MOZILLA_CERTIFICATE_FOLDER
</quote>

I get
<quote>
~/.mozilla/firefox/2gsprytl.default
</quote>

(I have anonyzed /home/$user to gain a little bit privacy ... ;) ), which is interesting, as this profile is in ~/mozilla/firefox_old, which I created, when I had a problem with Firefox ... ;)

> MOZILLA_CERTIFICATE_FOLDER was the "old" way to force setting the cert dir
> while the new way is to use these new gui settings, but the old way is still
> supported in the sense that setting the env variable
> MOZILLA_CERTIFICATE_FOLDER will override any user selected option.

What would happen, if I unset the path (if this is possible)? And I am wondering, if it is the default way to show it in the Certificate window. In LO Version 4.0.4.2 (Build ID: 9e9821abd0ffdbc09cd8c52eaa574fa09eb08f2) with installed Germanophone lang- as well as helppack it isn't ... ;)

Thanks for your interest in my bug
Thomas.
Comment 3 Caolán McNamara 2013-06-26 19:14:44 UTC
You can unset it (for a given environment) with unset MOZILLA_CERTIFICATE_FOLDER in a terminal and launch office from the command line of that terminal.

The question is though where is it getting set. e.g. see http://stackoverflow.com/questions/5299886/find-out-where-an-environment-variable-was-last-set-in-bash for debugging where that's coming from. Common places of course are ~/.bashrc ~/.bash_profile. Maybe the output of...

grep -r MOZILLA_CERTIFICATE_FOLDER /etc/profile.d/* ~/.bash*

might get lucky and hit the right place.

I'll remove this from MAB 4.1, as given that the env var is set, then its working correctly to honour that above all else.
Comment 4 Thomas Hackert 2013-06-27 04:50:54 UTC
Good morning Caolán, *,
(In reply to comment #3)
> You can unset it (for a given environment) with unset
> MOZILLA_CERTIFICATE_FOLDER in a terminal and launch office from the command
> line of that terminal.

ah, OK. Then it works :) Thanks for your tip :)

> The question is though where is it getting set. e.g. see
> http://stackoverflow.com/questions/5299886/find-out-where-an-environment-
> variable-was-last-set-in-bash for debugging where that's coming from. Common
> places of course are ~/.bashrc ~/.bash_profile. Maybe the output of...

Thanks for the link :) I found it in ~/.bashrc, though I am not sure, when I have set it ... :(

<snip>
> I'll remove this from MAB 4.1, as given that the env var is set, then its
> working correctly to honour that above all else.

OK. Should I close this bug as "WORKSFORME" or something else? Or would you mind to close it?
Thanks again
Thomas.
Comment 5 Caolán McNamara 2013-06-27 08:58:29 UTC
Great, that's the mystery solved then. We'll use "NOTABUG" as its working as intended, i.e. backwards compatibility if that variable is set. Though recommendation these days is to not set it and let the auto-profile detect do its thing and if necessary override it through the UI.