LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
cy...

Option to enable SubVI version absolute

Status: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined.

What do you think if there is an BD SubVI (right click) option in enforcing SubVI code version to be absolute. Maybe through verifying SubVI's hashes etc, when individually enabled; to protect the source distribution from tampering. By default, LV will look for missing VIs if not found in its original path. That opens a window for the user to load another VI in place of the intended VI as long as it doesn't break the arrow and with a warning. An option to enforce SubVI identity in a password protected main/sub VI can be useful in maintaining the integrity of the codes.

 

CY (expired CLAD)
13 Comments
AristosQueue (NI)
NI Employee (retired)

> The idea focuses on the option of enforcing execution of

> the right codes, not SCC

 

And SCC is how you enforce execution of the right codes when in the editor. You sync specific changelists from SCC and that pulls down all the right pieces. Your build scripts (if any) pull in additional dependencies from known depots for systems whose complexity rises above the local set of VIs. (Those build scripts are in SCC with your VIs.)

 

> That can be dealt with SCC, no?

 

No. The whole point of source-only is to not make changes to source code when dependencies change that can be auto applied. With this feature, you'd have to make changes to callers for every change to the dependency. SCC does nothing to help with that. It is the antithesis of SCC because it pollutes your SCC logs with essentially junk changes.

cy...
Active Participant

I am back... Robot Happy

 

>And SCC is how you enforce execution of the right codes when in the editor.

but not during runtime; the scope may not be limited to just subVI; perhaps even the library functions are called from as well

 

>The whole point of source-only is to not make changes to source code when dependencies change that can be auto applied. With this feature, you'd have to make changes to callers for every change to the dependency.

That is why it is proposed to be optional. Not all subVI needed auto implementation of changes to its dependencies, which in some cases, the auto update can be used as an exploit

 

 

CY (expired CLAD)
Darren
Proven Zealot
Status changed to: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined.