<commit_before>SHIELD Roadmap
==============

This document contains the current SHIELD Roadmap, a set of things
we hope to accomplish, features we hope to implement, and code
management / maintenance efforts we hope to undertake in 2017/18.

Roadmap items are listed in order of importance, roughly.  If you
would like to see ammendments to this Roadmap, please discuss them
in the [#shield Slack channel][1]

Encryption of Archives
----------------------

For security and peace of mind, operators would like to have their
backup archives encrypted, prior to storage in the backend storage
system.  Key features:

**Upgradable Encryption** - As time moves on, operators will need
to be able to upgrade to stronger cryptographic primitives as
current best-practice algorithms are broken and fall out of favor.
These changes must only affect future archives, such that extant
archives are still able to be decrypted using the same algorithm
that they were encrypted with.

**Managed Key Rotation** - Ideally, each backup task would get a
new encryption key to mitigate the damage of a leaked key.  The
"smoking hole" scenario presents some interesting challenges with
regards to restoring the SHIELD database (and by extension, all
encryption keys) from nothing.

User-Driven Backup and Restore
------------------------------

Currently, SHIELD has a flat access model, an all-or-nothing
proposition for review and management of jobs, tasks, archives,
etc.

We would like to move to a more robust access model that permits
individual customers, be they operators or develoeprs, to view and
control a limited subset of the data set, and effect backup and
restore operations on owned jobs and target systems.

Ideally, non-administrator users will be able to:

  - Create stores, targets, and retention policies
  - Schedule and run backup jobs
  - Restore their data from their backup archives
  - Review logs for scheduled and ad hoc tasks
  - Utilize global stores, targets, and policies

Both the web interface and the `shield` command-line utility will
need to support this isolation of resources.

In addition to user-level access, SHIELD needs to support _teams_,
allowing multiple users to share management of a set of resources.

Documentation
-------------<commit_msg>Fix small typo in ROADMAP.md<commit_after>SHIELD Roadmap
==============

This document contains the current SHIELD Roadmap, a set of things
we hope to accomplish, features we hope to implement, and code
management / maintenance efforts we hope to undertake in 2017/18.

Roadmap items are listed in order of importance, roughly.  If you
would like to see ammendments to this Roadmap, please discuss them
in the [#shield Slack channel][1]

Encryption of Archives
----------------------

For security and peace of mind, operators would like to have their
backup archives encrypted, prior to storage in the backend storage
system.  Key features:

**Upgradable Encryption** - As time moves on, operators will need
to be able to upgrade to stronger cryptographic primitives as
current best-practice algorithms are broken and fall out of favor.
These changes must only affect future archives, such that extant
archives are still able to be decrypted using the same algorithm
that they were encrypted with.

**Managed Key Rotation** - Ideally, each backup task would get a
new encryption key to mitigate the damage of a leaked key.  The
"smoking hole" scenario presents some interesting challenges with
regards to restoring the SHIELD database (and by extension, all
encryption keys) from nothing.

User-Driven Backup and Restore
------------------------------

Currently, SHIELD has a flat access model, an all-or-nothing
proposition for review and management of jobs, tasks, archives,
etc.

We would like to move to a more robust access model that permits
individual customers, be they operators or developers, to view and
control a limited subset of the data set, and effect backup and
restore operations on owned jobs and target systems.

Ideally, non-administrator users will be able to:

  - Create stores, targets, and retention policies
  - Schedule and run backup jobs
  - Restore their data from their backup archives
  - Review logs for scheduled and ad hoc tasks
  - Utilize global stores, targets, and policies

Both the web interface and the `shield` command-line utility will
need to support this isolation of resources.

In addition to user-level access, SHIELD needs to support _teams_,
allowing multiple users to share management of a set of resources.

Documentation
-------------
{'fraction_non_alphanumeric': 0.06853514342018831, 'fraction_numerical': 0.003065469673746442, 'mean_word_length': 3.9224137931034484, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '281108', 'n_tokens_mistral': 1138, 'n_tokens_neox': 1069, 'n_words': 666}