currently bundled jvm is extracted to hardcoded "java_vm" subdirectory making it impossible to use getdown in conjunction with packr. pr adds custom "java_local_dir" config arg that denotes any location relative to the app dir

upd: verified with packr, it works

Some applications require a system environment variable to be passed in as a command line argument. Since these are specific to the client launching the app, they can't be pre-configured in the getdown.txt.

It seems to not break functionality; only irritating / wrong metadata TL;DR

The Resource.computeDigest() Line 241 ignores the META-INF. This might work well for most users, but i encountered an issue while working with my project:

Have a Maven project, distributing sometimes some snapshot jars (for testers). In gui, i display the JAR manifest impl version, to get a clue what is deployed in what version.

When i now release that jar, so that ONLY the metadata changes (but not a class file; compared to last snapshot update), the digest is the same, and never downloaded/updated the release version! (still displaying snapshot in gui) (Would be the same, if you always release unchanged jars, to have them all on same version)

What is/was the need for skipping the meta-inf? How could i change that w/o breaking live instances (aka GD self update)? It gives me a slightly bad feeling, that not the jar i deploy is downloaded and checked 1:1...

Hi,

Last version of getdown allows to launch a 'jar' application with the "manifest" keyword. (class = manifest) However the wiki states that it is not possible to use the flag "-Ddirect=true" with this option.

Launching the app in the same jvm than getdown would be interesting to directly get the application's output in the same console used to launch the update of the said app.(instead of tailing the log file)

Do you think this would be easy to achieve ?

Thx

The System.out prints are getting swallowed by the getdown app. I can see that my application is launching successfully and writing a test file to the filesystem but can't see any stdout in either the launcher.log or in the console I launch the app from. I guess it's something to do with log4j config?

Hello,

We noticed that over time obsolete resources accumulate in Getdown folder. This PR allows to define optional list of Glob patterns in Getdown.txt, like:

cleanup_pattern = lib\*.jar
cleanup_pattern = rsrcs\*.jpg
cleanup_pattern = old_*.png

Glob patterns are defined relative to 'getdown' folder.
In this case Getdown would collect list for files from the patterns, that is cross-check against resources specified in Getdown.txt. Then only the files that are not in getdown resource list, will be removed.

Potentially closes #183

I just changed our application delivery so that getdown is responsible to install the application and keep it up-to-date. Now, I have the following situation:

1. I run the application via getdown. It opens and everything is fine.
2. While the application is running, I open another instance of the application. getdown is now running an update because I changed a jar file (by intention).
3. Back in the previously opened application I issue a command that results in a ClassNotFoundException.

As far as I know this is the expected result if a jar file is being replaced while an application is running. What can be done in order to prevent such situations? I'm on Windows 8.1 if that helps.

I'm still new to getdown, so bear with me if that's a configuration issue or this question has already been asked.

Regards, -- Thomas

Is it possible to show the GUI, but not launch the application? In a worst-case scenario I guess I can import getdown.jar into my classpath, and extend the StatusPanel to create my own GUI, but that sounds like a lot of work ...

@samskivert, hi. found small issue in logger. w/o fix:

...
2019/05/05 20:24:49:266 INFO Application requires update.
2019/05/05 20:29:53:149 WARNING Download failed [rsrc=patch201904141803.dat, java.io.FileNotFoundException: http://app/files/201905051855/patch201904141803.dat=<toString() failure: java.lang.ArrayIndexOutOfBoundsException: 3>]
java.io.FileNotFoundException: http://app/files/201905051855/patch201904141803.dat
...

wrote a test which initially failed:

Expected :Download failed [rsrc=Resource]
Actual   :Download failed [rsrc=Resource, java.io.FileNotFoundException: patch.dat=<toString() failure: java.lang.ArrayIndexOutOfBoundsException: 3>]

i got a question though. why not change Log.format method to accept Map<String, Object> instead of Object[]? Map is verbose to write of course but better reflects method requirements and less error-prone.

Hi there,

we added support for Proxy Authentification to getdown. We mainly changed 3 things:

1. We are using the java.net.Proxy class for proxy settings in the URLConnections. This is because if you set it only as SystemProperty, it seems java uses a fallback if the proxy is not reachable and tries to connect without proxy. Which we think is not desirable.
2. We changed the Proxy dialog to include 2 fields with username and password and a checkbox field to activate the 2 input fields. Also we changed some minor locales in the dialog.
3. Since it is not very secure to set the credentials as SystemProperty to pass trough to the main application that gets started, we included a Service Provider Interface. One method for saving the credentials and one for loading the credentials. With this way everyone who uses getdown can implement there own secure way of passing the credentials to the application that gets started. If no SPI is implemented, the credentials will only be set in getdown.

Greetings ThomasG

Hi,

we need a as simple as possible bootstrap solution for our application. Therefor deploying a getdown-launcher.jar including a getdown.txt is a step to much for us and we don't have the possibility to deploy the first getdown-launcher.jar and txt otherwise.

I developed a simple solution to include a "bootstrap.properties" file in the getdown-launcher.jar so getdown will fetch the first getdown.txt in a (server-side) configurable appdir. There is an optional variable in the appdir property to reference the user home directory on the client.

I tried to be as less invasive as possible. Please feel free to comment and correct style and location. I hope there is a chance to merge this request somehow.

Volker

I have a cleanup pattern defined like

cleanup_pattern = *.jar

since I have no special lib folder. This does not seem to work. Since I have no logging feedback, which pathes where to be cleaned it is difficult to find the error. So first could you introduce some more logging for this clean up process.

Is there a problem using this *.jar in the "root" getdown folder?

By the way which files should be cleaned? Only those with a corresponding jarv file? Or is not yet included in your actual 1.8.7 version?

Specifying eg. in getdown.txt - java_location = [mac os x-aarch64]binary/javavm-mac-arm-23.1-SNAPSHOT.zip doesn't work. I would like Getdown to use the custom arm based java vm if running on an arm based Mac. Is this possible?

Security Vulnerability Fix

This pull request fixes a Temporary File Information Disclosure Vulnerability, which existed in this project.

Preamble

The system temporary directory is shared between all users on most unix-like systems (not MacOS, or Windows). Thus, code interacting with the system temporary directory must be careful about file interactions in this directory, and must ensure that the correct file posix permissions are set.

This PR was generated because a call to File.createTempFile(..) was detected in this repository in a way that makes this project vulnerable to local information disclosure. With the default uname configuration, File.createTempFile(..) creates a file with the permissions -rw-r--r--. This means that any other user on the system can read the contents of this file.

Impact

Information in this file is visible to other local users, allowing a malicious actor co-resident on the same machine to view potentially sensitive files.

Other Examples

• CVE-2020-15250 - junit-team/junit
• CVE-2021-21364 - swagger-api/swagger-codegen
• CVE-2022-24823 - netty/netty
• CVE-2022-24823 - netty/netty

The Fix

The fix has been to convert the logic above to use the following API that was introduced in Java 1.7.

File tmpDir = Files.createTempFile("temp dir").toFile();

The API both creates the file securely, ie. with a random, non-conflicting name, with file permissions that only allow the currently executing user to read or write the contents of this file. By default, Files.createTempFile("temp dir") will create a file with the permissions -rw-------, which only allows the user that created the file to view/write the file contents.

:arrow_right: Vulnerability Disclosure :arrow_left:

: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!

1. Is the vulnerable code only in tests or example code? No disclosure required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability disclosure is probably required!

Vulnerability Disclosure How-To

You have a few options options to perform vulnerability disclosure. However, I'd like to suggest the following 2 options:

1. Request a CVE number from GitHub by creating a repository-level GitHub Security Advisory. This has the advantage that, if you provide sufficient information, GitHub will automatically generate Dependabot alerts for your downstream consumers, resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be reached at the Snyk's Disclosure Email.

Detecting this and Future Vulnerabilities

This vulnerability was automatically detected by GitHub's CodeQL using this CodeQL Query.

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.

Source

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: SecureTempFileCreation

Opting-Out

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.

CLA Requirements

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).

- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

Sponsorship & Support

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.

Tracking

All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/security-research/issues/18

Security Vulnerability Fix

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.

Preamble

Impact

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.

Why?

The best description of Zip-Slip can be found in the white paper published by Snyk: Zip Slip Vulnerability

But I had a guard in place, why wasn't it sufficient?

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.

The Fix

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())

Other Examples

• CVE-2018-1002201 - zeroturnaround/zt-zip
• CVE-2018-1002202 - srikanth-lingala/zip4j
• CVE-2018-8009 - apache/hadoop

:arrow_right: Vulnerability Disclosure :arrow_left:

: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!

1. Is the vulnerable code only in tests or example code? No disclosure required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability disclosure is probably required!

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.

Vulnerability Disclosure How-To

You have a few options options to perform vulnerability disclosure. However, I'd like to suggest the following 2 options:

1. Request a CVE number from GitHub by creating a repository-level GitHub Security Advisory. This has the advantage that, if you provide sufficient information, GitHub will automatically generate Dependabot alerts for your downstream consumers, resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be reached at the Snyk's Disclosure Email. Note: Please include JLLeitschuh Disclosure in the subject of your email so it is not missed.

Detecting this and Future Vulnerabilities

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.

Source

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

Why didn't you disclose privately (ie. coordinated disclosure)?

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

Opting Out

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.

CLA Requirements

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).

- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

Sponsorship & Support

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.

Tracking

All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/security-research/issues/16

I'm trying to use the JavaFX toolkit inside of my application. I'm running using OpenJDK 11.0.15 and running on Windows 10 64-bit. Using the latest 1.8.7 version of Getdown.

I have added the following options to my getdown.txt file:

# ---------------------------------------------------------------
# Parameters passed to the JVM
# ---------------------------------------------------------------

jvmarg = -Xms256M
jvmarg = -Xmx1024M
jvmarg = -Djava.library.path=%APPDIR%/lib/native
jvmarg = -Datms.log.type=log4j
jvmarg = -DLOG=logs
jvmarg = -Datms.log.dir=logs
jvmarg = -Datms.log.filename=desktopDecoder.log
jvmarg = -DrootWebUrl=http://10.1.249.13/inet/desktopdecoder
jvmarg = --module-path %APPDIR%/javafx-sdk-11.0.2/lib
jvmarg = --add-modules javafx.controls,javafx.fxml,javafx.web,javafx.media,javafx.swing

However, when I compile and run the application I get a popup saying that the JVM can't be started (Error: Could not create the Java Virtual Machine) and the following error in the launcher.log file:

Unrecognized option: --module-path C:\path\to\./javafx-sdk-11.0.2/lib

Strangely enough, I tried taking the complete command line from the launcher.log file and ran it in a separate command prompt and had no issues starting the application using that approach. I tried single and double quoting the --module-path and --add-modules options but nothing worked.

Thanks, Dave

Is there a way of generating the digest.txt file if you project is not using a built tool such as maven or ant. it seems the documentation only talks of getting it done with build tools