{"id":15171029,"url":"https://github.com/nixos/security","last_synced_at":"2025-10-01T06:31:47.976Z","repository":{"id":66132980,"uuid":"68965995","full_name":"NixOS/security","owner":"NixOS","description":null,"archived":true,"fork":false,"pushed_at":"2017-03-15T23:18:10.000Z","size":115,"stargazers_count":30,"open_issues_count":42,"forks_count":12,"subscribers_count":14,"default_branch":"master","last_synced_at":"2025-01-16T10:43:14.467Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/NixOS.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null},"funding":{"open_collective":"nixos"}},"created_at":"2016-09-22T22:06:12.000Z","updated_at":"2024-02-07T15:52:26.000Z","dependencies_parsed_at":"2023-03-27T16:47:16.246Z","dependency_job_id":null,"html_url":"https://github.com/NixOS/security","commit_stats":{"total_commits":74,"total_committers":7,"mean_commits":"10.571428571428571","dds":0.08108108108108103,"last_synced_commit":"b3fd5264d1218b7e181b8130c43592d5846b3002"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/NixOS%2Fsecurity","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/NixOS%2Fsecurity/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/NixOS%2Fsecurity/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/NixOS%2Fsecurity/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/NixOS","download_url":"https://codeload.github.com/NixOS/security/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":234837047,"owners_count":18894523,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-09-27T08:43:00.019Z","updated_at":"2025-10-01T06:31:47.642Z","avatar_url":"https://github.com/NixOS.png","language":"Rust","funding_links":["https://opencollective.com/nixos"],"categories":[],"sub_categories":[],"readme":"# lwn-vulns automation\n\n## How It Works\n\nIn the root of this repository is a file titled `db`. It is a new-line\nseparated list of vulnerability IDs from the LWN database.\n\nThe [`new`][new] tool screen-scrapes the database until it finds two\nfull pages with no new vulnerabilities.\n\nThe [`reformat`][reformat] tool updates an issue in progress to\nhighlight remaining items to do.\n\nWhen a roundup issue is closed, the contents of it are sent to the\n[`updatedb`][updatedb] command which outputs a list of the\nvulnerability IDs marked as done in the roundup. This should then\nappended to the `db` file.\n\nThe shell script `./notate.sh` peruses all the recent commits and\nprompts for security notes to be added.\n\nFinally, `./ported-notes.sh` takes the security notes and makes a\nsecurity announcement email's text.\n\n### Tool Interface\n\nThese tools are a bit like plumbing right now, and I would like some\nsimpler user interfaces to be developed on top. Right now, I think\nthey work okay.\n\n## Lifecycle of an Issue\n\nHere is a typical workflow. I'll be using `pbcopy` and `pbpaste` to\ncopy and paste to/from my system clipboard. On Linux, it may be\n`xclip -sel clip -i` and `xclip -sel clip -o`.\n\n### Build the tools\n\nStart with `nix-build ./default.nix -A lwnvulns.pkg`. This will create\nthe `result` symlink referenced here. Note, if you're doing\ndevelopment, you can enter a `nix-shell` (just run `nix-shell`) and\nreplace `./result/bin/` with `cargo run --bin \u003ccommand\u003e`:\n\n    security$ nix-shell\n\n    [nix-shell:~/projects/security/lwnvulns]$ pbpaste | cargo run --bin reformat | pbcopy\n        Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs\n         Running `target/debug/reformat`\n\n\n### Making a new issue\n\n    $ ./result/bin/new | pbcopy\n    Page 0 yielded 30 issues, after 0 pages with nothing\n    Page 1 yielded 0 issues, after 0 pages with nothing\n    Page 2 yielded 0 issues, after 1 pages with nothing\n\nMy clipboard now contains a full report to open as an issue. It has a\nfew sections of things in here for you to do. Starting with:\n\n    # POSTING TODO (DELETE PRIOR TO POSTING)\n\n     - [ ] Title it \"Vulnerability Roundup \u003cn\u003e\"\n     - [ ] Update the last roundup link\n     - [ ] CC everyone who participated in the previous roundup\n     - [ ] Label with `security`\n\n\nWhere, obviously, `\u003cn\u003e` is the last one +1. For example, if the last\none was Roundup 9, this one would be Roundup 10. A bit later there\nwill be a place to put a link to the previous roundup:\n\n\n    Here are all the vulnerabilities from https://lwn.net/Vulnerabilities\n    since our [last roundup]()\n\nbetween those two `()`. Make sure to correctly find the latest roundup\nand update this link accordingly.\n\nThen:\n\n    cc: .\n\nVisit the last roundup and review all the contributors in the sidebar.\nIt will say something like \"7 participants\". Make sure each one of\nthose people are CC'd in the new issue. This way it is easy for people\nto join and drop out of roundups. If they participate in one, they'll\nbe tagged in the next one. If they don't participate in that one, they\nwon't be tagged on the one after that.\n\n### Updating an issue\n\n1. Refresh the issue's page. This is important to make sure we don't\naccidentally delete progress not loaded on your page.\n2. Click edit on the issue, and copy the full markdown contents.\n3. Run it through the [`reformat`][reformat] tool like this: `pbpaste\n   | ./result/bin/reformat | pbcopy`.\n4. Paste the newly altered contents in to the issue, and click Save.\n\n### Closing an issue\n\nAfter the roundup is done and all the issues are solved, make sure to\nfinish out the list at the top of each issue.\n\n### Updating the database\n\n1. Refresh the issue's page. This is important to make sure we don't\naccidentally delete progress not loaded on your page.\n2. Click edit on the issue, and copy the full markdown contents.\n3. `pbpaste | ./result/bin/updatedb \u003e\u003e db`\n4. Commit these changes, and open a PR with the new changes.\n\n### Review and backport commits from master to stable (`release-16.09`)\n\nRun `./notate.sh` from within the nixpkgs checkout to go through each\ncommit since the previous review. It will ask if the commit should\nhave security notes attached to it. Saying yes will open an editor to\nadd notes. Try looking at release notes or the pull request to\ndetermine if there are security implications. If there are, add CVE\ninformation and perhaps some notes about what the issue is. Make sure\nany security fixes to master are applied to the stable branch as well.\nIf not, cherry-pick them yourself. If you're not sure, open a PR with\nthe backported commits.\n\nIn the `state/notate_state.sh` state file, we track the last commit to\nbe reviewed.\n\n### Creating an Announcement\n\n1. `cd` in to a nixpkgs clone and run `ported-notes.sh`. It\n   will output a rough template of all the announcements to make, but\n   make sure to audit it and review, by following the remainder of\n   these steps.\n2. Update the link at the end of the output to point to the latest\n   security vulnerability roundup.\n3. Commit and push and open a PR with the updated ported state file.\n4. Send the generated email\n\n## Developing\n\nRun `nix-shell` and within that, `cargo run --bin\nnew|updatedb|reformat` etc.\n\n### Architecture\nThis tooling includes a tokenizer for tokenizing the issues, a parser\nto build a \"syntax tree\", and then various AST transformations to\nupdate the document later on. There is a tool for writing out a syntax\ntree as text. The [`new`][new] tool which generates new reports emits\ntokens to the parser, and then uses the writer to output the report.\n\nIt is important to me that code be well formatted and have tests. One\nplace in particular that I have failed to adhere to these standards in\nparticular is the [`new`][new] code... this isn't an excuse to get\nsloppy. Sorry. :(\n\n## Dataformat\n\n### Terms\n\n#### Document\n\nA document is the entire markdown contents of a Github Issue. A\ndocument begins with a **preamble**, and ends with a **report**.\n\n#### Preamble\n\nThe preamble is arbitrary text and has no specific rules about its\ncontent. When being parsed and generated, the preamble is left\ncompletely alone and is to be preserved bit-for-bit when outputted.\n\nThe preamble is begins at the start of the document, and ends at the\nfirst occurance of a **Header**.\n\n#### Report\n\nThe Report is a collection of **Headers** and **Issues**, where a\nHeader is typically followed by zero or more Issues.\n\n**Any lines of data inside the Report which is not a Header or an\nIssue is considered garbage, and should be discarded.**\n\n#### Header\n\nA Header is defined by the following regular expression:\n\n    ^### (.*) \\((\\d+) issues?\\)( .*)?\\n$\n         (1)    (2)            (3)\n\n         (1) Package Name\n         (2) Issue Count\n         (3) Additional Notes (optional)\n\nThe header is designed to start with arbitrary text describing the\naffected packages, the number of issues affecting the package, and\nthen optional notes. Note that the number of issues in the header\n_does not_ necessarily reflect the true number of contained issues,\nhowever a well behaved parser will correctly update the counter. Note\nthat the plural `s` in `issues` is optional.\n\nHere are some example headers:\n\n    ### jasper (2 issues)\n    ### jasper (0 issues)\n    ### jasper (1 issue)\n    ### foo bar baz tux!!! (1 issues) extra notes go here\n\n#### Issue\n\nAn Issue is defined by the following regular expression:\n\n    ^ ?- \\[(x| )\\] \\[`#(.*)`\\]\\((.*)\\) (.*)$\n           (1)         (2)      (3)    (4)\n\n           (1) Completion Indicator (x == complete)\n           (2) Vulnerability ID\n           (3) URL for the Vulnerability\n           (4) Arbitraty text describing the vulnerability\n\n\nThe issue is designed to be in a markdown formatted list with a\nbeginning checkbox and a link. This checkbox may either be filled or\nunfilled, following a link indicating the primary URL for this issue.\nThe link's text, currently, must start with a #, followed by an\nidentifier to identify this issue. It is assumed this identifier is\nunique to this issue, and that this issue will never need to be\naddressed again. Following the link may be arbitrary content. The\nmarkdown list line may or may not be prefixed by a blank space.\n\nHere are some example Issues:\n\n     - [x] [`#705362`](https://lwn.net/Vulnerabilities/705362/) ([search](http://search.nix.gsc.io/?q=bind\u0026i=fosho\u0026repos=nixos-nixpkgs), [files](https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93\u0026q=bind+in%3Apath\u0026type=Code))  bind: denial of service\n     - [ ] [`#705917`](https://lwn.net/Vulnerabilities/705917/) ([search](http://search.nix.gsc.io/?q=java-1.8.0-openjdk-aarch32\u0026i=fosho\u0026repos=nixos-nixpkgs), [files](https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93\u0026q=java-1.8.0-openjdk-aarch32+in%3Apath\u0026type=Code))  java-1.8.0-openjdk-aarch32: multiple vulnerabilities\n    - [x] [`#705362`](https://lwn.net/Vulnerabilities/705362/) ([search](http://search.nix.gsc.io/?q=bind\u0026i=fosho\u0026repos=nixos-nixpkgs), [files](https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93\u0026q=bind+in%3Apath\u0026type=Code))  bind: denial of service\n    - [ ] [`#705917`](https://lwn.net/Vulnerabilities/705917/) ([search](http://search.nix.gsc.io/?q=java-1.8.0-openjdk-aarch32\u0026i=fosho\u0026repos=nixos-nixpkgs), [files](https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93\u0026q=java-1.8.0-openjdk-aarch32+in%3Apath\u0026type=Code))  java-1.8.0-openjdk-aarch32: multiple vulnerabilities\n\n### Example Document\n\n    Here are all the vulnerabilities from https://lwn.net/Vulnerabilities\n    ## Notes on the list\n    1. The reports have been roughly grouped by the package name. This\n       isn't perfect, but is intended to help identify if a whole group\n    ### This is valid too, because it doesn't have an issue count!\n     - [ ] even this isn't counted!\n\n\n    ### Assorted (31 issues)\n     - [ ] [`#705568`](https://lwn.net/Vulnerabilities/705568/) ([search](http://search.nix.gsc.io/?q=libvirt\u0026i=fosho\u0026repos=nixos-nixpkgs), [files](https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93\u0026q=libvirt+in%3Apath\u0026type=Code))  libvirt: privilege escalation\n     - [ ] [`#705361`](https://lwn.net/Vulnerabilities/705361/) ([search](http://search.nix.gsc.io/?q=java\u0026i=fosho\u0026repos=nixos-nixpkgs), [files](https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93\u0026q=java+in%3Apath\u0026type=Code))  java: unspecified vulnerability\n     - [ ] [`#705578`](https://lwn.net/Vulnerabilities/705578/) ([search](http://search.nix.gsc.io/?q=qemu\u0026i=fosho\u0026repos=nixos-nixpkgs), [files](https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93\u0026q=qemu+in%3Apath\u0026type=Code))  qemu: multiple vulnerabilities\n    This stuff is garbage and will be deleted when the parser is run again.\n    ### tiff (2 issues)\n     - [x] [`#705364`](https://lwn.net/Vulnerabilities/705364/) ([search](http://search.nix.gsc.io/?q=tiff\u0026i=fosho\u0026repos=nixos-nixpkgs), [files](https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93\u0026q=tiff+in%3Apath\u0026type=Code))  tiff: multiple vulnerabilities\n     - [x] [`#635993`](https://lwn.net/Vulnerabilities/635993/) ([search](http://search.nix.gsc.io/?q=tiff\u0026i=fosho\u0026repos=nixos-nixpkgs), [files](https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93\u0026q=tiff+in%3Apath\u0026type=Code))  tiff: multiple vulnerabilities\n\n# Addendum\n\n## Why LWN? Why not NVD?\n\nLWN nicely aggregates reports from distributions, who also aggregate\nCVE IDs they are responding to. This means instead of checking several\nCVE IDs individually, we know we just need to update a package.\n\nNVD and other CVE databases are frequently dreadfully out of date, and\nare won't have data for a CVE data for a long time, where as LWN will\nalready have information about the report.\n\n## Has LWN approved this?\n\nYes.\n\n## `new` emits `Problem with the SSL CA cert (path? access rights?)`?\n\nI was missing a `/etc/ssl/certs/ca-certificates.crt` and copied my\n`/etc/ssl/certs/ca-bundle.crt` to be there... _shrug_.\n\n\n## Why rust?\n\nI originally wrote this tooling in python, but wanted to have strong\ntyping to provide structure to the parser and tokenizer. I don't any\nfunctional languages that are vogue in the Nix ecosystem.\n\n[new]: ./lwnvulns/src/bin/new.rs\n[reformat]: ./lwnvulns/src/bin/reformat.rs\n[updatedb]: ./lwnvulns/src/bin/updatedb.rs\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnixos%2Fsecurity","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnixos%2Fsecurity","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnixos%2Fsecurity/lists"}