Remote Secure Installer: Difference between revisions

From NSIS Wiki
Jump to navigationJump to search
(Created page with 'This is an automatic, remote installer. It downloads packages from some locations, verifies and install them. Readme: Remote installer components: ---------------------------…')
 
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This is an automatic, remote installer. It downloads packages from some locations, verifies and install them.  
This is an automatic, remote installer. It downloads packages from some locations, verifies and installs them.  


The source code is here:
*<attach>Auto remote installer.zip</attach>
*http://forums.winamp.com/showthread.php?s=&threadid=308388
=Readme=


Readme:
==Remote installer components==


Remote installer components:
*installer: installs the two components in their place.
----------------------------
*updater: when started, checks urls as given in the updater.ini file.
 
*checker: runs in the background, periodically starts updater as a background process.
installer: installs the two components in their place
checker: runs in the background, periodically starts updater as a background process
updater: when started, checks urls as given in the updater.ini file


What it does:
What it does:
1. updater has a configuration file installer.ini which lives in the same directory
#updater has a configuration file installer.ini which lives in the same directory
- it holds section "Download locations"
#*it holds section "Download locations"
- there up to 50 url links (http, ftp (not tested) and file:///)
#*there up to 50 url links (http, ftp (not tested) and file:///)
- file:/// can be relative or absolute path
#*file:/// can be relative or absolute path
- e.g. file:///components.txt.asc
#*e.g. file:///components.txt.asc
 
#updater consults installer.ini
2. updater consults installer.ini
#*downloads the "manifest" from the first valid url into a temporary location
- downloads the "manifest" from the first valid url into a temporary location
#*it should be signed with a private key of a TRUSTED_SIGNATORY (see source)
- it should be signed with a private key of a TRUSTED_SIGNATORY (see source)
#*the downloaded file is verified, if the signature is not recognized, downloader tries next url(s)
- the downloaded file is verified, if the signature is not recognized, downloader tries next url(s)
#*if no valid manifest is downloaded, program aborts
- if no valid manifest is downloaded, program aborts
#the downloaded manifest contains "changesets" in the ini structure
#*name of the section is the name of the feature
#*eg. [001 - Silent changes]
#*it is a good idea to put numbers, sections are sorted alphabetically
#*each section should contain: url, md5, args, onfailure keys
#**url: where to download the new/changed feature
#**md5: checksum of the downloaded file
#**args: instructions how to execute the downloaded file, in case of 7z, it is a directory where it will be unpacked
#*onfailure: continue|stop|retry
#updater first sorts sections alphabetically and starts from the first
#*if already installed (it will be skipped)
#**records of the installed features are kept in a separate ini: updated.ini
#*if not installed:
#**url is downloaded into temporary location
#**downloaded file is checked against the md5 checksum
#**if the file has .gpg suffix, it is decrypted
#**e.g. "program.exe.gpg" will become "program.exe"
#**decryption uses gpg and a private key of the program
#**package should be encrypted for ID of the installer
#**installer also checks if the file was encrypted by TRUSTED_SIGNATORY
#**"args" are expanded (ie. args=%(DOWNLOADED_FILE)s /S becomes "some_path\ns6984.exe /S")
#**file is in a temporary location is executed (based on the suffix)
#**exe files: run using ExecTimeout
#**7z files: output dir is set to the path in "args" and run Extract
#**more actions could be added later
#**if everything goes fine, package name is added into the updated.ini
#**ID = date (eg. 001 - Silent changes=07.07.2009 22:41:28)
#*if anything went wrong:
#**package installation is ended
#**no records is written in the updated.ini
#**based on the onfailure value, installation stops or continuew with a next package
#**it is up to you to solve the failure states


3. the downloaded manifest contains "changesets" in the ini structure
==How to make a distribution==
- name of the section is the name of the feature
- eg. [001 - Silent changes]
- it is a good idea to put numbers, sections are sorted alphabetically
- each section should contain: url, md5, args, onfailure keys
- url: where to download the new/changed feature
- md5: checksum of the downloaded file
- args: instructions how to execute the downloaded file, in case of 7z, it is a directory where it will be unpacked
- onfailure: continue|stop|retry
4. updater first sorts sections alphabetically and starts from the first
- if already installed (it will be skipped)
- records of the installed features are kept in a separate ini: updated.ini
- if not installed:
- url is downloaded into temporary location
- downloaded file is checked against the md5 checksum
- if the file has .gpg suffix, it is decrypted
- e.g. "program.exe.gpg" will become "program.exe"
- decryption uses gpg and a private key of the program
- package should be encrypted for ID of the installer
- installer also checks if the file was encrypted by TRUSTED_SIGNATORY
- "args" are expanded (ie. args=%(DOWNLOADED_FILE)s /S becomes "some_path\ns6984.exe /S")
- file is in a temporary location is executed (based on the suffix)
- exe files: run using ExecTimeout
- 7z files: output dir is set to the path in "args" and run Extract
- more actions could be added later
- if everything goes fine, package name is added into the updated.ini
- ID = date (eg. 001 - Silent changes=07.07.2009 22:41:28)
- if anything went wrong:
- package installation is ended
- no records is written in the updated.ini
- based on the onfailure value, installation stops or continuew with a next package
- it is up to you to solve the failure states


#prepare a manifest:
#*e.g. .\tests\components.0.01.txt
#sign the manifest with gpg
#*e.g. .\gpg\gpg.exe --homedir .\gpg_local_side --clearsign .\tests\components.0.01.txt
#check the updater.ini file
#*it must contain valid future URL locations of the manifest
#check the installer.ini file
#*it must have a valid args in the section [Checker]
#*this tells installer what to put in the Run section of the registry
#*and also how to start checker after the installation
#compile the scripts, in this order:
##checker.nsi --> semanchk.exe
##updater.nsi --> updater.win32.0.01.exe
##installer.nsi --> installer.win32.0.01.exe


How to make a distribution:
---------------------------


1. prepare a manifest:
==To encrypt a file==
- e.g. .\tests\components.0.01.txt
2. sign the manifest with gpg
- e.g. .\gpg\gpg.exe --homedir .\gpg_local_side --clearsign .\tests\components.0.01.txt
3. check the updater.ini file
- it must contain valid future URL locations of the manifest
4. check the installer.ini file
- it must have a valid args in the section [Checker]
- this tells installer what to put in the Run section of the registry
- and also how to start checker after the installation
5. compile the scripts, in this order:
a) checker.nsi --> semanchk.exe
b) updater.nsi --> updater.win32.0.01.exe
c) installer.nsi --> installer.win32.0.01.exe


*you have to encrypt and sign it
*the SIGNATORY must be known to the updater
*see updater.nsi, search for TRUSTED_SIGNATORY
*the file must be addressed to the updater
*you must have the public key of the recipient in the keyring


To encrypt a file:
===example===
------------------
.\gpg\gpg.exe --homedir .\gpg_local_side -r "John the Recipient" -se .\tests\program.exe
- you have to encrypt and sign it
- the SIGNATORY must be known to the updater
- see updater.nsi, search for TRUSTED_SIGNATORY
- the file must be addressed to the updater
- you must have the public key of the recipient in the keyring


example:
[[Category:Real World Installers]]
.\gpg\gpg.exe --homedir .\gpg_local_side -r "John the Recipient" -se .\tests\program.exe

Latest revision as of 09:21, 11 March 2010

This is an automatic, remote installer. It downloads packages from some locations, verifies and installs them.

The source code is here:

Readme

Remote installer components

  • installer: installs the two components in their place.
  • updater: when started, checks urls as given in the updater.ini file.
  • checker: runs in the background, periodically starts updater as a background process.

What it does:

  1. updater has a configuration file installer.ini which lives in the same directory
    • it holds section "Download locations"
    • there up to 50 url links (http, ftp (not tested) and file:///)
    • file:/// can be relative or absolute path
    • e.g. file:///components.txt.asc
  2. updater consults installer.ini
    • downloads the "manifest" from the first valid url into a temporary location
    • it should be signed with a private key of a TRUSTED_SIGNATORY (see source)
    • the downloaded file is verified, if the signature is not recognized, downloader tries next url(s)
    • if no valid manifest is downloaded, program aborts
  3. the downloaded manifest contains "changesets" in the ini structure
    • name of the section is the name of the feature
    • eg. [001 - Silent changes]
    • it is a good idea to put numbers, sections are sorted alphabetically
    • each section should contain: url, md5, args, onfailure keys
      • url: where to download the new/changed feature
      • md5: checksum of the downloaded file
      • args: instructions how to execute the downloaded file, in case of 7z, it is a directory where it will be unpacked
    • onfailure: continue|stop|retry
  4. updater first sorts sections alphabetically and starts from the first
    • if already installed (it will be skipped)
      • records of the installed features are kept in a separate ini: updated.ini
    • if not installed:
      • url is downloaded into temporary location
      • downloaded file is checked against the md5 checksum
      • if the file has .gpg suffix, it is decrypted
      • e.g. "program.exe.gpg" will become "program.exe"
      • decryption uses gpg and a private key of the program
      • package should be encrypted for ID of the installer
      • installer also checks if the file was encrypted by TRUSTED_SIGNATORY
      • "args" are expanded (ie. args=%(DOWNLOADED_FILE)s /S becomes "some_path\ns6984.exe /S")
      • file is in a temporary location is executed (based on the suffix)
      • exe files: run using ExecTimeout
      • 7z files: output dir is set to the path in "args" and run Extract
      • more actions could be added later
      • if everything goes fine, package name is added into the updated.ini
      • ID = date (eg. 001 - Silent changes=07.07.2009 22:41:28)
    • if anything went wrong:
      • package installation is ended
      • no records is written in the updated.ini
      • based on the onfailure value, installation stops or continuew with a next package
      • it is up to you to solve the failure states

How to make a distribution

  1. prepare a manifest:
    • e.g. .\tests\components.0.01.txt
  2. sign the manifest with gpg
    • e.g. .\gpg\gpg.exe --homedir .\gpg_local_side --clearsign .\tests\components.0.01.txt
  3. check the updater.ini file
    • it must contain valid future URL locations of the manifest
  4. check the installer.ini file
    • it must have a valid args in the section [Checker]
    • this tells installer what to put in the Run section of the registry
    • and also how to start checker after the installation
  5. compile the scripts, in this order:
    1. checker.nsi --> semanchk.exe
    2. updater.nsi --> updater.win32.0.01.exe
    3. installer.nsi --> installer.win32.0.01.exe


To encrypt a file

  • you have to encrypt and sign it
  • the SIGNATORY must be known to the updater
  • see updater.nsi, search for TRUSTED_SIGNATORY
  • the file must be addressed to the updater
  • you must have the public key of the recipient in the keyring

example

.\gpg\gpg.exe --homedir .\gpg_local_side -r "John the Recipient" -se .\tests\program.exe