Confused about selfsign vs. signed vs. unsigned

[peppebe]

My head is about to explode from all these terms.
Basically, what my ultimate goal is is to develop a pys60 app that in the end results in ONE .SIS file that I can give to anybody who won't have to install pys60 separately or install anything else separately for that matter. This app must be able to do all kinds of dances such as GPS, networking, appswitching, connect to music player and maybe more. I'm also hoping to piggiback on existing pys60 software I find around here which isn't always a .py file.

What do I need to do?
Will it be possible to do all this with Ensymble on Linux?

How to get the software working on my own development phone is less of an issue. It's the deployment on other peoples mobiles I worry about. I can imagine telling them to use the PC Suite to copy some_location_module.pyd into C:\\bin\\something as part of the installation instructions.

PS. I'm happy to pay if necessary but I don't want to have to pay every time I build a new version for my users.

PS2. Did I mention that I'm a complete newbie in Symbian-land but know my way around Python?

[jethro.fn]

Hello.

Symbian recently changed their signing policy. Unfortunately the new policy does not leave any avenue for distributing SIS files to users without paying for each signing. Many extension modules you find here are not signed at all due to the policy change. You would need to sign each one. In the worst case, you need to recompile/repackage each extension module (written in C++) with your own UID, as some of the signing options check that you own the UID of the SIS file (and due to capability problems, see below).

Here are the signing options and some thoughts about them (also see Symbian Signed Grid):

• Self-signing - Free, no need to deal with Nokia or Symbian at all. Llimited set of capabilities available: LocalServices, Location, NetworkServices, ReadUserData, UserEnvironment, WriteUserData. Operators may prevent installing of self-signed applications. Some operators already do this with their own phone variants. Also, there's no guarantee that any future Nokia phones accept self-signed SIS files.
• Open Signed Online - Free, but not suitable for distribution. Locked to one IMEI and the UID ownership is checked during signing, preventing the signing of other peoples extension modules. Each signing valid for three years.
• Open Signed Offline - Requires a Publisher ID (about $200 per year). Max. 1000 IMEIs, each signing valid for three years.
• Express Signed - Requires a Publisher ID. Costs $20 per signing, no IMEI restrictions, valid perpetually.
• Certified Signed - Requires a Publisher ID. Requires a test report from an independent test house (costly).

So, to distribute your software you most likely need to use the Express Signed option. You need to sign each extension module (written in C++, pure Python ones are OK) separately. Every time a SIS file changes, you need to re-sign the changed SIS file and the resulting one big SIS file.

Then there's the capability mix-up problem. Your Python application (more precisely the Ensymble-generated EXE stub that loads the Python interpreter DLL) needs at least the capabilities you're going to use. However, some extension modules may come compiled with a more limited set of capabilities, to allow self-signing. You cannot load extension modules with less capabilities than what your application has, so each extension module you are going to bundle with your application needs to have at least the capabilities your application has. This can cause all kinds of problems, especially with extension modules to which you don't have the source code.

Furhermore, Express Signed has these requirements:

You will need to submit the following in an application zip archive:

• .SIS file
• .PKG file used to make the .SIS
• User manual OR a 'how to use me' .TXT file
• 'Release notes' (known issues/limitations)

Now, Ensymble does not use PKG files. You would need to fake it or use the official makesis.exe from Symbian. You want a SIS file with several other SIS files inside it, which adds an additional twist to the plot.

I probably forgot some details, but I hope this will give you a quick overview of what you're up against.

[cyke64]

• Open Signed Online - Free, but not suitable for distribution. Locked to one IMEI and the UID ownership is checked during signing, preventing the signing of other peoples extension modules. Each signing valid for three years.
• Open Signed Offline - Requires a Publisher ID (about $200 per year). Max. 1000 IMEIs, each signing valid for three years.
• Express Signed - Requires a Publisher ID. Costs $20 per signing, no IMEI restrictions, valid perpetually.
• Certified Signed - Requires a Publisher ID. Requires a test report from an independent test house (costly).

Hello Jethro

Thanks you for the useful summary about signing ...
Could you please add Self-signed comment ?

Thanks

BR
Cyke64

[peppebe]

Thanks jethro.fn! That's a great response. You're my new hero. I really hope your post will help other people who are like me.

[jethro.fn]

Could you please add Self-signed comment ?

OK. I edited my first post and added notes about self-signing.

[gaba88]

hi jethro.fn
the post abt all types of signing is one of the best i consider in the python dibo.
great work and keep it up thanks.

[kandyfloss]

Hi Jethro,

Thats was a very useful and informative post you made

Good work.

[JOM]

Jethro.fn,

Maybe you could comment these issues, too? At least for me they are so confusing, that I believe it is completely impossible to developed and widely distribute any commercial apps using python:

1) You take C++ extension developed by someone else, pump up the capabilities to match your app and package in your own sis/sisx. What if the same extension is already installed with different set of capabilities?

Will the new overwrite the old? With more capabilities? With possibly less capabilities? Will installation be refused? What about self-signed vs open signed vs whatever signed? Which can overwrite which and what are the side-effects to other apps?

Do you have to change the UID to be able to install the extension? Which module would actually be used, when importing from script == do you have change the extension name, too ???

2) How to handle different pyS60 versions? User has already installed older / newer interpreter version than what you have included inside your sis/sisx? Whether pys60 is installed from your sis file or not, this definitely can cause problems to someone.

Worried,

--jouni

[jethro.fn]

Maybe you could comment these issues, too? At least for me they are so confusing, that I believe it is completely impossible to developed and widely distribute any commercial apps using python:

I think it is very difficult, but not impossible.

1) You take C++ extension developed by someone else, pump up the capabilities to match your app and package in your own sis/sisx. What if the same extension is already installed with different set of capabilities?

The installation will fail, even if the files are bitwise identical. No SIS file can overwrite files, unless the file to be overwritten came from an older version of the same SIS file (same UID).

Do you have to change the UID to be able to install the extension? Which module would actually be used, when importing from script == do you have change the extension name, too ???

Yes, I think the only way to be sure that there are no name collisions is to embed your own UID in the extension name and compile the extension with that UID.

2) How to handle different pyS60 versions? User has already installed older / newer interpreter version than what you have included inside your sis/sisx? Whether pys60 is installed from your sis file or not, this definitely can cause problems to someone.

This is a potential pitfall. Of course, compiling your own version of PyS60 with every built-in module renamed is one option, but is probably way too much work.

All this is the result of Symbian Signed and the overly simplistic design of Symbian OS Platform Security. It's not flexible enough for distributing SIS files which require other, possibly shared, SIS packages to be installed. As such, there's no point on trying to develop commercial PyS60 software unless the projected sales are huge, to offset the large amount of extra packaging work required.