A plugin for Android application development with Apache Maven 3.0.5+ and the Android SDK.
Please check out our website for further information!
We welcome all the help we can get! Read more on in the documentation and join the large list of contributors.
If you have project with one APK module and several AAR modules used with main APK module and run mvn package command. Maven should build AAR modules first and then use it as dependency for the main APK module.
It almost works. Maven build modules first and then unpack final AAR to the target/unpacked-libs of the main APK module. But during compile task it didn't use then unpacked directory but directory with the name of the latest version in the repository.
For example if I have version 2.0.5-SNAPSHOT of my AAR library module it is unpacked to this folder app/target/unpacked-libs/eial_android-about_2.0.5-SNAPSHOT But compile task is looking for: app/target/unpacked-libs/eial_android-about_2.0.5-20150112.101322-7/classes.jar instead of app/target/unpacked-libs/eial_android-about_2.0.5-SNAPSHOT/classes.jar
"2.0.5-20150112.101322-7" is latest version from my maven repo.
Related group thread https://groups.google.com/forum/#!topic/maven-android-developers/AdLn3i2EJEw
@william-ferguson-au does this sounds a bell to you ?
If not I will make a cut down project tomorrow morning.
This project has 2 modules app & espresso
If I comment the espresso module everything is fine.
My guess is that there's a configuration problem in the espresso module
Here is my pom:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.xxxxxx</groupId>
<artifactId>xxxxxx-parent</artifactId>
<version>1.0.3-SNAPSHOT</version>
</parent>
<artifactId>xxxxxx-espresso-test</artifactId>
<packaging>apk</packaging>
<name>xxxxxx - test</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<environment>development</environment>
<sonar.language>java</sonar.language>
<sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
</properties>
<dependencies>
<dependency>
<groupId>android</groupId>
<artifactId>android</artifactId>
<version>${android.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.google.android</groupId>
<artifactId>annotations</artifactId>
<version>4.1.1.4</version>
<scope>provided</scope>
</dependency>
<!--<dependency>
<groupId>com.android.support</groupId>
<artifactId>support-v4</artifactId>
<version>19.0.1</version>
<scope>provided</scope>
</dependency>-->
<!--<dependency>-->
<!--<groupId>com.android.support</groupId>-->
<!--<artifactId>appcompat-v7</artifactId>-->
<!--<version>19.0.1</version>-->
<!--<type>aar</type>-->
<!--</dependency>-->
<!--<dependency>
<groupId>com.xxxxx</groupId>
<artifactId>yyyy-app</artifactId>
<version>${project.version}</version>
<type>jar</type>
<scope>provided</scope>
</dependency>-->
<dependency>
<groupId>com.xxxxx</groupId>
<artifactId>yyyy-app</artifactId>
<version>${project.version}</version>
<type>apk</type>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.google.android.apps.common.testing</groupId>
<artifactId>espresso</artifactId>
<version>1.1</version>
</dependency>
</dependencies>
<build>
<outputDirectory>target/classes</outputDirectory>
<plugins>
<plugin>
<groupId>com.jayway.maven.plugins.android.generation2</groupId>
<artifactId>android-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<sdk>
<platform>${android.api}</platform>
</sdk>
<extractDuplicates>true</extractDuplicates>
<undeployBeforeDeploy>true</undeployBeforeDeploy>
<sign>
<debug>false</debug>
</sign>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
Error ouput of mvn clean install --debug
[DEBUG] Created dummy classes.jar exist=true
[DEBUG] Adding to classpath : D:\Workspace\myproject\module-app\target\unpacked-libs\cgfd_library\classes.jar
[DEBUG] Created dummy classes.jar exist=true
[DEBUG] Adding to classpath : D:\Workspace\myproject\module-app\target\unpacked-libs\nd_android.joda\classes.jar
[DEBUG] Created dummy classes.jar exist=true
[DEBUG] Adding to classpath : D:\Workspace\myproject\module-app\target\unpacked-libs\cas_appcompat-v7\classes.jar
[DEBUG] Created dummy classes.jar exist=true
[DEBUG]
[DEBUG] project=com.xxxxxx:yyyyy-espresso-test:apk:1.0.3-SNAPSHOT
[ERROR] Internal error: java.lang.ClassCastException: org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder cannot be cast to org.apache.maven.shared.dependency.graph.DependencyGraphBuilder -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: java.lang.ClassCastException: org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder cannot be cast to org.apache.maven.shared.dependency.graph.DependencyGraphBuilder
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:167)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.ClassCastException: org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder cannot be cast to org.apache.maven.shared.dependency.graph.DependencyGraphBuilder
at org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDependencyGraphBuilder.java:86)
at com.jayway.maven.plugins.android.common.DependencyResolver.getProjectDependenciesFor(DependencyResolver.java:45)
at com.jayway.maven.plugins.android.phase_prebuild.ClasspathModifierLifecycleParticipant.afterProjectsRead(ClasspathModifierLifecycleParticipant.java:87)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
... 11 more
[ERROR]
This is a WIP. I did not squash the commits, so you can see exactly what steps I did while experimenting.
This PR:
Unfortunately the Morseflash test fails sometimes, because the emulator is not unlocked despite it is instructed to. To debug this I print the build log and save the screenshots to a repo. Any help is appreciated to fix this last problem.
What steps will reproduce the problem?
<ndkArchitectures>armeabi armeabi-v7a</ndkArchitectures>
What is the expected output?
An APK with lib/armeabi-v7a/xxx.so and lib/armeabi/xxx.so
What do you see instead?
APK only contains lib/armeabi-v7a/xxx.so.
Also, the directory where the build is done only has libs/armeabi-v7a/xxx.so, libs/armeabi/xxx.so is missing here too.
What version of maven-android-plugin are you using?
3.8.2.
What are the complete output lines of "mvn -version" on your machine?
Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 17:22:22+0200) Maven home: /usr/local/apache-maven Java version: 1.6.0_65, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: sv_SE, platform encoding: MacRoman OS name: "mac os x", version: "10.9.1", arch: "x86_64", family: "mac"
Please provide any additional information below.
The output from the build suggests armeabi is build, and it is in the obj/ directory:
[INFO] --- android-maven-plugin:3.8.2:ndk-build (default) @ BlaAndroid --- [INFO] executing 8 parallel jobs [INFO] /Users/xxx/android-ndk-current/ndk-build [-C, /Users/xx/1.3.44, -j, 8, NDK_TOOLCHAIN=arm-linux-androideabi-4.6, APP_ABI=armeabi, xxx] [INFO] Cleaning up extracted include directories used for build [INFO] executing 8 parallel jobs [INFO] /Users/xxx/android-ndk-current/ndk-build [-C, /Users/xxx/1.3.44, -j, 8, NDK_TOOLCHAIN=arm-linux-androideabi-4.6, APP_ABI=armeabi-v7a, xxx] [INFO] Cleaning up extracted include directories used for build
Workaround is to set target to:
I don't understand the reason for this plugin to mess with APP_ABI at all, the info is in the Application.mk file already. Ditto NDK_TOOLCHAIN and target. A way to specify that a plain ndk-build without any arguments should be run would be appreciated. Or a way to say that no APP_ABI and/or no NDK_TOOLCHAIN and/or no target should be passed to ndk-build.
NDKWhile testing the upcoming 3.9.0-rc.2 (currently 3.9.0-SNAPSHOT) I ran into some problems getting the instrumentation tests to compile and run. This issue is to provide a reference point to link a sample test case against.
If you have
This might be related to how you are trying to switch over and use the updated path:
ManifestUpdateMojo.java#L662: project.getProperties().setProperty( "android.manifestFile", updatedManifestFile.getAbsolutePath() );
I don't think the other mojos are using the project property value instead of the pom value (
Running version 4.0.0-rc.2.
In order to update the sdk library we had to drop the Maven plugin testing harness based tests. The test coverage of these needs to be migrated into tests that use the Takari Plugin Testing infrastructure.
A minimal example exists in
https://github.com/jayway/maven-android-plugin/blob/master/src/test/java/com/jayway/maven/plugins/android/standalonemojos/ZipalignMojoIntegrationTest.java
The projects to used for testing are to be located in src/test/projects.
The tests we need to replaced have all been set to be ignored. See https://github.com/jayway/maven-android-plugin/commit/a707e82915add60065927f1582d0c6f8e4102afd
In-ProgressI'm looking through the NDK as part of a refactor with William on issue #360 and I think we can clean this up quite a bit.
I want to make sure we are on the same page before I make any drastic changes. Here's what I'm thinking...
First and foremost, only outputting files under target/ unless the user specifies otherwise.
clearNativeArtifacts parameter.
mvn clean to wipe out target instead)Change NDK_MAKFILE_DIRECTORY to "generated-sources/ndk"
target/generated-sources/ndk/android_maven_plugin_makefile.mktarget/ndk/build/android_maven_plugin_makefile.mk using ndkBuildDirectoryChange ndkBuildDirectory from project.getBasedir().getAbsolutePath() to "${project.build.directory}/ndk/build"
Change ndkOutputDirectory to "${project.build.directory}/ndk/libs"
Change nativeLibrariesOutputDirectory to "${project.build.directory}/ndk/obj/local"
ndkOutputDirectory and nativeLibrariesOutputDirectory? Do we need both?Because Android includes stale (or rather ancient) versions of a few popular open source libraries (e.g. Apache HttpClient & Apache Commons Codec) app developers may run into problems when they want to make use of more recent versions of these libraries (e.g. https://github.com/jayway/maven-android-plugin/issues/479).
Thankfully there is a Maven plugin, called maven-shade-plugin, which makes dealing with this sort of situation easy (e.g. http://stackoverflow.com/a/16916552/1084488).
But sadly android-maven-plugin and maven-shade-plugin do not seem to be compatible.
By default the maven-shade-plugin attaches itself to the package phase, meaning it performs the "class relocation" at the wrong moment in the apk build cycle, namely after, instead of before, dexing. Consequently only the jar is affected, not the apk (meaning the app code will still try to reference the library with the clashing package name).
I was therefore hoping it would be possible to make future versions of android-maven-plugin aware of maven-shade-plugin such that the shading can be triggered at the correct moment.
This possibility has been discussed before in 2011 (see https://code.google.com/p/maven-android-plugin/issues/detail?id=170) and a preliminary patch was produced, but as far as I've been able to find out the effort was abandoned.
In my opinion the most elegant solution would be to introduce some kind of <executeShadePlugin>true</executeShadePlugin> parameter in the <configuration> which would make android-maven-plugin aware of maven-shade-plugin.
Or, if the 2 plugins are inherently incompatible (which may be the case, see comment below) than perhaps it would be best if android-maven-plugin was extended with built-in support for this kind of "class relocation", without actually using the shade plugin as such.
this happens when my integration test project tries generate the sources and stumbles across my app.apk which is provided. the artifact's file name is "classes", since it refers to the target folder.
stacktrace:
on project integration: Execution default-generate-sources of goal com.jayway.maven.plugins.android.generation2:android-maven-plugin:4.0.0-SNAPSHOT:generate-sources failed: String index out of range: -1
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-generate-sources of goal com.jayway.maven.plugins.android.generation2:android-maven-plugin:4.0.0-1-SNAPSHOT:generate-sources failed: String index out of range: -1
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1911)
at com.jayway.maven.plugins.android.common.UnpackedLibHelper.getJarFileForApk(UnpackedLibHelper.java:159)
at com.jayway.maven.plugins.android.phase01generatesources.GenerateSourcesMojo.extractApkClassesJar(GenerateSourcesMojo.java:505)
at com.jayway.maven.plugins.android.phase01generatesources.GenerateSourcesMojo.extractLibraryDependencies(GenerateSourcesMojo.java:438)
at com.jayway.maven.plugins.android.phase01generatesources.GenerateSourcesMojo.execute(GenerateSourcesMojo.java:247)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
Work-around manifest update and merging messing up certain CRLF EOL markers -- fixes #511
Problem: When fed a manifest file with Windows-style line endings (CRLF) the ManifestMergerMojo replaces certain CRLF occurrences (specifically in multi-line XML comments) with Unix-style LF line endings, leaving the file with inconsistent line endings. The GenerateSourcesMojo and the (deprecated) ManifestUpdateMojo exhibit the same problem.
Because the ManifestMergerMojo relies on the Android builder library the problem should actually be tackled there (bug report: https://code.google.com/p/android/issues/detail?id=96992). But in the meantime, here is a stopgap solution...
Work-around being committed: In all 3 affected Mojos the I have added code to check whether the input manifest file has CRLF line endings, if it does I convert the file (or a temporary copy of it) to have LF line endings throughout and only then processes (update/merge) it. After processing the resulting (destination) manifest file is converted back to have CRLF line endings if the original file had them.
Hi! We spot a vulnerable dependency in your project, which might threaten your software. And we found that the vulnerable function of this CVE can be easily accessed from your software.
com.simpligility.maven.plugins.android.standalonemojos.ZipalignMojo:getFullPathWithName(java.lang.String)
⬇️
org.apache.commons.io.FilenameUtils:getFullPath(java.lang.String)
⬇️
org.apache.commons.io.FilenameUtils:doGetFullPath(java.lang.String,boolean)
⬇️
org.apache.commons.io.FilenameUtils:getPrefixLength(java.lang.String)
Therefore, maybe you need to upgrade this dependency. Hope this can help you! 😄
This pull request fixes a Zip Slip vulnerability either due to an insufficient, or missing guard when unzipping zip files.
Even if you deem, as the maintainer of this project, this is not necessarily fixing a security vulnerability, it is still, most likely, a valid security hardening.
This issue allows a malicious zip file to potentially break out of the expected destination directory, writing contents into arbitrary locations on the file system. Overwriting certain files/directories could allow an attacker to achieve remote code execution on a target system by exploiting this vulnerability.
The best description of Zip-Slip can be found in the white paper published by Snyk: Zip Slip Vulnerability
If the changes you see are a change to the guard, not the addition of a new guard, this is probably because this code contains a Zip-Slip vulnerability due to a partial path traversal vulnerability.
To demonstrate this vulnerability, consider "/usr/outnot".startsWith("/usr/out").
The check is bypassed although /outnot is not under the /out directory.
It's important to understand that the terminating slash may be removed when using various String representations of the File object.
For example, on Linux, println(new File("/var")) will print /var, but println(new File("/var", "/") will print /var/;
however, println(new File("/var", "/").getCanonicalPath()) will print /var.
Implementing a guard comparing paths with the method java.nio.files.Path#startsWith will adequately protect against this vulnerability.
For example: file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY) or file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY_FILE.getCanonicalFile().toPath())
:wave: Vulnerability disclosure is a super important part of the vulnerability handling process and should not be skipped! This may be completely new to you, and that's okay, I'm here to assist!
First question, do we need to perform vulnerability disclosure? It depends!
For partial path traversal, consider if user-supplied input could ever flow to this logic. If user-supplied input could reach this conditional, it's insufficient and, as such, most likely a vulnerability.
You have a few options options to perform vulnerability disclosure. However, I'd like to suggest the following 2 options:
![[SECURITY] Fix Zip Slip Vulnerability](https://avatars.githubusercontent.com/u/1323708?v=4)
JLLeitschuh Disclosure in the subject of your email so it is not missed.You can automatically detect future vulnerabilities like this by enabling the free (for open-source) GitHub Action.
I'm not an employee of GitHub, I'm simply an open-source security researcher.
This contribution was automatically generated with an OpenRewrite refactoring recipe, which was lovingly handcrafted to bring this security fix to your repository.
The source code that generated this PR can be found here: Zip Slip
This PR was automatically generated, in-bulk, and sent to this project as well as many others, all at the same time.
This is technically what is called a "Full Disclosure" in vulnerability disclosure, and I agree it's less than ideal. If GitHub offered a way to create private pull requests to submit pull requests, I'd leverage it, but that infrastructure, sadly, doesn't exist yet.
The problem is that, as an open source software security researcher, I (exactly like open source maintainers), I only have so much time in a day. I'm able to find vulnerabilities impacting hundreds, or sometimes thousands of open source projects with tools like GitHub Code Search and CodeQL. The problem is that my knowledge of vulnerabilities doesn't scale very well.
Individualized vulnerability disclosure takes time and care. It's a long and tedious process, and I have a significant amount of experience with it (I have over 50 CVEs to my name). Even tracking down the reporting channel (email, Jira, etc..) can take time and isn't automatable. Unfortunately, when facing problems of this scale, individual reporting doesn't work well either.
Additionally, if I just spam out emails or issues, I'll just overwhelm already over-taxed maintainers, I don't want to do this either.
By creating a pull request, I am aiming to provide maintainers something highly actionable to actually fix the identified vulnerability; a pull request.
There's a larger discussion on this topic that can be found here: https://github.com/JLLeitschuh/security-research/discussions/12
If you'd like to opt out of future automated security vulnerability fixes like this, please consider adding a file called
.github/GH-ROBOTS.txt to your repository with the line:
User-agent: JLLeitschuh/security-research
Disallow: *
This bot will respect the ROBOTS.txt format for future contributions.
Alternatively, if this project is no longer actively maintained, consider archiving the repository.
This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.
It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed off.
The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).
If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.
This contribution is sponsored by HUMAN Security Inc. and the new Dan Kaminsky Fellowship, a fellowship created to celebrate Dan's memory and legacy by funding open-source work that makes the world a better (and more secure) place.
This PR was generated by Moderne, a free-for-open source SaaS offering that uses format-preserving AST transformations to fix bugs, standardize code style, apply best practices, migrate library versions, and fix common security vulnerabilities at scale.
All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/security-research/issues/16
This pull request fixes a partial-path traversal vulnerability due to an insufficient path traversal guard.
Even if you deem, as the maintainer of this project, this is not necessarily fixing a security vulnerability, it is still a valid security hardening.
This issue allows a malicious actor to potentially break out of the expected directory. The impact is limited to sibling directories. For example, userControlled.getCanonicalPath().startsWith("/usr/out") will allow an attacker to access a directory with a name like /usr/outnot.
To demonstrate this vulnerability, consider "/usr/outnot".startsWith("/usr/out").
The check is bypassed although /outnot is not under the /out directory.
It's important to understand that the terminating slash may be removed when using various String representations of the File object.
For example, on Linux, println(new File("/var")) will print /var, but println(new File("/var", "/") will print /var/;
however, println(new File("/var", "/").getCanonicalPath()) will print /var.
Comparing paths with the java.nio.files.Path#startsWith will adequately protect againts this vulnerability.
For example: file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY) or file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY_FILE.getCanonicalFile().toPath())
:wave: Vulnerability disclosure is a super important part of the vulnerability handling process and should not be skipped! This may be completely new to you, and that's okay, I'm here to assist!
First question, do we need to perform vulnerability disclosure? It depends!
For partial path traversal, consider if user-supplied input could ever flow to this logic. If user supplied input could reach this conditional, it's insufficient and, as such, most likely a vulnerability.
You have a few options options to perform vulnerability disclosure. However, I'd like to suggest the following 2 options:
JLLeitschuh Disclosure in the subject of your email so it is not missed.You can automatically detect future vulnerabilities like this by enabling the free (for open-source) GitHub Action.
I'm not an employee of GitHub, I'm simply an open-source security researcher.
This contribution was automatically generated with an OpenRewrite refactoring recipe, which was lovingly hand crafted to bring this security fix to your repository.
The source code that generated this PR can be found here: PartialPathTraversalVulnerability
This PR was automatically generated, in-bulk, and sent to this project as well as many others, all at the same time.
This is technically what is called a "Full Disclosure" in vulnerability disclosure, and I agree it's less than ideal. If GitHub offered a way to create private pull requests to submit pull requests, I'd leverage it, but that infrastructure, sadly, doesn't exist yet.
The problem is that as an open source software security researcher, I (exactly like open source maintainers), I only have so much time in a day. I'm able to find vulnerabilities impacting hundreds, or sometimes thousands of open source projects with tools like GitHub Code Search and CodeQL. The problem is that my knowledge of vulnerabilities doesn't scale very well.
Individualized vulnerability disclosure takes time and care. It's a long and tedious process, and I have a significant amount of experience with it (I have over 50 CVEs to my name). Even tracking down the reporting channel (email, Jira, ect..) can take time and isn't automatable. Unfortunately, when facing prblems of this scale, individual reporting doesn't work well either.
Additionally, if I just spam out emails or issues, I'll just overwhelm already over taxed maintainers, I don't want to do this either.
By creating a pull request, I am aiming to provide maintainers something highly actionable to actually fix the identified vulnerability; a pull request.
There's a larger discussion on this topic that can be found here: https://github.com/JLLeitschuh/security-research/discussions/12
If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called
.github/GH-ROBOTS.txt to your repository with the line:
User-agent: JLLeitschuh/security-research
Disallow: *
This bot will respect the ROBOTS.txt format for future contributions.
Alternatively, if this project is no longer actively maintained, consider archiving the repository.
This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.
It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.
The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).
If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.
This contribution is sponsored by HUMAN Security Inc. and the new Dan Kaminsky Fellowship, a fellowship created to celebrate Dan's memory and legacy by funding open-source work that makes the world a better (and more secure) place.
This PR was generated by Moderne, a free-for-open source SaaS offering that uses format-preserving AST transformations to fix bugs, standardize code style, apply best practices, migrate library versions, and fix common security vulnerabilities at scale.
All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/security-research/issues/13
try to build with JAVA 11:
JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 mvn -U -B clean -P windows-linux,android-release-build install -Dandroid.sdk.path=/home/hanmac/android-sdks/ -T 1C -DskipTests=true -e
Plugin Config in Maven pom.xml
![[4.6.0] NPE when trying to call getAndroidTargetManager](https://avatars.githubusercontent.com/u/225553?v=4)
<plugin>
<groupId>com.simpligility.maven.plugins</groupId>
<artifactId>android-maven-plugin</artifactId>
<dependencies>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.1</version>
</dependency>
</dependencies>
<version>4.6.0</version>
<extensions>true</extensions>
<configuration>
<sign>
<debug>false</debug>
</sign>
<sdk>
<platform>26</platform>
</sdk>
<zipalign>
<verbose>false</verbose>
</zipalign>
<dexForceJumbo>true</dexForceJumbo>
<androidManifestFile>${project.basedir}/AndroidManifest.xml</androidManifestFile>
<assetsDirectory>${project.basedir}/assets</assetsDirectory>
<resourceDirectory>${project.basedir}/res</resourceDirectory>
<nativeLibrariesDirectory>${project.basedir}/libs</nativeLibrariesDirectory>
<extractDuplicates>true</extractDuplicates>
<proguard>
<skip>false</skip>
<config>${project.basedir}/proguard.cfg</config>
</proguard>
<release>true</release>
<dex>
<jvmArguments>
<argument>${build.min.memory}</argument>
<argument>${build.max.memory}</argument>
</jvmArguments>
</dex>
</configuration>
</plugin>
getting the following NPE:
[ERROR] Failed to execute goal com.simpligility.maven.plugins:android-maven-plugin:4.6.0:generate-sources (default-generate-sources) on project forge-gui-android: Execution default-generate-sources of goal com.simpligility.maven.plugins:android-maven-plugin:4.6.0:generate-sources failed. NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.simpligility.maven.plugins:android-maven-plugin:4.6.0:generate-sources (default-generate-sources) on project forge-gui-android: Execution default-generate-sources of goal com.simpligility.maven.plugins:android-maven-plugin:4.6.0:generate-sources failed.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:190)
at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:186)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)
at java.lang.Thread.run (Thread.java:829)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-generate-sources of goal com.simpligility.maven.plugins:android-maven-plugin:4.6.0:generate-sources failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:190)
at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:186)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)
at java.lang.Thread.run (Thread.java:829)
Caused by: java.lang.NullPointerException
at com.android.repository.impl.meta.SchemaModuleUtil.marshal (SchemaModuleUtil.java:264)
at com.android.repository.impl.manager.LocalRepoLoaderImpl.writePackage (LocalRepoLoaderImpl.java:275)
at com.android.repository.impl.manager.LocalRepoLoaderImpl.parsePackages (LocalRepoLoaderImpl.java:169)
at com.android.repository.impl.manager.LocalRepoLoaderImpl.getPackages (LocalRepoLoaderImpl.java:124)
at com.android.repository.impl.manager.RepoManagerImpl$LoadTask.run (RepoManagerImpl.java:517)
at com.android.repository.api.RepoManager$DummyProgressRunner.runSyncWithProgress (RepoManager.java:397)
at com.android.repository.impl.manager.RepoManagerImpl.load (RepoManagerImpl.java:364)
at com.android.repository.api.RepoManager.loadSynchronously (RepoManager.java:290)
at com.android.sdklib.repository.AndroidSdkHandler$RepoConfig.createRepoManager (AndroidSdkHandler.java:718)
at com.android.sdklib.repository.AndroidSdkHandler.getSdkManager (AndroidSdkHandler.java:295)
at com.android.sdklib.repository.AndroidSdkHandler.getAndroidTargetManager (AndroidSdkHandler.java:330)
at com.simpligility.maven.plugins.android.AndroidSdk.findPlatformByApiLevel (AndroidSdk.java:129)
at com.simpligility.maven.plugins.android.AndroidSdk.<init> (AndroidSdk.java:107)
at com.simpligility.maven.plugins.android.AbstractAndroidMojo.getAndroidSdk (AbstractAndroidMojo.java:1172)
at com.simpligility.maven.plugins.android.phase01generatesources.GenerateSourcesMojo.generateR (GenerateSourcesMojo.java:789)
at com.simpligility.maven.plugins.android.phase01generatesources.GenerateSourcesMojo.execute (GenerateSourcesMojo.java:240)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:190)
at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:186)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)
at java.lang.Thread.run (Thread.java:829)
4.6.0 and 4.5.0 cause this NPE 4.4.3 does not
AMP only uses AAPT (1). AAPT2 has been available since Android 24 https://developer.android.com/studio/command-line/aapt2
The resource value file in AndroidX.savedState has a structure that cannot be parsed by AAPT. I suspect there will be others.
AAPT2 explicitly splits resource packaging into compiling and linking (which we knew needed to be done because AMP invokes it twice, once in GenerateResources and once when packaging an AAR/APK)
We need to
I was having trouble using android-maven-plugin to build an aar library for the first time, and realised the examples defaulted to version 4.4.1 . When I change that version to 4.6.0, the examples no longer build for me. The version should probably be updated: https://github.com/simpligility/android-maven-plugin/blob/master/src/test/projects/libraryprojects/pom.xml#L31
android-archetypes This projects provides several Maven archetypes for Android. Those archetypes allows to quickly bootstrap a Maven project to develo
#Android for Maven Eclipse Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015 Ricardo Gladwell, Hugo Josefson, Anthony Dannane, Mykola Nikishov, R
ADB Idea A plugin for Android Studio and Intellij IDEA that speeds up your day to day android development. The following commands are provided: Uninst
vim-android Develop for Android using vim. Overview There are three vim scripts that are included in this setup. Those scripts are: SuperTab GitHub Vi
Flutter-Toolkit 中文文档 A plugin for Android Studio that speeds up your day-to-day flutter development. Flutter ToolKit(Flutter Build Runner Helper), to
pluginExporlor Template ToDo list Create a new IntelliJ Platform Plugin Template project. Get familiar with the template documentation. Verify the plu
gradle-android-scala-plugin gradle-android-scala-plugin adds scala language support to official gradle android plugin. See also sample projects at htt
eventbus-intellij-plugin Plugin to navigate between events posted by EventBus. Post to onEvent and onEvent to Post Install There are two ways. Prefere
IntelliJ Idea Astor Plugin IntelliJ Idea Astor Plugin is a plugin that integrates Astor in Intellij Idea. It communicates with a local/remote program
IntelliJ Platform Plugin Template TL;DR: Click the Use this template button and
BuildPlotsPlugin PaperMC-Plugin for build contests. This is my first time using Kotlin and the first plugin I've written after a long time. It is stil
IntelliJ-based Plugin to run k6 tests locally or in the k6 Cloud from your Intel
Gradle code ownership verification plugin A gradle plugin that will verify owner
?? common-utils Common Kotlin utilities made for my personal usage, comes with SLF4J utilities, common extensions, ansi-colours, common Gradle utiliti
Methodic Super Project Get started developing faster! This superproject helps you get started building on the Methodic platform by providing a single
Gradle Play Publisher Gradle Play Publisher is Android's unofficial release automation Gradle Plugin. It can do anything from building, uploading, and
EasyDokkaPlugin Gradle Script plugin to generate documentation by Dokka documentation engine in Javadoc or other formats for Java, Kotlin, Android and
DEPRECATED This plugin is deprecated and is no longer being developed. Tools and dependencies are automatically downloaded using version 2.2.0 of the
alpha-color Description This is an android studio plugin that allows you to creates new color in hex format based on a percentage (0-100) and a base c
444 Nov 25, 2022
338 Nov 25, 2022
2k Dec 28, 2022
178 Dec 23, 2022
4 Oct 19, 2022
0 Nov 23, 2021
345 Dec 10, 2022
315 Aug 8, 2022
4 Aug 28, 2021
0 Jan 1, 2022
0 Jan 1, 2022
8 Jan 2, 2023
4 Dec 15, 2022
6 Dec 2, 2022
1 Mar 24, 2022
3.9k Dec 30, 2022
13 Oct 3, 2022
1.4k Dec 29, 2022
1 Nov 12, 2021