Currently I generate an installer for a program using NSIS on a Linux machine. The NSIS binaries have been compiled for Ubuntu, and using the .nsi script presents no difficulties. However, the resulting setup.exe file is unsigned. This results in scary warnings for our users who download the installer via most common web browsers, as well as warnings from Windows itself when run.
We'd like to avoid these warnings, and unless I'm missing something, that requires using a Windows tool to sign the generated setup.exe file. Is there a way to do this on a non-Windows machine?
Unfortunately, each installer is unique (different files are bundled depending on the customer's request, and a unique ID included) so I cannot sign the installer on a Windows machine and then upload it.
Your best choice is probably the use of: osslsigncode. Built easily for me (make sure to have the OpenSSL headers available). It may have difficulties with the kernel mode signing policy, though (embedding the parent certs up to the root) - so you may still have to resort to WINE in the end.
I had to do it a few weeks ago, without using wine. What I did was to import the pfx file to windows and then exported it with "Include all certificates in the certificate path if possible" option. then I followed the instruction on this page .
After you have all the certs (spc and pvk files) you should use the following command:
signcode -spc [spc file] -v [pvk file] -a sha1 -$ commercial -t http://timestamp.verisign.com/scripts/timstamp.dll -tr 10 [exe file to sign]
I had to install mono-dev pack:
sudo apt-get install mono-devel
Signing files for Windows uses Microsoft Authenticode signatures. There is a tool in the SDK that signs Executables and DLLs (signtool.exe). You might be able to run that using Wine.
It's also possible to sign files through Windows API calls - these functions might be implemented in Wine aswell, but I sort of doubt it because Authenticode is only used and implemented by Microsoft (as far as I know).
However this tool doesn't to very much - it basically appends the certificate and a signed timestamp at the end of the file. There might exist adaptations for Linux aswell.
Here is a link to someone who got it working using signcode.
Related
On my website I need to give users an ability to download and easily start my executable (AppImage binary) on Linux.
For Windows version it is just .exe which works after downloading and clicking:
Download file
Click on file in browser downloads panel to start it
For Linux user now needs to do following:
Download file
Open folder containing file from browser downloads panel
Right click on it to add exec permission
Click on "Allow execution of this file" checkbox
Press Ok
Click on file to start it
It is hard to explain this flow for regular user, it makes users leave away.
Is it possible to minimize it to minimal clicks as on Windows?
Any advises appreciated to achieve minimal clicks. I can compile app for any format (its on electron but I can process it before upload)
I thought about using .deb . It will limit app for Debian-based only, but main problem in same time that I did not find ability to run post installation to exec app, and I don't want ask user to enter start menu.
Executable bits are a basic UNIX security measure thus it is not really easy to work around this (for good reason). Thinking about this, for the specific case of downloaded files, Windows also applies some restrictions (special NTFS stream which tells Windows Explorer to warn about the dangers of an executable file from the Internet).
You can of course provide your application as a .tar.something archive and store executable files in there. After extraction, they will normally have the correct execution bits set.
The option with the deb-package can also solve your problem (for some users) but is a little more complicated:
User downloads deb package
User clicks on deb package and has some program installed that provides a GUI for installing packages (like gdebi). Like on Windows there will be some "security check" in form of a dialog box where the user needs to enter a (sudo) password. Afterwards, apt will install the package
If the package is created correctly, it can transport the executable bit correctly such that no explicit permission change is needed afterwards. If for some reason there is need to do something post-installation, Debian packages can provide postinst scripts which run (as root!) at the end of the package's installation.
In any case, as dealing with executable files is a common procedure on Linux, it might not scare so many users away as expected. If you want to make it comfortable for the users, provide the package as they expect/like them. On Windows I would think that to be a .msi package and on Linux I prefer a package corresponding to my distribution (.deb, .rpm).
If you want the users to update their packages regularly (good for security) then it is helpful to provide a "repository" that users can add and install your package from. Of course, "the best" is having a package as part of the distribution, but that is quite some effort and needs to pass a lot of "quality assurance gates" :)
I have a windows desktop application which is currently available on a Linux server for download on user's machine. I want to automate the process of MSI packaging on the same Linux server using any EXE/DLL.
I have an App.exe and App.txt file. Some information should be read from text file and injected into exe before creating an MSI package. This entire process has to happen dynamically in the Linux server only after the user clicks on download.
Can anybody point me in the right direction as to how i can achieve my goal? I want to achieve the same by having minimum dependencies on any additional/3rd party tool. TIA for any time and effort.
p.s - I have done some R&D about various installers but none of them were matching the criteria as they have too many dependencies.
False Positive Risk: Creating a new binary for every user would seem to be very unwise because of malware scanners and their ability to recognize "known" versions of binaries (by hash).
If you create a new binary for each user, the malware suite might suddenly start to quarantine your setup without any warning or sense. This problem is not trivial anymore as malware control is hardened everywhere and setups that run with elevated rights are "prime suspects for risk management".
Digital signatures can help, but they are merely a guarantee that you made the setup, and not a guarantee that the setup doesn't contain anything harmful. Nothing worse than signed malware vectors. In fact it is proof positive that the malware came from you :-). Note: some people even manage to tamper with signed executables. The combination of the latter two fact is very troubling.
Application Setup: I like to eliminate such features and details from the setup and make the application itself responsible for it own configuration on first launch after installation. I find this more reliable and easier to debug.
Custom Configuration: You can apply custom configuration information at runtime via various mechanisms. You should add in a transform, or you can create a batch file next to the setup with this information embedded and pass to the MSI or the setup.exe.
Batch File?: The msiexec.exe command line supports passing parameters to the MSI. You can generate a batch file that will run the setup with such parameters if you design your setup to support these "incoming" parameters.
msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" SERIALKEY="1234-1234" /qn
Transform: You can also create a transform to contain the parameters (a transform is a tiny MSI fragment with settings and changes to the original MSI):
msiexec.exe /i myinstaller.msi TRANSFORMS="mytransform.mst" /qn
A transform would be difficult to create on a Linux box, seeing as they are COM-structured storage files native to Windows only. I am not sure if it is even possible, but maybe.
Some Links:
Can the resulting command line be determined after running an .msi installer?
Change Program Name and Shortcut Title during installation
How to make better use of MSI files
We have had some success with wixl from msitools.
Also WiX will run under WINE.
However, in both cases we have not had EmbedCab="yes" work, which may or may not affect you.
I have a standalone server running Cygwin -- I did not setup this server, it was inherited. Anyway, I'd like to know what options the installing admin selected in the setup program.
I've read that I could look in /etc/setup, /etc/postinstall, or /etc/preremove but there are a lot of packages in those directories... same goes for the output of cygcheck -c.
I don't want to know every single library on the system... just how to duplicate the install. Is there a way to determine which packages were select in the GUI setup program?
Thanks!
Cygwin is pretty standalone. You should be able to archive up the entire Cygwin directory (and subdirectories) and move it to the same location on another system.
If you archive it up I recommend 7-zip. You can get it free here. The built in Windows archiver can create permission problems when an archive is extracted on a destination system. I recommend 7-zip for both archiving and unarchiving. If you use the built in Windows archiver and then move it to the new system and extract it - it will extract without errors. However you may find things don't actually work right while using some Cygwin applications
If you don't copy everything you won't move any of the original admin's custom changes.
It would appear that VS2012 uses PFX files for signing instead of SNK files. I get the impression this is related to delayed signing; but I don't care.
When I build my application, I can use "sn -tp <my assembly>" and see it is signed.
When I ilmerge the debug folder and use the /keyfile directive (the way I was successfully doing with SNK files), the DLLs merge into one unsigned DLL.
I have read articles suggesting clever workarounds, such as extracting the public key from the original DLL and then using this in the /keyfile directive...which also failed to allow me to create a strongly signed DLL.
So, what do I need to do to get ilmerge to work with the PFX file so that my assembly will be strongly typed?
Thanks
I recently was attempting to do just the same thing (this time with VS 2015, but I am sure the results are the same).
PFX files are password-protected by default and ILMerge (at the time of this writing) does not appear to support them.
Manual Signing
The "clever workaround" as you describe it is presented here, and it appears to be the only way to accomplish this:
>sn -p some.pfx some.pub
>ilmerge /keyfile:some.pub /delaysign /out:merged\some.dll some.dll
>sn -R merged\some.dll some.pfx
Note that extracting the public key from the PFX file requires user input - allegedly it was previously possible to pipe in the password, but the current version of sn.exe does not permit console redirection.
Automated (CI Build System) Signing
In order to strong sign ILMerged assemblies in an automated way, it is necessary to install they key on the local build machine. This still requires user input in the form of password input, but only has to be done once per build machine.
As before, we need to extract the public key from the PFX file (this only has to be done once, and the PUB file can be saved alongside the PFX or even checked-in to source).
Here is the one-time setup code (both require password input):
>sn -p some.pfx some.pub
>sn -i some.pfx SomeContainerName
During the automated build, it is now possible to run:
>ilmerge /keyfile:some.pub /delaysign /out:merged\some.dll some.dll
>sn -Rc merged\some.dll SomeContainerName
I've been looking for a solution to this for about a year, still haven't found one.
I'm trying to get a website snapshot script that I can host on my server and use freely that works well on 99% of webpages.
So far I've been using html2canvas but it doesn't really display images.
I looked into wkhtml2pdf before but I tried installing every single binary and executing from PHP. None of them worked!
All I know about my server is that it is Linux (so I only tested Linux static binaries). Even the basic --help command didn't work.
Please help me out. Thanks!
If you are using a hosting service, it is possible that it is impossible to execute binary programs stored in users' directories. (noexec flag on specific partition). You should first contact system administrator and ask if it is possible to put your own binary executables there. Perhaps, you can ask system administrator to install wkhtmltopdf for you in a global directory /usr/local/bin.
You'll need more then a simple shared hosting, and more then "it is Linux". PHP could be in safemod and lots and lots of other limitations. I would choose a minimal VPS (like digitalocean or similar), root access, install wkhtml2pdf with dnf, yum or what's on you Linux distro, because it brings lots of dependencies to your machine. A minimal LAMP server should not have what's needed on it. You need to be able to allow Apache (or other user) to exec the binary.