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
Related
The id_rsa.pub file is basically some encrypted text in the .ssh folder under the home folder in Linux and is used for public-key cryptography. It uses the .pub file format. But why does this file format also happen to be the file extension for Microsoft Publisher? Microsoft Publisher isn't involved with this kind of encryption in any way, so why does id_rsa.pub also use .pub? Also, how do computer program distinguish between these uses?
Nobody enforces file extension choices.
The file extension .pub was selected for a public key because it is short for public.
The file extension .pub was selected for a Microsoft Publisher document because it is short for Publisher.
That they conflict is unfortunate.
There is no central registry for file extensions, so many extensions are re-used by different applications.
A better system for figuring out 'what type is this file' is probably not an extension, but a mime-type. But because there's no standard way for a file to say 'I am this mimetype' and that information to be carried along with the file, systems end up using extensions for this and sometimes there's a collision.
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.
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.
I would like to start checking that the open source projects that I am using in my apps are what the developers released. I noticed that many projects have a SHA1 and MD5 digests presumably these can be easily tampered with for example if a hacker replaces the orginial zip file on a mirror they can also replace the .md5 and .sha1.
How can I check the integrity of third party open source libraries that I depend on?
I think , there is No trusted way for this, since the hacker may change the source files and its (md5 or sh1) files. He simply may replace the whole project with another one.
so , download the source from trusted sites such as sourceforg and code.google.com and codeproject and mirrors recommended by these sites.
typically an open source project, although open to all to download and modify themselves, the ability to actually change the uploaded files is restricted to certain individuals governed by the project owner.
A good example is https://github.com/thecodemine/formwizard, where you can see a read-only link, but cannot modify directly unless authorised.
However you can fork the project to your own account and modify as you wish, for example https://github.com/AlexKey/formwizard
I'm also guessig on large open source projects like linux distributions for example, even code / files uploaded by authorised individuals will also go through stringent reviews before official release.
A hacker of course on comprosising a system could change files at will, but this isn't a weakness of an opensource model but instead could be a problem for any project.
Also things like Code signing help detect unauthorised modification.
http://en.wikipedia.org/wiki/Code_signing
Code signing is the process of digitally signing executables and
scripts to confirm the software author and guarantee that the code has
not been altered or corrupted since it was signed by use of a
cryptographic hash.
You have not Googled your question. If you do so you'll get a lot of content about it. The link below will teach you how to check the integrity of a downloaded file.
https://help.ubuntu.com/community/HowToMD5SUM
You may also check the following link, which shows that it is very difficult to modify or replace the .md5 and .sh1 files.
Here's the link.
The majority of our C# projects configuration is kept in *.ini files. Mainly these files hold
many sections affecting all aspects of programs behaviour. But besides of regular configuration data some of sections are vulnerable like db connection string or server password. We try to keep this sections in following forms:
[Database]
user=testuser
database=testdb
password=
But when developer is testing application he must fill the config in order to start application. It is quite common that some of the passwords are commited into version control.
Because these files are indispensable for application they cannot be included in .svnignore.
Probably what I'm looking for is some kind of script (maybe in powershell). That would scan all *.ini files and erase all passwords. The most interesting solution would be adding some external password storage that can be used both to encode and decode passwords in *.ini files.
I always push to store configuration template files in subversion, but not actual configuration files. So if the configuration file is "config.ini" then I'll check in a "config.ini.template" populated with non-working sample data.
Then to prevent multiple developers from checking in their individual "config.ini" files, I'll add the actual configation file name to the svn:ignore properties list.
This forces the developer to copy the file and modify it appropriately for their environment, but eases the work of that task by not forcing them to find out which fields need to be present. If you have the time, you can even embed comments into the template file to simplify the meanings of some of the configuration options.
At the top of the file, include the directions of how to configure the system using the template, which should read something like:
# *** CONFIGURATION TEMPLATE --- DO NOT MODIFY THIS FILE ***
# 1. Make a copy of this file in the same directory with the command "copy config.ini.template config.ini"
# 2. Edit the new copy and follow the rest of the instructions
#
# Change "this.system.hostname" to the hostname of this system
Hostname = this.system.hostname
# Set the answer "23" to "42"
Answer = 23
You get the idea....
If you have problems (or think you might have problems) with people checking in their configuration options over the config.ini.template file, then I'd recommend using "svn lock" on the template file. However, with the appropriate warning, I've never found it necessary.
I'll not answer your question and instead recommend a different approach, assuming it's not too late to change the relevant design.
You should not store passwords in the same files as the rest. Have the application read a dedicated password file (or retrieve the password from a password storage service) in addition to the regular configuration file. This is not just about not storing passwords in svn, but also about not having passwords exposed to shoulder surfing, accidentally mailed or posted when someone asks for help with a non-working configuration, etc.