Improve references in RUSTSEC-2024-0359 (#2202)

* Improve attribution in RUSTSEC-2024-0359

In some cases it is easy to see who discovered and reported a bug,
but in the case of RUSTSEC-2024-0359 (GHSA-cx7h-h87r-jpgr) one
would have had to follow a link to the issue (or look at the
advisory-db commit history).

Furthermore, the text of the advisory here is directly based on
the text of that issue. So improving attribution seems worthwhile
in this case.

This adds brief explicit credit to @ssbr at the end of the body of
the advisory. This is modeled roughly after how credit was given in
RUSTSEC-2023-0064 (GHSA-rrjw-j4m2-mf34), another gitoxide advisory.

Because the GitHub Advisory Database entry GHSA-cx7h-h87r-jpgr for
RUSTSEC-2024-0359 is imported from here, I believe it will also
(eventually) be updated with this change, even without being edited
directly.

Although that database supports credit metadata, it seems currently
infeasible to add reporter or finder credit to an entry that is
imported from RUSTSEC rather than, e.g., from a repo-local GHSA
(github/advisory-database#4620). So
this is also in effect a workaround for that.

* Update RUSTSEC-2024-0359 external info metadata

The main metadata change here is to add the missing global GHSA
alias (see GHSA-cx7h-h87r-jpgr).

While I'm at it, I've also updated the reference issue URL, since
the `gitoxide` repository is under `GitoixeLabs` now (moved from
`Byron`).

Author: EliahKagan

crates/gix-attributes/RUSTSEC-2024-0359.md

@@ -3,8 +3,9 @@
 id = "RUSTSEC-2024-0359"
 package = "gix-attributes"
 date = "2024-07-24"
-url = "https://github.com/Byron/gitoxide/issues/1460"
+url = "https://github.com/GitoxideLabs/gitoxide/issues/1460"
 informational = "unsound"
+aliases = ["GHSA-cx7h-h87r-jpgr"]
 
 [versions]
 patched = [">= 0.22.3"]
@@ -21,3 +22,5 @@ patched = [">= 0.22.3"]
 The problem is that the non-UTF8 `str` **is** exposed to outside code: first to the `kstring` crate itself, which requires UTF-8 in its documentation and may have UB as a consequence of this, but also to `serde`, where it propagates to e.g. `serde_json`, `serde_yaml`, etc., where the same problems occur.
 
 This is not sound, and it could cause further UB down the line in these places that can view the `&str`.
+
+*Thanks to [Devin Jeanpierre](https://github.com/ssbr) for discovering and reporting this issue.*