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.