Draft: Challenge X: nexus credentials as part of a project pushed (#810)

[divyanshuagarwal-23]

What kind of changes does this PR include?

-Fixes

Description

As per #810 task one was to Create a settings.xml to connect to an imaginary Nexus repo,
I have created the settings.xml file for the same
and have created a challenge reading the credential

Relations

closes #810

References

issue: #810
took ref from: https://github.com/sonatype/nexus-book-examples/blob/master/maven/settings/settings.xml

[divyanshuagarwal-23]

@commjoen please review this new PR,
I will close the old one, which was causing issue due to challenge number

[commjoen]

I was not able to get it running on my system in this shape. Can you please have a look at the comments for an alternative approach?

[commjoen]

this looks like a left-over from challenge41, can you remove this please?

[commjoen]

I am getting

java.io.FileNotFoundException: class path resource [maven/settings/settings.xml] cannot be opened because it does not exist
	at org.springframework.core.io.ClassPathResource.getInputStream(ClassPathResource.java:211) ~[spring-core-6.0.12.jar:6.0.12]
	at org.springframework.core.io.Resource.getContentAsString(Resource.java:165) ~[spring-core-6.0.12.jar:6.0.12]

[commjoen]

This resource does not exist (see below), can you instead have a look at the code of Challenge12.java? here you can see how a file is loaded either from test resources or from a filepath within a docker container or from the resources.

[commjoen]

this gives quite a few different exceptions. Can we do it with the jdk based parser?

DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
        DocumentBuilder dBuilder = dbFactory.newDocumentBuilder();
        dbFactory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
        Document doc = dBuilder.parse(Paths.get(filepath "settings.xml").toFile());
        doc.getDocumentElement().normalize();
        return doc.getDocumentElement().getElementsByTagName("servers").item(0).getChildNodes().item(0).getNextSibling().getChildNodes().item(4).getNextSibling().getTextContent();

or something among these lines. And can you remove the entry from the pom.xml ?

[commjoen]

Suggested change

	log.warn("there was an exception with decrypting content in challenge42", e);
	log.warn("there was an exception with retrieving and parsing the xml content for challenge42", e);

[commjoen]

Suggested change

	return "error_decryption";
	return "error_parsing";

[commjoen]

Suggested change

	Assertions.assertThat(challenge.answerCorrect(challenge.spoiler().solution())).isTrue();
	Assertions.assertThat(challenge.answerCorrect(challenge.spoiler().solution())).isTrue();
	Assertions.assertThat(challenge.answerCorrect("error_parsing").isFalse();

[commjoen]

Suggested change

	Storing nexus deployment credentials in your github project hardcoded is generally considered a bad practice because it undermines the security provided by encryption.
	A developer wanted to configure his Nexus credentials and copy-pasted the configuration from the internal Confluence documentation site, while accidentally committing it to git!
	Can you find the password?

[commjoen]

Suggested change

	Storing nexus deployment credentials in your github project hardcoded is generally considered a bad practice because it undermines the security provided by encryption.
	In such scenarios, an attacker has the key the moment the file is in his possession.
	It is always recommended to store your credentials securely.
	Storing the credentials of your artifact registry in your Github project is a bad practice, as others can use these credentials to login, pull, and sometimes push artifacts in the name of the identity user of which the credentials were committed to git.
	We often see the situation getting worse by just having one user hardcoded in many configurations of their projects.
	Alternatively, we often see the artifact registry credentials hardcoded in the internal documentation site of an organization.
	In all cases, we often end up with a compromised user used to inject payloads into the artifact registry.
	This is why it is better to have service accounts and/or personal accounts and/or a federated approach for users to the artifact registry. Next, make sure that you never hardcode the credentials: instead: have them configured as part of a secrets management setup.

[bendehaan]

Hello @divyanshuagarwal-23,

Thank you for your contribution. We appreciate your interest in helping improve WrongSecrets. However, we've noticed that there hasn't been any activity on this PR for several months.

We'll close this PR for now to maintain an efficient and organised workflow. Please don't be discouraged! We welcome you to reopen this PR or create a new one if you wish to continue your contribution in the future.

Feel free to reach out if you have any questions or need assistance.

Thank you for your understanding.