Multiple independent runtime keys?

[MichalDN]

One thing I am unable to determine from the documentation prior the purchase.

Say I have 5 packages, I will obfuscate each separately with --outer flag.
I will then distribute all these packages to a number of users without the keys.
Finally, I would like to send them individualized (-b) keys for a subset of packages.
Will changing the outer_keyname (using cfg) for each package allow me to achieve this? Or are the keys license bound, and copy pasting them will suffice in "unlocking" other packages?
Or will the name of runtime folder need to be changed as well? (How would this be accomplished docs only say that with payed version you can do that but not really how.)
Or is this outside of what pyarmor can reliably do?

I tried to test it by having an individualzed cfg outer_keyname for the key building, and it seems to do what I need, but I wanted to confirm this is a valid use.

[jondy]

The test result is correct, it's designed feature, different outer_keyname for different runtime key.

[MichalDN]

Thank you very much for the reply.

[Jerry-0202]

Hello, I have been repeatedly reading the documentation, but I still have a small question, even after going through the answers (to be honest, I didn't fully understand them).

I have a similar question to ask the author: you mentioned "different outer_keyname for different runtime key." In such a situation, if I have multiple packages and use --outer, it seems to me that the only way to logically change each package's outer_keyname is to manually implement it through configuration (using cfg). Is there an alternative way to achieve this automatically? I can't seem to find an answer. From my current understanding, it seems that I or anyone else using this product could generate external keys arbitrarily and overwrite them to achieve their goals. The explanations in the documentation did not resolve my concerns. I hope to receive your response. Thank you.@jondy

[jondy]

Just try it, take a simple test, it may make everything clear.

[Jerry-0202]

Just try it, take a simple test, it may make everything clear.

Haha, I don’t have any more devices to provide corresponding support for the time being. But after hearing the author's answer, I seem to have guessed the answer. The generator's verification information should also be present during runtime. That is, the source of the secret key will be detected internally during runtime, and the corresponding key should also be generated by this device.

[Jerry-0202]

Just try it, take a simple test, it may make everything clear.

But if that's the case, then there's a problem.
Because my office or my encryption location is an office computer, will someone else use my device to generate a key and copy it to my encryption operating environment? This is a ridiculous but real question, so do I have to go through more steps in my runtime to check the source of the key?