Re: [Maya-Python] V Crypt System

[Rudi Hammad]

yes, something like that might work, but if I am working locally from home 
sending files to someone else that is also in his own personal computer I 
can't really force that persone to set the usertSetup.py or the other 
alternative you mentioned.
aarrggg...callbacks are nice, but yeah...doesn't seem to hard to by 
pass them. I'll have to trust that people will respect the nda agreement...

About what I am trying to protect is the rig basically in 2 aspects:
1-prevent redistribution outside a production
2-prevent reverse ingeniering, which I did find out recently that a lot of 
nda's have a section stating that you agree not to do that...but 
againhow can you enforce that? it is impossible.

So far the safest system is VCrypt, but as we talked before, many clients 
might refuse to use it even if provide them a license. Anyway, thanks for 
all the suggestions.


El miércoles, 15 de septiembre de 2021 a las 7:47:08 UTC+2, Marcus Ottosson 
escribió:

> it work is you execute that at the beginning of every maya session (for 
> instance putting it in the userSetup.py), but then you just have to find 
> this part of the code and remove it…
>
> About MSceneMessage.addCheckCallback, there are a few ways of installing 
> it.
>
>- userSetup.py 
>- plug-in 
>- Script node in a New Scene Template 
>
> I’d argue each of these are equally insecure, in that anyone can (1) edit 
> the userSetup.py, or associated environment variable that points to it, (2) 
> unload the plug-in, forcefully or launch Maya without plug-ins and (3) find 
> that hidden spot where you edit the new scene template.
>
> userSetup.py can be made more secure by residing on PYTHONPATH rather than 
> in the user’s home directory. That way, you provide your own Maya 
> executable (e.g. a .bat file on Windows) whereby a userSetup of your choice 
> is added to PYTHONPATH prior to launch.
>
> :: maya.batset PYTHONPATH=\\server\pipeline\userSetup.pystart "c:\program 
> files\autodesk\maya2020\bin\maya.exe"
>
> That way, the user would be unable to launch Maya without also executing 
> this userSetup.py. Especially if it is also what loads up relevant pipeline 
> tooling such that if they were to try and launch it without this executable 
> (which is read-only, on a network), they would be unable to even use Maya 
> for their work.
>
> And again, I think you have to define what you protecting against. 
> Malicious hacker-animators, or the 99% case? Because no system can ever 
> protect against every attack; not in Maya, not anywhere. If what it takes 
> to defeat your system is to bypass a hidden userSetup.py then I’d argue you 
> have already protected against the vast majority of cases.
>
> On Wed, 15 Sept 2021 at 04:02, Justin Israel  wrote:
>
>>
>>
>> On Wed, Sep 15, 2021 at 11:36 AM Rudi Hammad  wrote:
>>
>>> So I cam up with a evil idea that seems to work.
>>> . I create a script node that travels with the scene that will check 
>>> your mac address out from a list of valid addresses (that would be the ones 
>>> corresponding to the people working remotly on their personal computers).
>>>   if the address doesn't match it wont open (it opens a new file for 
>>> instance)
>>> . So then, lets say that your address is valid. Now you would think that 
>>> you can just delete the scriptNode and that's it, right? weI 
>>> added a callback that triggers when you delete the scriptNode, that deletes 
>>> everything .
>>>
>>> Of course we can just change that to something less evil, but maybe this 
>>> might work? save a scriptnode will what ever callback are needed, and 
>>> prevent this script node from bein delete?
>>> I don't know...I am starting to lose motivation...
>>>
>>
>> What if I just open the scene file with the option to disable script 
>> nodes? If it's somewhat trivial to defeat the security then you have to 
>> decide if you are doing this with the goal of absolute security, or just 
>> being a deterrent and using security-via-obscurity. If there is any way to 
>> get the scene file opened, either by disabling script nodes, or by another 
>> binary to ascii conversion that can then edit the script nodes, it kind of 
>> makes this pointless if the goal is security.
>>
>>  
>>
>>>
>>>
>>>
>>> El lunes, 13 de septiembre de 2021 a las 22:21:47 UTC+2, 
>>> justin...@gmail.com escribió:
>>>
 On Tue, Sep 14, 2021 at 7:52 AM Rudi Hammad  wrote:

> About V crypt, I got in thouch with them and they sent me the system 
> to test it in demo mode. It work pretty well, but as Justin anticipated 
> and 
> as the video showed, all clients are requiered to have the app.
> So maya is should be launched from V Crypt, and then you can open the 
> encrypted files. Which is not ideal because you are enforcing everyone to 
> purchast their system.
>
> So as an alternatively I tried to do something with addCheckCallback 
> that Marcus mention:
>
> mSceneMsgOpenCheck = 

Re: [Maya-Python] V Crypt System

[Rudi Hammad]

oh noI had no idea you can open files disabeling script nodes. 
Bummer...good thing I am not working in security.

El miércoles, 15 de septiembre de 2021 a las 5:02:23 UTC+2, 
justin...@gmail.com escribió:

> On Wed, Sep 15, 2021 at 11:36 AM Rudi Hammad  wrote:
>
>> So I cam up with a evil idea that seems to work.
>> . I create a script node that travels with the scene that will check your 
>> mac address out from a list of valid addresses (that would be the ones 
>> corresponding to the people working remotly on their personal computers).
>>   if the address doesn't match it wont open (it opens a new file for 
>> instance)
>> . So then, lets say that your address is valid. Now you would think that 
>> you can just delete the scriptNode and that's it, right? weI 
>> added a callback that triggers when you delete the scriptNode, that deletes 
>> everything .
>>
>> Of course we can just change that to something less evil, but maybe this 
>> might work? save a scriptnode will what ever callback are needed, and 
>> prevent this script node from bein delete?
>> I don't know...I am starting to lose motivation...
>>
>
> What if I just open the scene file with the option to disable script 
> nodes? If it's somewhat trivial to defeat the security then you have to 
> decide if you are doing this with the goal of absolute security, or just 
> being a deterrent and using security-via-obscurity. If there is any way to 
> get the scene file opened, either by disabling script nodes, or by another 
> binary to ascii conversion that can then edit the script nodes, it kind of 
> makes this pointless if the goal is security.
>
>  
>
>>
>>
>>
>> El lunes, 13 de septiembre de 2021 a las 22:21:47 UTC+2, 
>> justin...@gmail.com escribió:
>>
>>> On Tue, Sep 14, 2021 at 7:52 AM Rudi Hammad  wrote:
>>>
 About V crypt, I got in thouch with them and they sent me the system to 
 test it in demo mode. It work pretty well, but as Justin anticipated and 
 as 
 the video showed, all clients are requiered to have the app.
 So maya is should be launched from V Crypt, and then you can open the 
 encrypted files. Which is not ideal because you are enforcing everyone to 
 purchast their system.

 So as an alternatively I tried to do something with addCheckCallback 
 that Marcus mention:

 mSceneMsgOpenCheck = OpenMaya.MSceneMessage()
 def licenseCheckOnOpen(*args):  # a function that reads your mac 
 address and if it doesn't match the hardcoded one, it won't open.
  
 OpenMaya.MSceneMessage.addCheckCallback(mSceneMsgOpenCheck.kBeforeOpenCheck,
  
 licenseCheckOnOpen)

 but that was a total failit work is you execute that at the 
 beginning of every maya session (for instance putting it in the 
 userSetup.py),  but then you just have to find this part of the code and 
 remove it...

 ps: let me know if this last part is offtopic and I'll just shut up 
 about it.

>>>
>>> Oh I didn't even connect your MEL and callback questions to this topic. 
>>> I see now that you were experimenting with related custom approaches. 
>>>
>>> Yea I agree with you that it would be cumbersome to require everyone to 
>>> purchase some encryption app license. But maybe the approach is that a temp 
>>> license is given to the client on behalf of the owner of the media and the 
>>> one imposing the workflow? Having full ownership of the Maya process, as V 
>>> Crypt wants to do, seems like the only way to get close enough to securing 
>>> the media. If you ever let the user have direct unregulated access to the 
>>> source then they can disable whatever checks (callbacks or whatever). 
>>> "Close enough" is maybe just making it hard enough to avoid mistakes and 
>>> easily sharing things? 
>>>  
>>>

 El lunes, 13 de septiembre de 2021 a las 19:22:37 UTC+2, Rudi Hammad 
 escribió:

> It was still kind in the context of encrypting a maya scene that 
> derived from the main V Crypt topic, but we'll do.
> El lunes, 13 de septiembre de 2021 a las 19:07:28 UTC+2, 
> justin...@gmail.com escribió:
>
>> Please make sure to start a new thread if you want to engage in new 
>> topics. It seems two completely new questions have been asked since the 
>> original thread was started about V Crypt, and are entirely unrelated. 
>> Thanks! 
>>
>> On Tue, 14 Sep 2021, 4:25 am Rudi Hammad,  wrote:
>>
>>> That's it! thanks Juan
>>>
>>> El lunes, 13 de septiembre de 2021 a las 15:33:57 UTC+2, Juan Moraga 
>>> escribió:
>>>
 Try using "def onOpenCallBack(*args):" instead. 
 Callbacks may pass on arguments to you method, which you can use or 
 not. But you need to allow the function to receive these arguments, 
 otherwise it will raise an exception.


 On Mon, 13 Sep 2021, 15:09 Rudi Hammad,  wrote:

> Hello,

Re: [Maya-Python] V Crypt System

[Marcus Ottosson]

it work is you execute that at the beginning of every maya session (for
instance putting it in the userSetup.py), but then you just have to find
this part of the code and remove it…

About MSceneMessage.addCheckCallback, there are a few ways of installing it.

   - userSetup.py
   - plug-in
   - Script node in a New Scene Template

I’d argue each of these are equally insecure, in that anyone can (1) edit
the userSetup.py, or associated environment variable that points to it, (2)
unload the plug-in, forcefully or launch Maya without plug-ins and (3) find
that hidden spot where you edit the new scene template.

userSetup.py can be made more secure by residing on PYTHONPATH rather than
in the user’s home directory. That way, you provide your own Maya
executable (e.g. a .bat file on Windows) whereby a userSetup of your choice
is added to PYTHONPATH prior to launch.

:: maya.batset PYTHONPATH=\\server\pipeline\userSetup.pystart
"c:\program files\autodesk\maya2020\bin\maya.exe"

That way, the user would be unable to launch Maya without also executing
this userSetup.py. Especially if it is also what loads up relevant pipeline
tooling such that if they were to try and launch it without this executable
(which is read-only, on a network), they would be unable to even use Maya
for their work.

And again, I think you have to define what you protecting against.
Malicious hacker-animators, or the 99% case? Because no system can ever
protect against every attack; not in Maya, not anywhere. If what it takes
to defeat your system is to bypass a hidden userSetup.py then I’d argue you
have already protected against the vast majority of cases.

On Wed, 15 Sept 2021 at 04:02, Justin Israel  wrote:

>
>
> On Wed, Sep 15, 2021 at 11:36 AM Rudi Hammad  wrote:
>
>> So I cam up with a evil idea that seems to work.
>> . I create a script node that travels with the scene that will check your
>> mac address out from a list of valid addresses (that would be the ones
>> corresponding to the people working remotly on their personal computers).
>>   if the address doesn't match it wont open (it opens a new file for
>> instance)
>> . So then, lets say that your address is valid. Now you would think that
>> you can just delete the scriptNode and that's it, right? weI
>> added a callback that triggers when you delete the scriptNode, that deletes
>> everything .
>>
>> Of course we can just change that to something less evil, but maybe this
>> might work? save a scriptnode will what ever callback are needed, and
>> prevent this script node from bein delete?
>> I don't know...I am starting to lose motivation...
>>
>
> What if I just open the scene file with the option to disable script
> nodes? If it's somewhat trivial to defeat the security then you have to
> decide if you are doing this with the goal of absolute security, or just
> being a deterrent and using security-via-obscurity. If there is any way to
> get the scene file opened, either by disabling script nodes, or by another
> binary to ascii conversion that can then edit the script nodes, it kind of
> makes this pointless if the goal is security.
>
>
>
>>
>>
>>
>> El lunes, 13 de septiembre de 2021 a las 22:21:47 UTC+2,
>> justin...@gmail.com escribió:
>>
>>> On Tue, Sep 14, 2021 at 7:52 AM Rudi Hammad  wrote:
>>>
 About V crypt, I got in thouch with them and they sent me the system to
 test it in demo mode. It work pretty well, but as Justin anticipated and as
 the video showed, all clients are requiered to have the app.
 So maya is should be launched from V Crypt, and then you can open the
 encrypted files. Which is not ideal because you are enforcing everyone to
 purchast their system.

 So as an alternatively I tried to do something with addCheckCallback
 that Marcus mention:

 mSceneMsgOpenCheck = OpenMaya.MSceneMessage()
 def licenseCheckOnOpen(*args):  # a function that reads your mac
 address and if it doesn't match the hardcoded one, it won't open.
  
 OpenMaya.MSceneMessage.addCheckCallback(mSceneMsgOpenCheck.kBeforeOpenCheck,
 licenseCheckOnOpen)

 but that was a total failit work is you execute that at the
 beginning of every maya session (for instance putting it in the
 userSetup.py),  but then you just have to find this part of the code and
 remove it...

 ps: let me know if this last part is offtopic and I'll just shut up
 about it.

>>>
>>> Oh I didn't even connect your MEL and callback questions to this topic.
>>> I see now that you were experimenting with related custom approaches.
>>>
>>> Yea I agree with you that it would be cumbersome to require everyone to
>>> purchase some encryption app license. But maybe the approach is that a temp
>>> license is given to the client on behalf of the owner of the media and the
>>> one imposing the workflow? Having full ownership of the Maya process, as V
>>> Crypt wants to do, seems like the only way to get close 

Re: [Maya-Python] V Crypt System

[Justin Israel]

On Wed, Sep 15, 2021 at 11:36 AM Rudi Hammad  wrote:

> So I cam up with a evil idea that seems to work.
> . I create a script node that travels with the scene that will check your
> mac address out from a list of valid addresses (that would be the ones
> corresponding to the people working remotly on their personal computers).
>   if the address doesn't match it wont open (it opens a new file for
> instance)
> . So then, lets say that your address is valid. Now you would think that
> you can just delete the scriptNode and that's it, right? weI
> added a callback that triggers when you delete the scriptNode, that deletes
> everything .
>
> Of course we can just change that to something less evil, but maybe this
> might work? save a scriptnode will what ever callback are needed, and
> prevent this script node from bein delete?
> I don't know...I am starting to lose motivation...
>

What if I just open the scene file with the option to disable script nodes?
If it's somewhat trivial to defeat the security then you have to decide if
you are doing this with the goal of absolute security, or just being a
deterrent and using security-via-obscurity. If there is any way to get the
scene file opened, either by disabling script nodes, or by another binary
to ascii conversion that can then edit the script nodes, it kind of makes
this pointless if the goal is security.



>
>
>
> El lunes, 13 de septiembre de 2021 a las 22:21:47 UTC+2,
> justin...@gmail.com escribió:
>
>> On Tue, Sep 14, 2021 at 7:52 AM Rudi Hammad  wrote:
>>
>>> About V crypt, I got in thouch with them and they sent me the system to
>>> test it in demo mode. It work pretty well, but as Justin anticipated and as
>>> the video showed, all clients are requiered to have the app.
>>> So maya is should be launched from V Crypt, and then you can open the
>>> encrypted files. Which is not ideal because you are enforcing everyone to
>>> purchast their system.
>>>
>>> So as an alternatively I tried to do something with addCheckCallback
>>> that Marcus mention:
>>>
>>> mSceneMsgOpenCheck = OpenMaya.MSceneMessage()
>>> def licenseCheckOnOpen(*args):  # a function that reads your mac address
>>> and if it doesn't match the hardcoded one, it won't open.
>>>  
>>> OpenMaya.MSceneMessage.addCheckCallback(mSceneMsgOpenCheck.kBeforeOpenCheck,
>>> licenseCheckOnOpen)
>>>
>>> but that was a total failit work is you execute that at the
>>> beginning of every maya session (for instance putting it in the
>>> userSetup.py),  but then you just have to find this part of the code and
>>> remove it...
>>>
>>> ps: let me know if this last part is offtopic and I'll just shut up
>>> about it.
>>>
>>
>> Oh I didn't even connect your MEL and callback questions to this topic. I
>> see now that you were experimenting with related custom approaches.
>>
>> Yea I agree with you that it would be cumbersome to require everyone to
>> purchase some encryption app license. But maybe the approach is that a temp
>> license is given to the client on behalf of the owner of the media and the
>> one imposing the workflow? Having full ownership of the Maya process, as V
>> Crypt wants to do, seems like the only way to get close enough to securing
>> the media. If you ever let the user have direct unregulated access to the
>> source then they can disable whatever checks (callbacks or whatever).
>> "Close enough" is maybe just making it hard enough to avoid mistakes and
>> easily sharing things?
>>
>>
>>>
>>> El lunes, 13 de septiembre de 2021 a las 19:22:37 UTC+2, Rudi Hammad
>>> escribió:
>>>
 It was still kind in the context of encrypting a maya scene that
 derived from the main V Crypt topic, but we'll do.
 El lunes, 13 de septiembre de 2021 a las 19:07:28 UTC+2,
 justin...@gmail.com escribió:

> Please make sure to start a new thread if you want to engage in new
> topics. It seems two completely new questions have been asked since the
> original thread was started about V Crypt, and are entirely unrelated.
> Thanks!
>
> On Tue, 14 Sep 2021, 4:25 am Rudi Hammad,  wrote:
>
>> That's it! thanks Juan
>>
>> El lunes, 13 de septiembre de 2021 a las 15:33:57 UTC+2, Juan Moraga
>> escribió:
>>
>>> Try using "def onOpenCallBack(*args):" instead.
>>> Callbacks may pass on arguments to you method, which you can use or
>>> not. But you need to allow the function to receive these arguments,
>>> otherwise it will raise an exception.
>>>
>>>
>>> On Mon, 13 Sep 2021, 15:09 Rudi Hammad,  wrote:
>>>
 Hello,
 any idea why this is not working?
 I opened a scene and created this callback, and then saved the scene

 def onOpenCallBack():
print "this is a test"

 checkCallback =
 OpenMaya.MSceneMessage.addCheckCallback(OpenMaya.MSceneMessage.kBeforeOpenCheck,
 onOpenCallBack)

 Now when I open the scene I 

Re: [Maya-Python] V Crypt System

[Rudi Hammad]

So I cam up with a evil idea that seems to work.
. I create a script node that travels with the scene that will check your 
mac address out from a list of valid addresses (that would be the ones 
corresponding to the people working remotly on their personal computers).
  if the address doesn't match it wont open (it opens a new file for 
instance)
. So then, lets say that your address is valid. Now you would think that 
you can just delete the scriptNode and that's it, right? weI 
added a callback that triggers when you delete the scriptNode, that deletes 
everything .

Of course we can just change that to something less evil, but maybe this 
might work? save a scriptnode will what ever callback are needed, and 
prevent this script node from bein delete?
I don't know...I am starting to lose motivation...



El lunes, 13 de septiembre de 2021 a las 22:21:47 UTC+2, 
justin...@gmail.com escribió:

> On Tue, Sep 14, 2021 at 7:52 AM Rudi Hammad  wrote:
>
>> About V crypt, I got in thouch with them and they sent me the system to 
>> test it in demo mode. It work pretty well, but as Justin anticipated and as 
>> the video showed, all clients are requiered to have the app.
>> So maya is should be launched from V Crypt, and then you can open the 
>> encrypted files. Which is not ideal because you are enforcing everyone to 
>> purchast their system.
>>
>> So as an alternatively I tried to do something with addCheckCallback that 
>> Marcus mention:
>>
>> mSceneMsgOpenCheck = OpenMaya.MSceneMessage()
>> def licenseCheckOnOpen(*args):  # a function that reads your mac address 
>> and if it doesn't match the hardcoded one, it won't open.
>>  
>> OpenMaya.MSceneMessage.addCheckCallback(mSceneMsgOpenCheck.kBeforeOpenCheck, 
>> licenseCheckOnOpen)
>>
>> but that was a total failit work is you execute that at the beginning 
>> of every maya session (for instance putting it in the userSetup.py),  but 
>> then you just have to find this part of the code and remove it...
>>
>> ps: let me know if this last part is offtopic and I'll just shut up about 
>> it.
>>
>
> Oh I didn't even connect your MEL and callback questions to this topic. I 
> see now that you were experimenting with related custom approaches. 
>
> Yea I agree with you that it would be cumbersome to require everyone to 
> purchase some encryption app license. But maybe the approach is that a temp 
> license is given to the client on behalf of the owner of the media and the 
> one imposing the workflow? Having full ownership of the Maya process, as V 
> Crypt wants to do, seems like the only way to get close enough to securing 
> the media. If you ever let the user have direct unregulated access to the 
> source then they can disable whatever checks (callbacks or whatever). 
> "Close enough" is maybe just making it hard enough to avoid mistakes and 
> easily sharing things? 
>  
>
>>
>> El lunes, 13 de septiembre de 2021 a las 19:22:37 UTC+2, Rudi Hammad 
>> escribió:
>>
>>> It was still kind in the context of encrypting a maya scene that derived 
>>> from the main V Crypt topic, but we'll do.
>>> El lunes, 13 de septiembre de 2021 a las 19:07:28 UTC+2, 
>>> justin...@gmail.com escribió:
>>>
 Please make sure to start a new thread if you want to engage in new 
 topics. It seems two completely new questions have been asked since the 
 original thread was started about V Crypt, and are entirely unrelated. 
 Thanks! 

 On Tue, 14 Sep 2021, 4:25 am Rudi Hammad,  wrote:

> That's it! thanks Juan
>
> El lunes, 13 de septiembre de 2021 a las 15:33:57 UTC+2, Juan Moraga 
> escribió:
>
>> Try using "def onOpenCallBack(*args):" instead. 
>> Callbacks may pass on arguments to you method, which you can use or 
>> not. But you need to allow the function to receive these arguments, 
>> otherwise it will raise an exception.
>>
>>
>> On Mon, 13 Sep 2021, 15:09 Rudi Hammad,  wrote:
>>
>>> Hello,
>>> any idea why this is not working?
>>> I opened a scene and created this callback, and then saved the scene
>>>
>>> def onOpenCallBack():
>>>print "this is a test"
>>>
>>> checkCallback = 
>>> OpenMaya.MSceneMessage.addCheckCallback(OpenMaya.MSceneMessage.kBeforeOpenCheck,
>>>  
>>> onOpenCallBack)
>>>
>>> Now when I open the scene I get this error:
>>> # TypeError: onOpenCallBack() takes no arguments (2 given) // 
>>> // Warning: line 0: Python callback failed // 
>>>
>>> but I didn't give any arguments. Why is it saying given 2? are they 
>>> *args and **kwargs? Still, any idea why this is not working?
>>> Thanks
>>>
>>> El lunes, 6 de septiembre de 2021 a las 22:23:04 UTC+2, Rudi Hammad 
>>> escribió:
>>>
 oh, about the screenshots. If the rig is encapsulated in a black 
 box, maybe it would be possible set a callback preventing from 
 unlocking 
 the blackbox?

Re: [Maya-Python] V Crypt System

[Justin Israel]

On Tue, Sep 14, 2021 at 7:52 AM Rudi Hammad  wrote:

> About V crypt, I got in thouch with them and they sent me the system to
> test it in demo mode. It work pretty well, but as Justin anticipated and as
> the video showed, all clients are requiered to have the app.
> So maya is should be launched from V Crypt, and then you can open the
> encrypted files. Which is not ideal because you are enforcing everyone to
> purchast their system.
>
> So as an alternatively I tried to do something with addCheckCallback that
> Marcus mention:
>
> mSceneMsgOpenCheck = OpenMaya.MSceneMessage()
> def licenseCheckOnOpen(*args):  # a function that reads your mac address
> and if it doesn't match the hardcoded one, it won't open.
>  OpenMaya.MSceneMessage.addCheckCallback(mSceneMsgOpenCheck.kBeforeOpenCheck,
> licenseCheckOnOpen)
>
> but that was a total failit work is you execute that at the beginning
> of every maya session (for instance putting it in the userSetup.py),  but
> then you just have to find this part of the code and remove it...
>
> ps: let me know if this last part is offtopic and I'll just shut up about
> it.
>

Oh I didn't even connect your MEL and callback questions to this topic. I
see now that you were experimenting with related custom approaches.

Yea I agree with you that it would be cumbersome to require everyone to
purchase some encryption app license. But maybe the approach is that a temp
license is given to the client on behalf of the owner of the media and the
one imposing the workflow? Having full ownership of the Maya process, as V
Crypt wants to do, seems like the only way to get close enough to securing
the media. If you ever let the user have direct unregulated access to the
source then they can disable whatever checks (callbacks or whatever).
"Close enough" is maybe just making it hard enough to avoid mistakes and
easily sharing things?


>
> El lunes, 13 de septiembre de 2021 a las 19:22:37 UTC+2, Rudi Hammad
> escribió:
>
>> It was still kind in the context of encrypting a maya scene that derived
>> from the main V Crypt topic, but we'll do.
>> El lunes, 13 de septiembre de 2021 a las 19:07:28 UTC+2,
>> justin...@gmail.com escribió:
>>
>>> Please make sure to start a new thread if you want to engage in new
>>> topics. It seems two completely new questions have been asked since the
>>> original thread was started about V Crypt, and are entirely unrelated.
>>> Thanks!
>>>
>>> On Tue, 14 Sep 2021, 4:25 am Rudi Hammad,  wrote:
>>>
 That's it! thanks Juan

 El lunes, 13 de septiembre de 2021 a las 15:33:57 UTC+2, Juan Moraga
 escribió:

> Try using "def onOpenCallBack(*args):" instead.
> Callbacks may pass on arguments to you method, which you can use or
> not. But you need to allow the function to receive these arguments,
> otherwise it will raise an exception.
>
>
> On Mon, 13 Sep 2021, 15:09 Rudi Hammad,  wrote:
>
>> Hello,
>> any idea why this is not working?
>> I opened a scene and created this callback, and then saved the scene
>>
>> def onOpenCallBack():
>>print "this is a test"
>>
>> checkCallback =
>> OpenMaya.MSceneMessage.addCheckCallback(OpenMaya.MSceneMessage.kBeforeOpenCheck,
>> onOpenCallBack)
>>
>> Now when I open the scene I get this error:
>> # TypeError: onOpenCallBack() takes no arguments (2 given) //
>> // Warning: line 0: Python callback failed //
>>
>> but I didn't give any arguments. Why is it saying given 2? are they
>> *args and **kwargs? Still, any idea why this is not working?
>> Thanks
>>
>> El lunes, 6 de septiembre de 2021 a las 22:23:04 UTC+2, Rudi Hammad
>> escribió:
>>
>>> oh, about the screenshots. If the rig is encapsulated in a black
>>> box, maybe it would be possible set a callback preventing from unlocking
>>> the blackbox?
>>> That way you can check want is inside and take screenshot.
>>>
>>> El lunes, 6 de septiembre de 2021 a las 22:02:29 UTC+2, Rudi Hammad
>>> escribió:
>>>
 Quick question, I haven't use mel in 4 years now so it is probably
 something foolish but why is this not working?

 string $toEval = "def foo():import uuid; macAddress =
 uuid.getnode(); return macAddress; foo()";
 string $macAddress = python($toEval);
 print $x;

 I would expect $x to print my computer mac address by it is empty.

 El lunes, 6 de septiembre de 2021 a las 15:39:02 UTC+2,
 golu...@gmail.com escribió:

> Marcus, thanks for your comment!
>
> When I talked about export I meant not to ma or mb, I meant for
> example to alembic or other,  because as I knew alembic export is 
> like a
> separate plugin, and .correct me if I am wrong export to alembic will 
> be
> ignored by this callback.
>
> I've not 

Re: [Maya-Python] V Crypt System

[Rudi Hammad]

About V crypt, I got in thouch with them and they sent me the system to 
test it in demo mode. It work pretty well, but as Justin anticipated and as 
the video showed, all clients are requiered to have the app.
So maya is should be launched from V Crypt, and then you can open the 
encrypted files. Which is not ideal because you are enforcing everyone to 
purchast their system.

So as an alternatively I tried to do something with addCheckCallback that 
Marcus mention:

mSceneMsgOpenCheck = OpenMaya.MSceneMessage()
def licenseCheckOnOpen(*args):  # a function that reads your mac address 
and if it doesn't match the hardcoded one, it won't open.
 OpenMaya.MSceneMessage.addCheckCallback(mSceneMsgOpenCheck.kBeforeOpenCheck, 
licenseCheckOnOpen)

but that was a total failit work is you execute that at the beginning 
of every maya session (for instance putting it in the userSetup.py),  but 
then you just have to find this part of the code and remove it...

ps: let me know if this last part is offtopic and I'll just shut up about 
it.

El lunes, 13 de septiembre de 2021 a las 19:22:37 UTC+2, Rudi Hammad 
escribió:

> It was still kind in the context of encrypting a maya scene that derived 
> from the main V Crypt topic, but we'll do.
> El lunes, 13 de septiembre de 2021 a las 19:07:28 UTC+2, 
> justin...@gmail.com escribió:
>
>> Please make sure to start a new thread if you want to engage in new 
>> topics. It seems two completely new questions have been asked since the 
>> original thread was started about V Crypt, and are entirely unrelated. 
>> Thanks! 
>>
>> On Tue, 14 Sep 2021, 4:25 am Rudi Hammad,  wrote:
>>
>>> That's it! thanks Juan
>>>
>>> El lunes, 13 de septiembre de 2021 a las 15:33:57 UTC+2, Juan Moraga 
>>> escribió:
>>>
 Try using "def onOpenCallBack(*args):" instead. 
 Callbacks may pass on arguments to you method, which you can use or 
 not. But you need to allow the function to receive these arguments, 
 otherwise it will raise an exception.


 On Mon, 13 Sep 2021, 15:09 Rudi Hammad,  wrote:

> Hello,
> any idea why this is not working?
> I opened a scene and created this callback, and then saved the scene
>
> def onOpenCallBack():
>print "this is a test"
>
> checkCallback = 
> OpenMaya.MSceneMessage.addCheckCallback(OpenMaya.MSceneMessage.kBeforeOpenCheck,
>  
> onOpenCallBack)
>
> Now when I open the scene I get this error:
> # TypeError: onOpenCallBack() takes no arguments (2 given) // 
> // Warning: line 0: Python callback failed // 
>
> but I didn't give any arguments. Why is it saying given 2? are they 
> *args and **kwargs? Still, any idea why this is not working?
> Thanks
>
> El lunes, 6 de septiembre de 2021 a las 22:23:04 UTC+2, Rudi Hammad 
> escribió:
>
>> oh, about the screenshots. If the rig is encapsulated in a black box, 
>> maybe it would be possible set a callback preventing from unlocking the 
>> blackbox?
>> That way you can check want is inside and take screenshot.
>>
>> El lunes, 6 de septiembre de 2021 a las 22:02:29 UTC+2, Rudi Hammad 
>> escribió:
>>
>>> Quick question, I haven't use mel in 4 years now so it is probably 
>>> something foolish but why is this not working?
>>>
>>> string $toEval = "def foo():import uuid; macAddress = 
>>> uuid.getnode(); return macAddress; foo()";
>>> string $macAddress = python($toEval);
>>> print $x;
>>>
>>> I would expect $x to print my computer mac address by it is empty.
>>>
>>> El lunes, 6 de septiembre de 2021 a las 15:39:02 UTC+2, 
>>> golu...@gmail.com escribió:
>>>
 Marcus, thanks for your comment!

 When I talked about export I meant not to ma or mb, I meant for 
 example to alembic or other,  because as I knew alembic export is like 
 a 
 separate plugin, and .correct me if I am wrong export to alembic will 
 be 
 ignored by this callback.

 I've not understood you, sorry, yes it is already protected, but if 
 this protected scene to /myrig.mb will be referenced in the main 
 scene, 
 during the main parent scene opening, I will need to decrypt my rig.mb 
 and 
 any other child scene which is referenced and send to a remote worker,
 or I understand you wrong)

 About RAM I'm sorry, that's my mistake, later edited the message, 
 but was too late, you absolutely right!

 понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson: 

> The part of Maya that does the serialisation to ma and mb - be it 
> via export or save - is a singular point of access. The scene 
> callbacks 
> should account for all ways in which creating those is possible, 
> including 
> via Python and MEL. It wouldn’t 

Re: [Maya-Python] V Crypt System

[Rudi Hammad]

It was still kind in the context of encrypting a maya scene that derived 
from the main V Crypt topic, but we'll do.
El lunes, 13 de septiembre de 2021 a las 19:07:28 UTC+2, 
justin...@gmail.com escribió:

> Please make sure to start a new thread if you want to engage in new 
> topics. It seems two completely new questions have been asked since the 
> original thread was started about V Crypt, and are entirely unrelated. 
> Thanks! 
>
> On Tue, 14 Sep 2021, 4:25 am Rudi Hammad,  wrote:
>
>> That's it! thanks Juan
>>
>> El lunes, 13 de septiembre de 2021 a las 15:33:57 UTC+2, Juan Moraga 
>> escribió:
>>
>>> Try using "def onOpenCallBack(*args):" instead. 
>>> Callbacks may pass on arguments to you method, which you can use or not. 
>>> But you need to allow the function to receive these arguments, otherwise it 
>>> will raise an exception.
>>>
>>>
>>> On Mon, 13 Sep 2021, 15:09 Rudi Hammad,  wrote:
>>>
 Hello,
 any idea why this is not working?
 I opened a scene and created this callback, and then saved the scene

 def onOpenCallBack():
print "this is a test"

 checkCallback = 
 OpenMaya.MSceneMessage.addCheckCallback(OpenMaya.MSceneMessage.kBeforeOpenCheck,
  
 onOpenCallBack)

 Now when I open the scene I get this error:
 # TypeError: onOpenCallBack() takes no arguments (2 given) // 
 // Warning: line 0: Python callback failed // 

 but I didn't give any arguments. Why is it saying given 2? are they 
 *args and **kwargs? Still, any idea why this is not working?
 Thanks

 El lunes, 6 de septiembre de 2021 a las 22:23:04 UTC+2, Rudi Hammad 
 escribió:

> oh, about the screenshots. If the rig is encapsulated in a black box, 
> maybe it would be possible set a callback preventing from unlocking the 
> blackbox?
> That way you can check want is inside and take screenshot.
>
> El lunes, 6 de septiembre de 2021 a las 22:02:29 UTC+2, Rudi Hammad 
> escribió:
>
>> Quick question, I haven't use mel in 4 years now so it is probably 
>> something foolish but why is this not working?
>>
>> string $toEval = "def foo():import uuid; macAddress = uuid.getnode(); 
>> return macAddress; foo()";
>> string $macAddress = python($toEval);
>> print $x;
>>
>> I would expect $x to print my computer mac address by it is empty.
>>
>> El lunes, 6 de septiembre de 2021 a las 15:39:02 UTC+2, 
>> golu...@gmail.com escribió:
>>
>>> Marcus, thanks for your comment!
>>>
>>> When I talked about export I meant not to ma or mb, I meant for 
>>> example to alembic or other,  because as I knew alembic export is like 
>>> a 
>>> separate plugin, and .correct me if I am wrong export to alembic will 
>>> be 
>>> ignored by this callback.
>>>
>>> I've not understood you, sorry, yes it is already protected, but if 
>>> this protected scene to /myrig.mb will be referenced in the main scene, 
>>> during the main parent scene opening, I will need to decrypt my rig.mb 
>>> and 
>>> any other child scene which is referenced and send to a remote worker,
>>> or I understand you wrong)
>>>
>>> About RAM I'm sorry, that's my mistake, later edited the message, 
>>> but was too late, you absolutely right!
>>>
>>> понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson: 
>>>
 The part of Maya that does the serialisation to ma and mb - be it 
 via export or save - is a singular point of access. The scene 
 callbacks 
 should account for all ways in which creating those is possible, 
 including 
 via Python and MEL. It wouldn’t account for manual export to other 
 formats, 
 but there’s no end to that. Screenshotting your viewport is a format 
 too, 
 albeit a lossy one. But I’d argue that depending on what you want to 
 protect, if that is rigs and animation, the Maya scene format should 
 be 
 enough.

- OpenMaya.MSceneMessage.addCheckCallback() 

 
  

 And all of it must be done recursively on the whole data tree in 
 scene

 I’d argue not. The information you protect is the information in 
 the scene file. If that scene file consists of an absolute path to 
 e.g. 
 c:\myassets\myrig.mb then that is *already* protected; nobody can 
 access that file but you on your local machine.

 so at some point how to handle your RAM memory, because you can’t 
 store this encrypted data somewhere…)

 I’d argue not (again :)). Is it to protect against hacker-animators 
 and hacker-riggers? Or against 

Re: [Maya-Python] V Crypt System

[Reza Aarabi]

agreed!

On Mon, Sep 13, 2021 at 10:07 AM Justin Israel 
wrote:

> Please make sure to start a new thread if you want to engage in new
> topics. It seems two completely new questions have been asked since the
> original thread was started about V Crypt, and are entirely unrelated.
> Thanks!
>
> On Tue, 14 Sep 2021, 4:25 am Rudi Hammad,  wrote:
>
>> That's it! thanks Juan
>>
>> El lunes, 13 de septiembre de 2021 a las 15:33:57 UTC+2, Juan Moraga
>> escribió:
>>
>>> Try using "def onOpenCallBack(*args):" instead.
>>> Callbacks may pass on arguments to you method, which you can use or not.
>>> But you need to allow the function to receive these arguments, otherwise it
>>> will raise an exception.
>>>
>>>
>>> On Mon, 13 Sep 2021, 15:09 Rudi Hammad,  wrote:
>>>
 Hello,
 any idea why this is not working?
 I opened a scene and created this callback, and then saved the scene

 def onOpenCallBack():
print "this is a test"

 checkCallback =
 OpenMaya.MSceneMessage.addCheckCallback(OpenMaya.MSceneMessage.kBeforeOpenCheck,
 onOpenCallBack)

 Now when I open the scene I get this error:
 # TypeError: onOpenCallBack() takes no arguments (2 given) //
 // Warning: line 0: Python callback failed //

 but I didn't give any arguments. Why is it saying given 2? are they
 *args and **kwargs? Still, any idea why this is not working?
 Thanks

 El lunes, 6 de septiembre de 2021 a las 22:23:04 UTC+2, Rudi Hammad
 escribió:

> oh, about the screenshots. If the rig is encapsulated in a black box,
> maybe it would be possible set a callback preventing from unlocking the
> blackbox?
> That way you can check want is inside and take screenshot.
>
> El lunes, 6 de septiembre de 2021 a las 22:02:29 UTC+2, Rudi Hammad
> escribió:
>
>> Quick question, I haven't use mel in 4 years now so it is probably
>> something foolish but why is this not working?
>>
>> string $toEval = "def foo():import uuid; macAddress = uuid.getnode();
>> return macAddress; foo()";
>> string $macAddress = python($toEval);
>> print $x;
>>
>> I would expect $x to print my computer mac address by it is empty.
>>
>> El lunes, 6 de septiembre de 2021 a las 15:39:02 UTC+2,
>> golu...@gmail.com escribió:
>>
>>> Marcus, thanks for your comment!
>>>
>>> When I talked about export I meant not to ma or mb, I meant for
>>> example to alembic or other,  because as I knew alembic export is like a
>>> separate plugin, and .correct me if I am wrong export to alembic will be
>>> ignored by this callback.
>>>
>>> I've not understood you, sorry, yes it is already protected, but if
>>> this protected scene to /myrig.mb will be referenced in the main scene,
>>> during the main parent scene opening, I will need to decrypt my rig.mb 
>>> and
>>> any other child scene which is referenced and send to a remote worker,
>>> or I understand you wrong)
>>>
>>> About RAM I'm sorry, that's my mistake, later edited the message,
>>> but was too late, you absolutely right!
>>>
>>> понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson:
>>>
 The part of Maya that does the serialisation to ma and mb - be it
 via export or save - is a singular point of access. The scene callbacks
 should account for all ways in which creating those is possible, 
 including
 via Python and MEL. It wouldn’t account for manual export to other 
 formats,
 but there’s no end to that. Screenshotting your viewport is a format 
 too,
 albeit a lossy one. But I’d argue that depending on what you want to
 protect, if that is rigs and animation, the Maya scene format should be
 enough.

- OpenMaya.MSceneMessage.addCheckCallback()

 

 And all of it must be done recursively on the whole data tree in
 scene

 I’d argue not. The information you protect is the information in
 the scene file. If that scene file consists of an absolute path to e.g.
 c:\myassets\myrig.mb then that is *already* protected; nobody can
 access that file but you on your local machine.

 so at some point how to handle your RAM memory, because you can’t
 store this encrypted data somewhere…)

 I’d argue not (again :)). Is it to protect against hacker-animators
 and hacker-riggers? Or against the general workforce that has no clue 
 about
 callbacks and encryption? If the latter, then saving it into a temp
 directory first, and encrypting it after should suffice. To the user, 
 the
 file would 

Re: [Maya-Python] V Crypt System

[Justin Israel]

Please make sure to start a new thread if you want to engage in new topics.
It seems two completely new questions have been asked since the original
thread was started about V Crypt, and are entirely unrelated. Thanks!

On Tue, 14 Sep 2021, 4:25 am Rudi Hammad,  wrote:

> That's it! thanks Juan
>
> El lunes, 13 de septiembre de 2021 a las 15:33:57 UTC+2, Juan Moraga
> escribió:
>
>> Try using "def onOpenCallBack(*args):" instead.
>> Callbacks may pass on arguments to you method, which you can use or not.
>> But you need to allow the function to receive these arguments, otherwise it
>> will raise an exception.
>>
>>
>> On Mon, 13 Sep 2021, 15:09 Rudi Hammad,  wrote:
>>
>>> Hello,
>>> any idea why this is not working?
>>> I opened a scene and created this callback, and then saved the scene
>>>
>>> def onOpenCallBack():
>>>print "this is a test"
>>>
>>> checkCallback =
>>> OpenMaya.MSceneMessage.addCheckCallback(OpenMaya.MSceneMessage.kBeforeOpenCheck,
>>> onOpenCallBack)
>>>
>>> Now when I open the scene I get this error:
>>> # TypeError: onOpenCallBack() takes no arguments (2 given) //
>>> // Warning: line 0: Python callback failed //
>>>
>>> but I didn't give any arguments. Why is it saying given 2? are they
>>> *args and **kwargs? Still, any idea why this is not working?
>>> Thanks
>>>
>>> El lunes, 6 de septiembre de 2021 a las 22:23:04 UTC+2, Rudi Hammad
>>> escribió:
>>>
 oh, about the screenshots. If the rig is encapsulated in a black box,
 maybe it would be possible set a callback preventing from unlocking the
 blackbox?
 That way you can check want is inside and take screenshot.

 El lunes, 6 de septiembre de 2021 a las 22:02:29 UTC+2, Rudi Hammad
 escribió:

> Quick question, I haven't use mel in 4 years now so it is probably
> something foolish but why is this not working?
>
> string $toEval = "def foo():import uuid; macAddress = uuid.getnode();
> return macAddress; foo()";
> string $macAddress = python($toEval);
> print $x;
>
> I would expect $x to print my computer mac address by it is empty.
>
> El lunes, 6 de septiembre de 2021 a las 15:39:02 UTC+2,
> golu...@gmail.com escribió:
>
>> Marcus, thanks for your comment!
>>
>> When I talked about export I meant not to ma or mb, I meant for
>> example to alembic or other,  because as I knew alembic export is like a
>> separate plugin, and .correct me if I am wrong export to alembic will be
>> ignored by this callback.
>>
>> I've not understood you, sorry, yes it is already protected, but if
>> this protected scene to /myrig.mb will be referenced in the main scene,
>> during the main parent scene opening, I will need to decrypt my rig.mb 
>> and
>> any other child scene which is referenced and send to a remote worker,
>> or I understand you wrong)
>>
>> About RAM I'm sorry, that's my mistake, later edited the message, but
>> was too late, you absolutely right!
>>
>> понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson:
>>
>>> The part of Maya that does the serialisation to ma and mb - be it
>>> via export or save - is a singular point of access. The scene callbacks
>>> should account for all ways in which creating those is possible, 
>>> including
>>> via Python and MEL. It wouldn’t account for manual export to other 
>>> formats,
>>> but there’s no end to that. Screenshotting your viewport is a format 
>>> too,
>>> albeit a lossy one. But I’d argue that depending on what you want to
>>> protect, if that is rigs and animation, the Maya scene format should be
>>> enough.
>>>
>>>- OpenMaya.MSceneMessage.addCheckCallback()
>>>
>>> 
>>>
>>> And all of it must be done recursively on the whole data tree in
>>> scene
>>>
>>> I’d argue not. The information you protect is the information in the
>>> scene file. If that scene file consists of an absolute path to e.g.
>>> c:\myassets\myrig.mb then that is *already* protected; nobody can
>>> access that file but you on your local machine.
>>>
>>> so at some point how to handle your RAM memory, because you can’t
>>> store this encrypted data somewhere…)
>>>
>>> I’d argue not (again :)). Is it to protect against hacker-animators
>>> and hacker-riggers? Or against the general workforce that has no clue 
>>> about
>>> callbacks and encryption? If the latter, then saving it into a temp
>>> directory first, and encrypting it after should suffice. To the user, 
>>> the
>>> file would end up where they said it should. But really, it’s a 
>>> different
>>> file altogether. Then that file is copied back into a temp directory and
>>> decrypted whenever they 

Re: [Maya-Python] V Crypt System

[Rudi Hammad]

That's it! thanks Juan

El lunes, 13 de septiembre de 2021 a las 15:33:57 UTC+2, Juan Moraga 
escribió:

> Try using "def onOpenCallBack(*args):" instead. 
> Callbacks may pass on arguments to you method, which you can use or not. 
> But you need to allow the function to receive these arguments, otherwise it 
> will raise an exception.
>
>
> On Mon, 13 Sep 2021, 15:09 Rudi Hammad,  wrote:
>
>> Hello,
>> any idea why this is not working?
>> I opened a scene and created this callback, and then saved the scene
>>
>> def onOpenCallBack():
>>print "this is a test"
>>
>> checkCallback = 
>> OpenMaya.MSceneMessage.addCheckCallback(OpenMaya.MSceneMessage.kBeforeOpenCheck,
>>  
>> onOpenCallBack)
>>
>> Now when I open the scene I get this error:
>> # TypeError: onOpenCallBack() takes no arguments (2 given) // 
>> // Warning: line 0: Python callback failed // 
>>
>> but I didn't give any arguments. Why is it saying given 2? are they *args 
>> and **kwargs? Still, any idea why this is not working?
>> Thanks
>>
>> El lunes, 6 de septiembre de 2021 a las 22:23:04 UTC+2, Rudi Hammad 
>> escribió:
>>
>>> oh, about the screenshots. If the rig is encapsulated in a black box, 
>>> maybe it would be possible set a callback preventing from unlocking the 
>>> blackbox?
>>> That way you can check want is inside and take screenshot.
>>>
>>> El lunes, 6 de septiembre de 2021 a las 22:02:29 UTC+2, Rudi Hammad 
>>> escribió:
>>>
 Quick question, I haven't use mel in 4 years now so it is probably 
 something foolish but why is this not working?

 string $toEval = "def foo():import uuid; macAddress = uuid.getnode(); 
 return macAddress; foo()";
 string $macAddress = python($toEval);
 print $x;

 I would expect $x to print my computer mac address by it is empty.

 El lunes, 6 de septiembre de 2021 a las 15:39:02 UTC+2, 
 golu...@gmail.com escribió:

> Marcus, thanks for your comment!
>
> When I talked about export I meant not to ma or mb, I meant for 
> example to alembic or other,  because as I knew alembic export is like a 
> separate plugin, and .correct me if I am wrong export to alembic will be 
> ignored by this callback.
>
> I've not understood you, sorry, yes it is already protected, but if 
> this protected scene to /myrig.mb will be referenced in the main scene, 
> during the main parent scene opening, I will need to decrypt my rig.mb 
> and 
> any other child scene which is referenced and send to a remote worker,
> or I understand you wrong)
>
> About RAM I'm sorry, that's my mistake, later edited the message, but 
> was too late, you absolutely right!
>
> понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson: 
>
>> The part of Maya that does the serialisation to ma and mb - be it via 
>> export or save - is a singular point of access. The scene callbacks 
>> should 
>> account for all ways in which creating those is possible, including via 
>> Python and MEL. It wouldn’t account for manual export to other formats, 
>> but 
>> there’s no end to that. Screenshotting your viewport is a format too, 
>> albeit a lossy one. But I’d argue that depending on what you want to 
>> protect, if that is rigs and animation, the Maya scene format should be 
>> enough.
>>
>>- OpenMaya.MSceneMessage.addCheckCallback() 
>>
>> 
>>  
>>
>> And all of it must be done recursively on the whole data tree in scene
>>
>> I’d argue not. The information you protect is the information in the 
>> scene file. If that scene file consists of an absolute path to e.g. 
>> c:\myassets\myrig.mb then that is *already* protected; nobody can 
>> access that file but you on your local machine.
>>
>> so at some point how to handle your RAM memory, because you can’t 
>> store this encrypted data somewhere…)
>>
>> I’d argue not (again :)). Is it to protect against hacker-animators 
>> and hacker-riggers? Or against the general workforce that has no clue 
>> about 
>> callbacks and encryption? If the latter, then saving it into a temp 
>> directory first, and encrypting it after should suffice. To the user, 
>> the 
>> file would end up where they said it should. But really, it’s a 
>> different 
>> file altogether. Then that file is copied back into a temp directory and 
>> decrypted whenever they open it. All of that can happen on disk.
>>
>> And besides, memory is just another location. A motivated-enough 
>> hacker-animator could access RAM as easily as any location on disk. 
>> Doesn’t 
>> increase the level of protection.
>>
>> On Mon, 6 Sept 2021 at 11:02, Andrew Golubev  
>> wrote:
>>
>>> It is 

Re: [Maya-Python] V Crypt System

[Juan Moraga]

Try using "def onOpenCallBack(*args):" instead.
Callbacks may pass on arguments to you method, which you can use or not.
But you need to allow the function to receive these arguments, otherwise it
will raise an exception.


On Mon, 13 Sep 2021, 15:09 Rudi Hammad,  wrote:

> Hello,
> any idea why this is not working?
> I opened a scene and created this callback, and then saved the scene
>
> def onOpenCallBack():
>print "this is a test"
>
> checkCallback =
> OpenMaya.MSceneMessage.addCheckCallback(OpenMaya.MSceneMessage.kBeforeOpenCheck,
> onOpenCallBack)
>
> Now when I open the scene I get this error:
> # TypeError: onOpenCallBack() takes no arguments (2 given) //
> // Warning: line 0: Python callback failed //
>
> but I didn't give any arguments. Why is it saying given 2? are they *args
> and **kwargs? Still, any idea why this is not working?
> Thanks
>
> El lunes, 6 de septiembre de 2021 a las 22:23:04 UTC+2, Rudi Hammad
> escribió:
>
>> oh, about the screenshots. If the rig is encapsulated in a black box,
>> maybe it would be possible set a callback preventing from unlocking the
>> blackbox?
>> That way you can check want is inside and take screenshot.
>>
>> El lunes, 6 de septiembre de 2021 a las 22:02:29 UTC+2, Rudi Hammad
>> escribió:
>>
>>> Quick question, I haven't use mel in 4 years now so it is probably
>>> something foolish but why is this not working?
>>>
>>> string $toEval = "def foo():import uuid; macAddress = uuid.getnode();
>>> return macAddress; foo()";
>>> string $macAddress = python($toEval);
>>> print $x;
>>>
>>> I would expect $x to print my computer mac address by it is empty.
>>>
>>> El lunes, 6 de septiembre de 2021 a las 15:39:02 UTC+2,
>>> golu...@gmail.com escribió:
>>>
 Marcus, thanks for your comment!

 When I talked about export I meant not to ma or mb, I meant for example
 to alembic or other,  because as I knew alembic export is like a separate
 plugin, and .correct me if I am wrong export to alembic will be ignored by
 this callback.

 I've not understood you, sorry, yes it is already protected, but if
 this protected scene to /myrig.mb will be referenced in the main scene,
 during the main parent scene opening, I will need to decrypt my rig.mb and
 any other child scene which is referenced and send to a remote worker,
 or I understand you wrong)

 About RAM I'm sorry, that's my mistake, later edited the message, but
 was too late, you absolutely right!

 понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson:

> The part of Maya that does the serialisation to ma and mb - be it via
> export or save - is a singular point of access. The scene callbacks should
> account for all ways in which creating those is possible, including via
> Python and MEL. It wouldn’t account for manual export to other formats, 
> but
> there’s no end to that. Screenshotting your viewport is a format too,
> albeit a lossy one. But I’d argue that depending on what you want to
> protect, if that is rigs and animation, the Maya scene format should be
> enough.
>
>- OpenMaya.MSceneMessage.addCheckCallback()
>
> 
>
> And all of it must be done recursively on the whole data tree in scene
>
> I’d argue not. The information you protect is the information in the
> scene file. If that scene file consists of an absolute path to e.g.
> c:\myassets\myrig.mb then that is *already* protected; nobody can
> access that file but you on your local machine.
>
> so at some point how to handle your RAM memory, because you can’t
> store this encrypted data somewhere…)
>
> I’d argue not (again :)). Is it to protect against hacker-animators
> and hacker-riggers? Or against the general workforce that has no clue 
> about
> callbacks and encryption? If the latter, then saving it into a temp
> directory first, and encrypting it after should suffice. To the user, the
> file would end up where they said it should. But really, it’s a different
> file altogether. Then that file is copied back into a temp directory and
> decrypted whenever they open it. All of that can happen on disk.
>
> And besides, memory is just another location. A motivated-enough
> hacker-animator could access RAM as easily as any location on disk. 
> Doesn’t
> increase the level of protection.
>
> On Mon, 6 Sept 2021 at 11:02, Andrew Golubev 
> wrote:
>
>> It is a very interesting discussion.
>>
>> Yeah, I will agree that it definitely must be invisible - so artists
>> don't even know that encryption happened.
>> But you can't stop on scene saving and loading, you should create
>> lots of workarounds in this "secure Maya client".
>> Somehow 

Re: [Maya-Python] V Crypt System

[Rudi Hammad]

Hello,
any idea why this is not working?
I opened a scene and created this callback, and then saved the scene

def onOpenCallBack():
   print "this is a test"

checkCallback = 
OpenMaya.MSceneMessage.addCheckCallback(OpenMaya.MSceneMessage.kBeforeOpenCheck,
 
onOpenCallBack)

Now when I open the scene I get this error:
# TypeError: onOpenCallBack() takes no arguments (2 given) // 
// Warning: line 0: Python callback failed // 

but I didn't give any arguments. Why is it saying given 2? are they *args 
and **kwargs? Still, any idea why this is not working?
Thanks

El lunes, 6 de septiembre de 2021 a las 22:23:04 UTC+2, Rudi Hammad 
escribió:

> oh, about the screenshots. If the rig is encapsulated in a black box, 
> maybe it would be possible set a callback preventing from unlocking the 
> blackbox?
> That way you can check want is inside and take screenshot.
>
> El lunes, 6 de septiembre de 2021 a las 22:02:29 UTC+2, Rudi Hammad 
> escribió:
>
>> Quick question, I haven't use mel in 4 years now so it is probably 
>> something foolish but why is this not working?
>>
>> string $toEval = "def foo():import uuid; macAddress = uuid.getnode(); 
>> return macAddress; foo()";
>> string $macAddress = python($toEval);
>> print $x;
>>
>> I would expect $x to print my computer mac address by it is empty.
>>
>> El lunes, 6 de septiembre de 2021 a las 15:39:02 UTC+2, golu...@gmail.com 
>> escribió:
>>
>>> Marcus, thanks for your comment!
>>>
>>> When I talked about export I meant not to ma or mb, I meant for example 
>>> to alembic or other,  because as I knew alembic export is like a separate 
>>> plugin, and .correct me if I am wrong export to alembic will be ignored by 
>>> this callback.
>>>
>>> I've not understood you, sorry, yes it is already protected, but if this 
>>> protected scene to /myrig.mb will be referenced in the main scene, during 
>>> the main parent scene opening, I will need to decrypt my rig.mb and any 
>>> other child scene which is referenced and send to a remote worker,
>>> or I understand you wrong)
>>>
>>> About RAM I'm sorry, that's my mistake, later edited the message, but 
>>> was too late, you absolutely right!
>>>
>>> понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson: 
>>>
 The part of Maya that does the serialisation to ma and mb - be it via 
 export or save - is a singular point of access. The scene callbacks should 
 account for all ways in which creating those is possible, including via 
 Python and MEL. It wouldn’t account for manual export to other formats, 
 but 
 there’s no end to that. Screenshotting your viewport is a format too, 
 albeit a lossy one. But I’d argue that depending on what you want to 
 protect, if that is rigs and animation, the Maya scene format should be 
 enough.

- OpenMaya.MSceneMessage.addCheckCallback() 

 
  

 And all of it must be done recursively on the whole data tree in scene

 I’d argue not. The information you protect is the information in the 
 scene file. If that scene file consists of an absolute path to e.g. 
 c:\myassets\myrig.mb then that is *already* protected; nobody can 
 access that file but you on your local machine.

 so at some point how to handle your RAM memory, because you can’t store 
 this encrypted data somewhere…)

 I’d argue not (again :)). Is it to protect against hacker-animators and 
 hacker-riggers? Or against the general workforce that has no clue about 
 callbacks and encryption? If the latter, then saving it into a temp 
 directory first, and encrypting it after should suffice. To the user, the 
 file would end up where they said it should. But really, it’s a different 
 file altogether. Then that file is copied back into a temp directory and 
 decrypted whenever they open it. All of that can happen on disk.

 And besides, memory is just another location. A motivated-enough 
 hacker-animator could access RAM as easily as any location on disk. 
 Doesn’t 
 increase the level of protection.

 On Mon, 6 Sept 2021 at 11:02, Andrew Golubev  wrote:

> It is a very interesting discussion.  
>
> Yeah, I will agree that it definitely must be invisible - so artists 
> don't even know that encryption happened.
> But you can't stop on scene saving and loading, you should create lots 
> of workarounds in this "secure Maya client".
> Somehow you need to lock any exporting of data inside in any format, 
> hide\lock\encrypt code of all used inside scripts, lock any new plugin 
> loading\or current plugins disabling. 
> And lock script editor, or make some sort of interceptor, to ensure, 
> that no script will run to export or explore private scene data. 
> Also, if I 

Re: [Maya-Python] V Crypt System

[Rudi Hammad]

oh, about the screenshots. If the rig is encapsulated in a black box, maybe 
it would be possible set a callback preventing from unlocking the blackbox?
That way you can check want is inside and take screenshot.

El lunes, 6 de septiembre de 2021 a las 22:02:29 UTC+2, Rudi Hammad 
escribió:

> Quick question, I haven't use mel in 4 years now so it is probably 
> something foolish but why is this not working?
>
> string $toEval = "def foo():import uuid; macAddress = uuid.getnode(); 
> return macAddress; foo()";
> string $macAddress = python($toEval);
> print $x;
>
> I would expect $x to print my computer mac address by it is empty.
>
> El lunes, 6 de septiembre de 2021 a las 15:39:02 UTC+2, golu...@gmail.com 
> escribió:
>
>> Marcus, thanks for your comment!
>>
>> When I talked about export I meant not to ma or mb, I meant for example 
>> to alembic or other,  because as I knew alembic export is like a separate 
>> plugin, and .correct me if I am wrong export to alembic will be ignored by 
>> this callback.
>>
>> I've not understood you, sorry, yes it is already protected, but if this 
>> protected scene to /myrig.mb will be referenced in the main scene, during 
>> the main parent scene opening, I will need to decrypt my rig.mb and any 
>> other child scene which is referenced and send to a remote worker,
>> or I understand you wrong)
>>
>> About RAM I'm sorry, that's my mistake, later edited the message, but was 
>> too late, you absolutely right!
>>
>> понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson: 
>>
>>> The part of Maya that does the serialisation to ma and mb - be it via 
>>> export or save - is a singular point of access. The scene callbacks should 
>>> account for all ways in which creating those is possible, including via 
>>> Python and MEL. It wouldn’t account for manual export to other formats, but 
>>> there’s no end to that. Screenshotting your viewport is a format too, 
>>> albeit a lossy one. But I’d argue that depending on what you want to 
>>> protect, if that is rigs and animation, the Maya scene format should be 
>>> enough.
>>>
>>>- OpenMaya.MSceneMessage.addCheckCallback() 
>>>
>>> 
>>>  
>>>
>>> And all of it must be done recursively on the whole data tree in scene
>>>
>>> I’d argue not. The information you protect is the information in the 
>>> scene file. If that scene file consists of an absolute path to e.g. 
>>> c:\myassets\myrig.mb then that is *already* protected; nobody can 
>>> access that file but you on your local machine.
>>>
>>> so at some point how to handle your RAM memory, because you can’t store 
>>> this encrypted data somewhere…)
>>>
>>> I’d argue not (again :)). Is it to protect against hacker-animators and 
>>> hacker-riggers? Or against the general workforce that has no clue about 
>>> callbacks and encryption? If the latter, then saving it into a temp 
>>> directory first, and encrypting it after should suffice. To the user, the 
>>> file would end up where they said it should. But really, it’s a different 
>>> file altogether. Then that file is copied back into a temp directory and 
>>> decrypted whenever they open it. All of that can happen on disk.
>>>
>>> And besides, memory is just another location. A motivated-enough 
>>> hacker-animator could access RAM as easily as any location on disk. Doesn’t 
>>> increase the level of protection.
>>>
>>> On Mon, 6 Sept 2021 at 11:02, Andrew Golubev  wrote:
>>>
 It is a very interesting discussion.  

 Yeah, I will agree that it definitely must be invisible - so artists 
 don't even know that encryption happened.
 But you can't stop on scene saving and loading, you should create lots 
 of workarounds in this "secure Maya client".
 Somehow you need to lock any exporting of data inside in any format, 
 hide\lock\encrypt code of all used inside scripts, lock any new plugin 
 loading\or current plugins disabling. 
 And lock script editor, or make some sort of interceptor, to ensure, 
 that no script will run to export or explore private scene data. 
 Also, if I understand all correctly, it will give a lot of restrictions 
 for people who work with their tools(it will lock them on the layout of 
 instruments you gave to them).

 And this only stuff that comes up to mind immediately, I think during 
 the development of such Maya launch wrapper lot's of underwater stones 
 will 
 come up eventually.

 Additionally, if in your scene you will have references, during 
 reference load you will need to decrypt this data,
 the same will go to any geometry\textures or any files - you will need 
 to decrypt on the run.
 All of it must be done recursively on the whole data tree in scene,
 so at some point how to handle your RAM memory, because you can't store 
 

Re: [Maya-Python] V Crypt System

[Rudi Hammad]

Quick question, I haven't use mel in 4 years now so it is probably 
something foolish but why is this not working?

string $toEval = "def foo():import uuid; macAddress = uuid.getnode(); 
return macAddress; foo()";
string $macAddress = python($toEval);
print $x;

I would expect $x to print my computer mac address by it is empty.

El lunes, 6 de septiembre de 2021 a las 15:39:02 UTC+2, golu...@gmail.com 
escribió:

> Marcus, thanks for your comment!
>
> When I talked about export I meant not to ma or mb, I meant for example to 
> alembic or other,  because as I knew alembic export is like a separate 
> plugin, and .correct me if I am wrong export to alembic will be ignored by 
> this callback.
>
> I've not understood you, sorry, yes it is already protected, but if this 
> protected scene to /myrig.mb will be referenced in the main scene, during 
> the main parent scene opening, I will need to decrypt my rig.mb and any 
> other child scene which is referenced and send to a remote worker,
> or I understand you wrong)
>
> About RAM I'm sorry, that's my mistake, later edited the message, but was 
> too late, you absolutely right!
>
> понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson: 
>
>> The part of Maya that does the serialisation to ma and mb - be it via 
>> export or save - is a singular point of access. The scene callbacks should 
>> account for all ways in which creating those is possible, including via 
>> Python and MEL. It wouldn’t account for manual export to other formats, but 
>> there’s no end to that. Screenshotting your viewport is a format too, 
>> albeit a lossy one. But I’d argue that depending on what you want to 
>> protect, if that is rigs and animation, the Maya scene format should be 
>> enough.
>>
>>- OpenMaya.MSceneMessage.addCheckCallback() 
>>
>> 
>>  
>>
>> And all of it must be done recursively on the whole data tree in scene
>>
>> I’d argue not. The information you protect is the information in the 
>> scene file. If that scene file consists of an absolute path to e.g. 
>> c:\myassets\myrig.mb then that is *already* protected; nobody can access 
>> that file but you on your local machine.
>>
>> so at some point how to handle your RAM memory, because you can’t store 
>> this encrypted data somewhere…)
>>
>> I’d argue not (again :)). Is it to protect against hacker-animators and 
>> hacker-riggers? Or against the general workforce that has no clue about 
>> callbacks and encryption? If the latter, then saving it into a temp 
>> directory first, and encrypting it after should suffice. To the user, the 
>> file would end up where they said it should. But really, it’s a different 
>> file altogether. Then that file is copied back into a temp directory and 
>> decrypted whenever they open it. All of that can happen on disk.
>>
>> And besides, memory is just another location. A motivated-enough 
>> hacker-animator could access RAM as easily as any location on disk. Doesn’t 
>> increase the level of protection.
>>
>> On Mon, 6 Sept 2021 at 11:02, Andrew Golubev  wrote:
>>
>>> It is a very interesting discussion.  
>>>
>>> Yeah, I will agree that it definitely must be invisible - so artists 
>>> don't even know that encryption happened.
>>> But you can't stop on scene saving and loading, you should create lots 
>>> of workarounds in this "secure Maya client".
>>> Somehow you need to lock any exporting of data inside in any format, 
>>> hide\lock\encrypt code of all used inside scripts, lock any new plugin 
>>> loading\or current plugins disabling. 
>>> And lock script editor, or make some sort of interceptor, to ensure, 
>>> that no script will run to export or explore private scene data. 
>>> Also, if I understand all correctly, it will give a lot of restrictions 
>>> for people who work with their tools(it will lock them on the layout of 
>>> instruments you gave to them).
>>>
>>> And this only stuff that comes up to mind immediately, I think during 
>>> the development of such Maya launch wrapper lot's of underwater stones will 
>>> come up eventually.
>>>
>>> Additionally, if in your scene you will have references, during 
>>> reference load you will need to decrypt this data,
>>> the same will go to any geometry\textures or any files - you will need 
>>> to decrypt on the run.
>>> All of it must be done recursively on the whole data tree in scene,
>>> so at some point how to handle your RAM memory, because you can't store 
>>> this encrypted data somewhere.
>>>
>>> And even this will not save you from attempt to try take this decrypted 
>>> data from RAM...
>>> воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 
>>>
 I agree with you. This would not solve all problems with working 
 remotely, but it would solve some. Perhaps the biggest problems, namely 
 accidental sharing and theft. I have also 

Re: [Maya-Python] V Crypt System

[Andrew Golubev]

Marcus, thanks for your comment!

When I talked about export I meant not to ma or mb, I meant for example to 
alembic or other,  because as I knew alembic export is like a separate 
plugin, and .correct me if I am wrong export to alembic will be ignored by 
this callback.

I've not understood you, sorry, yes it is already protected, but if this 
protected scene to /myrig.mb will be referenced in the main scene, during 
the main parent scene opening, I will need to decrypt my rig.mb and any 
other child scene which is referenced and send to a remote worker,
or I understand you wrong)

About RAM I'm sorry, that's my mistake, later edited the message, but was 
too late, you absolutely right!

понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson: 

> The part of Maya that does the serialisation to ma and mb - be it via 
> export or save - is a singular point of access. The scene callbacks should 
> account for all ways in which creating those is possible, including via 
> Python and MEL. It wouldn’t account for manual export to other formats, but 
> there’s no end to that. Screenshotting your viewport is a format too, 
> albeit a lossy one. But I’d argue that depending on what you want to 
> protect, if that is rigs and animation, the Maya scene format should be 
> enough.
>
>- OpenMaya.MSceneMessage.addCheckCallback() 
>
> 
>  
>
> And all of it must be done recursively on the whole data tree in scene
>
> I’d argue not. The information you protect is the information in the scene 
> file. If that scene file consists of an absolute path to e.g. 
> c:\myassets\myrig.mb then that is *already* protected; nobody can access 
> that file but you on your local machine.
>
> so at some point how to handle your RAM memory, because you can’t store 
> this encrypted data somewhere…)
>
> I’d argue not (again :)). Is it to protect against hacker-animators and 
> hacker-riggers? Or against the general workforce that has no clue about 
> callbacks and encryption? If the latter, then saving it into a temp 
> directory first, and encrypting it after should suffice. To the user, the 
> file would end up where they said it should. But really, it’s a different 
> file altogether. Then that file is copied back into a temp directory and 
> decrypted whenever they open it. All of that can happen on disk.
>
> And besides, memory is just another location. A motivated-enough 
> hacker-animator could access RAM as easily as any location on disk. Doesn’t 
> increase the level of protection.
>
> On Mon, 6 Sept 2021 at 11:02, Andrew Golubev  wrote:
>
>> It is a very interesting discussion.  
>>
>> Yeah, I will agree that it definitely must be invisible - so artists 
>> don't even know that encryption happened.
>> But you can't stop on scene saving and loading, you should create lots of 
>> workarounds in this "secure Maya client".
>> Somehow you need to lock any exporting of data inside in any format, 
>> hide\lock\encrypt code of all used inside scripts, lock any new plugin 
>> loading\or current plugins disabling. 
>> And lock script editor, or make some sort of interceptor, to ensure, that 
>> no script will run to export or explore private scene data. 
>> Also, if I understand all correctly, it will give a lot of restrictions 
>> for people who work with their tools(it will lock them on the layout of 
>> instruments you gave to them).
>>
>> And this only stuff that comes up to mind immediately, I think during the 
>> development of such Maya launch wrapper lot's of underwater stones will 
>> come up eventually.
>>
>> Additionally, if in your scene you will have references, during reference 
>> load you will need to decrypt this data,
>> the same will go to any geometry\textures or any files - you will need to 
>> decrypt on the run.
>> All of it must be done recursively on the whole data tree in scene,
>> so at some point how to handle your RAM memory, because you can't store 
>> this encrypted data somewhere.
>>
>> And even this will not save you from attempt to try take this decrypted 
>> data from RAM...
>> воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 
>>
>>> I agree with you. This would not solve all problems with working 
>>> remotely, but it would solve some. Perhaps the biggest problems, namely 
>>> accidental sharing and theft. I have also personally received material from 
>>> artists at studios that really shouldn't have managed to leave the studio. 
>>> Some even have limited internet access with local browsers accessible only 
>>> through a virtual machine or local VNC connection, and assets *still* 
>>> manage to leave the premises.
>>>
>>> That not only puts the studio at risk, but the recipient too. Both as a 
>>> private person, as now your machine can leak confidential material, and as 
>>> another business. If a leak should happen that leads 

Re: [Maya-Python] V Crypt System

[Marcus Ottosson]

The part of Maya that does the serialisation to ma and mb - be it via
export or save - is a singular point of access. The scene callbacks should
account for all ways in which creating those is possible, including via
Python and MEL. It wouldn’t account for manual export to other formats, but
there’s no end to that. Screenshotting your viewport is a format too,
albeit a lossy one. But I’d argue that depending on what you want to
protect, if that is rigs and animation, the Maya scene format should be
enough.

   - OpenMaya.MSceneMessage.addCheckCallback()
   


And all of it must be done recursively on the whole data tree in scene

I’d argue not. The information you protect is the information in the scene
file. If that scene file consists of an absolute path to e.g.
c:\myassets\myrig.mb then that is *already* protected; nobody can access
that file but you on your local machine.

so at some point how to handle your RAM memory, because you can’t store
this encrypted data somewhere…)

I’d argue not (again :)). Is it to protect against hacker-animators and
hacker-riggers? Or against the general workforce that has no clue about
callbacks and encryption? If the latter, then saving it into a temp
directory first, and encrypting it after should suffice. To the user, the
file would end up where they said it should. But really, it’s a different
file altogether. Then that file is copied back into a temp directory and
decrypted whenever they open it. All of that can happen on disk.

And besides, memory is just another location. A motivated-enough
hacker-animator could access RAM as easily as any location on disk. Doesn’t
increase the level of protection.

On Mon, 6 Sept 2021 at 11:02, Andrew Golubev  wrote:

> It is a very interesting discussion.
>
> Yeah, I will agree that it definitely must be invisible - so artists don't
> even know that encryption happened.
> But you can't stop on scene saving and loading, you should create lots of
> workarounds in this "secure Maya client".
> Somehow you need to lock any exporting of data inside in any format,
> hide\lock\encrypt code of all used inside scripts, lock any new plugin
> loading\or current plugins disabling.
> And lock script editor, or make some sort of interceptor, to ensure, that
> no script will run to export or explore private scene data.
> Also, if I understand all correctly, it will give a lot of restrictions
> for people who work with their tools(it will lock them on the layout of
> instruments you gave to them).
>
> And this only stuff that comes up to mind immediately, I think during the
> development of such Maya launch wrapper lot's of underwater stones will
> come up eventually.
>
> Additionally, if in your scene you will have references, during reference
> load you will need to decrypt this data,
> the same will go to any geometry\textures or any files - you will need to
> decrypt on the run.
> All of it must be done recursively on the whole data tree in scene,
> so at some point how to handle your RAM memory, because you can't store
> this encrypted data somewhere.
>
> And even this will not save you from attempt to try take this decrypted
> data from RAM...
> воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson:
>
>> I agree with you. This would not solve all problems with working
>> remotely, but it would solve some. Perhaps the biggest problems, namely
>> accidental sharing and theft. I have also personally received material from
>> artists at studios that really shouldn't have managed to leave the studio.
>> Some even have limited internet access with local browsers accessible only
>> through a virtual machine or local VNC connection, and assets *still*
>> manage to leave the premises.
>>
>> That not only puts the studio at risk, but the recipient too. Both as a
>> private person, as now your machine can leak confidential material, and as
>> another business. If a leak should happen that leads to loss of cash for
>> any larger entity such as WB there will be investigations and consequences.
>> Private persons can get in trouble and businesses can crumble.
>>
>> The part I'm sceptical about is whether this particular tool is what
>> solves this problem. If it complicates saving and loading of scenes (and
>> even launching of Maya?) then I'd imagine people simply would not use it.
>> But the idea sounds worth exploring, so off the top of my head I would try
>> implementing a scene save/open callback to perform the encryption live and
>> natively, rather than rely on an external tool. It could be as simple as
>> letting Maya produce that binary `.mb` file of 1's and 0's, and reversing
>> the whole thing on save, and then do the opposite on load. No one would
>> know it happened, and it would unlikely have any noticeable effect on
>> save/load time, and there are equal callbacks for exporting.
>>
>> On 

Re: [Maya-Python] V Crypt System

[Andrew Golubev]

It is a very interesting discussion.  

Yeah, I will agree that it definitely must be invisible - so artists don't 
even know that encryption happened.
But you can't stop on scene saving and loading, you should create lots of 
workarounds in this "secure Maya client".
Somehow you need to lock any exporting of data inside in any format, 
hide\lock\encrypt code of all used inside scripts, lock any new plugin 
loading\or current plugins disabling. 
And lock script editor, or make some sort of interceptor, to ensure, that 
no script will run to export or explore private scene data. 
Also, if I understand all correctly, it will give a lot of restrictions for 
people who work with their tools(it will lock them on the layout of 
instruments you gave to them).

And this only stuff that comes up to mind immediately, I think during the 
development of such Maya launch wrapper lot's of underwater stones will 
come up eventually.

Additionally, if in your scene you will have references, during reference 
load you will need to decrypt this data,
the same will go to any geometry\textures or any files - you will need to 
decrypt on the run.
All of it must be done recursively on the whole data tree in scene,
so at some point how to handle your RAM memory, because you can't store 
this encrypted data somewhere.

And even this will not save you from attempt to try take this decrypted 
data from RAM...
воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 

> I agree with you. This would not solve all problems with working remotely, 
> but it would solve some. Perhaps the biggest problems, namely accidental 
> sharing and theft. I have also personally received material from artists at 
> studios that really shouldn't have managed to leave the studio. Some even 
> have limited internet access with local browsers accessible only through a 
> virtual machine or local VNC connection, and assets *still* manage to leave 
> the premises.
>
> That not only puts the studio at risk, but the recipient too. Both as a 
> private person, as now your machine can leak confidential material, and as 
> another business. If a leak should happen that leads to loss of cash for 
> any larger entity such as WB there will be investigations and consequences. 
> Private persons can get in trouble and businesses can crumble.
>
> The part I'm sceptical about is whether this particular tool is what 
> solves this problem. If it complicates saving and loading of scenes (and 
> even launching of Maya?) then I'd imagine people simply would not use it. 
> But the idea sounds worth exploring, so off the top of my head I would try 
> implementing a scene save/open callback to perform the encryption live and 
> natively, rather than rely on an external tool. It could be as simple as 
> letting Maya produce that binary `.mb` file of 1's and 0's, and reversing 
> the whole thing on save, and then do the opposite on load. No one would 
> know it happened, and it would unlikely have any noticeable effect on 
> save/load time, and there are equal callbacks for exporting.
>
> On Sat, 4 Sept 2021 at 22:26, Rudi Hammad  wrote:
>
>> I think they must have thought about the export aswell. Otherwise it 
>> wouldn't make any sense.
>> Of course ideally you would each person would work in their office 
>> stations remotly, but it is not up to me. So if I choose not work with a 
>> client unless he guaranties remote workstation solutions, I will loose a 
>> lot of work.
>> Also  many studios have not the resources , and even if they do, the lag 
>> is some times to high to work remotly.
>>
>> Many times sharing is accidental due to the lack of control, or planning 
>> in a production. In my experience I was doing a freelance work a couple of 
>> month a go. And we where all working remotly in our personal computers.
>> The supervisor at somepoint, sent me a rig from another project as a 
>> reference. So obviously that was accidental because working in this 
>> situations like that, you do always thing that you are doing anywrong.
>> So even if you sign NDAs, and you have good intentions, it can leak. And 
>> of course, there is always people with bad intentions, so we can't be naive 
>> thinking that everyone will be professional. I work with a guy who managed
>> to get rigs that he shouldn't have. When I asked how did he get them, he 
>> told me he took them out of the office in his last day.
>>
>> My point being, that with a system like V Crypt, wheter it is by accident 
>> or not, it might be the solution to encrypt files and safely work as 
>> freelance (specially for me since now I am full time freelancer)
>>
>> I'll keep you posted
>>
>> El sábado, 4 de septiembre de 2021 a las 22:59:06 UTC+2, 
>> justin...@gmail.com escribió:
>>
>>> On Sun, Sep 5, 2021 at 8:38 AM Marcus Ottosson  
>>> wrote:
>>>
 That is true, that does sound like a good idea. Assuming the software 
 actually does what it says on the tin, it would at least protect against 
 

Re: [Maya-Python] V Crypt System

[Andrew Golubev]

And additionally, if in your scene you will have references, 
during reference load you will need to decrypt this data,
the same will go to any geometry\textures or any files - you will need to 
decrypt on the run.
And all of it must be done recursively on the whole data tree in scene,
so at some point how to handle your RAM memory, because you can't store 
this encrypted data somewhere...)

понедельник, 6 сентября 2021 г. в 12:14:38 UTC+3, Andrew Golubev: 

> It is a very interesting discussion.  
>
> Yeah, I will agree that it definitely must be invisible - so artists don't 
> even know that encryption happened.
> But you can't stop on scene saving and loading, you should create lots of 
> workarounds in this "secure Maya client".
> Somehow you need to lock any exporting of data inside in any format, 
> hide\lock\encrypt code of all used inside scripts, lock any new plugin 
> loading\or current plugins disabling. 
> And lock script editor, or make some sort of interceptor, to ensure, that 
> no script will run to export or explore private scene data. 
> Also, if I understand all correctly, it will give a lot of restrictions 
> for people who work with their tools(it will lock them on the layout of 
> instruments you gave to them).
>
> And this only stuff that comes up to mind immediately, I think during the 
> development of such Maya launch wrapper lot's of underwater stones will 
> come up eventually.
> But I must admit that it is a very cool task to work on!:D
> воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 
>
>> I agree with you. This would not solve all problems with working 
>> remotely, but it would solve some. Perhaps the biggest problems, namely 
>> accidental sharing and theft. I have also personally received material from 
>> artists at studios that really shouldn't have managed to leave the studio. 
>> Some even have limited internet access with local browsers accessible only 
>> through a virtual machine or local VNC connection, and assets *still* 
>> manage to leave the premises.
>>
>> That not only puts the studio at risk, but the recipient too. Both as a 
>> private person, as now your machine can leak confidential material, and as 
>> another business. If a leak should happen that leads to loss of cash for 
>> any larger entity such as WB there will be investigations and consequences. 
>> Private persons can get in trouble and businesses can crumble.
>>
>> The part I'm sceptical about is whether this particular tool is what 
>> solves this problem. If it complicates saving and loading of scenes (and 
>> even launching of Maya?) then I'd imagine people simply would not use it. 
>> But the idea sounds worth exploring, so off the top of my head I would try 
>> implementing a scene save/open callback to perform the encryption live and 
>> natively, rather than rely on an external tool. It could be as simple as 
>> letting Maya produce that binary `.mb` file of 1's and 0's, and reversing 
>> the whole thing on save, and then do the opposite on load. No one would 
>> know it happened, and it would unlikely have any noticeable effect on 
>> save/load time, and there are equal callbacks for exporting.
>>
>> On Sat, 4 Sept 2021 at 22:26, Rudi Hammad  wrote:
>>
>>> I think they must have thought about the export aswell. Otherwise it 
>>> wouldn't make any sense.
>>> Of course ideally you would each person would work in their office 
>>> stations remotly, but it is not up to me. So if I choose not work with a 
>>> client unless he guaranties remote workstation solutions, I will loose a 
>>> lot of work.
>>> Also  many studios have not the resources , and even if they do, the lag 
>>> is some times to high to work remotly.
>>>
>>> Many times sharing is accidental due to the lack of control, or planning 
>>> in a production. In my experience I was doing a freelance work a couple of 
>>> month a go. And we where all working remotly in our personal computers.
>>> The supervisor at somepoint, sent me a rig from another project as a 
>>> reference. So obviously that was accidental because working in this 
>>> situations like that, you do always thing that you are doing anywrong.
>>> So even if you sign NDAs, and you have good intentions, it can leak. And 
>>> of course, there is always people with bad intentions, so we can't be naive 
>>> thinking that everyone will be professional. I work with a guy who managed
>>> to get rigs that he shouldn't have. When I asked how did he get them, he 
>>> told me he took them out of the office in his last day.
>>>
>>> My point being, that with a system like V Crypt, wheter it is by 
>>> accident or not, it might be the solution to encrypt files and safely work 
>>> as freelance (specially for me since now I am full time freelancer)
>>>
>>> I'll keep you posted
>>>
>>> El sábado, 4 de septiembre de 2021 a las 22:59:06 UTC+2, 
>>> justin...@gmail.com escribió:
>>>
 On Sun, Sep 5, 2021 at 8:38 AM Marcus Ottosson  
 wrote:

> That is 

Re: [Maya-Python] V Crypt System

[Andrew Golubev]

It is a very interesting discussion.  

Yeah, I will agree that it definitely must be invisible - so artists don't 
even know that encryption happened.
But you can't stop on scene saving and loading, you should create lots of 
workarounds in this "secure Maya client".
Somehow you need to lock any exporting of data inside in any format, 
hide\lock\encrypt code of all used inside scripts, lock any new plugin 
loading\or current plugins disabling. 
And lock script editor, or make some sort of interceptor, to ensure, that 
no script will run to export or explore private scene data. 
Also, if I understand all correctly, it will give a lot of restrictions for 
people who work with their tools(it will lock them on the layout of 
instruments you gave to them).

And this only stuff that comes up to mind immediately, I think during the 
development of such Maya launch wrapper lot's of underwater stones will 
come up eventually.
But I must admit that it is a very cool task to work on!:D
воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus Ottosson: 

> I agree with you. This would not solve all problems with working remotely, 
> but it would solve some. Perhaps the biggest problems, namely accidental 
> sharing and theft. I have also personally received material from artists at 
> studios that really shouldn't have managed to leave the studio. Some even 
> have limited internet access with local browsers accessible only through a 
> virtual machine or local VNC connection, and assets *still* manage to leave 
> the premises.
>
> That not only puts the studio at risk, but the recipient too. Both as a 
> private person, as now your machine can leak confidential material, and as 
> another business. If a leak should happen that leads to loss of cash for 
> any larger entity such as WB there will be investigations and consequences. 
> Private persons can get in trouble and businesses can crumble.
>
> The part I'm sceptical about is whether this particular tool is what 
> solves this problem. If it complicates saving and loading of scenes (and 
> even launching of Maya?) then I'd imagine people simply would not use it. 
> But the idea sounds worth exploring, so off the top of my head I would try 
> implementing a scene save/open callback to perform the encryption live and 
> natively, rather than rely on an external tool. It could be as simple as 
> letting Maya produce that binary `.mb` file of 1's and 0's, and reversing 
> the whole thing on save, and then do the opposite on load. No one would 
> know it happened, and it would unlikely have any noticeable effect on 
> save/load time, and there are equal callbacks for exporting.
>
> On Sat, 4 Sept 2021 at 22:26, Rudi Hammad  wrote:
>
>> I think they must have thought about the export aswell. Otherwise it 
>> wouldn't make any sense.
>> Of course ideally you would each person would work in their office 
>> stations remotly, but it is not up to me. So if I choose not work with a 
>> client unless he guaranties remote workstation solutions, I will loose a 
>> lot of work.
>> Also  many studios have not the resources , and even if they do, the lag 
>> is some times to high to work remotly.
>>
>> Many times sharing is accidental due to the lack of control, or planning 
>> in a production. In my experience I was doing a freelance work a couple of 
>> month a go. And we where all working remotly in our personal computers.
>> The supervisor at somepoint, sent me a rig from another project as a 
>> reference. So obviously that was accidental because working in this 
>> situations like that, you do always thing that you are doing anywrong.
>> So even if you sign NDAs, and you have good intentions, it can leak. And 
>> of course, there is always people with bad intentions, so we can't be naive 
>> thinking that everyone will be professional. I work with a guy who managed
>> to get rigs that he shouldn't have. When I asked how did he get them, he 
>> told me he took them out of the office in his last day.
>>
>> My point being, that with a system like V Crypt, wheter it is by accident 
>> or not, it might be the solution to encrypt files and safely work as 
>> freelance (specially for me since now I am full time freelancer)
>>
>> I'll keep you posted
>>
>> El sábado, 4 de septiembre de 2021 a las 22:59:06 UTC+2, 
>> justin...@gmail.com escribió:
>>
>>> On Sun, Sep 5, 2021 at 8:38 AM Marcus Ottosson  
>>> wrote:
>>>
 That is true, that does sound like a good idea. Assuming the software 
 actually does what it says on the tin, it would at least protect against 
 theft and accidental sharing.

 It wouldn’t protect against sending files though, because if someone 
 wanted to send some model or some rig, they could still just export it to 
 a 
 new .ma? For that, you’d probably be better off intermingling it with 
 custom nodes. Like how anything rigged with mGear is riddled with mGear 
 nodes, making anyone attempting to open that rig without 

Re: [Maya-Python] V Crypt System

[Marcus Ottosson]

I agree with you. This would not solve all problems with working remotely,
but it would solve some. Perhaps the biggest problems, namely accidental
sharing and theft. I have also personally received material from artists at
studios that really shouldn't have managed to leave the studio. Some even
have limited internet access with local browsers accessible only through a
virtual machine or local VNC connection, and assets *still* manage to leave
the premises.

That not only puts the studio at risk, but the recipient too. Both as a
private person, as now your machine can leak confidential material, and as
another business. If a leak should happen that leads to loss of cash for
any larger entity such as WB there will be investigations and consequences.
Private persons can get in trouble and businesses can crumble.

The part I'm sceptical about is whether this particular tool is what solves
this problem. If it complicates saving and loading of scenes (and even
launching of Maya?) then I'd imagine people simply would not use it. But
the idea sounds worth exploring, so off the top of my head I would try
implementing a scene save/open callback to perform the encryption live and
natively, rather than rely on an external tool. It could be as simple as
letting Maya produce that binary `.mb` file of 1's and 0's, and reversing
the whole thing on save, and then do the opposite on load. No one would
know it happened, and it would unlikely have any noticeable effect on
save/load time, and there are equal callbacks for exporting.

On Sat, 4 Sept 2021 at 22:26, Rudi Hammad  wrote:

> I think they must have thought about the export aswell. Otherwise it
> wouldn't make any sense.
> Of course ideally you would each person would work in their office
> stations remotly, but it is not up to me. So if I choose not work with a
> client unless he guaranties remote workstation solutions, I will loose a
> lot of work.
> Also  many studios have not the resources , and even if they do, the lag
> is some times to high to work remotly.
>
> Many times sharing is accidental due to the lack of control, or planning
> in a production. In my experience I was doing a freelance work a couple of
> month a go. And we where all working remotly in our personal computers.
> The supervisor at somepoint, sent me a rig from another project as a
> reference. So obviously that was accidental because working in this
> situations like that, you do always thing that you are doing anywrong.
> So even if you sign NDAs, and you have good intentions, it can leak. And
> of course, there is always people with bad intentions, so we can't be naive
> thinking that everyone will be professional. I work with a guy who managed
> to get rigs that he shouldn't have. When I asked how did he get them, he
> told me he took them out of the office in his last day.
>
> My point being, that with a system like V Crypt, wheter it is by accident
> or not, it might be the solution to encrypt files and safely work as
> freelance (specially for me since now I am full time freelancer)
>
> I'll keep you posted
>
> El sábado, 4 de septiembre de 2021 a las 22:59:06 UTC+2,
> justin...@gmail.com escribió:
>
>> On Sun, Sep 5, 2021 at 8:38 AM Marcus Ottosson 
>> wrote:
>>
>>> That is true, that does sound like a good idea. Assuming the software
>>> actually does what it says on the tin, it would at least protect against
>>> theft and accidental sharing.
>>>
>>> It wouldn’t protect against sending files though, because if someone
>>> wanted to send some model or some rig, they could still just export it to a
>>> new .ma? For that, you’d probably be better off intermingling it with
>>> custom nodes. Like how anything rigged with mGear is riddled with mGear
>>> nodes, making anyone attempting to open that rig without mGear loaded left
>>> with a sorely broken rig. And no amount of exporting or tampering with the
>>> scene file could fix it.
>>>
>> From the video it looks like you have to launch Maya from their launcher,
>> which I assume installs a particular reader/writer plugin. I wonder if it's
>> specific to ma/mb file types or if it hooks into every type. Because I was
>> thinking that same thing you said about exporting to other formats, and
>> would that go through the same hook?  Also once Maya is launched, could
>> someone turn off the plugin after the scene is loaded?
>>
>> When it comes to protecting stuff like code, usually you hear the best
>> security is to just never let the source get onto the client side. But with
>> DCC scene files if you have to work with them locally then it feels like
>> there is going to be some way to defeat it. Once its unencrypted in the
>> DCC, there must be a weakness that might just be more obscure to many
>> people and the security is really just focused on the obvious act of
>> copying files around. Probably the better approach is just not letting
>> people work on their person workstations and only support a remote
>> workstation solution like 

Re: [Maya-Python] V Crypt System

[Rudi Hammad]

I think they must have thought about the export aswell. Otherwise it 
wouldn't make any sense.
Of course ideally you would each person would work in their office stations 
remotly, but it is not up to me. So if I choose not work with a client 
unless he guaranties remote workstation solutions, I will loose a lot of 
work.
Also  many studios have not the resources , and even if they do, the lag is 
some times to high to work remotly.

Many times sharing is accidental due to the lack of control, or planning in 
a production. In my experience I was doing a freelance work a couple of 
month a go. And we where all working remotly in our personal computers.
The supervisor at somepoint, sent me a rig from another project as a 
reference. So obviously that was accidental because working in this 
situations like that, you do always thing that you are doing anywrong.
So even if you sign NDAs, and you have good intentions, it can leak. And of 
course, there is always people with bad intentions, so we can't be naive 
thinking that everyone will be professional. I work with a guy who managed
to get rigs that he shouldn't have. When I asked how did he get them, he 
told me he took them out of the office in his last day.

My point being, that with a system like V Crypt, wheter it is by accident 
or not, it might be the solution to encrypt files and safely work as 
freelance (specially for me since now I am full time freelancer)

I'll keep you posted

El sábado, 4 de septiembre de 2021 a las 22:59:06 UTC+2, 
justin...@gmail.com escribió:

> On Sun, Sep 5, 2021 at 8:38 AM Marcus Ottosson  
> wrote:
>
>> That is true, that does sound like a good idea. Assuming the software 
>> actually does what it says on the tin, it would at least protect against 
>> theft and accidental sharing.
>>
>> It wouldn’t protect against sending files though, because if someone 
>> wanted to send some model or some rig, they could still just export it to a 
>> new .ma? For that, you’d probably be better off intermingling it with 
>> custom nodes. Like how anything rigged with mGear is riddled with mGear 
>> nodes, making anyone attempting to open that rig without mGear loaded left 
>> with a sorely broken rig. And no amount of exporting or tampering with the 
>> scene file could fix it.
>>
> From the video it looks like you have to launch Maya from their launcher, 
> which I assume installs a particular reader/writer plugin. I wonder if it's 
> specific to ma/mb file types or if it hooks into every type. Because I was 
> thinking that same thing you said about exporting to other formats, and 
> would that go through the same hook?  Also once Maya is launched, could 
> someone turn off the plugin after the scene is loaded?
>
> When it comes to protecting stuff like code, usually you hear the best 
> security is to just never let the source get onto the client side. But with 
> DCC scene files if you have to work with them locally then it feels like 
> there is going to be some way to defeat it. Once its unencrypted in the 
> DCC, there must be a weakness that might just be more obscure to many 
> people and the security is really just focused on the obvious act of 
> copying files around. Probably the better approach is just not letting 
> people work on their person workstations and only support a remote 
> workstation solution like teradici.
>  
>
>>
>> On Sat, 4 Sept 2021 at 19:50, Rudi Hammad  wrote:
>>
>>> Yes I am refereing to the actual file, not source code.
>>> Here's a usecase:
>>> due to covid a lot of production are done remotly. In somecase you can 
>>> connect  by logging remotly to office computers to work, in which case no 
>>> protection is needed since it pretty much as if you where in the office.
>>> But in many cases, the files are sent to personal computers. Let's say  
>>> you rig  characters  that are sent to 10 different animators to their 
>>> personal computers. Despite the NDAs, its impossible to police everyone,
>>> specially if you don't know the client but you don't want to miss the 
>>> opportunity to get a job. There is no guaranty that someone will not leak 
>>> the file outside the production.
>>> So here is where you use in V Crypt system. It is not like you are 
>>> recieving a file from an untrusted source because you are part of a 
>>> production and you know that your .mb and .ma files are from the rigger not 
>>> form a the prince
>>> of niggeria that is asking you for money XD.
>>>
>>> That's seem a pretty secure way of working don't you think? you know you 
>>> recieve a file that is encrypted because you know you are in production 
>>> context. You can open it and work with it. It simply won't work outside you
>>> computer.
>>> El sábado, 4 de septiembre de 2021 a las 20:06:47 UTC+2, Marcus Ottosson 
>>> escribió:
>>>
 To protect the contents of a Maya file? Typically protection would 
 involve software, like Python source, but you mean to protect like a model 
 or some animation? At that 

Re: [Maya-Python] V Crypt System

[Rudi Hammad]

oh yea, nothing protects it from sending it to anyone, but you can encrypt 
the MAC address of your client's computer, so if it doesn't match it won't 
open. Or something like that.
Maybe you ask the client to give you his MAX address and generate a license 
number mapped to it.

El sábado, 4 de septiembre de 2021 a las 22:38:20 UTC+2, Marcus Ottosson 
escribió:

> That is true, that does sound like a good idea. Assuming the software 
> actually does what it says on the tin, it would at least protect against 
> theft and accidental sharing.
>
> It wouldn’t protect against sending files though, because if someone 
> wanted to send some model or some rig, they could still just export it to a 
> new .ma? For that, you’d probably be better off intermingling it with 
> custom nodes. Like how anything rigged with mGear is riddled with mGear 
> nodes, making anyone attempting to open that rig without mGear loaded left 
> with a sorely broken rig. And no amount of exporting or tampering with the 
> scene file could fix it.
>
> On Sat, 4 Sept 2021 at 19:50, Rudi Hammad  wrote:
>
>> Yes I am refereing to the actual file, not source code.
>> Here's a usecase:
>> due to covid a lot of production are done remotly. In somecase you can 
>> connect  by logging remotly to office computers to work, in which case no 
>> protection is needed since it pretty much as if you where in the office.
>> But in many cases, the files are sent to personal computers. Let's say  
>> you rig  characters  that are sent to 10 different animators to their 
>> personal computers. Despite the NDAs, its impossible to police everyone,
>> specially if you don't know the client but you don't want to miss the 
>> opportunity to get a job. There is no guaranty that someone will not leak 
>> the file outside the production.
>> So here is where you use in V Crypt system. It is not like you are 
>> recieving a file from an untrusted source because you are part of a 
>> production and you know that your .mb and .ma files are from the rigger not 
>> form a the prince
>> of niggeria that is asking you for money XD.
>>
>> That's seem a pretty secure way of working don't you think? you know you 
>> recieve a file that is encrypted because you know you are in production 
>> context. You can open it and work with it. It simply won't work outside you
>> computer.
>> El sábado, 4 de septiembre de 2021 a las 20:06:47 UTC+2, Marcus Ottosson 
>> escribió:
>>
>>> To protect the contents of a Maya file? Typically protection would 
>>> involve software, like Python source, but you mean to protect like a model 
>>> or some animation? At that point, why wouldn’t you just hold onto the file, 
>>> and not send it or make it publicly available? Maybe you have a particualr 
>>> usecase in mind, because I can’t quite see it.
>>>
>>> Also I would be most weary opening an .mb from an untrusted source. 
>>> That’s what .ma is for, so you can inspect it for any script-related 
>>> things. I’ve been bitten before and, as they saying goes, fool me once.
>>>
>>> On Sat, 4 Sept 2021 at 16:17, Rudi Hammad  wrote:
>>>
 Hi,
 a while a go I create a thread about protecting your work.
 Along the same lines I saw this

 V Crypt maya files 

 So in theory, you can generate a license for the computer mac address, 
 and inside your
 .ma and .mb so some kind of assertion make sure sure that the file is 
 being open in the right computer. And since both files are crypted, you 
 can 
 remove that block of the code.
 Also, if you try to saveAs, it is saved with th crypted format.

 It seems like a good solution right? what do you think?

 R

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Python Programming for Autodesk Maya" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to python_inside_m...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/python_inside_maya/a1c4949b-eead-412d-b10a-6750ab07ef85n%40googlegroups.com
  
 
 .

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to python_inside_m...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/python_inside_maya/e91cc054-a7ce-42d0-8d69-920dfdaa9ffcn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 

Re: [Maya-Python] V Crypt System

[Rudi Hammad]

I don't know about the export...h..., but saveas is safe. I am talking 
with them via email and that's what they said. I will ask about the export 
too.
(About custom nodes I am not using any at the moment, I might implement 
that later as an alternative option to the client. It is all maya nodes)

El sábado, 4 de septiembre de 2021 a las 22:38:20 UTC+2, Marcus Ottosson 
escribió:

> That is true, that does sound like a good idea. Assuming the software 
> actually does what it says on the tin, it would at least protect against 
> theft and accidental sharing.
>
> It wouldn’t protect against sending files though, because if someone 
> wanted to send some model or some rig, they could still just export it to a 
> new .ma? For that, you’d probably be better off intermingling it with 
> custom nodes. Like how anything rigged with mGear is riddled with mGear 
> nodes, making anyone attempting to open that rig without mGear loaded left 
> with a sorely broken rig. And no amount of exporting or tampering with the 
> scene file could fix it.
>
> On Sat, 4 Sept 2021 at 19:50, Rudi Hammad  wrote:
>
>> Yes I am refereing to the actual file, not source code.
>> Here's a usecase:
>> due to covid a lot of production are done remotly. In somecase you can 
>> connect  by logging remotly to office computers to work, in which case no 
>> protection is needed since it pretty much as if you where in the office.
>> But in many cases, the files are sent to personal computers. Let's say  
>> you rig  characters  that are sent to 10 different animators to their 
>> personal computers. Despite the NDAs, its impossible to police everyone,
>> specially if you don't know the client but you don't want to miss the 
>> opportunity to get a job. There is no guaranty that someone will not leak 
>> the file outside the production.
>> So here is where you use in V Crypt system. It is not like you are 
>> recieving a file from an untrusted source because you are part of a 
>> production and you know that your .mb and .ma files are from the rigger not 
>> form a the prince
>> of niggeria that is asking you for money XD.
>>
>> That's seem a pretty secure way of working don't you think? you know you 
>> recieve a file that is encrypted because you know you are in production 
>> context. You can open it and work with it. It simply won't work outside you
>> computer.
>> El sábado, 4 de septiembre de 2021 a las 20:06:47 UTC+2, Marcus Ottosson 
>> escribió:
>>
>>> To protect the contents of a Maya file? Typically protection would 
>>> involve software, like Python source, but you mean to protect like a model 
>>> or some animation? At that point, why wouldn’t you just hold onto the file, 
>>> and not send it or make it publicly available? Maybe you have a particualr 
>>> usecase in mind, because I can’t quite see it.
>>>
>>> Also I would be most weary opening an .mb from an untrusted source. 
>>> That’s what .ma is for, so you can inspect it for any script-related 
>>> things. I’ve been bitten before and, as they saying goes, fool me once.
>>>
>>> On Sat, 4 Sept 2021 at 16:17, Rudi Hammad  wrote:
>>>
 Hi,
 a while a go I create a thread about protecting your work.
 Along the same lines I saw this

 V Crypt maya files 

 So in theory, you can generate a license for the computer mac address, 
 and inside your
 .ma and .mb so some kind of assertion make sure sure that the file is 
 being open in the right computer. And since both files are crypted, you 
 can 
 remove that block of the code.
 Also, if you try to saveAs, it is saved with th crypted format.

 It seems like a good solution right? what do you think?

 R

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Python Programming for Autodesk Maya" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to python_inside_m...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/python_inside_maya/a1c4949b-eead-412d-b10a-6750ab07ef85n%40googlegroups.com
  
 
 .

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to python_inside_m...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/python_inside_maya/e91cc054-a7ce-42d0-8d69-920dfdaa9ffcn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are 

Re: [Maya-Python] V Crypt System

[Justin Israel]

On Sun, Sep 5, 2021 at 8:38 AM Marcus Ottosson 
wrote:

> That is true, that does sound like a good idea. Assuming the software
> actually does what it says on the tin, it would at least protect against
> theft and accidental sharing.
>
> It wouldn’t protect against sending files though, because if someone
> wanted to send some model or some rig, they could still just export it to a
> new .ma? For that, you’d probably be better off intermingling it with
> custom nodes. Like how anything rigged with mGear is riddled with mGear
> nodes, making anyone attempting to open that rig without mGear loaded left
> with a sorely broken rig. And no amount of exporting or tampering with the
> scene file could fix it.
>
>From the video it looks like you have to launch Maya from their launcher,
which I assume installs a particular reader/writer plugin. I wonder if it's
specific to ma/mb file types or if it hooks into every type. Because I was
thinking that same thing you said about exporting to other formats, and
would that go through the same hook?  Also once Maya is launched, could
someone turn off the plugin after the scene is loaded?

When it comes to protecting stuff like code, usually you hear the best
security is to just never let the source get onto the client side. But with
DCC scene files if you have to work with them locally then it feels like
there is going to be some way to defeat it. Once its unencrypted in the
DCC, there must be a weakness that might just be more obscure to many
people and the security is really just focused on the obvious act of
copying files around. Probably the better approach is just not letting
people work on their person workstations and only support a remote
workstation solution like teradici.


>
> On Sat, 4 Sept 2021 at 19:50, Rudi Hammad  wrote:
>
>> Yes I am refereing to the actual file, not source code.
>> Here's a usecase:
>> due to covid a lot of production are done remotly. In somecase you can
>> connect  by logging remotly to office computers to work, in which case no
>> protection is needed since it pretty much as if you where in the office.
>> But in many cases, the files are sent to personal computers. Let's say
>> you rig  characters  that are sent to 10 different animators to their
>> personal computers. Despite the NDAs, its impossible to police everyone,
>> specially if you don't know the client but you don't want to miss the
>> opportunity to get a job. There is no guaranty that someone will not leak
>> the file outside the production.
>> So here is where you use in V Crypt system. It is not like you are
>> recieving a file from an untrusted source because you are part of a
>> production and you know that your .mb and .ma files are from the rigger not
>> form a the prince
>> of niggeria that is asking you for money XD.
>>
>> That's seem a pretty secure way of working don't you think? you know you
>> recieve a file that is encrypted because you know you are in production
>> context. You can open it and work with it. It simply won't work outside you
>> computer.
>> El sábado, 4 de septiembre de 2021 a las 20:06:47 UTC+2, Marcus Ottosson
>> escribió:
>>
>>> To protect the contents of a Maya file? Typically protection would
>>> involve software, like Python source, but you mean to protect like a model
>>> or some animation? At that point, why wouldn’t you just hold onto the file,
>>> and not send it or make it publicly available? Maybe you have a particualr
>>> usecase in mind, because I can’t quite see it.
>>>
>>> Also I would be most weary opening an .mb from an untrusted source.
>>> That’s what .ma is for, so you can inspect it for any script-related
>>> things. I’ve been bitten before and, as they saying goes, fool me once.
>>>
>>> On Sat, 4 Sept 2021 at 16:17, Rudi Hammad  wrote:
>>>
 Hi,
 a while a go I create a thread about protecting your work.
 Along the same lines I saw this

 V Crypt maya files 

 So in theory, you can generate a license for the computer mac address,
 and inside your
 .ma and .mb so some kind of assertion make sure sure that the file is
 being open in the right computer. And since both files are crypted, you can
 remove that block of the code.
 Also, if you try to saveAs, it is saved with th crypted format.

 It seems like a good solution right? what do you think?

 R

 --
 You received this message because you are subscribed to the Google
 Groups "Python Programming for Autodesk Maya" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to python_inside_m...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/python_inside_maya/a1c4949b-eead-412d-b10a-6750ab07ef85n%40googlegroups.com
 

Re: [Maya-Python] V Crypt System

[Marcus Ottosson]

That is true, that does sound like a good idea. Assuming the software
actually does what it says on the tin, it would at least protect against
theft and accidental sharing.

It wouldn’t protect against sending files though, because if someone wanted
to send some model or some rig, they could still just export it to a new .ma?
For that, you’d probably be better off intermingling it with custom nodes.
Like how anything rigged with mGear is riddled with mGear nodes, making
anyone attempting to open that rig without mGear loaded left with a sorely
broken rig. And no amount of exporting or tampering with the scene file
could fix it.

On Sat, 4 Sept 2021 at 19:50, Rudi Hammad  wrote:

> Yes I am refereing to the actual file, not source code.
> Here's a usecase:
> due to covid a lot of production are done remotly. In somecase you can
> connect  by logging remotly to office computers to work, in which case no
> protection is needed since it pretty much as if you where in the office.
> But in many cases, the files are sent to personal computers. Let's say
> you rig  characters  that are sent to 10 different animators to their
> personal computers. Despite the NDAs, its impossible to police everyone,
> specially if you don't know the client but you don't want to miss the
> opportunity to get a job. There is no guaranty that someone will not leak
> the file outside the production.
> So here is where you use in V Crypt system. It is not like you are
> recieving a file from an untrusted source because you are part of a
> production and you know that your .mb and .ma files are from the rigger not
> form a the prince
> of niggeria that is asking you for money XD.
>
> That's seem a pretty secure way of working don't you think? you know you
> recieve a file that is encrypted because you know you are in production
> context. You can open it and work with it. It simply won't work outside you
> computer.
> El sábado, 4 de septiembre de 2021 a las 20:06:47 UTC+2, Marcus Ottosson
> escribió:
>
>> To protect the contents of a Maya file? Typically protection would
>> involve software, like Python source, but you mean to protect like a model
>> or some animation? At that point, why wouldn’t you just hold onto the file,
>> and not send it or make it publicly available? Maybe you have a particualr
>> usecase in mind, because I can’t quite see it.
>>
>> Also I would be most weary opening an .mb from an untrusted source.
>> That’s what .ma is for, so you can inspect it for any script-related
>> things. I’ve been bitten before and, as they saying goes, fool me once.
>>
>> On Sat, 4 Sept 2021 at 16:17, Rudi Hammad  wrote:
>>
>>> Hi,
>>> a while a go I create a thread about protecting your work.
>>> Along the same lines I saw this
>>>
>>> V Crypt maya files 
>>>
>>> So in theory, you can generate a license for the computer mac address,
>>> and inside your
>>> .ma and .mb so some kind of assertion make sure sure that the file is
>>> being open in the right computer. And since both files are crypted, you can
>>> remove that block of the code.
>>> Also, if you try to saveAs, it is saved with th crypted format.
>>>
>>> It seems like a good solution right? what do you think?
>>>
>>> R
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Python Programming for Autodesk Maya" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to python_inside_m...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/python_inside_maya/a1c4949b-eead-412d-b10a-6750ab07ef85n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to python_inside_maya+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/e91cc054-a7ce-42d0-8d69-920dfdaa9ffcn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCpAua2TmorENN9OOzG%3Deg5T-cxotu%3DW8OBTA%2B-RacWjQ%40mail.gmail.com.

Re: [Maya-Python] V Crypt System

[Rudi Hammad]

Yes I am refereing to the actual file, not source code.
Here's a usecase:
due to covid a lot of production are done remotly. In somecase you can 
connect  by logging remotly to office computers to work, in which case no 
protection is needed since it pretty much as if you where in the office.
But in many cases, the files are sent to personal computers. Let's say  you 
rig  characters  that are sent to 10 different animators to their personal 
computers. Despite the NDAs, its impossible to police everyone,
specially if you don't know the client but you don't want to miss the 
opportunity to get a job. There is no guaranty that someone will not leak 
the file outside the production.
So here is where you use in V Crypt system. It is not like you are 
recieving a file from an untrusted source because you are part of a 
production and you know that your .mb and .ma files are from the rigger not 
form a the prince
of niggeria that is asking you for money XD.

That's seem a pretty secure way of working don't you think? you know you 
recieve a file that is encrypted because you know you are in production 
context. You can open it and work with it. It simply won't work outside you
computer.
El sábado, 4 de septiembre de 2021 a las 20:06:47 UTC+2, Marcus Ottosson 
escribió:

> To protect the contents of a Maya file? Typically protection would involve 
> software, like Python source, but you mean to protect like a model or some 
> animation? At that point, why wouldn’t you just hold onto the file, and not 
> send it or make it publicly available? Maybe you have a particualr usecase 
> in mind, because I can’t quite see it.
>
> Also I would be most weary opening an .mb from an untrusted source. 
> That’s what .ma is for, so you can inspect it for any script-related 
> things. I’ve been bitten before and, as they saying goes, fool me once.
>
> On Sat, 4 Sept 2021 at 16:17, Rudi Hammad  wrote:
>
>> Hi,
>> a while a go I create a thread about protecting your work.
>> Along the same lines I saw this
>>
>> V Crypt maya files 
>>
>> So in theory, you can generate a license for the computer mac address, 
>> and inside your
>> .ma and .mb so some kind of assertion make sure sure that the file is 
>> being open in the right computer. And since both files are crypted, you can 
>> remove that block of the code.
>> Also, if you try to saveAs, it is saved with th crypted format.
>>
>> It seems like a good solution right? what do you think?
>>
>> R
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to python_inside_m...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/python_inside_maya/a1c4949b-eead-412d-b10a-6750ab07ef85n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/e91cc054-a7ce-42d0-8d69-920dfdaa9ffcn%40googlegroups.com.

Re: [Maya-Python] V Crypt System

[Marcus Ottosson]

To protect the contents of a Maya file? Typically protection would involve
software, like Python source, but you mean to protect like a model or some
animation? At that point, why wouldn’t you just hold onto the file, and not
send it or make it publicly available? Maybe you have a particualr usecase
in mind, because I can’t quite see it.

Also I would be most weary opening an .mb from an untrusted source. That’s
what .ma is for, so you can inspect it for any script-related things. I’ve
been bitten before and, as they saying goes, fool me once.

On Sat, 4 Sept 2021 at 16:17, Rudi Hammad  wrote:

> Hi,
> a while a go I create a thread about protecting your work.
> Along the same lines I saw this
>
> V Crypt maya files 
>
> So in theory, you can generate a license for the computer mac address, and
> inside your
> .ma and .mb so some kind of assertion make sure sure that the file is
> being open in the right computer. And since both files are crypted, you can
> remove that block of the code.
> Also, if you try to saveAs, it is saved with th crypted format.
>
> It seems like a good solution right? what do you think?
>
> R
>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to python_inside_maya+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/a1c4949b-eead-412d-b10a-6750ab07ef85n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBEVnF37zBNqhdOpp4tj%3D0UstaXo7N16uLzD8MC_FPNrw%40mail.gmail.com.

[Maya-Python] V Crypt System

[Rudi Hammad]

Hi,
a while a go I create a thread about protecting your work.
Along the same lines I saw this

V Crypt maya files 

So in theory, you can generate a license for the computer mac address, and 
inside your
.ma and .mb so some kind of assertion make sure sure that the file is being 
open in the right computer. And since both files are crypted, you can 
remove that block of the code.
Also, if you try to saveAs, it is saved with th crypted format.

It seems like a good solution right? what do you think?

R

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/a1c4949b-eead-412d-b10a-6750ab07ef85n%40googlegroups.com.