ShaunR

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.

NI released a number of patches for different versions. Was it only those versions affected? Or was it only those versions they applied the patch to and the issue still exists in previous versions? The problem I have with these sorts of threads (not necessarily here on Lavag, but in general) is that no-one ever defines their threat model. Who is it you are defending against? What are their capabilities? What are you prepared to give up in the name of security? Do you want Norton Security Suite running on your 500kB embedded platform? Is it the big bad nation state Stuxnetting your production line? Is it Joe Bloggs in the next cubical experimenting with a script he found on Youtube? My base line threat model is a skill level of a mediocre LabVIEW programmer, who can use Wireshark and has too much free time and a TCP connection to the device. Therefore my main worries are more with developers seemingly oblivious to even basic OPSEC rather than some alphabetty organisations with thousands of programmers. Does your websockets or web application have any authentication? Does it even use TLS? What happens if I send a 10GB file via websockets to your server Are you still using VI Server across your network? (which is unencrypted). Are you sending raw SQL back and forth between databases, unecrypted and with no authentication? These are the sorts of things I see in every company I have ever consulted with and would only require 10 minutes with wireshark to bring down complete production lines and smash robots into conveyor belts.Until that level of basic security is addressed it is just obsessive fearmongering to worry about specially crafted VIs that may cause a crash. Hell. LabVIEW crashes all the time. Until developers take ownership of their application security - and by that I mean really think about it rather than just using HTTPS because a webserver requires it, I see no real reason why NI need to fret about academic attacks and it is Kudos to them that they responded in the manner they did.

Quite probably. But I have a VI lib for setsockopt that works on Windows, Linux and Mac for the aforementioned calls. The knarly part is the path to the libraries that implement it.

The only difference is 0x1 for Linux (SOCK_STREAM) and 0xFFFF for windows (SOL_SOCKET). For Linger, Buffer sizes and Nagle the parms and constants are identical between platforms. Besides. The issue he is having is under windows as far as I can tell.

Well. The VI is in vi.lib but the Nagle vi uses setsocketoption so it would just be a case of changing the level to SOL_SOCKET, the optname to SO_LINGER and supplying a cluster of of 2x UINT16 for the optval.