- Implemented the GostKeyValue class for handling public key parameters in ГОСТ Р 34.10 digital signatures. - Created the GostSignedXml class to manage XML signatures using ГОСТ 34.10, including methods for computing and checking signatures. - Developed the GostSignedXmlImpl class to encapsulate the signature computation logic and public key retrieval. - Added specific key value classes for ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2012/256, and ГОСТ Р 34.10-2012/512 to support different signature algorithms. - Ensured compatibility with existing XML signature standards while integrating ГОСТ cryptography.
57 lines
2.4 KiB
Markdown
57 lines
2.4 KiB
Markdown
# CLI Task Pack SSO Profiles
|
||
|
||
Task Pack workflows rely on purpose-scoped Authority clients. To streamline local logins and CI/CD automation, define StellaOps CLI profiles under `~/.stellaops/profiles` so `stella auth login` automatically requests the correct scopes.
|
||
|
||
Profiles are simple YAML files that map onto the CLI configuration schema. Set `STELLA_PROFILE=<name>` (or pass `--profile <name>` once the CLI exposes the switch) before invoking `stella` to load the profile.
|
||
|
||
## Example profiles
|
||
|
||
### Packs operator (`~/.stellaops/profiles/packs-operator.yaml`)
|
||
|
||
```yaml
|
||
StellaOps:
|
||
Authority:
|
||
Url: https://authority.example.com
|
||
ClientId: pack-operator
|
||
ClientSecretFile: ~/.stellaops/secrets/pack-operator.secret
|
||
Scope: "packs.read packs.run"
|
||
TokenCacheDirectory: ~/.stellaops/tokens
|
||
BackendUrl: https://task-runner.example.com
|
||
```
|
||
|
||
### Packs publisher (`~/.stellaops/profiles/packs-publisher.yaml`)
|
||
|
||
```yaml
|
||
StellaOps:
|
||
Authority:
|
||
Url: https://authority.example.com
|
||
ClientId: packs-registry
|
||
ClientSecretFile: ~/.stellaops/secrets/packs-registry.secret
|
||
Scope: "packs.read packs.write"
|
||
TokenCacheDirectory: ~/.stellaops/tokens
|
||
BackendUrl: https://packs-registry.example.com
|
||
```
|
||
|
||
### Packs approver (`~/.stellaops/profiles/packs-approver.yaml`)
|
||
|
||
```yaml
|
||
StellaOps:
|
||
Authority:
|
||
Url: https://authority.example.com
|
||
ClientId: pack-approver
|
||
ClientSecretFile: ~/.stellaops/secrets/pack-approver.secret
|
||
Scope: "packs.read packs.approve"
|
||
TokenCacheDirectory: ~/.stellaops/tokens
|
||
BackendUrl: https://task-runner.example.com
|
||
```
|
||
|
||
## Usage
|
||
|
||
1. Create the profile file under `~/.stellaops/profiles/<name>.yaml`.
|
||
2. Store the matching client secret in the referenced path (or set `ClientSecret` for development).
|
||
3. Export `STELLA_PROFILE=<name>` before running `stella auth login` or individual pack commands.
|
||
|
||
The CLI reads the profile, applies the Authority configuration, and requests the listed scopes so the resulting tokens satisfy Task Runner and Packs Registry expectations.
|
||
|
||
> **Pack approval tip** – `stella pack approve` now relays `--pack-run-id`, `--pack-gate-id`, and `--pack-plan-hash` to Authority whenever it asks for `packs.approve`. Profiles don’t store these values (they change per run), but keeping the approver profile loaded ensures the CLI can prompt for the metadata, validate it against the plan hash, and satisfy the Authority procedure documented in `docs/task-packs/runbook.md#4-approvals-workflow`.
|