How to remove a password-protected VI from an .lvlib

[Justin Goeres]

I have an old GOOP 1.0 class that I implemented a long time ago. At some point (during 8.2.x) I put it into an .lvlib, because that seemed like a good way to manage it.

Now, however, I need to remove all the VIs from this .lvlib, but LabVIEW 8.5 won't let me, because the objectRepository.vi is password-protected! (because it's part of a GOOP 1.0 class).

My question is two-fold:

1. How do I get the VI out of the .lvlib? Is it even possible?
   
2. How did I get myself into this mess? Is there some restriction on password-protected VIs vis-a-vis .lvlibs that LV85 enforces but LV82 didn't? (FYI, trying to backsave it to LV821 crashes LabVIEW, so that's nice, too. :headbang: )
   

[Christina Rogers]

Hi Justin,

I'm sorry to say, you can't remove a password-protected VI from a library without providing its password (and the library's password, if it's also password-protected).

LabVIEW shouldn't have let you add the VI to a library without providing a password. That was a bug.

Do you have a backup of the VI?

- Christina

[Justin Goeres]

Thanks, Christina.

QUOTE(Christina Rogers @ Oct 9 2007, 01:55 PM)

LabVIEW shouldn't have let you add the VI to a library without providing a password. That was a bug.

Like I said, I'm certain it happened back in the days of LV82 (or LV821). I wish I remembered the circumstances better. It appears that LV85 enforces that a little more strictly .

QUOTE

Do you have a backup of the VI?

Yeah, I pulled an old rev out of the repository from 12+ months ago, before my little .lvlib experiment.

This concludes today's lesson on "Why Source Code Control is Important, and Will Quickly Pay for Itself in Ways You Didn't Specifically Anticipate".

Tune in again for tomorrow's episode, "Don't Worry That LabVIEW Corrupted Your Project, You Can Just Revert It". :ninja:

[Tomi Maila]

QUOTE(Christina Rogers @ Oct 9 2007, 11:55 PM)

I'm sorry to say, you can't remove a password-protected VI from a library without providing its password (and the library's password, if it's also password-protected).

I think this behavior should be considered as a bug! One should always be able to remove a VI from a library if one has the password of the library or if the library is not password protected. Owner of the library should be able to modify the library as he/she will. However removing the password protected VI from the library should not modify the password protected VI. That VI should still think it's part of the library and as it really is not, it should be removed from the project all together.

Then for hackers a quick solution to solve the problem. Open the lvlib file and remove the password protected VI with your favorite text or XML editor. Save the lvlib file and close it. Then open it with LabVIEW and the VI should no longer be part of your library nor your life.

Cheers,

Tomi

[Justin Goeres]

QUOTE(Tomi Maila @ Oct 10 2007, 01:03 AM)

Then for hackers a quick solution to solve the problem. Open the lvlib file and remove the password protected VI with your favorite text or XML editor. Save the lvlib file and close it. Then open it with LabVIEW and the VI should no longer be part of your library nor your life.

But then when you open the VI later, won't the VI still think it's part of the library? My understanding is that it will, at which point LabVIEW will present you with the password dialog, because updating the VI to no longer belong to the library counts as a "modification."

I would test this myself, but I blew away all the evidence already .

[Tomi Maila]

QUOTE(Justin Goeres @ Oct 10 2007, 04:58 PM)

But then when you open the VI later, won't the VI still think it's part of the library? My understanding is that it will, at which point LabVIEW will present you with the password dialog, because updating the VI to no longer belong to the library counts as a "modification."

I guess it would. But I understood the problem was to fix the library by removing an unnecessary VI from the library. So it doesn't matter if the VI still thinks it's part of the library as it's no longer used. And the library doesn't think the VI is part of it. This can be achieved to my knowledge by editing the lvlib/lvclass/xcontrol/xnode file.

Cheers,

Tomi

[silmaril]

QUOTE(Justin Goeres @ Oct 10 2007, 03:58 PM)

But then when you open the VI later, won't the VI still think it's part of the library? My understanding is that it will, at which point LabVIEW will present you with the password dialog, because updating the VI to no longer belong to the library counts as a "modification."

Of course it will. That's exactly the point of password protection

From my point of view, this is the one and only correct behaviour.

This way you can for example put password protected VIs into a password protected library and sell it to customers to use it without giving them the chance to pick out single VIs for standalone use (which could be hidden deeply inside the project more easily).

[Justin Goeres]

QUOTE(Tomi Maila @ Oct 10 2007, 11:27 AM)

I guess it would. But I understood the problem was to fix the library by removing an unnecessary VI from the library. So it doesn't matter if the VI still thinks it's part of the library as it's no longer used. And the library doesn't think the VI is part of it. This can be achieved to my knowledge by editing the lvlib/lvclass/xcontrol/xnode file.

Good point. What I left out of my example was that I wanted to remove the VI from the library, but actually wanted to continue using it outside the library.

QUOTE(silmaril @ Oct 12 2007, 02:04 AM)

Of course it will. That's exactly the point of password protection

From my point of view, this is the one and only correct behaviour.

This way you can for example put password protected VIs into a password protected library and sell it to customers to use it without giving them the chance to pick out single VIs for standalone use (which could be hidden deeply inside the project more easily).

But what about the case where you might want to distribute a password-protected VI and allow users to put it in an .lvlib? For instance, my original example was a GOOP 1.0 class. The objectRepository.vi file for a GOOP 1.0 class is always password protected. That means that with the current implementation, you cannot put a GOOP 1.0 class inside an .lvlib!¹ Can that possibly be the one and only correct behavior? "Ability to view/edit the VI's block diagram" and "ability to organize the VI in an .lvlib" strike me as orthogonal goals.

I agree with Tomi. This feels like a bug to me.

¹Or, alternatively, you can't get it out once you manage to somehow get it in.

[Tomi Maila]

QUOTE(Justin Goeres @ Oct 12 2007, 02:14 PM)

I agree with Tomi. This feels like a bug to me.

Actually I think NI is mixing two different concepts here, namely protecting the VI and locking the VI context. A VI could have multiple contexts. It could be part of a library. It could be on a block diagram of another VI etc. Password protecting a VI has until now meant hiding the implementation of the VI. Now it seems that NI has added a second meaning, namely locking the VI context as well. I think this is not how it should be as it limits the usage of password protection to only those cases where you want to lock the context as well. With this design NI is actually limiting the usage of password protection.

For me the correct behavior is such that when a VI is password protected, then its implementation is hidden and nothing more. There could be new security options in addition to this old 0) 'hide block diagram and VI options' option. New options could include 1) don't allow dropping the VI to block diagrams, 2) don't allow executing VI independently. However I think it's a property of library to lock some or all items to the library. So if we need such a functionality that a VI is tied to a specific library, then we need to modify the security options of the library and not the VI. So I propose a change to the next LV version such that any LabVIEW library could lock its items but not the other way around. A VI should always be removable from a library. I agree with current functionality in that when a locked VI is removed from a library, then it becomes broken as this would mean a change to VI. However there could be a new security option 'allow context changes' that would allow renaming the VI as well as dropping it to a library even when password protected.

Cheers

Tomi

[Justin Goeres]

QUOTE(Tomi Maila @ Oct 12 2007, 05:35 AM)

Actually I think NI is mixing two different concepts here, namely protecting the VI and locking the VI context.

<SNIP>

There could be new security options...

:thumbup: