We were already doing this for bootstrap.properties-based launches, but there's
no reason to restrict it to that. If you run Getdown with an appbase and an
appdir, it can create the app dir and download the app into it.
This enables scenarios where getdown is installed to a shared location and
users that run the app install it in their private storage area (or on a
machine local file system, or who knows).
Closes#163.
- Max concurrent downloads is controlled by a config in getdown.txt:
max_concurrent_downloads. It defaults to two.
- A bunch of thread-safety problems were fixed.
- While in there, I revamped the downloader to be less crufty from years of
ad-hoc requirements accretion.
- I disabled the Channel.transferFrom based download change because it prevents
fine-grained feedback (and abort checking) from taking place, and it doesn't
handle failure cases. Maybe we'll clean it up and re-enable it in the future.
The new code is more careful about how it obtains config info, and issues
warnings when sources of info conflict. It does not abort in such circumstances
as Getdown's prime directive is to do the best it can to get the app updated
and launched. But the warnings will hopefully allow accidental conflicts to be
detected and avoided before being deployed to customers.
We also now allow bootstrap.properties to provide an appid; that matches what
was possible via system properties and command line arguments. We also avoid
"communicating" environment configuration through the Java system properties
mechanism. We now read from sysprops but do not write back to them.
Lastly, this includes some name tidying (like appdir -> appDir and
getAppdir -> getAppDir).
Apologies for messing with code after the fact, but some OOPisms are just too
much for me to stomach. This should just be a function of two arguments. No
objects required.
Yes, we're now reparsing the whitelist on every call, but this function is
called only a handful of times.
When a constructor calls an overridable function, it may allow an attacker to access the "this" reference prior to the object being fully initialized, which can in turn lead to a vulnerability.
Application -> getLocalPath
ProxyPanel -> get
AbortPanel -> get
RotatingBackgrounds -> makeEmpty
(Triggered by internal security audit and Fortify analysis.)
Allows users to build customized Getdown JARs which can only talk to whitelisted hosts. This can be useful for very security-conscious organizations which want to distribute Getdown internally as a standard application bootstrapping mechanism, but want to ensure that it can only be used for internal applications.
This is an adaptation of the whitelist proof-of-concept discussed on the mailing list, adjusted to use the new Build class.
(Triggered by internal security audit and Fortify analysis.)
Because we are running cmd.exe here, it is possible to use a malicious URL to execute arbitrary commands on the shell ( e.g. if url=http://my-patch-notes.com/" & del C:\ )
(Triggered by internal security audit and Fortify analysis.)
These types of denial of service issues are more common in web applications, but even here an attacker could tie up system resources indefinitely by specifying a very large start delay.
(Triggered by internal security audit and Fortify analysis.)
We can just keep Color in its ARGB format and have a single static brightness()
helper. Reactangle grew a union method which allows us to avoid AWT's Rectangle
entirely.
stringsToList() needed to return null for null array input, and I went ahead
and used Arrays.asList while I was in there because we know the provenance of
the input array, no one will mutate it.
This commit makes the UpdateInterface class immutable. The Config -> UpdateInterface initialization is moved to the UpdateInterface constructor. Default values for the fields are moved to the constructor as well. Instances of String[] are changed to List<String> and made immutable. Instances of java.awt.Rectangle (which is mutable) are replaced with a new immutable com.threerings.getdown.util.Rectangle class.
Although java.awt.Color is (sort of) immutable, it was also removed and replaced with a new immutable com.threerings.getdown.util.Color class, since it was the last dependency from the getdown core module to anything in the java.awt package, which means that when we migrate to Java 9+ the core module should no longer require a dependency on the java.desktop module.
The assertions and expected values in ColorTest have been verified against the corresponding java.awt.Color values.
(Triggered by internal security audit and Fortify analysis.)
It wasn't actually providing any value. Neither tools nor core have any special
dependencies. The code in tools operates on the same files, formats and data
structures that core/runtime code operates on. It is simpler to have them in
the same module.
I've long wanted to do this, but the launcher's use of all the samskivert UI
stuff made it onerous. Now that the launcher is a separate module, we can
remove the samskivert dependency in core (and tools), which simplifies things
and makes it easier to depend on core in a (future) self-updating app (when we
add support for that).
I don't want to pollute the com.threerings top-level namespace with a bunch of
getdown-foo artifacts, and grouping everything under the top-level project
name, even when that name is repeated for all the artifacts is fairly standard
practice.
- core: the main Getdown logic code
- tools: code to create digest.txt & patch files
- launcher: the standalone launcher/updater app
- ant: the Ant task for creating digest.txt files
This paves the way for a proper Jigsaw-ification of the Getdown code.
I may further factor code out of getdown-launcher and into getdown-core to
enable the use-case where an app embeds Getdown completely and does not use the
launcher app/UI. That will also make it easier to create a JavaFX UI and retire
the old Swing UI.
This also moves the obsolete applet code into a separate applet module, which
is merely a temporary holding area. It will be deleted in the next commit.
Michael Bayne