Page History
...
| Version | Date | Description of Changes |
|---|---|---|
| v0.0 | 4/??/24 | Initial draft work by Marcio and Jeremy |
| v0.1 | 5/2/24 | Applied changes from last meeting. Made note of "interface" GitHub organizations, removed lcls-daq from the organization list, noted down additional discussion points about team setup. |
| v0.2 | 5/3/24 | Added section about READMEs and GitHub pages. Added note that the "Other aspects to consider" is mostly noting capabilities that we probably want to apply in a more localized way. (we don't want to enforce a certain branching workflow for the whole lab!) |
| v0.3 | 5/3/24 | Added section on security, for discussion in next meeting. |
Definitions
| Term | Description |
|---|---|
| Organization | A location on GitHub where many repositories and teams can be stored. Translates into a URL when browsing or cloning a repository. |
| Working Copy | A clone of a Git repository that you can edit and compile. |
| Repository | A location where Git history and code are stored. These are added as "remotes" on a local working copy. |
| GHE | GitHub Enterprise |
| HLA | High-Level Applications |
| Fork | A copy of a repository from one organization to another. For example, github.com/slac-epics/asyn would be a fork of github.com/epics-modules/asyn. GitHub keeps track of forks so the upstream code has the link clearly visible. |
| Upstream | Repository that is the original basis of a fork. |
...
NOTE (5/1/24): SLAC legal is probably concerned about licensed code from other sources (i.e. vxWorks), not open source software. It is probably fine to keep open source projects we fork public.
Security
Some thoughts about security:
- Some slaclab admins do not work at SLAC anymore
- Effort is required to keep this list up to date
- Some slaclab admins do not have 2fa enabled
- Enforce 2fa for everyone in slaclab, probably!
- Fine-grained personal access tokens should be used instead of classic tokens
- Classic tokens allow access to all repos for a user. If a PAN is compromised for a slaclab user, a threat actor could read/write to any repositories that user can.
- GitHub does a good job detecting compromised tokens and accounts, but still.
- Classic tokens allow access to all repos for a user. If a PAN is compromised for a slaclab user, a threat actor could read/write to any repositories that user can.
- Use deploy tokens for CI/CD work.
- Alternative to personal access tokens for CI/CD. More secure because it's added per-repo and scoped only to that repo.
- Doesn't work for private submodules...
- Alternative to personal access tokens for CI/CD. More secure because it's added per-repo and scoped only to that repo.
- Require signed commits?
- Branch protections/rulesets allow you to require signed commits for matching refs. (i.e. to avoid compromised maintainer accounts from pushing malicious code/releases)
- Just makes it harder for an attacker to attack things: They'd need auth token/SSH private key, and GPG private key to push a malicious release.
- Branch protections/rulesets allow you to require signed commits for matching refs. (i.e. to avoid compromised maintainer accounts from pushing malicious code/releases)
Other aspects to consider
...
Overview
Content Tools