patch_capabilities.pl solution not suitable for Symbian builds

Qt 4.7 introduces a script (patch_capabilities.pl) which is supposed to "normalise" the capability requirements of an application in order to allow it to be self-signed if the developer does not have (or does not specify) a suitable developer certificate.

I will start by declaring that I do not agree with this type of solution which presumes that the tools can make arbitrary decisions in behalf of the developer. If the developer has any reason to declare capability X in its project then the best the tool can do is to warn, at compile time, that such capability may not be suitable and that in the current project configuration the generated install package cannot be signed. The tool cannot however take corrective actions, simply because it has no efficient way of doing this.

Problems:

0) You make the assumption that a capability statement was added to the *.pro file by mistake

Wrong.

1) Which capabilities are self-signable?

The tool has the following set:
my @capabilitiesToAllow = ("LocalServices", "NetworkServices", "ReadUserData", "UserEnvironment", "WriteUserData");

So what happened with Location? Since S60 3.2 this capability is user grantable (Basic set) as well, and it is very likely that developers are testing Qt apps on 5.0 and 3.2 rather than the 3.1 platform.

2) What to patch?

The tool currently changes the capabilities set of the binaries, sets the VID to 0 and the package UID (pUID) is mapped to the 0xE range.

Risks:

• if a capability is removed, calls to APIs controlled by it will fail with KErrPermissionDenied - applications may not work reliably or even panic if error handling is not robust enough
• any plug-in DLLs which are to be loaded by pre-installed components would fail to be loaded if not having the expected set of capabilities
• application's registration resource file (and icon) are linked to the application through SID/UID3 which means binary's UID3 and the private paths cannot be patched - this results in the sis file installation failing if the application used private UID3 (0x2)
• pUID clash if the uid resulting after conversion to 0xE range was used already for test projects

3) What are the "known problem packages"?

I see that packages with UIDs 0x2002af5f and 0x2001E61C are skipped. Why only those? Any embedded package with a valid signature should not be touched. That includes Qt, Qt Mobility and any other package provided by Forum Nokia or a 3rd party vendor.

My proposal:

• drop this feature and replaced it with error messages and proper documentation of the PlatSec requirements
  "Not attempting to create SIS file. Reason: no suitable developer certificate available to allow signing of a project using capabilities X,Y,Z for device with IMEI 123456789012345. For more information see <link to help>"
• implement a certificate manager plug-in which will be able to tell which of the available certificates is suitable for use for signing the current project, for deployment on the connected device or for deployment to Symbian Signed or Ovi Store.