ShaunR

@hooovahh: Thanks for moving the posts. No need to clutter the other thread with this. If that is the the cmd line one, it's of no interest to me. I can't imagine how you would use a command line to create a palette. I would also suspect it doesn't install existing VIPM and NIPM files and, if that is true, it is doomed.

A few years ago, I created an installer with a view to replacing VIPM in its entirety Partly because of this and a few other features that I wanted, but mainly because VPIM broke compatibility with VIPM 2014. I got as far as an installer which had categories, 64/32 bit support and some other features such as code signing, which was based around SQLite databases. The ini file feature of the SQLite API for LabVIEW was created specifically so that I could ingest VIPM spec files for this installer to install them instead of VIPM. It could also build packages (a SQLite database file instead of an INI file and a less sophisticated zip file) for its own format but I stopped short at the VIPM format as it was too restrictive (for the reasons we have discussed) and I didn't want to step on JKIs toes by releasing a competitive product. It has remained in my private toolbox ever since. Now that we have two installers, the NI and JKI ones; I can envisage one manager doing both, which IMO the NI one should have done from the get-go. If that is the case, we can kind of ignore the VIPM package format for building (but still able to install and convert them) and subsume both package managers. If we decided that we wanted to support the VIPM build standard, then that is possible too, with the same caveats as VIPM as regards bitness etc or by extending the format. However. I don't see much utility in supporting the VIPM build but I do see a lot of the code in the OpenG Package builder being useful since there is nothing inherently wrong with the zipped file format used by VIPM for distribution. Do you know anything about the NI Package Manager formats?

OpenG DEAB tool? It is quite likely I already have code for many of the features required for a package manager. Certainly the installation side since I've had my own for a few years, some of which is in the SQLite API installer (kind of precursor). What it lacks is the builder side but much of what is required exists (at least in part) as individual scripting tools. However, I'm still reliant on the JKI PM for menu creation and applying licences. For my purposes, I find the JKI package manager insufficient for my distribution of 32 & 64 bit binaries causing me to be heavily reliant on the pre/post install VI and carefully ensuring they aren't handled by the Package Manager. A useful feature for me would be to be the ability to define slightly different configurations for 32 & 64 bit LabVIEW at the individual file level. Please do post what you have.

I do neither

Let's agree to disagree Very much so. But lets not forget the great job VIPM does with versioning, dependencies and applying licences. That's just not true. What is true is that it is a hack at best to create a LabVIEW service. Perhaps this is what was meant.

We already know how to share code. The problem is it is fragmented, de-integrated, and unsearchable across the myriad of different platforms and websites. The LVTN is supposed to alleviate that by having a central listing/repository and VIPM is the UI to administer it. What VIPM doesn't have (at least in the Community Edition) is a submission process - build, upload & publish. There is nothing to stop publishing being on Github, BitBucket or any other repository either- could be all of them and have the best of both worlds. If VIPM isn't doing it as we would like; we can always go back to its predecessor to build in what we need (Tell us about your enhancements, Rolf )

VIPM is the sure-fire method. It has it's quirks but ticks most boxes. There are only a couple issues that mean it doesn't necessarily suit all people, one of which is getting your repository listed. That should be up to the developer. You can argue all day and night about which licences are better or worse, but the developer is the arbiter of his creation. One of the other deficiencies of VIPM is not having a way of documenting all the licences of a package with all it's dependencies. That could be addressed fairly straightforwardly, but so far hasn't. For your particular conundrum, I would suggest multi-licencing. List multiple licences (e.g. CC-0, Public domain, MIT, BSD) then tell people they can use any one of them to their liking. Public domain is the "free"est but it is not recognised in some countries (Germany?). If it's in VIPM that's not an issue. Getting it in there is. I really thought the NI Package Manager (which I always said they should have done instead of using the JKI one) would address all this. They could even have had native SCC integration. But from what I have seen it is a poor replacement for VIPM targeted at NI products rather than addons.

What is this? The 1990s?. One of the major problems with search and distribution is verification. By that I mean verified as in tested, robust code that is fit-for-purpose. One reason why many packages aren't on the Tools Network is this overhead. It's also why we have the Lava CR vetting.

DHCP is UDP/IP not TCP/IP.

The second is usually used when there are multiple inputs and the terminal spacing forces bends in the wires. If you are forced to have bends because otherwise the terminals would overlap to keep the tram-lines, then you might as well make more room on the diagram for labels and controls/indicators so it doesn't look cluttered.

Yes and no. I find it useful to find the unhandled errors. When I build the final solution I have a scripting VI that turns it off along with others (like debug enable, VI short names etc). There are two error practices that may be being conflated from what you describe and what smithd is concerned with (and Darren describes in his talk) . Having a pass-through error (error in/out with no affecting code) and having a case structure around code with a switch on error; one case of which passes through.

The Sqlite API for LabVIEW has encryption and is free for non-commercial use.;)

I can. If you use event driven comms then you need it. Ala:

It's a fairly vague requirement that needs a bit more digging before examples can be offered. You also say that an Ethernet connected device is a possibility. These will always be cheaper than NIs cDAQ. There there are hundreds of Ethernet solutions out there but you can narrow that down for certain criteria. You say DIO. Does that mean you don't need a multifunction device (with analogue)? Single function devices are much cheaper and, when it comes to DIO, dedicated Input or output channels are generally cheaper than programmable - even if on the same board (e.g. 8 digital in, 8 digital out). What voltage range will you be working with? For DIO there are options for 24v,12v,5v and 3.3v. 24v are rare whilst 5v are ubiquitous. Does the IO need to be isolated? Non isolated devices are always cheaper but more risky. How many channels of digital in and digital out do you require? I so miss the NI DIO96! For DIO does it need to be current sourcing or sinking? How much current needs to be provided/dissipated - per channel, per bank or per device? What is the nature of the signal you are trying to detect? If it is transience, then most Ethernet DIO devices have on board processing to edge detect, vastly reducing the need for fast update rates in the client. If the processing is, say, sampling a signal, then the update rate at the client end will be crucial. These are the kinds of things that need to be considered when looking at a device of any type. What you require or choose will greatly reduce the applicability of the devices on offer and in some cases make you compromise on your requirements.

It does surprise me. I would have thought an entry for VI Type would have been added to the enum.

Well. Just to fan the flames of fear a bit more . I worry more about all the web/DNS servers, updaters, databases and weird and wonderfully named background tasks/services,(some of which I have no idea what they are for) that get installed by NI out-of-the-box, than tricksy code like that. I try and push that sort of defence problem to IT. However, when you install LabVIEW the attack surface increases 100 fold. It would be helpful if NI produced a document detailing all the services and background apps - what they do, what they are for and, more importantly, what LabVIEW features rely on which. A lot of them could also be on-demand rather than continuously running as I have found out by trial and error.

Just coerce to lower (or upper) case then it's just y|n|yes|no|true|false|on|off|0|1

You may also be interested in the responses when I posed the question Security? Who cares?. I don't think much has changed since then.

So you are not using client certificates? Verification does not mean "secure". On LavaG it means someone has inspected it and it works without errors and seems to work as advertised. Similarly the NI process is basically a few initial tests to make sure it installs and doesn't impact existing LabVIEW features. It's probably virus scanned several time whilst on the NI network. Yes you are [taking the risk]. That has nothing to do with the "ecosystem". It is the trade-off between your effort and leveraging other peoples effort. It applies to all open source projects. The premise is that security flaws will be identified by having more eyes on the code, not that it is unequivocally "secure". If you want someone else to take the responsibility, then use a company that specialises in security. That is the converse of "monolithic". Many services interacting to produce a cohesive system is what Systems Engineers are for. In that domain there is the concept of "compartmentalise and contain" - meaning attempting to design a system so that problems (be they security or otherwise) are limited to single modules/services and unintended consequences cannot propagate to other services. This is a kind of "design for damage limitation" and you can do your part for your contribution. You can't outsource security and keeping your private keys on some elses server is a trend that I resist. I stated previously that is was a bad idea to connect anything to the internet so connecting everything to someone elses servers that you do not have physical control over, don't know where it is residing, and that can be cut off on a whim is not a viable solution for me.

A bit of light background reading.

Yes. I'll see if I can upload the video to my website for download. There are some interesting responses from NI.

If you are using "WSHttpBinding" then that is SSL, IIRC. You can sniff the network packets with wireshark if you have the private key(s). You should always go over others code regardless of licence (if you have the source). At the very least, one might learn something. That's what Limited Liability Insurance is for but there are some things you can do to try to mitigate these possibilities (no USB ports, no network access, basic OPSEC etc.). OpenSSL is written in C. You are using .NET (C#?). You could write an SSL protocol provider in LabVIEW, if you wanted to. They may have bugs, but the protocols are language agnostic as are mitigations such as keeping a server room locked, not connecting an application to the internet/network and not telling people your passwords. Security is a huge specialist domain. You will hear about things like "defence in depth" which means not relying on a single mitigation or security feature, rather, many layers of protection. "Reducing the attack surface" - making methods of ingress as small as possible whilst still maintaining functionality. You are thinking about it, which, IMO, is already ahead of the average programmer (especially in IoT ). There was a very good video at one of the NI meetings at CERN by their IT manager (2014ClaEu_Day3_03_Control System Security). Well worth a watch if you can find it. Good communication with an IT department is paramount as they are your first and best line of defence and have the expertise. Once an adversary is inside the network, your options are more limited and they have demonstrated a certain skill level. Oh yes. One final point. DON'T CONNECT ANYTHING TO THE INTERNET!

If you are writing the software, then it is all within your control. What do you consider "reasonable"? What is a .net secure comm? What has licencing to do with security and what are you afraid of and whom? (refer to my previous statement about threat models). Security is language agnostic. Kind of. For the most part they think long and hard about certain things but my biggest bugbear is their deployment of OpenSSL libraries which is sporadic and doesn't seem to have a high priority in keeping up to date. I have, on more than one occasion, thought about deploying my own instead of using theirs for this reason.

You're welcome. Maybe it's time to think beyond the ostrich defence to adversaries?

I'm not so sure. For it to affect LabVIEW you have to open it. If that results in a crash then you have to restart LabVIEW (which will be fine) and then open it again for it to crash again. The effect doesn't seem to have LabVIEW-wide permanence so I'm not sure how you would DOS LabVIEW, rather, a developer would just curse the VI and move on unaffected. I suppose a plug-in architecture may be problematic, but as soon as a plug-in keeps crashing I expect it would be removed. The demonstrations also don't show a privilege escalation, rather, some C code to memcpy. Apart from the glaring obvious question of how do you execute C code within LabVIEW without DLLs etc; the exfiltration would be somewhat problematic. There are several levels of additional complexity to make that a useful attack. I'm not saying it can't be done, but for a random VI on the net or in your email client, there doesn't seem to be much of a consequence from opening it that we don't experience daily anyway-LabVIEW crashes or out of memory. That's why I remain unconcerned about this particular threat, for now, as it seems more of an academic exploit. There are far more egregious methods of DOSing LabVIEW applications and if it were shown that arbitrary code in the VI could be executed (therefore making exfiltration easier) then I would probably be more concerned.