Jump to content


  • Content Count

  • Joined

  • Days Won


Everything posted by ShaunR

  1. They will be vetted and approved by their respective governments. The problem as I see it isn't limiting execution to signed code, it is who has capability to create and control the keys. "Derived keys" are weasel words for backdoors. But I see it as worse than that. These proposed hardware keys only limit what you can run, not what they (M$ et.al.) can run and they are major players in my threat model. Remember the the Clipper Chip? Or the Apple "Kill Switch"?. These kinds of technologies are packaged as "security" but give the corporate behemoths an inordinate amount of control over your devices. The technology already exists for self-signed secure boot. and a similar route for execution is far more appropriate. You don't need to trust anyone else but yourself (by that I mean your company) - you can't outsource security! Nope. I don't trust them as far as I can throw them. I go to great lengths to mitigate exfiltration of information to the likes of Google, M$ (i refuse to use Apple products) etc. I block all sites that are behind Coudflare (which is a MITM) and I use my own servers for things like Git, SVN, Jenkins etc. I realise the current trend is for online services (e.g Github) storing all your data but this is folly IMO. I may have to use a M$ OS, but I can and do limit their ability to leverage their indisdious telemetry and who has Driver Signing turned on? The annointed ones? China has it's own Certificate Authorities so good luck with that if your data gets routed through their servers. Cert Auth is a poor solution that only really works for the man-in-the-street because the root certificates are routinely distributed with browsers (Windows updates it's store once a week, IIRC). When did NI last update their users' LabVIEW CA file for the HTTPS Vis? What exactly is NI's policy on this and where is it documented?
  2. Signing is great but just be aware the weakness is key distribution. Not so much a problem with physical distributions but a concern over the internet depending on your threat model.
  3. Chinese, Russian and North Korean companies too? Excuse me if I'm not entralled by allowing M$/Intel/Apple/etc backdoors or control of what I can and can't run in an age where computers are always connected and OS telemetry is rife. I reject this dystopian sales pitch for "security" which is nothing more than a hardware version of Certificate Authorities aimed squarely at market control.
  4. Hmm. Just looked at my creatfile in the Zip Library. Seems I used "FNewRefNum" rather than a cast so I was obviously talking out of my backside. I guess I remembered all the stuff that didn't work rather than what did.
  5. Is that a consequence of using an intermediary DLL and "adapt to type" on the CLFN? Using the type cast at the LabVIEW level should mitigate this for TCP and file refs. Depends on what you want to do with them. Deleting the target? If the LabVIEW delete function is based on deletefile (and I can't remember off hand if it is because it doesn't take a filename), then deleting the target depends on the FILE_FLAG_DELETE_ON_CLOSE when calling createfile. I'll have to go back over this because I figured it out last time with the Zip library but for release, only needed long filename support (and even then, only for extraction). I added the methods to create and read the symlink attribute with a view to adding the functionality later after some bug reports. IIRC writing symlinks wasn't much of a problem, reading them were a little bit harder but shorcuts were a pain which I decided not to do. The file read and write only take a handle and don't care about most of these issues. Of course I haven't concerned myself with Mac and Linux.
  6. This is what I deduced for Windows. (It was a while ago, but this is what I recall) Casting the refnum to an integer reveals the same value as the windows file handle (from Process Hacker). Casting it back enables using the native LabVIEW functions. Casting the handle from CreateFileW to a LabVIEW file refnum also allows usage of all the native file functions(including delete) but the LabVIEW delete function isn't symlink aware (treats it as a normal file). The LabVIEW file functions just seem to be primitives of the windows functions *A (which is what can be seen in the imports table). <- this is rubbish It'd be nice if someone from NI confirmed that the file refnum is or isn't just a LabVIEW version of the windows file handle (perhaps with a reference count) but that's all it seems to be. I think it is like the TCP reference in that regard.
  7. Nothing what. It's just an interesting data presentation showing the rise and fall of languages over time. It's just a shame LabVIEW isn't on there.
  8. Neither is SQLite. My (brief) foray into this area was before those solutions were available.
  9. Well. SQLite doesn't let you use point cloud queries directly like LASTools or PGPointCloud. drjdpowell would be better to answer that question on how he did it.
  10. If you grew up on Fortran I would have hoped they had let you retire by now. No rest for the wicked?
  11. RTree just gives you a bounded nearest neighbour search. How you come up with those bounds is not within that scope.
  12. "Just". Without it, it would be a debugging nightmare and if I was coming up with that method, I would "just" think it wasn't working.
  13. Yup. On first glance I thought something could have been done with bytearraytostring etc. But the handle created isn't an array (in the LabVIEW sense) so a Moveblock would be needed to copy into another array to dereference it (double the memory required-not what we want). The really devious bit of your code is the sequence structure. That's some voodoo I probably would never have thought of.
  14. One of the requirements for 3d feature extraction is extracting datapoints in the neighbourhood of the feature. RTree is a good solution for that. RTree would give you the datapoints around your "finger", "elbow" and "shoulder" and you could draw lines between the centroid of those (giving you the lengths). Given you have three centroids you can then calculate the angle between the shoulder/elbow and finger/elbow.
  15. I have done this for VIP, and Zip packages for an installer I've had on the back burner for a while.
  16. I already have that superpower I once used lots of letters so that if you read the for loops top to bottom the letters spelt out my name and a message. I also once heard that wether you use "a" or "i" depends on if you came from a mathematical or engineering background. What's really stange (for me) is in C and PHP; I use "i". But in Pascal, and Python ; I use "a". I know that to a certain extent it is muscle memory since if I use "i" in Pascal, I nearly always leave out the colon before the equal sign. Maybe it's a coping mechanism because I switch between languages so much.
  17. There is DSMaxMem and DSMemStats which aren't much use. Do you have any info on DSMemStatsSlow and DSMemStats2?
  18. Did this today (and any other day I write C). for (int i=0; i < len; i++){ The big question is .. should it have been "a" instead of "i"?
  19. I think you answered your own question there and used the two term method that I described. This is exactly why I said:
  20. I don't think it's that hard. You just have to use two words, one of which describes the domain. Learning complexity, system, complexity, code complexity, network complexity et. al. They all adequately describe what's being talked about. I only had an issue with "accidental" complexity. When using non-domain terminology (like "accidental", "inherent" etc) it needs more defintion in the statement, for example "the inherent complexity of the code". The inherent complexity of the system, etc. This is mainly a grammatical problem rather than semantic.
  21. Thanks.It worked great but I don't think I'm going to go through the other 13 versions and installing it.
  22. Hmm. No 64 bit versions for 2009-2015. Thanks for the info.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.