HBOF due to user-defined implementations of scratchpad::Tracking (fix note)

Author: Georgios Androutsopoulos

crates/scratchpad/RUSTSEC-0000-0000.md

@@ -22,4 +22,4 @@ The `get` and `set` methods of the public trait `scratchpad::Tracking` interact
 
 This becomes problematic because even safe implementations of `get` and `set`-written without using any unsafe code-can still result in ill-formed raw pointers. These pointers may later be dereferenced within safe APIs of the crate (e.g., `marker::MarkerBack::allocate_slice_copy`), potentially leading to arbitrary memory access or heap buffer overflows.
 
-According to the [penultimate commit](https://github.com/okready/scratchpad/commit/957dee1a3902f48600b06910e8e0b1d5ee7dab83), the crate is in maintenance mode awaiting a cleanup that will reduce the area of unsafe code.
+According to the [penultimate commit](https://github.com/okready/scratchpad/commit/957dee1a3902f48600b06910e8e0b1d5ee7dab83), the crate is in maintenance mode awaiting a cleanup that will reduce the area of unsafe code. Note that the last commits to the repository are from 4 years ago.