chore: regroup advisories by year

[blackheaven]

---

Advisory

• It's not duplicated
• All fields are filled
• It is validated by hsec-tools

hsec-tools

• Previous advisories are still valid

[frasertweedale]

The symbolic links need fixing up, but otherwise I'm happy to merge this.

I think we should have a fsck command to validate the symlinks - i.e. that all symlinks point to a matching advisory in the published tree, and that all affected components have inbound symlinks in the ghc or hackage tree. But that can be done in a subsequent PR.

[blackheaven]

The symbolic links need fixing up, but otherwise I'm happy to merge this.

I think it's builtin git, here's the script I have used:

mkdir -p advisories/published/{2023,2024,2025}
find advisories/{ghc,hackage} -type f \
    | while read -r f; do \
    target=$(echo "$f" | sed -E 's|.*/HSEC-([0-9]+)-([0-9]+)\.md|advisories/published/\1/\2.md|') 
    git mv "$f" "$target"
    touch "$f"
done
find advisories/{ghc,hackage} -name '*.md' \
    | while read -r f; do \
    target=$(echo "$f" | sed -E 's|.*/HSEC-([0-9]+)-([0-9]+)\.md|advisories/published/\1/\2.md|') 
    ln -sf "$target" "$f"
    git add "$f"
done

Let me know if you have an idea to fix linking.

Thanks in advance.

[mbauman]

My apologies for a fly-by question from an outsider here, but I've been taking inspiration from your design here for the Julia ecosystem (in following a great tradition :)). Would you be willing to share a bit about the rationale for this reorg — or have you described this in some place I have yet to find? I can definitely see a number of advantages! Are the symbolic links for backwards compatibility or UX (for advisory authors or maintainers or consumers?) or some other reason?

I know this is active work, and I know describing it is also work, but I just happen to be concurrently thinking about issues exactly like this. In any case, thank you for all you've done here — this is already quite helpful!

[frasertweedale]

My apologies for a fly-by question from an outsider here, but I've been taking inspiration from your design here for the Julia ecosystem (in following a great tradition :)). Would you be willing to share a bit about the rationale for this reorg — or have you described this in some place I have yet to find? I can definitely see a number of advantages! Are the symbolic links for backwards compatibility or UX (for advisory authors or maintainers or consumers?) or some other reason?

I know this is active work, and I know describing it is also work, but I just happen to be concurrently thinking about issues exactly like this. In any case, thank you for all you've done here — this is already quite helpful!

We already supported symbolic links - because a single advisory can affect multiple packages. But previously, the actual advisory files would reside in (one of) the package-based paths.

The main motivation for this change is to have the canonical advisory content at a location derived from the advisory ID (HSEC-YYYY-NNNN). This lets us play more nicely with osv.dev and any other system that wants to "link back" to the advisory source without knowing anything about Haskell package/component namespaces. We retain package-based paths but they will now all be symbolic links.

See #252 and google/osv.dev#2191 for more context.