Address CI friction between security and caching #155
Labels
No labels
0 points
0.5 points
1 point
13 points
2 points
21 points
3 points
34 points
5 points
55 points
8 points
api service
blocked
component: fediversity panel
component: nixops4
documentation
estimation high: >3d
estimation low: <2h
estimation mid: <8h
infinite points
productisation
project-management
question
role: application developer
role: application operator
role: hosting provider
role: maintainer
security
technical debt
testing
type unclear
type: bug
type: deliverable
type: key result
type: objective
type: task
type: user story
user experience
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Blocks
Depends on
#291 code passes security check
fediversity/fediversity
#87 Replace snakeoil-key with proper secret
fediversity/fediversity
#92 Continuous Integration builds available in a public cache
fediversity/fediversity
#493 portable ephemeral state
fediversity/fediversity
Reference: fediversity/fediversity#155
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Our NixOS-based Gitea actions runner's jobs can access their Nix store (shared), which includes other jobs. This is a potential security concern, particularly if we wanted to allow anyone to sign up to this Forgejo instance and make PRs checked by CI.
As such, we may want to further consider our options on this.
c.f. prior discussion at #152
Yes, essentially we just need two isolated instances for eval/build.
@fricklerhandwerk could you explain that a bit?
Like Nixpkgs or NGIpkgs does it: There's an isolated instance that will run builds on PRs, read-only accessing the main cache and not caching build results (or only between PR rebuilds), and another instance that runs builds on
mainand caches build results publicly.that makes sense, thanks.
in addition tho, i think we would need to make sure our (main) builds would not contain sensitive info then.