To be able to upload into a company's Maven Repository (like Nexus), Jenkins typically needs to know the passwort of the repo. The typical solution is to let the Config File Provider Plugin provide an account-specific settings.xml which contains this password. This works well already.

Unfortunately, the password is in plain text in this file so every user having read access to Jenkins now can see the upload password, which is typically not wanted in production environments. Maven could encrypt the password, but to decrypt it, Jenkins would need to know the master password, which typically is stored in a separate settings-security.xml file.

The Config File Provider plugin does not know directly how to handle settings-security.xml, so one has to put up a rather complex fixture with given paths and so on. This should work, but is neither smart now comfortable.

Hence my proposal is that the Config File Provider plugin should learn to natively deal with settings-security.xml files, just as it already natively knows how to deal with settings.xml files. One could then simply tell the plugin to provide a settings-security.xml file, then tell the Maven job to use the provided settings-security.xml file (just as one tells the Maven job to use the provided settings-security.xml file already).

This makes using settings-security.xml rather simple, smart, stable and secure, especially in environments with lots of clients and nosy users!