anchor.diff:  passphrases which are required on every use. We recommend encrypting the
   keys in the config with PEM encryption, config_updater will then ask for
   the passphrase when they are used. An alternative is to keep a separate
  -offline config that contains the private keys.
  +offline config that contains the private keys. 
  +
   
   Agent Protection.
   ~~~~~~~~~~~~~~~~~
  
positive.code: exec, but may well provide it indirectly via read access to important keys and
  passwords on disk or in memory.].
  However, there are a number of use cases where it makes sense to have GRR
  execute arbitrary code as explained in the section Deploying custom drivers
  and code.
  
  However, as part of the GRR design, we decided that administrative control of
  the GRR server shouldn't trivially lead to code execution on the clients. As
  such, we have a separate set of keys for driver signing and code signing.
  For a driver to be loaded, or binary to be run the code has to be signed by
  the specific key, the client will confirm this signature before execution.
  
  In the default install, the driver and code signing private keys are not
  passphrase protected. In a secure environment we strongly recommended
  
negative.code: 
  Deploying Custom Drivers and Code.
  ----------------------------------
  Drivers, binaries or python code can be pushed from the server to the clients
  to enable new functionality. This has a number of use cases, such as:
  
  