LabVIEW App - Self Updating Suggestions/Questions

[LuminaryKnight]

I've got some test racks off-site.  They log into our network via (I assume) VPN that requires employee login credentials.  I put together some janky self updating service in my testing application that checks a config file on our network drive and compares its own MD5 to the config file.  Instrumentation packed libraries.  Test VIs the app calls, Test Procedure/Instructions it follows.  Stuff like that.  The app can't update itself. But it can update all external files.  Anyways, the problem is the VPN.  The ongoing battle with IT and this VPN.  I get it, we don't want our test racks giving 24/7 access to our network drive for external customers to be able to access.

So I was hoping someone here and some sagely advice to this problem.  GitHub?  Can't download anything from Git unless you login with company credentials.  And I'm not about to deploy my creds with every rack.  Besides, gotta have that 6 digit ever changing 2-factor authentication thing.

I just want to be able to store my updates somewhere that these racks can safely check and download from.   Thoughts?

[BertMcMahan]

Surely your IT guys could set up an externally facing FTP server with login credentials, right? That would sit outside of your internal network's firewall and be "publicly" available to anyone with a login (which would just be your test racks). You could even give each rack a unique username and password, so it could get locked out at a later date if you ever needed to.

Regarding the self-update thing- if the software can see that it needs an update, it could stick the updater file into the "Startup" folder and it would get run when the system reboots. I'm sure there's some form of "windows task scheduler" out there that could run the update file later too. If it's Linux you could set up a cron job to run the installer, but you'd need to make sure the old version was closed before it ran.

[LLindenbauer]

It feels a bit like a "add more security" story, where the involved parties are not in alignment what to secure against. Are you able to sketch a diagram with IT where the components are marked as "trusted" and "not trusted"?

In this case, I guess that you consider the test racks to be a trusted environment (which I infer from you being comfortable with entering or storing credentials) and the updater software to be private sensitive data. In that case, I would recommend to encrypt the updater and storing the key locally on the test rack. With proper encryption, you can even deploy to public-facing platforms.

For transport security, I would probably use SSH/SCP with pubkey authentication. The client is already part of Windows, you can prevent MITM attacks, and I guess the IT department would also be already comfortable with the protocol and able to set you up with a simple isolated server that is only used to deploy updates.

PS: To me, the use of personal credentials for this kind of automated process always feels like a signal to rethink if it should rather be done with non-personal credentials.

[Jay14159265]

Had a situation that the IT department was never going to let a vendor machine on the local net have any external access. In the end, convinced the IT department to host a local update server. How the updates got on that server was convoluted, but it was a manageable solution.