How to secure Maven passwords?

[Steffen Breitbach]

Hi everyone!

I've been agonising about this for quite some time now. However, I have
yet to find a solution for this.

Is there a way to prevent malicious users from obtaining server
passwords from your Maven settings?

If you use the Config File Provider plug in with the Credentials plug
in, you can add "help:effective-settings -DshowPasswords=true" and you
will see the passwords in clear text.
Even if you use Maven's security mechanism to encrypt passwords via the
settings-security.xml, you could e.g. add a build step that executes
"cat ~/.m2/settings-security.xml" (or hide something similar in your
build process). This way you'll have the crypted password and the
settings-security.xml and could still deploy unauthorized software to
your artifact repository.

Is there any way to prevent this?

Regards
Steffen

[Stephen Connolly]

The best you can do is restrict the credentials in visibility.

Have separate jobs using the credentials from others...

Lock permission to configure the jobs using credentials

Etc

I have some other thoughts which I may work on for making maven easier with the literate job type.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/567A72F4.9060303%401und1.de.
For more options, visit https://groups.google.com/d/optout.

--
Sent from my phone

[Steffen Breitbach]

Hi Stephen,

I'm not exactly sure what you mean.

Are you saying that users should not be allowed to configure jobs so
they can't, for example, add "help:effective-settings
-DshowPasswords=true" to a job?

Cheers
Steffen

On 23.12.2015 13:24, Stephen Connolly wrote:
> The best you can do is restrict the credentials in visibility.
>
> Have separate jobs using the credentials from others...
>
> Lock permission to configure the jobs using credentials
>
> Etc
>
> I have some other thoughts which I may work on for making maven easier
> with the literate job type.
>
>
>
> On Wednesday 23 December 2015, Steffen Breitbach

> <mailto:jenkinsci-use...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMxrF%2BqxESGWTz3O8%3DtUd%2BCxQG4yS78vfxpRfUhYGayYaw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMxrF%2BqxESGWTz3O8%3DtUd%2BCxQG4yS78vfxpRfUhYGayYaw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

--

Steffen Breitbach

Operations Architect
Continuous Integration & Delivery BS

1&1 Internet SE | Bahnallee | 56410 Montabaur | Germany
Phone: +49 2602 96-1282
E-Mail: steffen....@1und1.de | Web: www.1und1.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Christian Bigatà Joseph, Robert Hoffmann, Hans-Henning
Kettler, Uwe Lamnek
Aufsichtsratsvorsitzender: Michael Scheeren


Member of United Internet

[Stephen Connolly]

Well they should also not be allowed to modify the pom.xml to stop them adding

<plugin>

  <artifactId>maven-help-plugin</artifactId>

  <executions>

    <execution>

      <phase>validate</phase>

      <goals><goal>effective-settings</goal></goals>

    </execution>

  </executions>

</plugin>

Oh and don't let them add unit tests because those could do System.exec("man help:effective-settings") and email the results to somewhere else

Etc

The long and the short is that you have to trust your developers at least somewhat...

If you have a critical password that they should not have access to, then don't let them have access to the job that has that password...

PS this is not a "Jenkins" problem as any CI system will have these issues... Fundamentally this is a trust problem

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/56823991.5070202%401und1.de.

For more options, visit https://groups.google.com/d/optout.