This addresses a TOCTOU (Time-of-Check to Time-of-Use) vulnerability in Nix's
build system that could potentially allow privilege escalation or unauthorized
file access during the build process.
The patch includes:
- Safe file operations using file descriptors
- Secure temporary directory handling
- Safe chown operations
- PassAsFile security improvements
- Path validation fixes
This addresses a TOCTOU (Time-of-Check to Time-of-Use) vulnerability in Nix's
build system that could potentially allow privilege escalation or unauthorized
file access during the build process.
The patch includes:
- Safe file operations using file descriptors
- Secure temporary directory handling
- Safe chown operations
- PassAsFile security improvements
- Path validation fixes
This addresses a TOCTOU (Time-of-Check to Time-of-Use) vulnerability in Nix's
build system that could potentially allow privilege escalation or unauthorized
file access during the build process.
The patch includes:
- Safe file operations using file descriptors
- Secure temporary directory handling
- Safe chown operations
- PassAsFile security improvements
- Path validation fixes
This addresses a TOCTOU (Time-of-Check to Time-of-Use) vulnerability in Nix's
build system that could potentially allow privilege escalation or unauthorized
file access during the build process.
The patch includes:
- Safe file operations using file descriptors
- Secure temporary directory handling
- Safe chown operations
- PassAsFile security improvements
- Path validation fixes
This manages the `2. status: stale` label for pull requests only (not
issues, yet) with the following conditions:
- The last event on the timeline of the Pull Request counts.
- Labeling and unlabeling of any kind are ignored.
- Older than 180 days are stale.
- Security labeled PRs are never stale.
To handle this label correctly, it's important to go through all pull
requests. Any approach to limit the list of PRs via search are not going
to work:
- Filtering by `updated` is not going to work, because it includes the
last time that *a label was set* on the PR. To actually find out whether
a PR is stale or not, the timeline of events needs to be looked at.
- Filtering by an existing stale label is not going to work either,
because such a label might have been added manually and thus breaking
the rules we set up here. Thus any existing label needs to be confirmed
as well.
We keep working through the PR, even though we don't have any eval
results. This will allow actually managing labels for much older PRs as
well. Most importantly, it will allow merge-conflict and stale-labeling
next.
This replaces the manual dispatch trigger with a batched run through all
pull requests every day. This has the small benefit of not having to
worry about backfilling labeling after fixing bugs - and the much bigger
one in being able to handle merge-conflict and stale labels properly
later. For those, it's inevitable to eventually scan through all PRs.
At this stage, the vast majority of PRs will still be skipped, because
there won't be an eval run with artifact available. This will be
improved in the next step.
Technically, the workflow_dispatch trigger is kept to allow easily
testing this in forks, where the scheduled jobs are disabled. The
triggered job will behave similar to the scheduled job, though, and have
no special inputs.
Florian RICHER