Re: Custom InputControl w/o char->string conversion
Hi Finn, I assume you are coming from a C# background and looking for a SecureString equivalent in Java. Check out this: https://github.com/OWASP/passfault/blob/master/core/src/main/java/org/owasp/passfault/impl/SecureString.java You could write your own javafx component with OWASP SecureString and achieve the same result as in C#. Hopefully this answers your question. That being said, what you said about being faster than garbage collection and again assuming you had SecureString in mind, makes me think you might not really understand the purpose of SecureString in C#. It does NOT guarantee that an attacker would not be able to see the string if they had access to the application's runtime memory. Think about it: if you can TYPE your password, there was a byte array containing your clear text password before it was put in the SecureString. And then if you can USE that password (during a database connection), there was a byte array containing your clear text password when you sent it to the driver. A simple breakpoint in the right spot and a heap dump would reveal your password, always. The reason is simple: your application does need to know the password! The purpose of SecureString is not to protect from being able to capture the password in memory or from heap dumps. The purpose is to avoid the password from leaking in log files, console output or in application messaging. By creating a separate String class extension for it, the developers made sure that inadvertently calling "toString()" (as a logger would do) would return some encrypted garbage. SecureString is a simply a Safeguard against leaking sensitive strings in logs, console output and application messaging. If you are still concerned about someone inspecting the heap and look for the short lived byte arrays containing what you typed, you can always call .fill(0) on that byte array when you're done with it to make it harder for the attacker. The OWASP class i shared with you does that in the constructor. But again, if the attacker has access to your process, all he has to do is set a breakpoint to the SecureString constructor and voila, he can read the byte buffer before its encrypted. Wiping only makes sure that the original byte array could not inadvertently be the source of a leak later (ie someone uses the byte array instead of the string)..That's the real reason why the OWASP class is wiping the array. Best regards, *Nicolas Therrien* Senior Software Developer *[image: https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]* *o*: +1.819.931.2053 On Tue, Mar 26, 2019 at 4:42 AM Finn Herpich wrote: > Hi everyone, > > I'll hope this is the right place to ask. I'm currently evaluating > multiple ways to write a cross platform application with the requirement > to be able to clear certain inputs from memory rather quickly and not > wait for the GCs mercy. > > I've tracked the JavaFx TextInputControls back to the point where the > character from the input event is transformed into a string. Which > happens roughly in com.sun.javafx.tk.quantum.GlassViewEventHandler. > > My questions results in, if it would be possible to write a custom > control (or some other way) which would leave at least no traces in the > string pool? Right now I've not enough knowledge about JavaFX internals, > but it seems like this event handling is implemented way down the rabbit > hole and it looks like a major afford to avoid the char->string conversion? > > I would be happy about any pointers where to look/start, or if a project > like this would be doomed from the start =). > > Cheers, > Finn > > -- > Alice and the Builders GmbH > Grantham-Allee 2-8, 53757 Sankt Augustin > Amtsgericht – Registergericht – Siegburg > HRB 13552, Sitz Siegburg > Geschäftsführer: Michael Sczepanski, Martin Hensel, Finn Herpich > >
Re: Distributing JavaFX 11 Application
Hi!
Thanks Sverre for your response and help in this matter! I am learning more
about Jpackage. However, the need to build on each OS platform to produce
installers is a drawback from our previous Java 8 packages and I was asked
to find another solution.
The good news is that I have managed to find a way to build multi-platform
Java 11 packages on any OS platform. I wanted to share that knowledge back
with the group.
The project dependencies are set as usual:
org.openjfx
javafx-controls
11.0.2
org.openjfx
javafx-fxml
11.0.2
Then the project uses simple launch scripts like this:
windows:
start javaw -Dfile.encoding=UTF-8 --module-path modules --module
modulename/class.package.Main
linux:
java -Dfile.encoding=UTF-8 --module-path modules --module
modulename/class.package.Main
These commands expect the proper jar files to be in the directory named
"modules".
The project uses Maven's copy dependencies like this:
org.apache.maven.plugins
maven-dependency-plugin
copy-dependencies
prepare-package
copy-dependencies
${project.build.directory}/staging/modules
runtime
linux,win
copy-linux-dependencies
prepare-package
copy-dependencies
${project.build.directory}/staging-linux-specific/modules
runtime
linux
copy-windows-dependencies
prepare-package
copy-dependencies
${project.build.directory}/staging-windows-specific/modules
runtime
win
Note the classifier filters which allow windows/linux specific files to be
separated and stored in different staging areas. The OS-agnostic staging
area uses exludes, while the OS-specific areas use includes.
Finally, the assemblies are created with multiple maven assembly xml files
which merge together the common staging area with the OS-specific staging
area corresponding to the assembly.
The result is a single OS-agnostic build which will produce one artifact
per OS platform assembly. Resulting assemblies are ready to be run on their
respective OSes. It also allows building a single larger package which
includes all OSes.
I've tested it on different build agents and it works well.
Hopefully this classifier trick will help or inspire someone else :)
Cheers, and thanks again for sharing your knowledge about JPackage! I am
still looking into that as it looks promising in the future. Especially for
creating packages that include the JVM, which is by the way a limitation of
the approach I presented here. It requires the user to have Java 11
installed.
*Nicolas Therrien*
Senior Software Developer
*[image:
https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]*
*o*: +1.819.931.2053
On Wed, Feb 20, 2019 at 2:50 PM Sverre Moe wrote:
> You could use the new jpackage to create a native runtime of your
> application.
> The jpackager is now targeted for JDK 13, but can still be used to create
> a native Java 11 application.
>
> You can download an EA build of JDK 13 with jpackage
> http://jdk.java.net/jpackage/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__jdk.java.net_jpackage_=DwMFaQ=q3cDpHe1hF8lXU5EFjNM_A=P3_1pTtMQK06fFymYIWbyyzVU6nc0CcwfuZhLhexammvaiCaU0ieHeI7BWvfbbjE=mIHIDl0OJMK77Y6JKmQei_6m8TKZmtD6WMu5i-qKU4w=v_u06Y0rRkWwAbDFChmSIvZzh8ewYjt9_n8HplXNlu0=>
>
> You would need to build on each platform, Linux, Windows, Mac.
>
> You mentioned you use Maven. When Java 9 came out I had already moved over
> to Gradle, so not familiar with the maven configuration.
> Here is a Gradle task to create a Java 11 runtime using jlink with the
> Java 11 jmods
>
> task createRuntime(type: Exec) {
> dependsOn installDist
>
> inputs.dir(installDist.outputs.files.singleFile)
> outputs.dir("${buildDir}/runtime")
>
> doFirst {
> delete "${buildDir}/runtime"
> }
>
> def libDir = new File(installDist.outputs.files.singleFile, "lib").path
>
> commandLine '/usr/java/jd
Distributing JavaFX 11 Application
Hi! What is the proper way to create distributable packages of a JavaFx Application? I have a Java 11 application which I build as a module. The distribution includes a "modules" folder with all dependencies in it, and a script to launch the module. This assembly works if I build it on the same machine as I am going to be running it on. However, I realized that depending on which build agent the assembly is going to be created, the platform specific javafx dependencies may not match the target assembly. For example, if the build agent is a linux build agent, the windows and mac assembly contains linux javafx runtime. Maven will always pull the platform-specific libraries of the system it is running on. This was not a problem when JavaFx was part of the JDK since the correct runtime libraries were installed on the system already. What is the correct way to create a windows or linux package in a build platform independent way? I found an article which showed how to force maven to include all platforms as dependencies, but then I have to add dependency on each transitive library. Sounds like a lot of trouble for a simple task. How do you guys package your apps for various platforms? *Nicolas Therrien* Senior Software Developer *[image: https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]* *o*: +1.819.931.2053
