[chadlwilson]

Description of Change

Sonatype Guide seems to have bad validation on its URIs and happily emits invalid URIs off this OSS Index compatibility API. Since this API and the client library is deprecated this is unlikely to change much, so we can probably safely override the unmarshaller to be lenient and ignore these bad URIs.

Related issues

• fixes OSS Index analyzer fails for all components: URISyntaxException on reference URL with multiple '#' (CVE-2026-101677) #8859

Have test cases been added to cover the new functionality?

yes

[marcelstoer]

@chadlwilson Thanks for this. I toyed with a very similar proposal back when I wrote #8859 (comment). However, in my sketch I try to fix rather than ignore invalid URIs. It percent-encodes all characters of the given value that are not allowed (existing percent-encoded octets are preserved).
However, as long as the number of invalid URIs at Sonatype is small, we should be fine ignoring them.

@jeremylong Do you plan to release 13.0.1. soon?

[chadlwilson]

I dropped them because theres not really a safe and deterministic way to fix a poorly encoded URI without creating risk, especially as we make them clickable to users on html reports.

Like if there are two hashes/fragment separators it's ambiguous as to which one is the fragment separator, or neither, especially if there are slashes or query separators anywhere in between. As a force-of-habit from security/owasp good practices I tend to avoid assuming anything, and it didn't seem worth putting any more effort into using other url decoders that might have already tested which deviations are "safe" to allow, and normal "in the wild". Manually fixing URLs is the road to hell (paved with good intentions), as with manually parsing times/dates, or using regexes to validate hosts/domains 😅

[janwillemkeizer-deltafiber]

Thanks!

[dl6lr]

Since this API and the client library is deprecated this is unlikely to change much

Is there any plan to move to a non-deprecated Sonatype Guide API? The API at https://guide.sonatype.com/api seems to have only the access with existing OSSI user/password marked as legacy.

[chadlwilson]

@dl6lr Do you actually have an issue?

Not really sure what you are talking about though on username/password. Their API docs are full of inaccuracies. It's been possible to use a Guide PAT with that APi for 6 months now, and that is the recommended way.

They only launched this thing 6 months ago, and it's essentially a bait and switch to turn OSSIndex into a paid service (totally within their rights, but let's call it what it is), so the motivation to do free work to bring them more customers is likely low for most volunteer contributors. Sonatype provided zero assistance during the earlier migration this year, despite multiple changes to compatibility and responses from the "compatibility" API that required change to ODC (and things like this which are also backward compatibility issues).

#8450

Anyway, I was speaking loosely - technically it is not deprecated, just not under active development. https://www.sonatype.com/products/sonatype-guide/oss-index-users https://help.sonatype.com/en/oss-index-migration-to-sonatype-guide.html

While nothing is published now, deprecating the only client library is not a good sign, and I would not be surprised to see them renege again on their promises of continuity, and after the legacy OSSIndex tokens expire at EOY 2026, and the old domain goes dark, for them to then set a new date to remove the compatibility API too. Hope not though.

[dl6lr]

Currently no issue. We are a paying Sonatype Guide user, so we switched from the old OSSIndex-credentials (username and password) for DependencyCheck to the Sonatype Guide personal access token. But we are facing the issue with invalid URIs, so I was hoping that there is a "non-legacy" API for Sonatype Guide. The first link states the OSSIndex API can be used as a compatibility with OSSIndex-Users and a new extended vulnerability API, so my thought were that this can be used in DependencyCheck in the future and do not rely on the compatibility API.

[chadlwilson]

You don't have to pay for Guide to use a PAT. Everyone should use a PAT, and eventually by end of year itll probably be the only option.

Anyway, rather than speculating, ask them, and state your needs. Complain about the broken URLs. Complain about relying on volunteer open source maintainers to work around their service bugs.

Why people ask volunteers on the internet rather than than the commercial providers they actually pay money to I'll never understand. You should expect better and impose on the right people.