There is a list of jar files, that I want to know if they are digitally signed, they are on a windows machine.
I tried to right click on one of the jars, but couldn't see anything related to digital signature, is there a way from windows to detect if file is signed or not?
Regards,
If you have a JDK installed, you can run jarsigner -verify from CMD or PS prompt, which will check the signature if it is present or tell you if it is absent, or just run jar tf file.jar META-INF and look for filenames like $signer.SF; for a multiversion jar with lots of clutter in META-INF, either search positively for .SF files with a tool like findstr (or -match in PS) or negatively exclude all versions/ files.
If you mean with only Windows, a jar file is really a zip file with certain restrictions, and Explorer (since Vista IIRC) understands zip files. Change the extension from .jar to .zip, then 'open' the file as a folder and look in META-INF for $signer.SF file(s). But this is a manual process so you can't really drive it from a list in a file, if that's what you mean.
Related
Please note: I have created this GitHub project right here that can be used to perfectly reproduce the problem I'm seeing.
Java 8 here attempting to use Launch4J via the gradle-launch4j Gradle plugin to build a Windows native EXE application. I am doing the development of a Java Swing app on my Mac but the app must run as a Windows EXE on Windows 10. I am also using ShadowJar to build my self-contained "fat jar".
I can build my (Swing) app's fat jar and then run it on my Mac via java -jar build/lib/myapp.jar. It starts and runs no problem.
Here is my Gradle config for Launch4J:
launch4j {
mainClassName = 'com.example.windows.hello.HelloWindowsApp'
icon = "${projectDir}/icon.ico"
jdkPreference = 'jdkOnly'
initialHeapSize = 128
jreMinVersion = '1.8.0'
jreMaxVersion = '1.8.9'
maxHeapSize = 512
stayAlive = false
bundledJre64Bit = true
bundledJrePath = '../hello-windows/jre8'
}
When I run ./gradle clean build shadowJar createExe createDistro it produces:
hello-windows.zip/
hello-windows.exe --> The Windows EXE built by the 'createExe' task
lib/* --> The lib/ dir for the EXE that is also built by the `createExe` task
jre8/ --> OpenJDK JRE8 (copied from the libs/jre8 dir)
So I copy that ZIP file and port it over to a Windows 10 (64-bit) machine. I extract the ZIP and run the EXE by double clicking it inside Windows Explorer (which I can confirm does see the EXE as an Application type). First I see this:
Why is this happening? Are there any Launch4J configurations/settings I can change so that this doesn't happen?
Thanks in advance!
You need to sign the executable created by launch4j as described here to prevent SmartScreen from blocking it to be run. See also the related discussion in the support forum.
Your first question is more like a Windows question. When you unzip an application from a zip file, Windows will naturally mark it as unsafe, in fact if you check the application properties tab, you will see a checkbox where you can remove that unsafe attribute. It's same as running chmod+x for an executable script in Linux.
For the second part, I assume you are using the gradle plugin for Launch4j, there are two main ways to configure Launch4j assuming your project folder is structured commonly with the jre library in the same folder containing your executable folder.
By specifying the path only like
../jre
By specifying the full relative path
../jre/bin/javaw.exe
Your generated xml at the end should look like this in the first case.
<jre>
<path>../jre</path>
</jre>
The main point is that the path to JRE is relative to the position of the executable not the current directory. In this case, we step back one directory from the executable folder to the folder containing jre.
Try setting the bundledJrePath in your build.gradle to just jre8:
launch4j {
...
bundledJrePath = 'jre8'
}
Because that is in your case the relative path where the jre is when extracting the zip.
http://launch4j.sourceforge.net/docs.html
<path>, <minVersion>, <maxVersion>
The <path> property is used to specify the absolute or relative path (to the executable) of a bundled JRE, it does not rely on the current directory or <chdir>. Note that this path is not checked until the actual application execution
Beware that the path must not contain the /bin/javaw.exe.
When running the exe with the debug flag like this
hello-windows.exe --l4j-debug
then it will create a file launch4j.log in the same directory.
There you can check that the correct jre is picked up, for example:
...
Bundled JRE: jre8
Check launcher: C:\Users\IEUser\Downloads\hello-windows\jre8\bin\javaw.exe (OK)
...
I upvoted the answer above from sschuberth, as that is the best answer to your question. Signing the executable will make SmartScreen happy.
As addition I would rather prevent trying to create an executable, even signing it, best to create a MSI. For example by using Javapackager. See also this question. That guy created his own tool after using Nullsoft.
It is very cumbersome to get an executable accepted by every virus scanner around the world. I have the experience of using WIX Toolset to create an MSI and wrapped it into a bootstrapper executable, signed it using the company signing certificate. However in the end I had to send requests to McAfee, Norton, Avast, AVG, KasperSky and Trend Micro. Gladly all accepted it over time, only Trend Micro never even responded.
I face a problem with an application which has folder "aux" . When I try to check out the app , svn failed on "aux" invalid folder name.
I understand this is a problem of windows with specials folders names.
Any idea how can resolve this problem .
Thanks in advance ...
AUX is simply not a valid pathname on windows. See Naming Files, Paths, and Namespaces.
Your only real option if you want to check this project out to a Windows system is to rename the directory on the SVN server.
Of course this could be easier said than done. If the directory name is part of a Java package structure for instance then that means you would have to refactor the code and rename the package(s) wherever they are used.
Also if there are other config files, etc. that reference this directory they would also need to be changed.
Unfortunately for you whoever named this directory aux was not aware it would break on Windows or perhaps never anticipated the need to check the project out on Windows.
I've set up a repository to distribute plug-ins using Npackd. I am aware, that I can use a batch script to move all files from a package wherever I want, but I'm afraid I might accidentally overwrite files. Currently, my setup works like this (which is npackd common practice, I believe):
a package myFile.zip gets downloaded
the contents gets extracted to %PROGRAMFILES%\myPackage\myFile
a batch script optionally moves the files elsewhere
Unfortunately, the Npackd documentation doesn't explain the internal process of how this is handled. My first concern is that a folder myPackage already exists and might get overwritten, consequently its files being moved by my Install.bat. Is there a way to define the destination path before the files get extracted? Since I'm installing plug-ins for an existing software, this would avoid my script moving all the files.
One way to achieve could be "abusing" the 7z examples, but if possible I'd like to a avoid the dependency since my plug-ins stored inside a standard zip archive, and Npackd can handle these without dependencies.
Npackd always creates a new directory during the installation of a package version. Normally the name of this directory is the package title (e.g. "Firefox"). If this directory already exists the version number is used as a suffix (e.g. "Firefox-27.0.1"). If this directory is also already there an underscore and a number is used additionally (e.g. "Firefox-27.0.1_2", "Firefox-27.0.1_3", etc.)
There is no way to define where a package should be installed exactly. As you would probably define a dependency on the main software package in each plugin anyway, I'd recommend something like this:
<dependency package="com.mycompany.WordProcessor" versions="[5.00.2195, 6.1)">
<variable>WP</variable>
</dependency>
<file path=".Npackd\Install.bat">copy spellcheck.dll "%WP%\plugins"</file>
I am doing what it says on the forum but can't figure out where is the problem. I downloaded the .zip and extracted it. There was 4 folders (Contrib,Docs,Plugins,Unicode) aside from Docs where do I put the rest ? From AccessControl/Plugins I put the .dll to my NSIS/Plugins folder where are the other .dll files. But the other two folders diden't contained any .nsh or .nsi file to put in NSIS/Include. Where is the problem ? I am using HM NIS Edit and when I try to compile it says Invalid Command.
I tried this code and it compiles but I dont think it does something.. or maybe I am using the wrong command. I need to give to my config folder read,write permission thats in the INSTDIR. I tried it with INSTDIR\config and INSTDIR. But nothing works at the moment. Maybe the plugin isent included.
System::Call 'AccesControl.dll::GrantOnFile (t ."$INSTDIR",t .""(S-1-5-32-545)",t ."FullAccess")'
Was going to add a comment to the above answer, but system wouldn't let me. A clarification as for NSIS 3.0+ the default folder locations didn't work. To fix it I copied the files to:
AccessControl.zip\Plugins\AccessControl.dll --> NSIS\Plugins\x86-ansi
AccessControl.zip\Unicode\Plugins\AccessControl.dll --> NSIS\Plugins\x86-unicode
You can unzip the plugin zip at the root of the NSIS directory, or at least, you need to put the plugin dll into the NSIS plugins directory (or to any directory you want if you include it with !addplugindir)
The core of the plugin is in the dll file in Plugins directory (the unicode/plugins contains the unicode version of the plugin suitable for the unicode flavor of NSIS 3.0+)
the Docs directory contains the plugin documentation
the Contrib directory contains the plugin source code useful if you want to modify the plugin and rebuild it. It is not needed in normal nsis usage.
The correct way to call an nsis plugin is not via the system plugin: you need to call directly the plugin methods from the nsis script, as illustrated in the plugin page :
# Make the directory "$INSTDIR\database" read write accessible by all users
AccessControl::GrantOnFile "$INSTDIR\database" "(BU)" "GenericRead + GenericWrite"
or from some code of mine
AccessControl::GrantOnFile `${somePath}` `(S-1-5-32-545)` `${someAccess}` ;(S-1-5-32-545) is local users GUID
Launch4j seems to simple to setup but after the exe has been generated it wouldn't run from another location.
The jar file used to create the launcher still needs to be in the same folder as the exe is.
I thought it would have wrapped the jar in exe and could run it from anywhere? I have done this with JSmooth before and it worked well. But JSmooth isn't supported on Windows 7 anymore.
Also could not find any proper documentation for it.
What is going wrong here.
Thanks,
Shankar.
Your simple scenario works for me. The only options I needed to fill in were Output file, Jar and Min JRE version. Everything else is left as default.
It's important to have all your external libraries packed into the JAR and not into a folder next to the generated JAR. To achieve that, select "Extract required libraries into generated JAR" option in Eclipse when exporting runnable JAR.
If we are talking about the JAR containing the main class, then this is configurable: http://launch4j.sourceforge.net/docs.html#Configuration_file
What you want to set is dontWrapJar to true, but this is the default value so you had to change something if it's not in the EXE. When toggling this boolean, one can clearly see the size difference (e.g. in my case it's 40K without JAR and 56 with 16K JAR included, also in Total Commander I can use Ctrl+PgDn to enter the EXE as any other ZIP if it has JAR included).
In POM file when using com.akathist.maven.plugins.launch4j:launch4j-maven-plugin plugin the option is named the same - dontWrapJar. In that case jar option must point to the built JAR (in target), because it is relative to EXE (and both goes to target) in most cases it's just the name of the JAR. While the JAR is lying next to the EXE, it is not necessary to run the EXE and can be removed to check it.
This does not tell anything about other dependencies for which there are other options and if you need everything in EXE than you need to use some uberjar solution.