Option to enable SubVI version absolute

[cy...]

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.

[wiebe@CARYA]

Guess it could work, technically it's a sound\feasible idea. I don't think I ever had need for it though.

SCC does this to some extend, as it would tell you what was changed and when and by whom.

Is this a real concern to you? And why?

[cy...]

I think it is quite useful in cases where SCC is not available, code inheritance, custom datatype and version compatibility, protection against intentional (or un-) modification of standard distributions, etc etc.

I cannot comment on what I have seen in the past... 

[crossrulz]

cy,

SCC is ALWAYS available and should always be used.  In the modern computer age, there is no reason not to use SCC.

Anyways, I think what you are really looking for is a way to lock in the relative path of a subVI.  And that seems like it would just cause all kinds of conflicts.  If a project file is properly maintained, this will become a non-factor.

[cy...]

To SCC or not would depend heavily on the client's policy

But even SCC also cannot prevent tampering, only tracing it. And the proposed option is not to lock the relative path, but the code itself, identified by matching hashes.

For instance, a MainVI that have a SubVI that contains certain algorithms, licensed propriety ones. Some external parties, modified aka tampered the SubVI to use alternative algoritms, so that they can use the MainVI. Option to lock absolute SubVI version inside a password protected MainVI can prevent it.

[wiebe@CARYA]

>But even SCC also cannot prevent tampering, only tracing it.

So would a hash!

[cy...]

It could if the subVI on BD that is set to absolute versioning breaks the arrow and a password protected main VI disallows editing... rendering the main useless if tampered

unless the editor somewhat edited the replacement SubVI to produce the same hash as the intended.

[wiebe@CARYA]

>It could if the subVI on BD that is set to absolute versioning breaks the arrow and a password protected main VI disallows editing... rendering the main useless if tampered

Exactly, so you would detect the tampering, it wouldn't prevent it .

I'm not sure if I'd find it useful in source code, as this is usually under control. It will probably slow me down more often then it would help me.

It is however (not easily but still) possible to replace VIs in executables. This is potentially dangerous. The executables might not be under control. A hash check during loading would prevent e.g. Check Password.vi to be replaced, so it always returns true. As an option, that wouldn't be a bad thing to have.

[AristosQueue (NI)]

Summary:

I'll leave the idea open for now, but:

1. I doubt we ever do anything with this in LV 20xx.
2. The deployment version of this issue doesn't exist in LabVIEW NXG.
3. The editor version of this issue already has an answer: source code control. And NXG eliminates the bulk of the crosslinking potential.

Unless more feedback develops on this idea, I'm going to recommend Declining it at the next quarterly review within R&D.

Details:

Let's start by splitting this into two separate problems: consistency of source at edit time and consistency of source at run time.

Regarding edit time: Consistency of the source files for any build should be done through source code control. That's the industry answer for it; that's the hobbyist answer for it. We aren't likely to take steps to sign a set of source code files together when the proper tools for that exist. Moreover, I'm doubtful that signing the files would be workable for most users -- signing would undermine "source only" settings by requiring all callers to change every time you modified a subVI AND you'd have to have all callers in memory any time you modified the subVI or else you'd be constantly having to patch your project back together. That sounds like a pretty miserable experience.

The danger of crosslinking in LabVIEW 20xx is addressed in LabVIEW NXG because VIs in NXG do not store paths to subVIs. Caller VIs only save the names of the subVIs they call. The resolution of those names is entirely under the control of the project file. NXG makes it generally meaningless to open a lone VI -- everything is oriented around the components file and the project file. Because all name resolution goes through the project, the project is always explicit about which directories and package repositories it is drawing upon, so if you've copied files to random places on your disk to make a backup, it doesn't matter -- those are never in the project's scope unless you've explicitly added them. Also, NXG never searches for missing dependencies.

Regarding run time: In LabVIEW 20xx, there is a risk if you deploy as a bunch of loose VIs that someone could replace individual VIs on your deployed image and thus inject code, whether maliciously or accidentally. This is a risk with any code that isn't all in a monolithic file. LabVIEW NXG flat out does not allow loose VIs in the run time engine -- EVER. Period. The only code that loads into the run-time engine are EXEs and compiled libraries. In the current version of NXG, the signing is not available, but eventually, the AppBuilder will be able to sign components and allow callers to check those signatures to ensure matching or compatible versions. By orienting the signing entirely around built components, we avoid the problems that signing the source code would have in the editor. (Only running built binaries has a lot of other advantages... I've lobbied for years to kill the so-called "feature" of loading loose VIs in runtime in LabVIEW 20xx, and TestStand folks always come back with *reasons*. Bah. Those reasons are dealt with in NXG!)

We welcome any further discussion, but my suspicion is that this will be declined in the next quarterly review.

[cy...]

>Exactly, so you would detect the tampering, it wouldn't prevent it .

I would consider a failure in building or running EXE as prevention, rather than detection. practically the main.vi without the right sub.vi will be useless and no EXE can be built using with it. The option, if NI would consider it will not only check during runtime, but during compilation as well.

>The editor version of this issue already has an answer: source code control. 

SCC is effective for collaboration and record keeping no doubt (and if the client policy allows); but it cannot enforce execution of the right codes. The idea focuses on the option of enforcing execution of the right codes, not SCC

>Moreover, I'm doubtful that signing the files would be workable for most users -- signing would undermine "source only" settings by requiring all callers to change every time you modified a subVI AND you'd have to have all callers in memory any time you modified the subVI or else you'd be constantly having to patch your project back together. That sounds like a pretty miserable experience.

That can be dealt with SCC, no?

The Check Password.vi example given by wiebe is spot on. Another example, maybe a data acquisition or instrument control system with limited user customization (through customizable subVIs for FP objects behaviour etc) but still subjected to top level protection or propriety (calculation, monitoring, reporting, etc2) algorithms (through version absolute, hash checks, signatures protection), which cannot be overruled/overwritten by any of the customization codes.

addition: the option proposal is for individual subVI in the calling vi, meaning that the Main.vi can have a mix of standard and hash-checked Sub.vi in the same BD

[wiebe@CARYA]

>This is a risk with any code that isn't all in a monolithic file.

I tried to describe editing a monolithic file. Even an monolithic .exe has VIs inside, and they can be replaced. Like I said: probably not that easy.

Signing the entire exe would prevent that, although the signature itself can be replaced of course. I think signing the exe is already possible CG with some help of external files. Haven't tried myself, but that should make it a lot harder.

@cy...: Note that the Check Password.vi example only applies to an executable. In my source code, I'd want to change that VI without re-validating all it's callers.