I understand that this can be done at release using the maven-gpg-plugin. However, I am not developing open source software. Do I still need to sign my own artifacts? What is the point of this? I thought that once my sources were compiled into a JAR, they were secure anyway? Thanks!
If you compile your sources into a jar is ok. But a jar a is simply zip file which can be simply unpacked by unzip/jar after that you can modify the contents of a jar which means you can simply change the contents and repackage that into a jar. So to say it clear: It's safe is simply wrong.
If you create your artifacts via maven you will deploy your artifacts to a repository manager and during the release process a SHA1 sum is created ...which can be checked during the usage of dependencies (download). The default configuration just prints out a warning if the checksum in the repository is not the same as calculated over the jar archive. You can if you like change the configuration to break the build if the checksum is wrong.
The checksum is only to identify modifications of artifacts which is also not 100% safe cause it can happen that you have a man-in-the-middle-attack which might not only modifiy the contents of the jar and also the checksum.
On the other hand the signing of an artifact is used to identify who has created that artifact. In some environments it does make sense to sign artifacts during the release process.
Update To prevent man-in-the-middle-attach the Maven central repository used for a long time https instead of http.
Related
I have this log4j-1.2.12.jar file in my jenkins server
Path to it: /data/jenkins/.m2/repository/log4j/log4j/1.2.12/log4j-1.2.12.jar I got this Apache Log4j Unsupported Version Detection message from security team, how to resolve this I tried downloading the latest version but it is something like this log4j-api-2.19.0.jar
No, it's not "in Jenkins", more accurately, log4j is not a part of Jenkins. Jenkins consumes its jars from the exploded war in ${JENKINS_HOME}/war/WEB-INF/lib. It is not located there.
If a plugin consumes log4j, that would be found within the exploded plugin directory at ${JENKINS_HOME}/plugins/<plugin_name>/WEB-INF/lib. The status of log4j as it related to most plugins was tracked under JENKINS-67353.
What you are referencing is the maven local repository, .m2/repository. This structure is created when running a maven build on the controller; the dependency jars specified in (one of) your build's pom.xml.
The guidance in the comments is correct; find the appropriate pom.xml and update it, then rebuild.
You can verify these claims by deleting the entire .m2 directory (or moving / zip;delete if you are paranoid) and restarting Jenkins. You'll discover Jenkins is running fine and the directory remains empty. Run your maven jobs and it will repopulate, including log4j-1.2.12.jar, assuming it's still specified in your pom.xml. Fix your maven pom.xml, delete the directory, rerun your jobs and it should not reappear.
Perhaps you have already updated your pom.xml but never cleared out your local maven repository, then it will not repopulate (you could check the timestamp of the directory to know when it was first/last downloaded).
You can also delete referenced portions of the repository by specifying mvn dependency:purge-local-repository and adding -DreResolve=false to avoid re-resolving. Of course, if you've already updated the pom.xml, it would remain since it's not referenced in the pom.xml` (yes, it would be nice if there was an option to purge all or most of a repository or all version of a given jar, but ...).
I'm working on a basic Jenkins pipeline. The build and testing are successful but I'm looking at how to archive the build. For context, this is a simple Rust webserver.
Under the pipeline steps documentation in the Basic Steps plugin, it has the archive function. But it says:
Archives build output artifacts for later use. As of Jenkins 2.x, you may use the more configurable archiveArtifacts.
I cannot find any documentation on archiveArtifacts. There are some examples, but I would like to look at the documentation for it, what parameters it accepts, i.e. what makes it more configurable than archive.
My question: is there a place where this documentation is best found? jenkins.io is incomplete and wiki.jenkins.io is missing this command.
I suggest archiveArtifacts: Archive the artifacts from the Pipeline Steps Reference.
Archives the build artifacts (for example, distribution zip files or
jar files) so that they can be downloaded later. Archived files will
be accessible from the Jenkins webpage. Normally, Jenkins keeps
artifacts for a build as long as a build log itself is kept, but if
you don't need old artifacts and would rather save disk space, you can
do so.
Note that the Maven job type automatically archives any produced Maven
artifacts. Any artifacts configured here will be archived on top of
that. Automatic artifact archiving can be disabled under the advanced
Maven options.
artifacts
You can use wildcards like 'module/dist/**/*.zip'. See the includes attribute of Ant fileset for the exact format. The base directory is the workspace. You can only archive files that are located in your workspace.
Type: String
allowEmptyArchive (optional)
Normally, a build fails if archiving returns zero artifacts. This option allows the archiving process to return nothing without failing the build. Instead, the build will simply throw a warning.
Type: boolean
excludes (optional)
Optionally specify the 'excludes' pattern, such as "foo/bar/**/*". A file that matches this mask will not be archived even if it matches the mask specified in 'files to archive' section.
Type: String
I wanted to know if we have a plugin or can we write a pre delivery script that will change the value of packaging in my pom file. I want it updated from jar to pom. Can a plugin help with this? Suggestion welcome.
I tried-and-tested with maven profiles but do not want to go that route.
When you deliver in RTC, all you are doing is making your file available to any repo workspace monitoring the common Stream.
If you need to make some change to a pom.xml (without using profiles), then it is simpler to publish (that is add, commit and deliver) as well a script which would:
copy the pom.xml
change it as you need
use it with a mvn -f pom-modified.xml
The point is, as mentioned in this thread:
There is no out of the box solution for enforcing any pre-deliver steps.
You can try and add an RTC extension, as described in "RTC: Build On Deliver Participant" by Jorge Díaz.
I am new to jenkins and I have tried downloading a zip archive of this workspace in jenkins, but I only get a part of it. Source folders like tensorflow or tools are not present inside the archive. Is this normal ?
If so, how do I get all of them inside a zip file ?
Use Archive Artifact plugin, to add your workspace into archive folder which will make it easily down-loadable.
But be aware that, an artifact in the Jenkins sense is the result of a build - the intended output of the build process.
A common convention is to put the result of a build into a build, target or bin directory.
The Jenkins archiver can use globs (target/*.jar) to easily pick up the right file even if you have a unique name per build.
putting a complete workspace into it will take lot of time.
I am new to ant and Ivy. We are using Jenkins for CI with ant for builds, Ivy for dependency manger. We have several modules/projects which generate jars and wars, which can be independently versioned and released (not all modules will be released at the same time), so, need to maintain version number separately for each module. We want to use the version format A.B.C.D (ex: 1.2.1.2). I found I can use a property file to enter a version number and use ant BuildNumber task to increment the number for our nightly builds. So, once all the features are in and tested we move the last successful nightly build as new released version but we want to change the version number without rebuilding it. For example last successful build was 1.2.1.20 and it was tested thoroughly and has all the feature, we have to make this build from 1.2.1.20 to 1.3.0.0 without rebuilding the modules. How can I do that using ant? And also I need to publish them to my shared repository with the version 1.3.0.0. How do I do that?
Also, we want to create a zip file for each module with all dependency files along with the module's jar file for delivery. Is there any ivy or ant tasks that can help to create this?
I think you've asked two questions...
Generally, every build I create is releasable so I'm always incrementing the last digit in my release number scheme. For controlling the version number I prefer to use the ivy buildnumber task, which increments based on what has been previously pushed to your repository (very useful).
Creating a zip package is quite straight forward. Just alter your ivy file to publish more than one artifact.