Approaches for the CSS WG

Intro

We want the CSS WG (and other new WGs too) to start publishing automatically with Echidna. The workflows for their specs are different to the most of the rest of specs Echidna is handling already:

• They use Bikeshed (instead of ReSpec; where Echidna has had more experience recently).
• They publish EDs on their own site (instead of having WDs on gh-pages as most other groups).

Options

1. Publish WDs + Echidna manifests somewhere

1a. Start using a new GH repo just to publish WDs

If the CSS WG doesn't want to pollute drafts.csswg.org with manifests, WDs, etc, we could have a separate GH repo for that.
If the CI system can simply commit snapshots to that repo, Echidna will take it up from there, exactly as it does now for other groups.

How to manage dozens of specs on one single GH repo?
We could have one spec per subdirectory. The CSSWG's own CI system (currently in place) would submit the files under one specific directory; depending on the spec that has been updated.

1b. CSS WG to put WDs + Echidna manifests on their public site

Changes required:
No changes on the part of Echidna.
CSS WG: start uploading more/other files to drafts.csswg.org as part of their CI cycle.

Pros:
Consistent with the usage of the rest of groups.
No TAR'ing, no signing.

Cons:
Changes required in CSS WG's CI.
Same level of security we have right now for other WGs: known location + token.

2. CSS WG to send signed TAR to Echidna

Changes required:
Echidna: learn how to verify signed files; store and manage public key(s) associated to tokens.
CSS WG: package their WD as a TAR file; sign it; manage private keys in a safe way (but as part of their CI system).

Pros:
More secure (yes? Same level of authentication is required to push to a GH repository anyway…). No need to publish anything publicly.

Cons:
New dependencies on both ends on tools to sign and handle public/private keys. Support for SSH signing in Node.js? More complexity (handling keys).

3. CSS WG to send TAR to Echidna, authenticating with a W3C account

Changes required:
None or minimal in Echidna per se (auth would be managed before HTTP requests get to Echidna?).

Pros:
Reuses existing authentication mechanism on w3.org, and existing W3C accounts (no need to generate/store keys).

Cons:
For authentication, needs a W3C Account for each person able to publish. For authentication a shared token or ACL allowing the operation.