[MNG-8417] New encrypted passwords prevent maven from building projects

[jira-importer]

Lenny Primak opened MNG-8417 and commented

When settings.xml contains new-style encrypted passwords, maven will not build unless it can decrypt the password.

The use case is that the passwords are used only for deployment, while 99% of the use cases don't require the passwords.

This forces the users to have to have secure environment variables or other ways to get the master password at all times, enhancing security risks

---

Affects: 4.0.0-beta-5, 4.0.0-rc-1

Issue Links:

• MNG-8419 non obvious errors if maven can not decrypt passwords in settings

[jira-importer]

Tamas Cservenak commented

Issue title is right: corrupt passwords will make Maven4 refuse to start.

But the assumptions in description are wrong. For start, on workstation you should use some tool (pinentry, gpg-agent) that is usually integrated with OS keychain and just not care about this (just like GPG plugin).
Second, if Maven "cannot decrypt" password, it implies that it will not able to do so even if needed. So this merely goes ahead, is more consistent, that telling you after 30 min build that it failed to deploy as, well, could not decrypt password.
Third, the fact you do have non-encryptable passwords in your settings just nicely shows why Maven3 approach was bad: nobody cared, and your config just went stale. Keep your settings tidy, and now you can (as Maven3 did not provide you any other option that to deploy, as you said, to check is pw ok or not).

Moreover, Maven4 now decrypts whole settings, so you are free now to put PT tokents into HTTP headers and so on. Again, whole settings is decrypted, and you are free to use encrypted strings wherever you want.

This solution is in fact far superior of that done in Maven3 (even if you neglect the fact that Maven3 merely "obfuscated" and not "encrypted" passwords).

There is no "security risk", unsure why you think there is. In fact, there IS if you use Maven3 passwords, as the master-master-password (pwd used to encrypt your master pw) is in plain sight. Just set up yourself properly, the env variable source is NOT meant for workstations, is for CI uses, gosh. Read on GPG site about this, as the strategy is pretty much similar.

[jira-importer]

Lenny Primak commented

Here is the use case.

Picture a CI system. Most requests to the CI is to do.. well. CI

CI will call maven many, many times for many tasks. CI has a settings.xml. file.

One of the jobs in this CI is to deploy to production.

The "deploy to production" script is the only one that's authorized to decrypt the passwords.

Let's say that said CI wants to reuse a settings.xml file. It can't. Because all jobs now need access to decrypt the passwords.

No good.

[jira-importer]

Tamas Cservenak commented

Use alternate settings? Use project level settings? And make user level provide auth when needed? So many options with Maven4, while I feel you are forcing Maven3 patterns onto Maven4.

Also, what does "The "deploy to production" script is the only one that's authorized to decrypt the passwords." even mean? It has own settings with secrets? If so, what is the problem? If secrets are shared, that I have no idea what this sentence means.

[jira-importer]

Lenny Primak commented

Yes, but this forces hundreds of thousands of CIs out there to deal with breaking changes like this.

Think about the work involved. It's one thing to volunteer for this, but when this is forced upon, it's not good.

What about backwards compatibility? Upgrade path? Downgrade path?

Some projects need one thing, some others, etc. etc. This is way too much work, way too risky as it stands now.

It will hurt adoption for sure.

 

Just in my case, my simple CI is completely broken and I spent >25 hours so far trying to fix it.

Think about the work this makes many, many people do unnecessarily.

[jira-importer]

Tamas Cservenak commented

Well, exactly as you mention: one need to bite the bullet (clean up settings for stale stuff) as mvn3 was very forgiving in this respect. Also, in case of progress you do need break few things. And here, it is not "breaking" things, just enforcing "they work" (or in other words, cleaning up the piled up stale things). I understand your frustration, just like when we did "warn for plugins using deprecated apis" and people were like "this was working for 10 years and now it warns me!" ... well, yes, the fact it worked for 10 years is great, but we need to move from this "status quo"...

[grubeninspekteur]

We have a settings.xml that sets properties like the following:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
  <profiles>
     <profile>
	   <id>curlyproperty</id>
	   <activation>
	     <activeByDefault>true</activeByDefault>
	   </activation>
	   <properties>
	     <some.property>%{foo}.txt</some.property>
	   </properties>
	 </profile>
  </profiles>
 
</settings>

This works fine in Maven 3.9.11 and provides the property to Maven projects as-is. However, with Maven 4.0.0-rc-4, this will yield FATAL: Could not decrypt password (fix the corrupted password or remove it, if unused) %{foo}.txt. I can't find a way to escape the property so it isn't recognized as an encrypted password.

[cstamas]

This is def a bug.

[arturobernalg]

Pleas take a look 11093