Module: Rootstore

About this module

The rootstore module contains all the root certificates embedded in Opera as well as all relevant information, as well as the functionality needed to add these certificates to an installed Opera's repository.

There are two different modes for the the distribuition: A hardcoded list stored in the browser, and an optional remote storage hosted on the server certs.opera.com. The remote storage also contains the EV OID database. The serverside implementation is documented here, and the client side autoupdate functionality is maintained by the libssl module

Interface overview and API documentation

The primary API for the rootstore module is

g_root_store_api
This object is used to access the function(s) defined in the module for intializing the root certificate database of a SSL_Options object (See Libssl module for more information).

Implementation description

When called the initalization function processes a list of active certificates, verifies that the certificates are valid, then inserts them in the database with the associated flags.

When the database has already been initialized only certificates added after the database's version are added (provided thatthey are not already installed)

A part of the module will be used to produce online updates of the embedded roots, as well as data used to check Extended Validation certificates

Footprint

The module is fairly large due to the size of each certificate (usually 1 to 3 KB, depending on the keysize and number of extensions in the certificate) embedded in the running executable. This size cannot be significantly reduced by compresion because the certificate contain encrypted (random) information.

Dynamic memory use and OOM handling

The module uses almost exclusively allocated memory in its operation, most of these have a relatively short lifespan. The structures with the longest timespans are the certificate items added to the database in the SSL_Options manager, and these are cleaned up when the object is destroyed.

OOM policies

The database will not complete individual certificate embeddings that fail to allocate memory, but will try to complete as many as possiblem. This can result in incomplete databases

Who handles OOM?

The module's code report some OOM situations as OP_STATUS indications, others are handled as gracefullay as possible

Flow

The module has a single pass through main function. The rest are module object initialization/cleanup code

Heap memory usage
Stack memory usage

The module uses little stack space, but may create various temporary vectors and dataprocessing objects, which may exceed 200 bytes.

Static memory usage

There is a single large hardcoded table, the root certificate array in defcert.cpp (via rootstore-table.h), which probably exceeds 80 KB. This may be duplicated by the selftest

On some platforms this array may be implemented as an allocated array with runtime initialization, but the array is deleted immediately after use.

Freeing memory on exit

The allocated global API object is destroyed by the module destruction.

Temp buffers

No temporary buffers are used

Memory tuning

It is not possible to tune the module's memory usage.

Tests

Selftests

Coverage

Selftest, or open the SSL preferences on a new installation.

Design choices

The certificates are stored internally in the executable.

Improvements

Most or all of the database can be moved to a remote download location reducing the executable size considerably. Work on this is underway.