Does the advisory database cover other maven repositories?

[joshbressers]

As best as I can tell, most of the current Java packages cover Maven Central and not other maven repositories

For example the Atlassian maven repo https://packages.atlassian.com/content/repositories/atlassian-public/com/atlassian/ contains confluence Java packages where Maven Central does not https://repo.maven.apache.org/maven2/com/atlassian/

If we look at the MVN Repository site, we can see the top maven repositories https://mvnrepository.com/repos (there are shockingly more of these than I expected)

Thanks in advance

[darakian]

The short answer is Sorta. As of today our data should be considered to refer to objects on maven central only and if the package names and versions happen to be useful when read in the context of another registry then that's a happy accident. Longer term we've got a conversation going with OSV here https://github.com/ossf/osv-schema/issues/208 on how to properly address the data which is happy accident today.

[KateCatlin]

Hey @joshbressers any other questions on this issue or shall we close this one out?

[joshbressers]

@KateCatlin Is there somewhere you track long term feature requests?

I understand the need to limit scope, but this is a blind spot in the way Maven is consumed in the Java ecosystem today. When OSV adopts the ability to correctly represent Maven repositories I would like to continue this disucssion

[KateCatlin]

@joshbressers we do have a public roadmap, but not everything we're planning to build is on it.

Happy to continue the discussion as well! Especially as OSV expands how they define it.

[joshbressers]

I want to give this one a bump. It looks like OSV has merged the ability to support multiple maven repositories

https://github.com/ossf/osv-schema/issues/208 https://github.com/ossf/osv-schema/pull/231

[darakian]

We have some work to do on our backend. I can't promise any timelines, but I'll ping back when we're ready to start accepting alternate registry info 👍