From 43a97878ce14b72f0981164f87f2e35e14151312 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 11:22:09 +0200 Subject: Adding upstream version 110.0.1. Signed-off-by: Daniel Baumann --- .../nss/doc/rst/legacy/tools/modutil/index.rst | 640 +++++++++++++++++++++ 1 file changed, 640 insertions(+) create mode 100644 security/nss/doc/rst/legacy/tools/modutil/index.rst (limited to 'security/nss/doc/rst/legacy/tools/modutil/index.rst') diff --git a/security/nss/doc/rst/legacy/tools/modutil/index.rst b/security/nss/doc/rst/legacy/tools/modutil/index.rst new file mode 100644 index 0000000000..52ffcabbcd --- /dev/null +++ b/security/nss/doc/rst/legacy/tools/modutil/index.rst @@ -0,0 +1,640 @@ +.. _mozilla_projects_nss_tools_modutil: + +NSS tools : modutil +=================== + +.. container:: + + | Name + |    modutil — Manage PKCS #11 module information within the security module + |    database. + | Synopsis + |    modutil [options] `arguments `__ + | Description + |    The Security Module Database Tool, modutil, is a command-line utility for + |    managing PKCS #11 module information both within secmod.db files and + |    within hardware tokens. modutil can add and delete PKCS #11 modules, + |    change passwords on security databases, set defaults, list module + |    contents, enable or disable slots, enable or disable FIPS 140-2 + |    compliance, and assign default providers for cryptographic operations. + |    This tool can also create certificate, key, and module security database + |    files. + |    The tasks associated with security module database management are part of + |    a process that typically also involves managing key databases and + |    certificate databases. + | Options + |    Running modutil always requires one (and only one) option to specify the + |    type of module operation. Each option may take arguments, anywhere from + |    none to multiple arguments. + |    Options + |    -add modulename + |            Add the named PKCS #11 module to the database. Use this option + |            with the -libfile, -ciphers, and -mechanisms arguments. + |    -changepw tokenname + |            Change the password on the named token. If the token has not been + |            initialized, this option initializes the password. Use this option + |            with the -pwfile and -newpwfile arguments. A password is + |            equivalent to a personal identification number (PIN). + |    -chkfips + |            Verify whether the module is in the given FIPS mode. true means to + |            verify that the module is in FIPS mode, while false means to + |            verify that the module is not in FIPS mode. + |    -create + |            Create new certificate, key, and module databases. Use the -dbdir + |            directory argument to specify a directory. If any of these + |            databases already exist in a specified directory, modutil returns + |            an error message. + |    -default modulename + |            Specify the security mechanisms for which the named module will be + |            a default provider. The security mechanisms are specified with the + |            -mechanisms argument. + |    -delete modulename + |            Delete the named module. The default NSS PKCS #11 module cannot be + |            deleted. + |    -disable modulename + |            Disable all slots on the named module. Use the -slot argument to + |            disable a specific slot. + |    -enable modulename + |            Enable all slots on the named module. Use the -slot argument to + |            enable a specific slot. + |    -fips [true \| false] + |            Enable (true) or disable (false) FIPS 140-2 compliance for the + |            default NSS module. + |    -force + |            Disable modutil's interactive prompts so it can be run from a + |            script. Use this option only after manually testing each planned + |            operation to check for warnings and to ensure that bypassing the + |            prompts will cause no security lapses or loss of database + |            integrity. + |    -jar JAR-file + |            Add a new PKCS #11 module to the database using the named JAR + |            file. Use this command with the -installdir and -tempdir + |            arguments. The JAR file uses the NSS PKCS #11 JAR format to + |            identify all the files to be installed, the module's name, the + |            mechanism flags, and the cipher flags, as well as any files to be + |            installed on the target machine, including the PKCS #11 module + |            library file and other files such as documentation. This is + |            covered in the JAR installation file section in the man page, + |            which details the special script needed to perform an installation + |            through a server or with modutil. + |    -list [modulename] + |            Display basic information about the contents of the secmod.db + |            file. Specifying a modulename displays detailed information about + |            a particular module and its slots and tokens. + |    -rawadd + |            Add the module spec string to the secmod.db database. + |    -rawlist + |            Display the module specs for a specified module or for all + |            loadable modules. + |    -undefault modulename + |            Specify the security mechanisms for which the named module will + |            not be a default provider. The security mechanisms are specified + |            with the -mechanisms argument. + |    Arguments + |    MODULE + |            Give the security module to access. + |    MODULESPEC + |            Give the security module spec to load into the security database. + |    -ciphers cipher-enable-list + |            Enable specific ciphers in a module that is being added to the + |            database. The cipher-enable-list is a colon-delimited list of + |            cipher names. Enclose this list in quotation marks if it contains + |            spaces. + |    -dbdir [sql:]directory + |            Specify the database directory in which to access or create + |            security module database files. + |            modutil supports two types of databases: the legacy security + |            databases (cert8.db, key3.db, and secmod.db) and new SQLite + |            databases (cert9.db, key4.db, and pkcs11.txt). If the prefix sql: + |            is not used, then the tool assumes that the given databases are in + |            the old format. + |    --dbprefix prefix + |            Specify the prefix used on the database files, such as my\_ for + |            my_cert8.db. This option is provided as a special case. Changing + |            the names of the certificate and key databases is not recommended. + |    -installdir root-installation-directory + |            Specify the root installation directory relative to which files + |            will be installed by the -jar option. This directory should be one + |            below which it is appropriate to store dynamic library files, such + |            as a server's root directory. + |    -libfile library-file + |            Specify a path to a library file containing the implementation of + |            the PKCS #11 interface module that is being added to the database. + |    -mechanisms mechanism-list + |            Specify the security mechanisms for which a particular module will + |            be flagged as a default provider. The mechanism-list is a + |            colon-delimited list of mechanism names. Enclose this list in + |            quotation marks if it contains spaces. + |            The module becomes a default provider for the listed mechanisms + |            when those mechanisms are enabled. If more than one module claims + |            to be a particular mechanism's default provider, that mechanism's + |            default provider is undefined. + |            modutil supports several mechanisms: RSA, DSA, RC2, RC4, RC5, AES, + |            DES, DH, SHA1, SHA256, SHA512, SSL, TLS, MD5, MD2, RANDOM (for + |            random number generation), and FRIENDLY (meaning certificates are + |            publicly readable). + |    -newpwfile new-password-file + |            Specify a text file containing a token's new or replacement + |            password so that a password can be entered automatically with the + |            -changepw option. + |    -nocertdb + |            Do not open the certificate or key databases. This has several + |            effects: + |               o With the -create command, only a module security file is + |                 created; certificate and key databases are not created. + |               o With the -jar command, signatures on the JAR file are not + |                 checked. + |               o With the -changepw command, the password on the NSS internal + |                 module cannot be set or changed, since this password is + |                 stored in the key database. + |    -pwfile old-password-file + |            Specify a text file containing a token's existing password so that + |            a password can be entered automatically when the -changepw option + |            is used to change passwords. + |    -secmod secmodname + |            Give the name of the security module database (like secmod.db) to + |            load. + |    -slot slotname + |            Specify a particular slot to be enabled or disabled with the + |            -enable or -disable options. + |    -string CONFIG_STRING + |            Pass a configuration string for the module being added to the + |            database. + |    -tempdir temporary-directory + |            Give a directory location where temporary files are created during + |            the installation by the -jar option. If no temporary directory is + |            specified, the current directory is used. + | Usage and Examples + |    Creating Database Files + |    Before any operations can be performed, there must be a set of security + |    databases available. modutil can be used to create these files. The only + |    required argument is the database that where the databases will be + |    located. + |  modutil -create -dbdir [sql:]directory + |    Adding a Cryptographic Module + |    Adding a PKCS #11 module means submitting a supporting library file, + |    enabling its ciphers, and setting default provider status for various + |    security mechanisms. This can be done by supplying all of the information + |    through modutil directly or by running a JAR file and install script. For + |    the most basic case, simply upload the library: + |  modutil -add modulename -libfile library-file [-ciphers cipher-enable-list] [-mechanisms + mechanism-list] + |    For example: + |  modutil -dbdir sql:/home/my/sharednssdb -add "Example PKCS #11 Module" -libfile + "/tmp/crypto.so" -mechanisms RSA:DSA:RC2:RANDOM + |  Using database directory ... + |  Module "Example PKCS #11 Module" added to database. + |    Installing a Cryptographic Module from a JAR File + |    PKCS #11 modules can also be loaded using a JAR file, which contains all + |    of the required libraries and an installation script that describes how to + |    install the module. The JAR install script is described in more detail in + |    [1]the section called “JAR Installation File Format”. + |    The JAR installation script defines the setup information for each + |    platform that the module can be installed on. For example: + |  Platforms { + |     Linux:5.4.08:x86 { + |        ModuleName { "Example PKCS #11 Module" } + |        ModuleFile { crypto.so } + |        DefaultMechanismFlags{0x0000} + |        CipherEnableFlags{0x0000} + |        Files { + |           crypto.so { + |              Path{ /tmp/crypto.so } + |           } + |           setup.sh { + |              Executable + |              Path{ /tmp/setup.sh } + |           } + |        } + |     } + |     Linux:6.0.0:x86 { + |        EquivalentPlatform { Linux:5.4.08:x86 } + |     } + |  } + |    Both the install script and the required libraries must be bundled in a + |    JAR file, which is specified with the -jar argument. + |  modutil -dbdir sql:/home/mt"jar-install-filey/sharednssdb -jar install.jar -installdir + sql:/home/my/sharednssdb + |  This installation JAR file was signed by: + |  ---------------------------------------------- + |  **SUBJECT NAME*\* + |  C=US, ST=California, L=Mountain View, CN=Cryptorific Inc., OU=Digital ID + |  Class 3 - Netscape Object Signing, OU="www.verisign.com/repository/CPS + |  Incorp. by Ref.,LIAB.LTD(c)9 6", OU=www.verisign.com/CPS Incorp.by Ref + |  . LIABILITY LTD.(c)97 VeriSign, OU=VeriSign Object Signing CA - Class 3 + |  Organization, OU="VeriSign, Inc.", O=VeriSign Trust Network \**ISSUER + |  NAME**, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 + |  VeriSign, OU=VeriSign Object Signing CA - Class 3 Organization, + |  OU="VeriSign, Inc.", O=VeriSign Trust Network + |  ---------------------------------------------- + |  Do you wish to continue this installation? (y/n) y + |  Using installer script "installer_script" + |  Successfully parsed installation script + |  Current platform is Linux:5.4.08:x86 + |  Using installation parameters for platform Linux:5.4.08:x86 + |  Installed file crypto.so to /tmp/crypto.so + |  Installed file setup.sh to ./pk11inst.dir/setup.sh + |  Executing "./pk11inst.dir/setup.sh"... + |  "./pk11inst.dir/setup.sh" executed successfully + |  Installed module "Example PKCS #11 Module" into module database + |  Installation completed successfully + |    Adding Module Spec + |    Each module has information stored in the security database about its + |    configuration and parameters. These can be added or edited using the + |    -rawadd command. For the current settings or to see the format of the + |    module spec in the database, use the -rawlist option. + |  modutil -rawadd modulespec + |    Deleting a Module + |    A specific PKCS #11 module can be deleted from the secmod.db database: + |  modutil -delete modulename -dbdir [sql:]directory + |    Displaying Module Information + |    The secmod.db database contains information about the PKCS #11 modules + |    that are available to an application or server to use. The list of all + |    modules, information about specific modules, and database configuration + |    specs for modules can all be viewed. + |    To simply get a list of modules in the database, use the -list command. + |  modutil -list [modulename] -dbdir [sql:]directory + |    Listing the modules shows the module name, their status, and other + |    associated security databases for certificates and keys. For example: + |  modutil -list -dbdir sql:/home/my/sharednssdb + |  Listing of PKCS #11 Modules + |  ----------------------------------------------------------- + |    1. NSS Internal PKCS #11 Module + |           slots: 2 slots attached + |          status: loaded + |           slot: NSS Internal Cryptographic Services + |          token: NSS Generic Crypto Services + |           slot: NSS User Private Key and Certificate Services + |          token: NSS Certificate DB + |  ----------------------------------------------------------- + |    Passing a specific module name with the -list returns details information + |    about the module itself, like supported cipher mechanisms, version + |    numbers, serial numbers, and other information about the module and the + |    token it is loaded on. For example: + |   modutil -list "NSS Internal PKCS #11 Module" -dbdir sql:/home/my/sharednssdb + |  ----------------------------------------------------------- + |  Name: NSS Internal PKCS #11 Module + |  Library file: \**Internal ONLY module*\* + |  Manufacturer: Mozilla Foundation + |  Description: NSS Internal Crypto Services + |  PKCS #11 Version 2.20 + |  Library Version: 3.11 + |  Cipher Enable Flags: None + |  Default Mechanism Flags: RSA:RC2:RC4:DES:DH:SHA1:MD5:MD2:SSL:TLS:AES + |    Slot: NSS Internal Cryptographic Services + |    Slot Mechanism Flags: RSA:RC2:RC4:DES:DH:SHA1:MD5:MD2:SSL:TLS:AES + |    Manufacturer: Mozilla Foundation + |    Type: Software + |    Version Number: 3.11 + |    Firmware Version: 0.0 + |    Status: Enabled + |    Token Name: NSS Generic Crypto Services + |    Token Manufacturer: Mozilla Foundation + |    Token Model: NSS 3 + |    Token Serial Number: 0000000000000000 + |    Token Version: 4.0 + |    Token Firmware Version: 0.0 + |    Access: Write Protected + |    Login Type: Public (no login required) + |    User Pin: NOT Initialized + |    Slot: NSS User Private Key and Certificate Services + |    Slot Mechanism Flags: None + |    Manufacturer: Mozilla Foundation + |    Type: Software + |    Version Number: 3.11 + |    Firmware Version: 0.0 + |    Status: Enabled + |    Token Name: NSS Certificate DB + |    Token Manufacturer: Mozilla Foundation + |    Token Model: NSS 3 + |    Token Serial Number: 0000000000000000 + |    Token Version: 8.3 + |    Token Firmware Version: 0.0 + |    Access: NOT Write Protected + |    Login Type: Login required + |    User Pin: Initialized + |    A related command, -rawlist returns information about the database + |    configuration for the modules. (This information can be edited by loading + |    new specs using the -rawadd command.) + |   modutil -rawlist -dbdir sql:/home/my/sharednssdb + |   name="NSS Internal PKCS #11 Module" parameters="configdir=. certPrefix= keyPrefix= + secmod=secmod.db flags=readOnly " NSS="trustOrder=75 cipherOrder=100 + slotParams={0x00000001=[slotFlags=RSA,RC4,RC2,DES,DH,SHA1,MD5,MD2,SSL,TLS,AES,RANDOM askpw=any + timeout=30 ] }  Flags=internal,critical" + |    Setting a Default Provider for Security Mechanisms + |    Multiple security modules may provide support for the same security + |    mechanisms. It is possible to set a specific security module as the + |    default provider for a specific security mechanism (or, conversely, to + |    prohibit a provider from supplying those mechanisms). + |  modutil -default modulename -mechanisms mechanism-list + |    To set a module as the default provider for mechanisms, use the -default + |    command with a colon-separated list of mechanisms. The available + |    mechanisms depend on the module; NSS supplies almost all common + |    mechanisms. For example: + |  modutil -default "NSS Internal PKCS #11 Module" -dbdir -mechanisms RSA:DSA:RC2 + |  Using database directory c:\databases... + |  Successfully changed defaults. + |    Clearing the default provider has the same format: + |  modutil -undefault "NSS Internal PKCS #11 Module" -dbdir -mechanisms MD2:MD5 + |    Enabling and Disabling Modules and Slots + |    Modules, and specific slots on modules, can be selectively enabled or + |    disabled using modutil. Both commands have the same format: + |  modutil -enable|-disable modulename [-slot slotname] + |    For example: + |  modutil -enable "NSS Internal PKCS #11 Module" -slot "NSS Internal Cryptographic + Services                            " -dbdir . + |  Slot "NSS Internal Cryptographic Services                            " enabled. + |    Be sure that the appropriate amount of trailing whitespace is after the + |    slot name. Some slot names have a significant amount of whitespace that + |    must be included, or the operation will fail. + |    Enabling and Verifying FIPS Compliance + |    The NSS modules can have FIPS 140-2 compliance enabled or disabled using + |    modutil with the -fips option. For example: + |  modutil -fips true -dbdir sql:/home/my/sharednssdb/ + |  FIPS mode enabled. + |    To verify that status of FIPS mode, run the -chkfips command with either a + |    true or false flag (it doesn't matter which). The tool returns the current + |    FIPS setting. + |  modutil -chkfips false -dbdir sql:/home/my/sharednssdb/ + |  FIPS mode enabled. + |    Changing the Password on a Token + |    Initializing or changing a token's password: + |  modutil -changepw tokenname [-pwfile old-password-file] [-newpwfile new-password-file] + |  modutil -dbdir sql:/home/my/sharednssdb -changepw "NSS Certificate DB" + |  Enter old password: + |  Incorrect password, try again... + |  Enter old password: + |  Enter new password: + |  Re-enter new password: + |  Token "Communicator Certificate DB" password changed successfully. + | JAR Installation File Format + |    When a JAR file is run by a server, by modutil, or by any program that + |    does not interpret JavaScript, a special information file must be included + |    to install the libraries. There are several things to keep in mind with + |    this file: + |      o It must be declared in the JAR archive's manifest file. + |      o The script can have any name. + |      o The metainfo tag for this is Pkcs11_install_script. To declare + |        meta-information in the manifest file, put it in a file that is passed + |        to signtool. + |    Sample Script + |    For example, the PKCS #11 installer script could be in the file + |    pk11install. If so, the metainfo file for signtool includes a line such as + |    this: + |  + Pkcs11_install_script: pk11install + |    The script must define the platform and version number, the module name + |    and file, and any optional information like supported ciphers and + |    mechanisms. Multiple platforms can be defined in a single install file. + |  ForwardCompatible { IRIX:6.2:mips SUNOS:5.5.1:sparc } + |  Platforms { + |     WINNT::x86 { + |        ModuleName { "Example Module" } + |        ModuleFile { win32/fort32.dll } + |        DefaultMechanismFlags{0x0001} + |        DefaultCipherFlags{0x0001} + |        Files { + |           win32/setup.exe { + |              Executable + |              RelativePath { %temp%/setup.exe } + |           } + |           win32/setup.hlp { + |              RelativePath { %temp%/setup.hlp } + |           } + |           win32/setup.cab { + |              RelativePath { %temp%/setup.cab } + |           } + |        } + |     } + |     WIN95::x86 { + |        EquivalentPlatform {WINNT::x86} + |     } + |     SUNOS:5.5.1:sparc { + |        ModuleName { "Example UNIX Module" } + |        ModuleFile { unix/fort.so } + |        DefaultMechanismFlags{0x0001} + |        CipherEnableFlags{0x0001} + |        Files { + |           unix/fort.so { + |              RelativePath{%root%/lib/fort.so} + |              AbsolutePath{/usr/local/netscape/lib/fort.so} + |              FilePermissions{555} + |           } + |           xplat/instr.html { + |              RelativePath{%root%/docs/inst.html} + |              AbsolutePath{/usr/local/netscape/docs/inst.html} + |              FilePermissions{555} + |           } + |        } + |     } + |     IRIX:6.2:mips { + |        EquivalentPlatform { SUNOS:5.5.1:sparc } + |     } + |  } + |    Script Grammar + |    The script is basic Java, allowing lists, key-value pairs, strings, and + |    combinations of all of them. + |  --> valuelist + |  valuelist --> value valuelist + |                 + |  value ---> key_value_pair + |              string + |  key_value_pair --> key { valuelist } + |  key --> string + |  string --> simple_string + |              "complex_string" + |  simple_string --> [^ \\t\n\""{""}"]+ + |  complex_string --> ([^\"\\\r\n]|(\\\")|(\\\\))+ + |    Quotes and backslashes must be escaped with a backslash. A complex string + |    must not include newlines or carriage returns.Outside of complex strings, + |    all white space (for example, spaces, tabs, and carriage returns) is + |    considered equal and is used only to delimit tokens. + |    Keys + |    The Java install file uses keys to define the platform and module + |    information. + |    ForwardCompatible gives a list of platforms that are forward compatible. + |    If the current platform cannot be found in the list of supported + |    platforms, then the ForwardCompatible list is checked for any platforms + |    that have the same OS and architecture in an earlier version. If one is + |    found, its attributes are used for the current platform. + |    Platforms (required) Gives a list of platforms. Each entry in the list is + |    itself a key-value pair: the key is the name of the platform and the value + |    list contains various attributes of the platform. The platform string is + |    in the format system name:OS release:architecture. The installer obtains + |    these values from NSPR. OS release is an empty string on non-Unix + |    operating systems. NSPR supports these platforms: + |      o AIX (rs6000) + |      o BSDI (x86) + |      o FREEBSD (x86) + |      o HPUX (hppa1.1) + |      o IRIX (mips) + |      o LINUX (ppc, alpha, x86) + |      o MacOS (PowerPC) + |      o NCR (x86) + |      o NEC (mips) + |      o OS2 (x86) + |      o OSF (alpha) + |      o ReliantUNIX (mips) + |      o SCO (x86) + |      o SOLARIS (sparc) + |      o SONY (mips) + |      o SUNOS (sparc) + |      o UnixWare (x86) + |      o WIN16 (x86) + |      o WIN95 (x86) + |      o WINNT (x86) + |    For example: + |  IRIX:6.2:mips + |  SUNOS:5.5.1:sparc + |  Linux:2.0.32:x86 + |  WIN95::x86 + |    The module information is defined independently for each platform in the + |    ModuleName, ModuleFile, and Files attributes. These attributes must be + |    given unless an EquivalentPlatform attribute is specified. + |    Per-Platform Keys + |    Per-platform keys have meaning only within the value list of an entry in + |    the Platforms list. + |    ModuleName (required) gives the common name for the module. This name is + |    used to reference the module by servers and by the modutil tool. + |    ModuleFile (required) names the PKCS #11 module file for this platform. + |    The name is given as the relative path of the file within the JAR archive. + |    Files (required) lists the files that need to be installed for this + |    module. Each entry in the file list is a key-value pair. The key is the + |    path of the file in the JAR archive, and the value list contains + |    attributes of the file. At least RelativePath or AbsolutePath must be + |    specified for each file. + |    DefaultMechanismFlags specifies mechanisms for which this module is the + |    default provider; this is equivalent to the -mechanism option with the + |    -add command. This key-value pair is a bitstring specified in hexadecimal + |    (0x) format. It is constructed as a bitwise OR. If the + |    DefaultMechanismFlags entry is omitted, the value defaults to 0x0. + |  RSA:                   0x00000001 + |  DSA:                   0x00000002 + |  RC2:                   0x00000004 + |  RC4:                   0x00000008 + |  DES:                   0x00000010 + |  DH:                    0x00000020 + |  FORTEZZA:              0x00000040 + |  RC5:                   0x00000080 + |  SHA1:                  0x00000100 + |  MD5:                   0x00000200 + |  MD2:                   0x00000400 + |  RANDOM:                0x08000000 + |  FRIENDLY:              0x10000000 + |  OWN_PW_DEFAULTS:       0x20000000 + |  DISABLE:               0x40000000 + |    CipherEnableFlags specifies ciphers that this module provides that NSS + |    does not provide (so that the module enables those ciphers for NSS). This + |    is equivalent to the -cipher argument with the -add command. This key is a + |    bitstring specified in hexadecimal (0x) format. It is constructed as a + |    bitwise OR. If the CipherEnableFlags entry is omitted, the value defaults + |    to 0x0. + |    EquivalentPlatform specifies that the attributes of the named platform + |    should also be used for the current platform. This makes it easier when + |    more than one platform uses the same settings. + |    Per-File Keys + |    Some keys have meaning only within the value list of an entry in a Files + |    list. + |    Each file requires a path key the identifies where the file is. Either + |    RelativePath or AbsolutePath must be specified. If both are specified, the + |    relative path is tried first, and the absolute path is used only if no + |    relative root directory is provided by the installer program. + |    RelativePath specifies the destination directory of the file, relative to + |    some directory decided at install time. Two variables can be used in the + |    relative path: %root% and %temp%. %root% is replaced at run time with the + |    directory relative to which files should be installed; for example, it may + |    be the server's root directory. The %temp% directory is created at the + |    beginning of the installation and destroyed at the end. The purpose of + |    %temp% is to hold executable files (such as setup programs) or files that + |    are used by these programs. Files destined for the temporary directory are + |    guaranteed to be in place before any executable file is run; they are not + |    deleted until all executable files have finished. + |    AbsolutePath specifies the destination directory of the file as an + |    absolute path. + |    Executable specifies that the file is to be executed during the course of + |    the installation. Typically, this string is used for a setup program + |    provided by a module vendor, such as a self-extracting setup executable. + |    More than one file can be specified as executable, in which case the files + |    are run in the order in which they are specified in the script file. + |    FilePermissions sets permissions on any referenced files in a string of + |    octal digits, according to the standard Unix format. This string is a + |    bitwise OR. + |  user read:                0400 + |  user write:               0200 + |  user execute:             0100 + |  group read:               0040 + |  group write:              0020 + |  group execute:            0010 + |  other read:               0004 + |  other write:              0002 + |  other execute:       0001 + |    Some platforms may not understand these permissions. They are applied only + |    insofar as they make sense for the current platform. If this attribute is + |    omitted, a default of 777 is assumed. + | NSS Database Types + |    NSS originally used BerkeleyDB databases to store security information. + |    The last versions of these legacy databases are: + |      o cert8.db for certificates + |      o key3.db for keys + |      o secmod.db for PKCS #11 module information + |    BerkeleyDB has performance limitations, though, which prevent it from + |    being easily used by multiple applications simultaneously. NSS has some + |    flexibility that allows applications to use their own, independent + |    database engine while keeping a shared database and working around the + |    access issues. Still, NSS requires more flexibility to provide a truly + |    shared security database. + |    In 2009, NSS introduced a new set of databases that are SQLite databases + |    rather than BerkleyDB. These new databases provide more accessibility and + |    performance: + |      o cert9.db for certificates + |      o key4.db for keys + |      o pkcs11.txt, which is listing of all of the PKCS #11 modules contained + |        in a new subdirectory in the security databases directory + |    Because the SQLite databases are designed to be shared, these are the + |    shared database type. The shared database type is preferred; the legacy + |    format is included for backward compatibility. + |    By default, the tools (certutil, pk12util, modutil) assume that the given + |    security databases follow the more common legacy type. Using the SQLite + |    databases must be manually specified by using the sql: prefix with the + |    given security directory. For example: + |  modutil -create -dbdir sql:/home/my/sharednssdb + |    To set the shared database type as the default type for the tools, set the + |    NSS_DEFAULT_DB_TYPE environment variable to sql: + |  export NSS_DEFAULT_DB_TYPE="sql" + |    This line can be set added to the ~/.bashrc file to make the change + |    permanent. + |    Most applications do not use the shared database by default, but they can + |    be configured to use them. For example, this how-to article covers how to + |    configure Firefox and Thunderbird to use the new shared NSS databases: + |      o https://wiki.mozilla.org/NSS_Shared_DB_Howto + |    For an engineering draft on the changes in the shared NSS databases, see + |    the NSS project wiki: + |      o https://wiki.mozilla.org/NSS_Shared_DB + | See Also + |    certutil (1) + |    pk12util (1) + |    signtool (1) + |    The NSS wiki has information on the new database design and how to + |    configure applications to use it. + |      o https://wiki.mozilla.org/NSS_Shared_DB_Howto + |      o https://wiki.mozilla.org/NSS_Shared_DB + | Additional Resources + |    For information about NSS and other tools related to NSS (like JSS), check + |    out the NSS project wiki at + |    + [2]\ `http://www.mozilla.org/projects/security/pki/nss/ `__. + The NSS site relates + |    directly to NSS code changes and releases. + |    Mailing lists: https://lists.mozilla.org/listinfo/dev-tech-crypto + |    IRC: Freenode at #dogtag-pki + | Authors + |    The NSS tools were written and maintained by developers with Netscape, Red + |    Hat, and Sun. + |    Authors: Elio Maldonado , Deon Lackey + |    . + | Copyright + |    (c) 2010, Red Hat, Inc. Licensed under the GNU Public License version 2. + | References + |    Visible links + |    1. JAR Installation File Format + |     ``file:///tmp/xmlto.6gGxS0/modutil.pro...r-install-file`` + |    2. https://www.mozilla.org/projects/security/pki/nss/ \ No newline at end of file -- cgit v1.2.3