Missing parts in the documentation

[d94pn]

After having read the documentation and checked the source code a bit, I have a few unanswered questions:

• My understanding is that the tool's public key is derived from the private key, correct? But how is the tool's private key obtained in practise? And how is it connected to the list of public keys in the lve? It seemss is must originate from the lve somehow.
• Regarding the function: mlle_tool_libpath, how is this not redundant? In a previous step, the lve is started using the path to it, and the library path seems to be already given in that step (the lve is supposed to be in a sub directory ".library").
• The tool can ask for availabiliy of specific features via mlle_tool_feature, but how does it know about these features in the first place? Seems like there is a function missing, providing a list of all features?
• Same question for files: mlle_tool_file.

[iakovn]

After having read the documentation and checked the source code a bit, I have a few unanswered questions:

• My understanding is that the tool's public key is derived from the private key, correct? But how is the tool's private key obtained in practise? And how is it connected to the list of public keys in the lve? It seemss is must originate from the lve somehow.

Tool vendors must generate private + public key pairs. Tool vendor provide public key(s) to the library vendor(s) and safely embeds (obfuscated) private key into the tool installation. Library vendors put the public key into the list of accepted tools. It's important to understand that library vendors show trust for the tool vendors as anyone with the access to the tool private key may be able to gain access to the library code by authorizing as that tool.

• Regarding the function: mlle_tool_libpath, how is this not redundant? In a previous step, the lve is started using the path to it, and the library path seems to be already given in that step (the lve is supposed to be in a sub directory ".library").

The idea is that lve can be moved around during the installation (unzipping) of mol. In that case it may be put in a different directory outside the library folder.

• The tool can ask for availabiliy of specific features via mlle_tool_feature, but how does it know about these features in the first place? Seems like there is a function missing, providing a list of all features?

The tool is expected to extract feature information from license annotations in the Modelica library code.

• Same question for files: mlle_tool_file.

Not sure what question you mean.

[d94pn]

The files question was the same as for the feaures; how to know the set of available files in the first place. Also from some annotation?

[iakovn]

The files question was the same as for the feaures; how to know the set of available files in the first place. Also from some annotation?

Ah, sorry... You just list the directory content.

Hope the answers makes sense to you.

[d94pn]

Thanks. But I still wonder about:

The tool is expected to extract feature information from license annotations in the Modelica library code.

How exactly? By first getting the proper file content via mlle_tool_file? If so, the scenario is a bit misleading since it omits that part.

[iakovn]

Thanks. But I still wonder about:

The tool is expected to extract feature information from license annotations in the Modelica library code.

How exactly? By first getting the proper file content via mlle_tool_file?

Yes. The tool starts by requesting package.moc from the root of the library. That one will typically contain:

annotation (
  Protection(
    License(    features={"SomeFeatureName"}  )
  )
)

The tool should then request the feature(s) required before proceeding with requests for further files.

If so, the scenario is a bit misleading since it omits that part.

Which scenario do you mean?

[d94pn]

I meant the scenario in the SEMLA specification: SEMLA - COMMUNICATION PROTOCOL BETWEEN A TOOL AND LVE
It would be instructive if the reuqest of package.moc and extraction of features would preceede the feature requests in that communication between tool and lve.

[niklwors]

I also have a question about querying the necessary license features. You wrote:

Yes. The tool starts by requesting package.moc from the root of the library. That one will typically contain:

annotation (
  Protection(
    License(    features={"SomeFeatureName"}  )
  )
)

The tool should then request the feature(s) required before proceeding with requests for further files.

But according to the diagram from here the licenses must be checked before you can request a decrypted file. Or is that not necessary for a package.mo file?