Comment 1 for bug 1859643

OTOH, I think it makes sense to allow for the ability to share ~/.pki/nssdb (and yes, a personal-files addition along with a snap change (perhaps just a symlink from $SNAP_USER_DATA/.pki/nssdb to ~/.pki/nssdb would be enough rather than patching?).

For read access, I have no problem with using personal-files to read the nssdb into $SNAP_USER_DATA, with auto-connection.

For write, chromium is not the clear owner of this directory, so I would be hesitant to recommend it as a default since IMO, chromium shouldn't be writing out to these files even in non-snap situations (again, perfectly reasonable to merge in changes if the user desires). I for one would be rather surprised to install a certificate via chromium and have it reflected in my session-wide nssdb for another application (eg, libvirt). Furthermore, there is nothing saying that nssdb might not change format incompatibly with nss in the chromium snap and software installed on the system. This is not theoretical: rather than using a single nssdb in the user's global ~/.pki/nssdb dir, firefox, for example, instead stores per-profile certN.db files in ~/.mozilla/firefox/<profile>/* and in my profile dirs I have a mixture of cert8.db and cert9.db. I do see that chromium only has cert9.db, so perhaps this is handled by the library itself (again, someone would need to verify), but then there is nssdb skew if some applications are writing to certN-1.db, some to certN.db and others to certN+1.db.