Configuration Specification

[fraxken]

The objective of the issue is to discuss the content and format of the NodeSecure configuration file. This configuration can be used in multiple projects:

• NodeSecure CLI
• Report
• In CI
• etc...

To discuss here:

• file name: nodesecurerc ?
• format: .json, .toml ?
• default required keys ? (in which version the configuration is, for example).
• How to code the first draft.

[fraxken]

Personally I would recommend the use of my package SlimIO/Config. I haven't had time to update the package for a while but I still maintain it.

It has many features such as support for JSON Schema and is capable to read JSON and TOML format automatically.

This would avoid having to redevelop those features.

[fraxken]

For me a first version should be capable of:

• read or fail.
• read or create.
• create or fail.
• write (update) or fail.

Note: SlimIO/config help a lot for those actions.

I guess each version should have is own "JSON Schema", so we can develop an upgrade method that work with fast-json-patch.

[tony-go]

Hi 👋 everyone,

Good idea to use config parser from SlimIO:

• file name: .nodesecurerc

• format: I really like YAML or JSON

• default required keys ?: IMO, if the file doesn't exist, the package should return a bunch of default values. Obviously, the config could be overwritten by the consumer of this package.

• How to code the first draft: there is a lot of approaches, what comes to me is, a block for

  • parsing (SlimIO lib)
  • validation wich a specific payload with semantic instead of throwing

  type ConfigResult<T> = Record<PropertyName, PropertyResult<T>>;
  
  type PropertyName = string;
  
  interface PropertyResult<T> = {
    value: T,
    error?: Error,
    ok: boolean
  }

  • outputs:
    • validation one (with the results types)
    • simple object one (with null values/default values is something was wrong)

And a good documentation 😜

[antoine-coulon]

Hello guys, sorry about the input delay.

• File name: nodesecurerc

• Format: I would say JSON, pretty straightforward (especially if we use SlimIO/config) and most widely used in the ecosystem.

• Default required keys? I agree with @tony-go about default values, the runtime configuration as a file should not be mandatory in the first place. Eventually, we could provide a way to initialize a root file yarn nodesecure init and this auto-generated file would contain the default required keys.
  Whatever the chosen solution is, I think we should in the first place discuss about what type of customization could be valuable for the consumer. We surely don't want to integrate too many implementation details, the first rule I would suggest about the configuration is that it should be very high level and understandable for people who aren't experts in security

• How to code the first draft :

1. Read/parse file (SlimIO/Config)
2. Provide either a default runtime configuration, or create a default nodesecurerc (if no file is present)
3. File validation

[fraxken]

PR #2 created

[fraxken]

Version 1.0.0 available!