Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
186 changes: 93 additions & 93 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,19 +1,19 @@
# PastureStack Web Console
Web Console provides the browser interface for compatible environments, hosts, stacks, services, containers, catalogs, storage, networking, access control, and administration.
PastureStack is an independent community effort to preserve, audit, and modernize the Rancher 1.6 ecosystem. It is not affiliated with or endorsed by Rancher Labs or SUSE.
**Upstream:** [`rancher/ui`](https://github.com/rancher/ui), preserved from its `1.6-dev` line. This GitHub fork retains upstream history, authorship, dates, tags, licenses, and dependency notices. PastureStack maintenance is consolidated into one commit after the preserved upstream boundary.
## Project status
# PastureStack Web Console

Web Console provides the browser interface for compatible environments, hosts, stacks, services, containers, catalogs, storage, networking, access control, and administration.

PastureStack is an independent community effort to preserve, audit, and modernize the Rancher 1.6 ecosystem. It is not affiliated with or endorsed by Rancher Labs or SUSE.

**Upstream:** [`rancher/ui`](https://github.com/rancher/ui), preserved from its `1.6-dev` line. This GitHub fork retains upstream history, authorship, dates, tags, licenses, and dependency notices. PastureStack maintenance is consolidated into one commit after the preserved upstream boundary.

## Project status

The current compatibility release is `1.6.105`. It retains the existing Node 24, Ember, Sass,
dependency, browser-smoke, terminal, console, and test-harness modernization.
It adds a provider-neutral OpenID Connect administration and sign-in flow with
PKCE S256, staged configuration validation, a real test login before
activation, and local-authentication recovery. Product-owned names, logos,
icons, package metadata, and visible text use PastureStack branding. API
dependency, browser-smoke, terminal, console, and test-harness modernization.
It adds a provider-neutral OpenID Connect administration and sign-in flow with
PKCE S256, staged configuration validation, a real test login before
activation, and local-authentication recovery. Product-owned names, logos,
icons, package metadata, and visible text use PastureStack branding. API
models and protocol fields remain compatible.

Release `1.6.105` fixes the post-save transition for a newly created service:
Expand All @@ -24,81 +24,81 @@ localized placeholders. The create and upgrade resource payloads remain
unchanged.

Release `1.6.104` keeps the authenticated browser-session and OIDC corrections
from `1.6.103`. It also keeps the init-process checkbox inside its own resource
grid column, with the launch-configuration binding unchanged, so the control no
longer touches the adjacent process-limit input on create or upgrade forms.
Release `1.6.103` keeps an authenticated browser session when a non-auth API
request fails during startup, displays the nested OIDC/API explanation instead
of an empty alert, and activates a newly verified provider in unrestricted mode
so every identity accepted by that provider can sign in. Administrators can
still narrow access afterward with the existing site-access controls.
The language picker includes English, German, Persian, Filipino, French,
Hungarian, Japanese, Korean, Brazilian Portuguese, Russian, Ukrainian,
Simplified Chinese, and Traditional Chinese for Taiwan. Every selectable locale
must satisfy the complete message contract and regional formatting gates
documented in [Localization](docs/localization.md).
New security-sensitive authentication text is maintained in English and
Traditional Chinese first; other locales inherit the complete English text
until a reviewed translation is available, rather than displaying missing
translation keys.
The manually dispatched validation workflow tests and builds the exact
selected commit on a GitHub-hosted runner and retains the reviewed candidate
for 30 days. Release publication remains a separate reviewed step.
## Build and test
```sh
npm ci --ignore-scripts
npm run build -- --environment=production
npm test
package_version=$(node -p 'require("./package.json").version')
bash scripts/package-static-candidate \
"$package_version" dist "build/ui/${package_version}.tar.gz"
```
The packaging command uses the current Git commit timestamp by default, or an
explicit `SOURCE_DATE_EPOCH`, and emits a deterministic tarball plus a portable
SHA-256 file. It creates a candidate only; publishing remains a separate,
reviewed release step. The archive root and `VERSION.txt` must equal the
numeric package version; a preserved compatibility version must not be
silently substituted into a new release artifact.
Catalog cards and launch pages read optional
`io.pasturestack.catalog.name.<locale>` and
`io.pasturestack.catalog.description.<locale>` labels. Unknown locales and
third-party catalogs fall back to their canonical metadata instead of showing
an empty string or an untranslated key.
Container terminals, container logs, and virtual machine consoles use the
movable window system documented in
[Console workspace](docs/console-workspace.md). Terminal and log sessions can
be reopened after a tab refresh or browser restart, and active output is shared
across signed-in tabs without persisting upstream access tokens.
Host storage pages provide checkbox selection, state filtering, search,
pagination, and one operator-confirmed removal action. Selection rules,
preview behavior, and the concurrency limit are documented in
[operator-selected storage removal](docs/storage-bulk-remove.md).
Linux shared memory, runtimes, GPU/graphics devices and advanced container limits
use the shared [Resources and hardware](docs/resources-and-hardware.md) form.
The guide covers coordinated agent/API rollout and the distinction between
device visibility and exclusive GPU allocation.
OpenID Connect configuration, stable account-to-identity assignment, safe
provider switching, and local recovery are documented in
[OpenID Connect](docs/openid-connect.md). TOTP, passkeys, recovery codes,
email account recovery, and administrator controls are documented in
[Multi-factor authentication](docs/multi-factor-authentication.md).
The repository includes explicit modernization gates because its historical
frontend toolchain cannot be trusted without review. See
[COMPATIBILITY.md](COMPATIBILITY.md), [SECURITY.md](SECURITY.md), and
[ORIGIN.md](ORIGIN.md).
## License and attribution
The inherited project remains licensed under [Apache License 2.0](LICENSE), with additional attribution in [COPYRIGHT_DETAILS.md](COPYRIGHT_DETAILS.md). Bundled dependencies retain their own licenses and notices. PastureStack contributors claim authorship only for their own changes.
from `1.6.103`. It also keeps the init-process checkbox inside its own resource
grid column, with the launch-configuration binding unchanged, so the control no
longer touches the adjacent process-limit input on create or upgrade forms.

Release `1.6.103` keeps an authenticated browser session when a non-auth API
request fails during startup, displays the nested OIDC/API explanation instead
of an empty alert, and activates a newly verified provider in unrestricted mode
so every identity accepted by that provider can sign in. Administrators can
still narrow access afterward with the existing site-access controls.

The language picker includes English, German, Persian, Filipino, French,
Hungarian, Japanese, Korean, Brazilian Portuguese, Russian, Ukrainian,
Simplified Chinese, and Traditional Chinese for Taiwan. Every selectable locale
must satisfy the complete message contract and regional formatting gates
documented in [Localization](docs/localization.md).
New security-sensitive authentication text is maintained in English and
Traditional Chinese first; other locales inherit the complete English text
until a reviewed translation is available, rather than displaying missing
translation keys.

The manually dispatched validation workflow tests and builds the exact
selected commit on a GitHub-hosted runner and retains the reviewed candidate
for 30 days. Release publication remains a separate reviewed step.

## Build and test

```sh
npm ci --ignore-scripts
npm run build -- --environment=production
npm test
package_version=$(node -p 'require("./package.json").version')
bash scripts/package-static-candidate \
"$package_version" dist "build/ui/${package_version}.tar.gz"
```

The packaging command uses the current Git commit timestamp by default, or an
explicit `SOURCE_DATE_EPOCH`, and emits a deterministic tarball plus a portable
SHA-256 file. It creates a candidate only; publishing remains a separate,
reviewed release step. The archive root and `VERSION.txt` must equal the
numeric package version; a preserved compatibility version must not be
silently substituted into a new release artifact.

Catalog cards and launch pages read optional
`io.pasturestack.catalog.name.<locale>` and
`io.pasturestack.catalog.description.<locale>` labels. Unknown locales and
third-party catalogs fall back to their canonical metadata instead of showing
an empty string or an untranslated key.

Container terminals, container logs, and virtual machine consoles use the
movable window system documented in
[Console workspace](docs/console-workspace.md). Terminal and log sessions can
be reopened after a tab refresh or browser restart, and active output is shared
across signed-in tabs without persisting upstream access tokens.

Host storage pages provide checkbox selection, state filtering, search,
pagination, and one operator-confirmed removal action. Selection rules,
preview behavior, and the concurrency limit are documented in
[operator-selected storage removal](docs/storage-bulk-remove.md).

Linux shared memory, runtimes, GPU/graphics devices and advanced container limits
use the shared [Resources and hardware](docs/resources-and-hardware.md) form.
The guide covers coordinated agent/API rollout and the distinction between
device visibility and exclusive GPU allocation.

OpenID Connect configuration, stable account-to-identity assignment, safe
provider switching, and local recovery are documented in
[OpenID Connect](docs/openid-connect.md). TOTP, passkeys, recovery codes,
email account recovery, and administrator controls are documented in
[Multi-factor authentication](docs/multi-factor-authentication.md).

The repository includes explicit modernization gates because its historical
frontend toolchain cannot be trusted without review. See
[COMPATIBILITY.md](COMPATIBILITY.md), [SECURITY.md](SECURITY.md), and
[ORIGIN.md](ORIGIN.md).

## License and attribution

The inherited project remains licensed under [Apache License 2.0](LICENSE), with additional attribution in [COPYRIGHT_DETAILS.md](COPYRIGHT_DETAILS.md). Bundled dependencies retain their own licenses and notices. PastureStack contributors claim authorship only for their own changes.
88 changes: 44 additions & 44 deletions SECURITY.md
Original file line number Diff line number Diff line change
@@ -1,45 +1,45 @@
# Security Policy
## Supported state
# Security Policy

## Supported state

The maintained compatibility release is the pure numeric `1.6.105` line used
by the current PastureStack Server release. Earlier branded coordinates are
historical records and are not current release or deployment targets.
Authentication-provider combinations must still be validated by an
administrator before activation.
## Security boundaries
- The console handles API credentials, cookies, authentication redirects, secrets, shell and console sessions, logs, and user-supplied content.
- OpenID Connect state, nonce, PKCE verifier, authorization code, and provider
configuration are sensitive. The browser must verify state before accepting
a callback, must not reuse authorization codes, and must not retain flow
material after completion or failure.
- Testing a proposed OpenID Connect provider must not change the active
authentication method or write an upstream access token into a browser
cookie. A fresh authorization flow is required for activation.
- External identities are assigned by their exact provider, issuer, and
subject. A username, display name, or email address is never an automatic
account-matching key.
- Provider switching keeps access control enabled and uses short-lived,
single-use proofs bound to the intended account and identity. Local recovery
is restricted to an active system administrator and remains subject to MFA.
- MFA login must complete before a browser session is stored. TOTP and email
challenges are rate-limited, single-use, and short-lived; email is an
account-recovery channel, not an authentication factor.
- MFA enrollment, recovery-code generation, and recovery-address verification
require the account holder's own authenticated session. Administrators may
inspect and revoke another account's factors, but cannot create or retrieve
authentication material for that account.
- Authenticator-enrollment QR codes are generated locally in the browser; a
provisioning secret must never be sent to an external rendering service.
- WebAuthn requires user verification, the exact origin, a matching
relying-party ID, and a non-public-suffix relying-party domain. HTTP is
accepted only for a loopback test origin.
- Remote API, catalog, log, terminal, and error content must be treated as untrusted.
- Bundled browser dependencies, generated assets, and source maps require review before publication.
- Do not commit credentials, private endpoints, captured production responses, certificates, or session data.
## Reporting
Report suspected vulnerabilities through this repository's private security advisory channel. Do not include credentials or production data in a public issue.
by the current PastureStack Server release. Earlier branded coordinates are
historical records and are not current release or deployment targets.
Authentication-provider combinations must still be validated by an
administrator before activation.

## Security boundaries

- The console handles API credentials, cookies, authentication redirects, secrets, shell and console sessions, logs, and user-supplied content.
- OpenID Connect state, nonce, PKCE verifier, authorization code, and provider
configuration are sensitive. The browser must verify state before accepting
a callback, must not reuse authorization codes, and must not retain flow
material after completion or failure.
- Testing a proposed OpenID Connect provider must not change the active
authentication method or write an upstream access token into a browser
cookie. A fresh authorization flow is required for activation.
- External identities are assigned by their exact provider, issuer, and
subject. A username, display name, or email address is never an automatic
account-matching key.
- Provider switching keeps access control enabled and uses short-lived,
single-use proofs bound to the intended account and identity. Local recovery
is restricted to an active system administrator and remains subject to MFA.
- MFA login must complete before a browser session is stored. TOTP and email
challenges are rate-limited, single-use, and short-lived; email is an
account-recovery channel, not an authentication factor.
- MFA enrollment, recovery-code generation, and recovery-address verification
require the account holder's own authenticated session. Administrators may
inspect and revoke another account's factors, but cannot create or retrieve
authentication material for that account.
- Authenticator-enrollment QR codes are generated locally in the browser; a
provisioning secret must never be sent to an external rendering service.
- WebAuthn requires user verification, the exact origin, a matching
relying-party ID, and a non-public-suffix relying-party domain. HTTP is
accepted only for a loopback test origin.
- Remote API, catalog, log, terminal, and error content must be treated as untrusted.
- Bundled browser dependencies, generated assets, and source maps require review before publication.
- Do not commit credentials, private endpoints, captured production responses, certificates, or session data.

## Reporting

Report suspected vulnerabilities through this repository's private security advisory channel. Do not include credentials or production data in a public issue.
Loading