Maven handles multiple "servers" (remote resources like for resolve, deploy, etc) that may need access credentials. Historically, these were stored in settings.xml, later the "SecDispatcher" was added, but it provides merely "security by obscurity" as we all know. This page would like to discuss how and what would we need to change in Maven, to properly handle (source) sensitive data.

I hope we all agree, that settings.xml with plaintext (or obfuscated, like SecDispatcher does) passwords and other security credentials is bad.

On CI systems users usually use properties in settings.xml (like ${env.SERVICE_PASSWORD} etc.) and configure those as "secrets", and this is fine.

This page is more about "workstation" case, where developers develop, deploy and maybe even release.

Just some ideas thrown out:

  • keep SecDispatcher but use 2.1+ (this requires full re-encryption) with one change: require GPG present on workstation (anyway is, if signing or releases happen from workstation) and use GPG Agent to store master password (instead as today, a file on disk). The GPG Agent could prompt once for password and "remember" it for login session duration.
  • Integrate something like
  • Come up with something completely new?

Ideally we should come up with something simple and "cheap" (implementation effort wise), hence my personal preference would be really (mis)use of GPG Agent. IMHO, if Maven user requires encryption of his settings.xml, this would be low barrier to jump. For plaintext users nothing would change, of course.

  • No labels


  1. Some oses  has a native storage for sensitive data, like MackOS - Keychain

  2. Doing that to work on all supported OSes IMHO would be very hard.

    Also, on CI systems users usually do ${env.SERVICE_PASSWORD} and it is configured as "secret" env variable. This is fine.

    Am more tinkering about workstations... 

  3. Storing plain text creds is not necessarily bad as long as you can properly protect the file by means of FS permissions. Also read Password.