Serguey Asael Shinder: Maven 3.10.0 binds server credentials to the origins of their repositories
Apache Maven 3.10.0 was released on 1 October. The release notes list validation changes, a newer Maven Resolver, server aliases in settings.xml and a long run of fixes. The change most likely to show up in your build log is about where your repository passwords are allowed to go.
What changed. Until now a <server> entry in settings.xml supplied credentials to whatever repository used the same id. In 3.10.0, according to pull request 12954, server credentials are scoped to the origin, meaning protocol, host and port, of a repository or mirror that you declared for that server id. The setting is maven.repository.credentialScope, and it defaults to origin. An id with no declared origin keeps the old behaviour but logs a warning naming the target origin; with maven.repository.credentialScope=strict Maven refuses the credentials instead. The same pull request makes DefaultWagonManager match server ids exactly, where it previously matched them ignoring case.
The reason is easy to see. A repository id can arrive from places you do not control, such as a dependency's POM, and a credential that follows the id rather than the host can be sent to a server it was never meant for.
The catch, and the fix for it. As pull request 13275 explains, Maven builds the list of declared origins before any project is read. Repositories declared inside a settings.xml profile only make that list when the profile is listed under <activeProfiles>. A profile switched on by an <activation> condition or by -P contributes no origin, so a legitimate corporate repository gets a warning on every build under the default scope, and a 401 under strict. The fix, included in 3.10.0, lets a server declare its origins directly:
<server>
<id>internal</id>
<username>u</username>
<password>p</password>
<repositoryOrigins>
<repositoryOrigin>https://repo.example.org</repositoryOrigin>
</repositoryOrigins>
</server>Declared origins are added to the ones Maven finds itself, so existing setups are unaffected, and values are checked by settings validation, so a typo is reported in the file rather than as a refused credential later.
What to do. After upgrading, read the first build log for credential-scope warnings. Each one names an origin that is about to receive a password without being declared. Either declare it in <repositoryOrigins>, or find out why your build talks to it at all. Then consider strict on CI, where a refused credential is a failed build rather than a line nobody reads.