{"vulnerability": "GHSA-W9VV-Q986-VJ7X", "sightings": [{"uuid": "dda27084-e1aa-4e16-acf3-c2d305342dc9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "GHSA-W9VV-Q986-VJ7X", "type": "seen", "source": "https://t.me/hn_best_comments/30331", "content": "Re: Bugs Rust won't catch\n\nHi, I am one of the maintainers of GNU Coreutils. Thanks for the article, it covers some interesting topics. In the little Rust that I have used, I have felt that it is far too easy to write TOCTOU races using std::fs. I hope the standard library gets an API similar to openat eventually.\n\nI just want to mention that I disagree with the section titled \"Rule: Resolve Paths Before Comparing Them\". Generally, it is better to make calls to fstat and compare the st_dev and st_ino. However, that was mentioned in the article. A side effect that seems less often considered is the performance impact. Here is an example in practice:\n\n  $ mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\\n')\n  $ while cd $(yes a/ | head -n 1024 | tr -d '\\n'); do :; done 2>/dev/null\n  $ echo a > file\n  $ time cp file copy\n\n  real 0m0.010s\n  user 0m0.002s\n  sys 0m0.003s\n  $ time uu_cp file copy\n\n  real 0m12.857s\n  user 0m0.064s\n  sys 0m12.702s\n\nI know people are very unlikely to do something like that in real life. However, GNU software tends to work very hard to avoid arbitrary limits [1].\n\nAlso, the larger point still stands, but the article says \"The Rust rewrite has shipped zero of these [memory saftey bugs], over a comparable window of activity.\" However, this is not true [2]. :)\n\n[1] https://www.gnu.org/prep/standards/standards.html#Semantics\n[2] https://github.com/advisories/GHSA-w9vv-q986-vj7x\n\ncollinfunk, 6 hours ago", "creation_timestamp": "2026-08-02T00:01:12.575367Z"}, {"uuid": "131a777d-b985-42ad-9d3a-86f36cfdbbd9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "GHSA-W9VV-Q986-VJ7X", "type": "seen", "source": "https://t.me/hn_best_comments/30331", "content": "Re: Bugs Rust won't catch\n\nHi, I am one of the maintainers of GNU Coreutils. Thanks for the article, it covers some interesting topics. In the little Rust that I have used, I have felt that it is far too easy to write TOCTOU races using std::fs. I hope the standard library gets an API similar to openat eventually.\n\nI just want to mention that I disagree with the section titled \"Rule: Resolve Paths Before Comparing Them\". Generally, it is better to make calls to fstat and compare the st_dev and st_ino. However, that was mentioned in the article. A side effect that seems less often considered is the performance impact. Here is an example in practice:\n\n  $ mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\\n')\n  $ while cd $(yes a/ | head -n 1024 | tr -d '\\n'); do :; done 2>/dev/null\n  $ echo a > file\n  $ time cp file copy\n\n  real 0m0.010s\n  user 0m0.002s\n  sys 0m0.003s\n  $ time uu_cp file copy\n\n  real 0m12.857s\n  user 0m0.064s\n  sys 0m12.702s\n\nI know people are very unlikely to do something like that in real life. However, GNU software tends to work very hard to avoid arbitrary limits [1].\n\nAlso, the larger point still stands, but the article says \"The Rust rewrite has shipped zero of these [memory saftey bugs], over a comparable window of activity.\" However, this is not true [2]. :)\n\n[1] https://www.gnu.org/prep/standards/standards.html#Semantics\n[2] https://github.com/advisories/GHSA-w9vv-q986-vj7x\n\ncollinfunk, 6 hours ago", "creation_timestamp": "2026-08-01T08:00:05.086873Z"}, {"uuid": "00ce5fe4-c8bc-4b6d-95f8-df2d1c833e78", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "GHSA-W9VV-Q986-VJ7X", "type": "seen", "source": "https://t.me/hn_best_comments/30331", "content": "Re: Bugs Rust won't catch\n\nHi, I am one of the maintainers of GNU Coreutils. Thanks for the article, it covers some interesting topics. In the little Rust that I have used, I have felt that it is far too easy to write TOCTOU races using std::fs. I hope the standard library gets an API similar to openat eventually.\n\nI just want to mention that I disagree with the section titled \"Rule: Resolve Paths Before Comparing Them\". Generally, it is better to make calls to fstat and compare the st_dev and st_ino. However, that was mentioned in the article. A side effect that seems less often considered is the performance impact. Here is an example in practice:\n\n  $ mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\\n')\n  $ while cd $(yes a/ | head -n 1024 | tr -d '\\n'); do :; done 2>/dev/null\n  $ echo a > file\n  $ time cp file copy\n\n  real 0m0.010s\n  user 0m0.002s\n  sys 0m0.003s\n  $ time uu_cp file copy\n\n  real 0m12.857s\n  user 0m0.064s\n  sys 0m12.702s\n\nI know people are very unlikely to do something like that in real life. However, GNU software tends to work very hard to avoid arbitrary limits [1].\n\nAlso, the larger point still stands, but the article says \"The Rust rewrite has shipped zero of these [memory saftey bugs], over a comparable window of activity.\" However, this is not true [2]. :)\n\n[1] https://www.gnu.org/prep/standards/standards.html#Semantics\n[2] https://github.com/advisories/GHSA-w9vv-q986-vj7x\n\ncollinfunk, 6 hours ago", "creation_timestamp": "2026-07-29T12:01:06.387226Z"}, {"uuid": "ec205944-f5f2-40f8-a061-a1991d6154c8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "GHSA-W9VV-Q986-VJ7X", "type": "seen", "source": "https://t.me/hn_best_comments/30331", "content": "Re: Bugs Rust won't catch\n\nHi, I am one of the maintainers of GNU Coreutils. Thanks for the article, it covers some interesting topics. In the little Rust that I have used, I have felt that it is far too easy to write TOCTOU races using std::fs. I hope the standard library gets an API similar to openat eventually.\n\nI just want to mention that I disagree with the section titled \"Rule: Resolve Paths Before Comparing Them\". Generally, it is better to make calls to fstat and compare the st_dev and st_ino. However, that was mentioned in the article. A side effect that seems less often considered is the performance impact. Here is an example in practice:\n\n  $ mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\\n')\n  $ while cd $(yes a/ | head -n 1024 | tr -d '\\n'); do :; done 2>/dev/null\n  $ echo a > file\n  $ time cp file copy\n\n  real 0m0.010s\n  user 0m0.002s\n  sys 0m0.003s\n  $ time uu_cp file copy\n\n  real 0m12.857s\n  user 0m0.064s\n  sys 0m12.702s\n\nI know people are very unlikely to do something like that in real life. However, GNU software tends to work very hard to avoid arbitrary limits [1].\n\nAlso, the larger point still stands, but the article says \"The Rust rewrite has shipped zero of these [memory saftey bugs], over a comparable window of activity.\" However, this is not true [2]. :)\n\n[1] https://www.gnu.org/prep/standards/standards.html#Semantics\n[2] https://github.com/advisories/GHSA-w9vv-q986-vj7x\n\ncollinfunk, 6 hours ago", "creation_timestamp": "2026-07-30T00:01:46.890166Z"}]}