The version number of the Modelica library is not passed to the SEMLA licence manager

[niklwors]

For us it is very important that the version number of the Modelica library is also passed to the licence manager interface function mlle_license_new(const char *libpath, struct mlle_error **error)
So that you can also check whether a licence is valid for a specific library version.

[hubertus65]

It is unusual to hard-connect licenses to version numbers: there are so many instances when new versions are needed. Isn't a date a much better solution in general? I agree that a version umber could be useful, but please elaborate on your use case.

[sbaetzing]

in general i agree. Licenses connected to a date are the most common solution.
But we also see the need to check for the version of a library and combine it with the life time of the license.

the main use case for us is to phase out old versions (mainly old major versions).
We have made the experience that without an update obligation, outdated versions (with bugs and known issues) will still be used for many years. In this way, we minimize the support required for problems that have already been solved.

[hubertus65]

Sorry for the long delay, but I now understand your motivation. Thanks!

[axelmartenssonmodelon]

We don't use this ourselves, but libpath that is passed in to mlle_license_new() may contain the version, since the top level package name may include the version of the library e.g. /a/b/MyLib 1.2/.

[sbaetzing]

in my opinion, this is not a good approach. Renaming the toplevel package according to the version would mean that every version each class would have to be converted when updating the library at the customer side.

[iakovn]

We didn't mean renaming, we referred to file system naming per Modelica spec "18.8.3 Versions in the File System" but for encrypted library:

A top-level class, IDENT, with version VERSION-NUMBER can be stored in one of the following ways in a directory given in the MODELICAPATH:
• The directory IDENT with the file package.mo directly inside it
Example: Modelica/package.mo
• The directory IDENT " " VERSION-NUMBER with the file package.mo directly inside it
Example: Modelica 2.1/package.mo

[niklwors]

But doesn't that mean that the user can manipulate the version number by renaming the folder?

[iakovn]

No, if specified, the version number must match the version annotation in Modelica library code

[niklwors]

@iakovn I have tested it when the library folder contains a different version number than the one in the version annoation. But the library is still loaded.

[iakovn]

@niklwors Could you elaborate what you tested and what would be the expected outcome?

[niwokr]

Could you elaborate what you tested and what would be the expected outcome?

I have a library that uses a version annotation, version="1.0.1". However, the folder name contains a different version 1.0.0. I have then encrypted it with the packagetool. But I can still load and use it in OMEdit. I have understood that this should not be possible.

[iakovn]

@niwokr Do you mean that you start with Library 1.0.1/package.mo, encrypt that, then test "tamper" by changing the name to Library 1.0.0?

I would actually expect compiler to refuse to load that library, so something to talk about with OMEdit devs.
You are definitely able to implement the check in you own license manager, e.g., by hardcoding the version check into the LVE, right? You can also (as a workaround) specify version in a "feature" annotation.

On the default SEMLA side we currently do not include name of the top level directory into the encryption protection and we probably should. That would imply that the library decryption will fail after directory rename.

[niklwors]

@niwokr Do you mean that you start with Library 1.0.1/package.mo, encrypt that, then test "tamper" by changing the name to Library 1.0.0?

I changed the annotation in the package.mo to 1.0.0 and used the folder Libarary 1.0.1/ for the packagetool.

I would actually expect compiler to refuse to load that library, so something to talk about with OMEdit devs. You are definitely able to implement the check in you own license manager, e.g., by hardcoding the version check into the LVE, right?

Your suggestion was that you get the version number of the library from the library path that is passed to the SEMLA licensemanager constructor. That's why I asked that a user can manipulate the version number if he renames the folder.

You can also (as a workaround) specify version in a "feature" annotation.

It would be better if the version form the annoation is available in the SEMLA license manager.

On the default SEMLA side we currently do not include name of the top level directory into the encryption protection and we probably should. That would imply that the library decryption will fail after directory rename.