As I understand, there is the idea to put information as well in the opam files of the opam-repository (security-message). This can be achieved by a tool that reads the advisories and adds data to the affected opam files. This tool is not there (yet?). The whole idea of security-message in opam files is as well not there (yet?). So there’s definitively room for people to improve the current situation.
I see now, thanks @dbuenzli@hannes. I though the package maintainer had editorial ownership of the opam files, and their maintenance came from the package repositories.
Just to expand a bit your idea which I was thinking about.
Given the current way the repo is managed now (no editorial ownership of the opam file), I think that having this in the opam repo is a good tradeoff. Your idea would increase failure modes which is not necessarily a good idea.
E.g. suppose someone DOSes the audit service but not the opam repo, what do you do now? More choices… disallow install, install but warn, etc.
Also opam is able to work offline, I think it’s nice to have the advisories that were there when you last captured the state of the repo even when you work offline. You could of course also grab the current state of the audit service before going offline but altogether it seems to me that it makes the system more complex for little gain.
If adding security-message or similar to opam packages I wonder what expectations people would have for archived packages - should they as well be updated with security-message?