Leaderboard

If only there was a > git fast-forward <new branch> One step, and no scary "-force" or "delete" involved.

Why not use the LabVIEW's native Application Directory VI? This automatically takes into account if you are in development mode or runtime (exe). Application Directory VI Owning Palette: File Constants Requires: Base Development System Returns the path to the directory containing the application. If you call this VI from a stand-alone application, this VI returns the path to the folder containing the stand-alone application. If you call this VI from the development environment and the VI is loaded in a LabVIEW project file (.lvproj), this VI returns the path to the folder containing the project file. If the project is not saved, this VI returns <Not a Path>.

Just for info: my recipe to fix a "detached head" is (using SourceTree) Create a temporary branch on the detached head commit (I prefer to name it "GitIsStupid") "Checkout" the real branch it should be on (usually) "Merge" the temporary branch into the current branch (no actual code merge occurs, so this is non-intuitive to me) Delete the now-unneeded temporary branch Git: making the easy things hard, and the hard things possible.

To add to the list of potential red flags: Windows Registry Access VIs VI Scripting calls (deleting or subtly modifying existing project code) Large VI file sizes / large constants (malicious VIs stored as byte arrays, so avoiding VI Analyzer's checks) Bugs known to crash LabVIEW Shortened links in VI help Non-standard block diagram colors (hiding a subVI on an identically colored BD) Obfuscated code (strings masquerading as boolean arrays, numbers with hidden precision, etc): Very small subVI icons (think a VI disguised as an error wire, as seen on reddit😞 In reality flagging a package based on any of the previously mentioned criteria will be almost exclusively false positives. Perhaps providing a list of function types a library uses would better help the developer assess the library, similar to the app permissions shown when downloading an app on iOS / Android. So a library may use Network, Scripting, and File System. As LogMAN said, it's ultimately up to the developer to take responsibility for the code they use. obfuscated_LV2014.vi

Here is my second part including some doubts. Please note that I make a few assumptions about the nature of this idea, so take it with a grain of salt. This will immediately flag all existing (non-malicious) packages as malicious, because each one will fail at least one of those checks. Just try running those checks on the OpenG packages... Also, most of those points only indicate potential technologies with which one could build malicious software. They are certainly not indicators of malicious software on their own. Not just that, but it also limits the options for the kind of licenses one can choose for their package. In fact, only an open source license is able to pass the checks (no password protected VIs + no removed block diagrams). While I like open source as much as the next developer, this will prevent businesses from providing licensed solutions via packages. In my opinion this is a bit too restrictive. I'm no security expert, but malicious code is generally detected during execution. Static code analysis is simply not smart enough to detect nuances in execution behavior. There is also no 100% guarantee that malicious code is triggered during code execution, which is why each users is responsible for verifying code that they downloaded from the internet (sandboxing). We are developers. As such it is our responsibility to take care of every tool we use for our work. This includes third-party packages from "unknown" sources or even package vendors. There are of course a few things that the package vendor could (should) do to help identify the origin of a package. For example, I want to be sure that the OpenG packages are actually from the OpenG community and not from someone random. This is why packages typically include information about their origin and are tied to a specific username. For example, the OpenG library (package) could belong to the OpenG account: "gcentral.org/packages/openg/openg-library". If you want to go one step further, have package owners sign their packages (i.e. PGP). For trusted package owners, GCentral could sign their keys to build a "web of trust". That way, if I trust GCentral, perhaps I can also trust the one that GCentral trusts... Regarding malicious code, I'd only expect GCentral to verify that packages don't include viruses (use your average anti-virus software). The rest of it is my responsibility. I am responsible for the code I download from the internet. GCentral should certainly not aim to take responsibility for that. My recommendation is to not have any kind of "no malicious code detected" tag on packages, because it will give developers a false sense of security. A "package from verified source" tag, however, could be worth looking into.