search

modelica / Encryption-and-Licensing

Standardized Encryption of Modelica Libraries and Artifacts
BSD 3-Clause "New" or "Revised" License
3 stars 6 forks source link

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

Open niklwors opened 7 months ago

niklwors commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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 commented 5 months ago

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

axelmartenssonmodelon commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

iakovn commented 4 months ago

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

niklwors commented 4 months ago

@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 commented 4 months ago

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

niwokr commented 4 months ago

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 commented 4 months ago

@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 commented 4 months ago

@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.