818686 - Support XDG basedir specification

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P5)

Description

[Eric Heintzmann]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121129151900

Comment 1

[Andre Klapper]

Where in the codebase would this be applied to?

Comment 2

[Eric Heintzmann]

I think these files should be moved:

$HOME/.pki/nssdb/pkcs11.txt --> $XDG_CONFIG_HOME/pki/nssdb/pkcs11.txt
$HOME/.pki/nssdb/cert9.db   --> $XDG_DATA_HOME/pki/nssdb/cert9.db
$HOME/.pki/nssdb/key4.db    --> $XDG_DATA_HOME/pki/nssdb/key4.db

http://ploum.net/post/207-modify-your-application-to-use-xdg-folders
https://live.gnome.org/GnomeGoals/XDGConfigFolders
http://standards.freedesktop.org/basedir-spec/latest/

Comment 3

[John Drinkwater (:beta)]

(In reply to Andre Klapper from comment #1)
> Where in the codebase would this be applied to?

From a quick non-comprehensive look, security/nss/lib/sysinit/nsssysinit.c getUserDB()

Comment 4

[Shmerl]

Would you accept a patch for it? I've just noticed this as well, after switching to newest Kmail (that indirectly relies on libnss3).

Comment 5

[Shmerl]

Attachment: XDG base directory spec support patch

Declutters $HOME by placing user DB in $XDG_DATA_HOME/pki/nssdb or in $HOME/.local/share/pki/nssdb if $XDG_DATA_HOME isn't set.

Comment 6

[Franziskus Kiefer [:franziskus]]

Comment on attachment 8929869 [details] [diff] [review]
XDG base directory spec support patch

Review of attachment 8929869 [details] [diff] [review]:
-----------------------------------------------------------------

Adding XDG_DATA_HOME support is fine in general. But it has to either keep the old default or add a migration path.

::: lib/sysinit/nsssysinit.c
@@ +54,5 @@
> +    if (userdir != NULL) {
> +        nssdir = PORT_Alloc(strlen(userdir) + sizeof(NSS_USER_PATH1) +
> +                 sizeof(NSS_USER_PATH2));
> +    } else {
> +        nssdir = PORT_Alloc(strlen(homedir) + sizeof(NSS_USER_PATH0) +

Always using ~/.local/share/pki/nssdb now as default will break old installations. If you want to change the default folder, you have to add an automatic migration.

Comment 7

[Shmerl]

You can't keep old default, the whole point is to get rid of it, to conform to XDG spec. How do you propose to introduce migration?

Comment 8

[Shmerl]

I'm not sure exactly about use cases, but for example in my particular situation Kmail is using it, and simply deleting $HOME/.pki/nss creates it again when Kmail is restarted. So it's not any worse than it creating it again in different location. Is there a situation when this directory switch can cause a problem?

Comment 9

[Franziskus Kiefer [:franziskus]]

> You can't keep old default, the whole point is to get rid of it, to conform to XDG spec. How do you propose to introduce migration?

There has to be something that detects the old config folder and moves it if it's there. This would break applications that hard code the path but that might be ok.
I think there's a redhat bug that was closed for this change. They probably know better.

Comment 10

[Shmerl]

Would it be OK to add that migration right here in getUserDB function?

Comment 11

[Edênis Freindorfer Azevedo]

Attachment: XDG Base Directory Support for NSS with an automated migration path.

I would like to also submit a patch for support but with an automated migration path included.

At this moment, I check if the folder "$HOME/.pki" exists and I rename it to "${XDG_DATA_HOME:-$HOME/.local/share}/pki".

I tried some tests, but it seems some apps hardcode this path to "$HOME/.pki/nssdb". I don't quite understand why they don't use this function, but I am still learning so maybe there is a very good explanation for it.

Comment 12

[Shmerl]

(In reply to Franziskus Kiefer [:franziskus] from comment #9)
> There has to be something that detects the old config folder and moves it if
> it's there. This would break applications that hard code the path but that
> might be ok.

Is the above solution good?

Comment 13

[Edênis Freindorfer Azevedo]

Attachment: Add support for the XDG Base Directory Specification with legacy support.

We check if $HOME/.pki and $HOME/.pki/nssdb exist; if they do, then we use
this path. Otherwise, use ${XDG_DATA_HOME:-$HOME/.local/share}/pki/nssdb

Comment 14

[Shmerl]

Which version will this be fixed in?

Comment 15

[Edênis Freindorfer Azevedo]

Hey @Shmerl(In reply to Shmerl from comment #14)
> Which version will this be fixed in?

Hey! Just a FYI about this, pushing this MR will not solve this issue once for all. The code on NSS is used as a reference of where applications should store their certificate files (see https://bugzilla.mozilla.org/show_bug.cgi?id=494481 ). The function getUserDB is not exposed. 

This change would motivate for us to go push on other software (I am trying this right now on chromium: https://chromium-review.googlesource.com/c/chromium/src/+/1364131 ). At least on chromium, they hardcoded this path "because NSS does like this and we would only change after the upstream NSS discussion".

Also, they are using phabricator at mozilla. If they are not replying to you here, check https://phabricator.services.mozilla.com for updates.

Comment 16

[Martin Thomson [:mt:]]

Bob,

As part of fixing this, we made a function in the nsssysinit.c non-static (so it could be tested).

I've added a .def file to the nsssysinit.so build so that we don't pollute the ABI. This does result in ABI changes (from the ABI compatibility check):

+Function symbols changes summary: 2 Removed, 0 Added function symbols not referenced by debug info
+Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info
+
+2 Removed function symbols not referenced by debug info:
+
+  _fini
+  _init
+

It seems like this is very likely OK: https://sourceware.org/ml/binutils/2018-05/msg00012.html

However, I just want to confirm that hiding the _init and _fini symbols isn't an issue in your experience? We hide those symbols for other libraries, and I don't see any special behavior here that warrants caution, but I thought that I'd double check.

Comment 17

[Robert Relyea]

Loosing those symbols should be fine.

On the base issue, there is a migration issue for us. We'll need to keep the old behavior on our existing RHEL platforms (at least the behavior without the environment variable). Fedora can move forward because applications that depend on the hard coded location can be changed to accommodate the move. I'll leave daiki to comment on how he wants to handle this in RHEL

Comment 18

[Ryan Sleevi]

Martin/Bob: Does Firefox use nsssysinit? Is my understanding correct that this change would only be applicable to Fedora/RHEL?

Comment 19

[Martin Thomson [:mt:]]

Ryan, that's a good question. Firefox builds don't exclude this library. That might be a mistake, because the make builds exclude it everywhere except non-Android Linux. Unfortunately, that will require some testing.

We also noticed that the file contains #ifdef XP_WIN and #ifdef XP_UNIX, which are pointless given the build conditions on it. I'll open a bug to remove that code.

Daiki, are you OK with landing this and dealing with the RHEL changes later, or would you like to hold it for those?

Comment 20

[Daiki Ueno [:ueno]]

(In reply to Martin Thomson [:mt:] from comment #19)

Daiki, are you OK with landing this and dealing with the RHEL changes later, or would you like to hold it for those?

Yes, we can adjust the RHEL packages later for this change (if the migration is really needed; the approach in comment 13 sounds good enough).

Comment 21

[Martin Thomson [:mt:]]

https://hg.mozilla.org/projects/nss/rev/da45424cb9a0b4d8e45e5040e2e3b574d994e254

Comment 22

[Shmerl]

Opened one for Kmail: https://bugs.kde.org/show_bug.cgi?id=403752

Comment 23

[u363675]

Can someone please explain why this is not working on my archlinux (nss v3.45-1) system? On my test case, everytime I launch qutebrowser it will create a ~/.pki, no matter if I remove this dir before the launching or even creating an empty one on ~/.local/share/pki/nssdb.

Comment 24

[janek]

Still same issue as @AlexandreProvencio, but I don't even know which application creates it

Comment 25

[lgarczyn]

Same issue on Ubuntu 20.04.1 LTS

Some app, likely firefox or vscode, appears to create a ~/.pki folder on startup

Comment 26

[lgarczyn]

(In reply to lgarczyn from comment #25)

Same issue on Ubuntu 20.04.1 LTS

Some app, likely firefox or vscode, appears to create a ~/.pki folder on startup

Can confirm it's visual studio code, version 1.52.1

Comment 27

[Ryan Sleevi]

You're seeing this because the file that was patched is not normally used by NSS using applications. That's what I was asking about in Comment #18. NSS using applications are very unlikely to be using this, the file is a bit more like a 'contrib' file. It's mostly harmless, it'll do something for some platforms (like RHEL), but it's not the main entry point most main NSS-using apps use.