Re signing to add embedded sis

Hi all,
I have a symbian signed application (SIS1). We had to write some waivers, hence we couldn't use Express signed.
Now I want to extend this package : I want to embed an other signed application (SIS2) into SIS1.
As a result i will have a single package that will deploy both applications.
This may seems silly but for a large scale deployment we want only one package to install, not 2.

I will not change anything in SIS1 (except the PKG). Do I have to go through all certified signed process again?
Since both app are signed it is only a repackaging...
Is there a way to do it quickly?

Thanks for your help!

I'm rather sure the answer is Yes, every time you make any modifications, you do need to go through the signing process just the same.

What SymbianSigned guarantees is that the sis file signed with the Symbian root certificate has not been tampered with, but what you are doing is tampering with it by adding new files.

Because the content of the sis file has changed, the signature would be invalid and so it would require re-cerification.

You could wrap the sis files together as an embedded sis file via the dependency line in the pkg file.

Things like this should be considered before signing in order to minimize the need for re-signing each time any of the sis file content is touched. The less likely to change SIS file is the one to be embedded inside the sis file who's content is more likely subject to change.

Now, if you have two signed sis file and all you want is to ensure distribution as one package there is of course the option of delivering both sis files embedded in one self-signed package. It will display that warning about your application not being trusted and will create one more entry in the application manager but on the other side will save you the trouble (and the cost) of signing the application again.

With a bit of extra cost (but no trouble at all) you can sign the delivery package using Express Signed.

Hi all,
Thanks for your replies.
Yes, both applications could be wrapped into an other package.
But then the problem is that one of the application should start at boot up. And I cannot manage to add an embedded sis into the startup list...

Basically to do it, you need to create a seperate sis file that is an augmentation package (type PA) to your original package (ie the one you want to make autostart) and then when your application starts for the first time use the silent installer API to augment the existing package which will then register the autostart correctly.

I'm not sure if this documented anywhere on the wiki but it probably should be.

Or you can add a launcher to the delivery package (now signing becomes mandatory) which on boot will take care of starting the initial launcer from your SIS1 so that it can then execute its tasks as initialy designed.

I'm not sure to understand...
I'll investigate SW Installer Launcher API, and see if it can register to autostart.

Regarding the case I have to add a launcher to the package. It would be :
- a simple exe that is launched at boot up (the sis would install 2 app + the laucher),
- the launcher would simply launch the SIS1 (or it's exe)
In that case I would have to sign the launcher only.
Am I right?

Paul's suggestion is that you make a sis file that contains the registration file and the SIS1 exe that is supposed to start on boot and have it patch the installation at a later time by silently installing the sis. The question is who will launch the patching, since the exe in SIS1 has no knowledge of this patch being needed. So you would need an installer utility that does the patching

[CODE]dist.sis
@sis1.sis
@sis2.sis
patch.sis - !:\...\patch.sis
patch_installer.exe - !:\sys\bin\patch_installer.exe, FR, RI[/CODE]

The patch_installer.exe uses the SW Installer API to perform the installation of patch.sis You will have to sign dist.sis of course.

With this approach you need to sign two additional SIS files: patch.sis and dist.sis

My suggestion is that you don't use an installer but a launcher:

[CODE]dist.sis
@sis1.sis
@sis2.sis
dist_launcher.exe - !:\sys\bin\dist_launcher.exe
[dist_pUID].rsc - c:\private\...\[dist_pUID].rsc[/CODE]

The launcher will then be started on boot and it will start the exe that SIS1 was supposed to register. From SIS1's perspective nothing's changed.

Got it!
Thank you all for your precious advices. I implemented ltomuta's solution because it seemed to me to be the simplest.
And it works perfecrly!