zydronium/google-nomulus
1
0
Fork 0
mirror of https://github.com/google/nomulus.git synced 2025-08-04 08:52:12 +02:00
Code Issues Projects Releases Packages Wiki Activity

Replace VoidKeyring with InMemoryKeyring and a dummy module

Browse source 
VoidKeyring always threw exceptions whenever any of its methods were called,
which caused several parts of the system to fail early (and thus required a
proper Keyring to be implemented almost immediately, early on in the "just
playing around with the system" phase).

I'm swapping this out with an InMemoryKeyring which is supplied by
DummyKeyringModule, which, instead of throwing exceptions, returns dummy
values, delaying the onset of errors to when connecting to external services
is attempted.  This pushes off the required implementation of a real Keyring-
providing module, allowing the system to be played around with more first.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132361157
This commit is contained in:
mcilwain 2016-09-06 14:16:08 -07:00 • committed by Ben McIlwain
parent 27dfe358ce
commit 3b4b7a475b
12 changed files with 326 additions and 171 deletions
Download patch file Download diff file Expand all files Collapse all files

32
docs/configuration.md
View file

@ -87,26 +87,24 @@ control mishap. We use a secret store to persist these values in a secure
manner, and abstract access to them using the `Keyring` interface.
The `Keyring` interface contains methods for all sensitive configuration values,
which are primarily credentials used to access various ICANN and
ICANN-affiliated services (such as RDE). These values are only needed for real
which are primarily credentials used to access various ICANN and ICANN-
affiliated services (such as RDE). These values are only needed for real
production registries and PDT environments. If you are just playing around with
the platform at first, it is OK to put off defining these values until
necessary. To that end, a `VoidKeyring` implementation is provided that simply
throws an `UnsupportedOperationException` whenever any code attempts to load a
secret key. This allows the codebase to compile, but of course any actions that
attempt to connect to these services will error out because the keys won't be
present.
necessary. To that end, a `DummyKeyringModule` is included that simply provides
an `InMemoryKeyring` populated with dummy values for all secret keys. This
allows the codebase to compile and run, but of course any actions that attempt
to connect to external services will fail because none of the keys are real.
`KeyModule` is a Dagger module that is used to provide injected values for all
of the sensitive configuration options. Each `@Provides` method requires a
`Keyring` instance. In the code release, a stub implementation in the form of
`VoidKeyring` is provided by the `VoidKeyringModule`. To configure a production
registry system, you will need to write your own module to provide your own
`Keyring` implementation (which you will also need to write), and replace the
usage of `VoidKeyringModule` with your own module in all of the per-service
components in which it is referenced. The functions in `PgpHelper` will likely
prove useful for loading keys stored in PGP format into the PGP key classes that
you'll need to provide from `Keyring`.
To configure a production registry system, you will need to write a replacement
module for `DummyKeyringModule` that loads the credentials in a secure way, and
provides them using either an instance of `InMemoryKeyring` or your own custom
implementation of `Keyring`. You then need to replace all usages of
`DummyKeyringModule` with your own module in all of the per-service components
in which it is referenced. The functions in `PgpHelper` will likely prove
useful for loading keys stored in PGP format into the PGP key classes that
you'll need to provide from `Keyring`, and you can see examples of them in
action in `DummyKeyringModule`.
## Per-TLD configuration