Symbian OS Platform Security/08. Native Software Installer - Revision history

Craig: /* UID Overload */ fix cross-references

2011-01-20T13:03:57Z

‎UID Overload: fix cross-references

Craig: removed category, added copyright template

2011-01-17T11:53:53Z

removed category, added copyright template

Craig: chapter author, navigation links, formatting

2011-01-07T16:44:38Z

chapter author, navigation links, formatting

Show changes

Admin: 27 revisions: import from developer.symbian.org

2010-12-18T16:04:03Z

27 revisions: import from developer.symbian.org

Stichbury: moved Symbian OS Platform Security/8. Native Software Installer to Symbian OS Platform Security/08. Native Software Installer

2010-03-24T11:52:26Z

moved Symbian OS Platform Security/8. Native Software Installer to Symbian OS Platform Security/08. Native Software Installer

Hamishwillee: moved Chapter 8: Native Software Installer to Symbian OS Platform Security/8. Native Software Installer: move to sub page model

2010-03-21T23:40:45Z

moved Chapter 8: Native Software Installer to Symbian OS Platform Security/8. Native Software Installer: move to sub page model

Satudahl at 16:11, 18 March 2010

2010-03-18T16:11:12Z

Satudahl: /* Summary */

2010-03-18T15:54:31Z

‎Summary

Satudahl: /* Installing to and from Removable Media */

2010-03-18T15:52:21Z

‎Installing to and from Removable Media

Satudahl: /* SIS File Changes for Platform Security */

2010-03-18T15:50:26Z

‎SIS File Changes for Platform Security

@@ Line 496: / Line 496: @@
 clarifying the role of the three UIDs, which are particularly significant to
 the software installer:
-*the SID or secure ID; allocation of SIDs is discussed in Chapter 2
+*the SID or secure ID; allocation of SIDs is discussed in [[Symbian_OS_Platform_Security/03._The_Platform_Security_Environment#UID_Allocation.2C_SIDs_and_VIDs|Chapter 3]]
-*the VID or vendor ID; an additional value, which can be assigned to an EXE, also discussed in Chapter 2
+*the VID or vendor ID; an additional value, which can be assigned to an EXE, also discussed in [[Symbian_OS_Platform_Security/03._The_Platform_Security_Environment#UID_Allocation.2C_SIDs_and_VIDs|Chapter 3]]
 *the pUID or package UID; this is a value assigned to a SIS file from the specification in the package file, and is essentially the identifier of a package, or set of files, that forms an installable unit.

← Older revision		Revision as of 11:53, 17 January 2011
Line 1,117:		Line 1,117:
	*Does your SIS file specify dependencies that cannot be met at the moment? For example, does another package need to be present first?		*Does your SIS file specify dependencies that cannot be met at the moment? For example, does another package need to be present first?

−	~~[[Category:Book]]~~	+	{{SymbianOSPlatformSecurity_Copyright}}

@@ Line 1: / Line 1: @@
 =Introduction to the Native Software Installer=
@@ Line 1,124: / Line 1,126: @@
 *Are you using a developer certificate outside of the context that you agreed with your developer certificate issuer? Perhaps the certificate has expired, or you are trying to install the package on the wrong handset.
 *Does your SIS file specify dependencies that cannot be met at the moment? For example, does another package need to be present first?

@@ Line 1,103: / Line 1,103: @@
 mobile phone successfully.
-As pointed out in Section 8.1.2, the additional security tends to manifest
+As pointed out in earlier, the additional security tends to manifest
 itself as additional restrictions, so it might be useful to recap and list
 a number of the most common reasons why your new Symbian OS v9
 SIS file does not, or may not, install:
-• Are you trying to install a pre-v9 SIS file?
+*Are you trying to install a pre-v9 SIS file?
-• Are the binaries in your package suitable for the target environment?
+*Are the binaries in your package suitable for the target environment? This includes installing emulator binaries on a mobile phone.
-This includes installing emulator binaries on a mobile phone.
+*Are you using the correct versions of the tools? MakeSIS, for example, should report a version of at least ‘4,0,0,1’. Tools from earlier kits will not work correctly.
-• Are you using the correct versions of the tools? MakeSIS, for example,
+*Does your operator or manufacturer demand that all applications are signed – even if they are only self-signed? If so, you’ll need to use the tools provided to generate a key and a certificate so that you can sign your own package.
-should report a version of at least ‘4,0,0,1’. Tools from earlier kits will
+*Is there any way the SIS file could have become corrupt? If so, the checksums and digital signatures might no longer match the rest of data in the package.
-not work correctly.
+*Do your package’s EXEs and DLLs require any system capabilities (as defined by your manufacturer)? If so, you’ll need to have them appropriately signed by a signing authority.
-• Does your operator or manufacturer demand that all applications are
+*Does the certificate with which you (or your signing authority) signed your SIS file actually chain to a trust anchor in the swicertstore? (If you are developing for a handset, did you even create a swicertstore in the first place?)
-signed – even if they are only self-signed? If so, you’ll need to use the
+*Is your package already installed? This seems obvious, but can be an occasional oversight.
-tools provided to generate a key and a certificate so that you can sign
+*Is your package attempting to overwrite a file that was delivered by an earlier package? If so, you may wish to restructure your package or rename your files. Delivering private application data files to a /private/<SID> directory is probably the best idea. If your intention was to upgrade a package, ensure you’ve used the same
-your own package.
+pUID (and matched name and vendor fields) otherwise the installer may treat it as a new package.
-• Is there any way the SIS file could have become corrupt? If so, the
+*Is your package installing files which may eclipse (or be eclipsed by)
 checksums and digital signatures might no longer match the rest of
 data in the package.
-• Do your package’s EXEs and DLLs require any system capabilities
 (as defined by your manufacturer)? If so, you’ll need to have them
 appropriately signed by a signing authority.
-• Does the certificate with which you (or your signing authority) signed
 your SIS file actually chain to a trust anchor in the swicertstore? (If
 you are developing for a handset, did you even create a swicertstore
 in the first place?)
-• Is your package already installed? This seems obvious, but can be an
 occasional oversight.
-• Is your package attempting to overwrite a file that was delivered by
 an earlier package? If so, you may wish to restructure your package
 or rename your files. Delivering private application data files to
 a /private/<SID> directory is probably the best idea. If your
 intention was to upgrade a package, ensure you’ve used the same
 pUID (and matched name and vendor fields) otherwise the installer
 may treat it as a new package.
-• Is your package installing files which may eclipse (or be eclipsed by)
 a file with the same path on another drive (this includes OS files)?
 Again, you may wish to restructure your package or rename your files.
-• Are you trying to install an EXE with a SID that is already in use? This
+*Are you trying to install an EXE with a SID that is already in use? This can easily happen if your SID is in the unprotected range. You could contact your signing authority and obtain your own SID range, which can be appropriately signed for.
-can easily happen if your SID is in the unprotected range. You could
+*Have you employed a reserved range pUID or SID? If so, your package must be signed appropriately for it to be trusted. Similarly, non-zero VIDs must also be signed-for.
-contact your signing authority and obtain your own SID range, which
+*Are you using a developer certificate outside of the context that you agreed with your developer certificate issuer? Perhaps the certificate has expired, or you are trying to install the package on the wrong handset.
-can be appropriately signed for.
+*Does your SIS file specify dependencies that cannot be met at the moment? For example, does another package need to be present first?
-• Have you employed a reserved range pUID or SID? If so, your package
 must be signed appropriately for it to be trusted. Similarly, non-zero
 VIDs must also be signed-for.
-• Are you using a developer certificate outside of the context that you
 agreed with your developer certificate issuer? Perhaps the certificate
 has expired, or you are trying to install the package on the wrong
 handset.
-• Does your SIS file specify dependencies that cannot be met at the
 moment? For example, does another package need to be present first?

@@ Line 987: / Line 987: @@
 from the mobile phone.
-The Software Installer and the OS Loader
+'''The Software Installer and the OS Loader'''
 A deal has been struck between the OS loader and the software install
@@ Line 1,002: / Line 1,002: @@
 SIS-based installation.
-‘Pre-Installed’ Media
+'''‘Pre-Installed’ Media'''
 It’s useful to be able to supply media cards, containing software that can
@@ Line 1,029: / Line 1,029: @@
 and make the application eligible to be run.
-Some New Package Types
+'''Some New Package Types'''
-In Section 8.3.3, we described the package install types (SA, SP, and PU)
+Earlier, we described the package install types (SA, SP, and PU)
 which are specified in the package file. At the time, we neglected to
 mention two additional types for pre-installed applications, which we
 can reveal now:
-• type PA – standard pre-installed application
+*type PA – standard pre-installed application
-• type PP – pre-installed patch.
+*type PP – pre-installed patch.
 Consider the following example:
 ; Pre-installed package example
 ; Languages
@@ Line 1,046: / Line 1,049: @@
 :”UniqueVendorName”
 “files\bigvideo.mpg”-“e:\public\bigvideo.mpg”
 You will notice that the resulting SIS file is rather small. This is because
@@ Line 1,051: / Line 1,055: @@
 you have been provided with by MakeSIS is a ‘SIS Stub File’.
-SIS Stub Files
+'''SIS Stub Files'''
 SIS stub files should be placed on the media card in directory \private
@@ Line 1,067: / Line 1,071: @@
 cache accordingly.
-Future Enhancements
+'''Future Enhancements'''
 At the time of writing it was necessary to specify, in the package file, the
@@ Line 1,075: / Line 1,079: @@
 stub SIS file.
-.5.2 Auto-Propagated Packages
+'''Auto-Propagated Packages'''
 As an additional feature, if you should perform a normal installation of
@@ Line 1,085: / Line 1,089: @@
 There are a number of limitations on the way that you should create
 your package if you want propagations to work. Most importantly:
-• Make sure all the required files install to your media card.
+*Make sure all the required files install to your media card.
-• Ensure the application doesn’t modify any of the files listed as part of
+*Ensure the application doesn’t modify any of the files listed as part of the package.
 the package.
 Deviating from these rules could mean that you have a propagated

← Older revision	Revision as of 16:04, 18 December 2010
(No difference)

← Older revision	Revision as of 11:52, 24 March 2010
(No difference)

← Older revision	Revision as of 23:40, 21 March 2010
(No difference)

@@ Line 818: / Line 818: @@
 language the user selects. The result of installing a SIS file is usually
 (assuming all is well) one of the following:
-• A new package is installed and available on the mobile phone.
+*A new package is installed and available on the mobile phone.
-• An existing package has been upgraded or modified.
+*An existing package has been upgraded or modified.
-• An existing package has had some new removable components
+*An existing package has had some new removable components
 installed (e.g. game levels).
@@ Line 834: / Line 834: @@
 The most significant point to be aware of about the new SIS file is as
 follows:
 Pre-Symbian OS v9 SIS files are not compatible with the Symbian OS
 v9 installer.
 This may appear to be a big compatibility break, but bear in mind that
 the binaries in an old SIS file wouldn’t be compatible with Symbian OS
@@ Line 844: / Line 846: @@
 OS releases.
-SIS File Format Changes
+'''SIS File Format Changes'''
 The new SIS file format changes are summarized briefly below:
-• Multiple Signatures
+*Multiple Signatures
 The new SignSIS tool allows packages to be signed multiple times.
@@ Line 857: / Line 860: @@
 certificate chains are handled and validated. This was covered in
 more detail earlier.
-• Larger Package Sizes
+*Larger Package Sizes
 The theoretical maximum package size has been increased significantly,
 well beyond the current mobile phone’s typical storage
 capacity – but Symbian likes to think of the future.
-• Streamed Install
+*Streamed Install
 Large package files may become necessary, but caching them locally
 on the mobile phone prior to installation is wasteful. The new format
@@ Line 867: / Line 870: @@
 a shortlink or network connection. The API for this is covered in
 Appendix C.3.
-• Future Proofing
 The underlying structure allows us to be much more flexible with the
 contents and ordering of a SIS file. This also means we can avoid
 SIS file compatibility problems in future, even if we enhance the file
 contents.
 Additional Compatibility Note
 While we are on the subject of SIS file compatibility, it is worth recalling
 that the binary format was modified for Symbian OS v8.1b and v9. Since
@@ Line 878: / Line 885: @@
 come as no surprise that, if the installer encounters an old-style binary in
 a new SIS file, the installation will be aborted.
 In general it’s a good idea to ensure that the binaries present in
 your package are applicable to the target environment. Look out for the
 following situations:
-• You are packaging emulator binaries for use on a mobile phone or
+*You are packaging emulator binaries for use on a mobile phone or
 vice versa.
-• You’re packaging binaries built for the wrong version of Symbian OS
+*You’re packaging binaries built for the wrong version of Symbian OS
 for your intended target.
 In short, please ensure your binaries are correct for the target environment;
 this includes having the appropriate binary version for the target version
@@ Line 923: / Line 932: @@
 Library).
 ; Exe that is run on installation. SWI
 ; will wait until Exe has completed.
@@ Line 939: / Line 949: @@
 be aware of. In future releases, this auto-run ability may be restricted to
 trusted applications.
-Limitations
+'''Limitations'''
 In previous OS releases, you might have used auto-execution to unpack
@@ Line 948: / Line 959: @@
 Now, we need to apply data-caging rules to auto-execution and some
 limitations become apparent:
-• The auto-run EXE has its own SID – by definition.
+*The auto-run EXE has its own SID – by definition. INSTALLING TO AND FROM REMOVABLE MEDIA 181
-INSTALLING TO AND FROM REMOVABLE MEDIA 181
+*The auto-run EXEcan see data in its own/private/<SID> directory.
-• The auto-run EXEcan see data in its own/private/<SID> directory.
+*The auto-run EXE cannot see data in any other EXE’s /private/ <SID> directory.
-• The auto-run EXE cannot see data in any other EXE’s /private/
 <SID> directory.
 Sadly, therefore, data-caging rules limit what the auto-run EXE would
@@ Line 959: / Line 968: @@
 unpack chess opening moves) in the private directory of an EXE being
 installed. The auto-run EXE can still, however:
-• manipulate any data in public (non-data-caged) areas
+*manipulate any data in public (non-data-caged) areas
-• communicate with servers
+*communicate with servers
-• act as a server itself.
+*act as a server itself.
 Note, also, that the auto-run EXE cannot write into the import directory of
 the EXE being installed – in fact, as we previously noted, only the installer
 can write into that directory.
 Finally, auto-run executables may not be allowed to run indefinitely.
 For example, the installer may terminate them after a period of time to