[arch-projects] [arch-repo-management] 2022-05-04 meeting notes
Formatted minutes can be viewed here: https://md.archlinux.org/s/rdnf9nzXj Raw Markdown (still hoping for an easy md→text conversion that formats links in a citation style...) # Arch-repo-management 2022-05-04 meeting Date: 2022-05-04T17:00:00Z Location: Jitsi Scribe: Brett (ainola) ## Attendees * Brett (ainola) * dvzrv * Torxed * wCPO ## Agenda ### Documentation * dvzrv has [created extensive sphinx documentation about the project](https://gitlab.archlinux.org/archlinux/arch-repo-management/-/merge_requests... #### Hosting It would be nice to set up e.g. docs.archlinux.org as a central documentation platform related to Arch-related tooling/projects with each project having its own subdomain. For instance, repod.docs.archlinux.org. * The wiki is more about configuration/situational help whereas the docs site would be more extensive documentation about the project itself: Much of the specifics don't belong on the wiki. GitLab pages used for WKD docs, let's use pages for all of this documentation * docs.archlinux.org would be a landing page * CI/CD into a repository's GitLab pages * foo.docs.archlinux.org would point to that repo's gitlab page. #### Security concerns The Gitlab page could potentially maliciously set cookies for archlinux.org. Since documentation changes can be deployed without DevOps, the accepted stewards of infrastructure, it means that non-DevOps members could theoretically maliciously attack the main site. Refer: https://github.com/w3c/webappsec/issues/432 Suggestions for resolution: 1. Change https://archlinux.org to https://www.archlinux.org so that the main page is on a separate subdomain * This would likely cause our search rankings to reset. Cookies would have to be reworked to use the new domain 3. Disable JavaScript via CSP * This would break search functionality for the Sphinx theme 4. Use `<script-src>` [hash argument](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-P...) to restrict the JavaScript allowed to run (to be managed by DevOps) 5. Widen the range of trust to include more than DevOps members * This is the path of least resistance 6. Enhance archlinux.org security to require more than cookies to authenticate * Not trivial, unlikely to happen No resolution made, we will revisit in a few weeks' time after the PR has been merged. ### Next Steps * next up: [rename the project to repod](https://gitlab.archlinux.org/archlinux/arch-repo-management/-/issues/45) * start implementing the consumption of package metadata (e.g. [.MTREE](https://gitlab.archlinux.org/archlinux/arch-repo-management/-/issues/51), [.BUILDINFO](https://gitlab.archlinux.org/archlinux/arch-repo-management/-/issues/52) (also selection of [.BUILDINFO fields](https://gitlab.archlinux.org/archlinux/arch-repo-management/-/issues/20)) and [.PKGINFO](https://gitlab.archlinux.org/archlinux/arch-repo-management/-/issues/53))
Great job with keeping the notes tidy!
Best wishes:
Anton Hvornum
IT Developer and Security Consultant
On Wed, May 4, 2022 at 10:00 PM Brett Cornwall via arch-projects
Formatted minutes can be viewed here:
https://md.archlinux.org/s/rdnf9nzXj
Raw Markdown (still hoping for an easy md→text conversion that formats links in a citation style...)
# Arch-repo-management 2022-05-04 meeting
Date: 2022-05-04T17:00:00Z Location: Jitsi Scribe: Brett (ainola)
## Attendees
* Brett (ainola) * dvzrv * Torxed * wCPO
## Agenda
### Documentation
* dvzrv has [created extensive sphinx documentation about the project](https://gitlab.archlinux.org/archlinux/arch-repo-management/-/merge_requests...
#### Hosting
It would be nice to set up e.g. docs.archlinux.org as a central documentation platform related to Arch-related tooling/projects with each project having its own subdomain. For instance, repod.docs.archlinux.org.
* The wiki is more about configuration/situational help whereas the docs site would be more extensive documentation about the project itself: Much of the specifics don't belong on the wiki.
GitLab pages used for WKD docs, let's use pages for all of this documentation
* docs.archlinux.org would be a landing page * CI/CD into a repository's GitLab pages * foo.docs.archlinux.org would point to that repo's gitlab page.
#### Security concerns
The Gitlab page could potentially maliciously set cookies for archlinux.org. Since documentation changes can be deployed without DevOps, the accepted stewards of infrastructure, it means that non-DevOps members could theoretically maliciously attack the main site.
Refer: https://github.com/w3c/webappsec/issues/432
Suggestions for resolution:
1. Change https://archlinux.org to https://www.archlinux.org so that the main page is on a separate subdomain * This would likely cause our search rankings to reset. Cookies would have to be reworked to use the new domain 3. Disable JavaScript via CSP * This would break search functionality for the Sphinx theme 4. Use `<script-src>` [hash argument](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-P...) to restrict the JavaScript allowed to run (to be managed by DevOps) 5. Widen the range of trust to include more than DevOps members * This is the path of least resistance 6. Enhance archlinux.org security to require more than cookies to authenticate * Not trivial, unlikely to happen
No resolution made, we will revisit in a few weeks' time after the PR has been merged.
### Next Steps
* next up: [rename the project to repod](https://gitlab.archlinux.org/archlinux/arch-repo-management/-/issues/45) * start implementing the consumption of package metadata (e.g. [.MTREE](https://gitlab.archlinux.org/archlinux/arch-repo-management/-/issues/51), [.BUILDINFO](https://gitlab.archlinux.org/archlinux/arch-repo-management/-/issues/52) (also selection of [.BUILDINFO fields](https://gitlab.archlinux.org/archlinux/arch-repo-management/-/issues/20)) and [.PKGINFO](https://gitlab.archlinux.org/archlinux/arch-repo-management/-/issues/53))
participants (2)
-
Anton Hvornum
-
Brett Cornwall