Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am interested to hear how secure the source code is when compiled with MATLAB Compiler as of 2014? I read two threads on the subject from 2011 that states that there are security flaws.
In this thread from 2011 it is stated that the names of the source files are exposed to the users
http://www.mathworks.fr/matlabcentral/newsreader/view_thread/299373
In this thread from 2011 it is stated that m-files sometimes are exposed at obscure locations in the host system.
http://www.mathworks.com/matlabcentral/newsreader/view_thread/310932
Do anyone know if these flaws have been addressed?
All applications produced by the MATLAB Compiler (and related toolboxes) include an embedded CTF archive. This archive is embedded in the generated component (standalone EXE, shared DLL, Java packes, .NET assemblies, etc..) along with a target-specific boilerplate code to expose it as a binary component of the expected format.
The CTF archive contains all the MATLAB source and data of the project files in an encrypted form (AES encryption). The archive is extracted when the application runs for the first time (to a configurable cache location), files are then decrypted and executed in the context of the MCR runtime. So even though there will be a bunch of visible M-files inside the cache directory, they all in an encrypted form (no clear text code is ever written to disk).
You can read more about this in the documentation.
The way I see it, there is no glaring flaw here, and there never was... I don't think the names of the source files is something one worries about exposing!
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'm currently using MatLab 6.5 (it's a 2004 version), because the custom code files I need aren't compatible with newer versions.
I'm wondering what are the necessary steps to update those files.
Thanks very much to everyone reading!
Ideally, those files have associated unit tests, so you could have an indication on whether each of them runs correctly or not. Probably not your case.
If you can, try having both Matlab versions on your machine, then have a copy of the file sets to modify and another copy just to inspect and run in the old version for reference.
If changes are expected to be made on a per file basis, then start by opening each file and checking warnings. As good practice, never leave warning in .m files, and suppress those that you'll be accepting nominally. I.e. put %#ok<NASGU> or other warning code but not simply %#ok. Most upgrade related issues are indicated by warnings. You can check the current folder for such problems with mlintrpt (see here)
Then, there is a compatibility tool codeCompatibilityReport, simply typing this will explore folders in your current workspace, and you might just use that if you expect changes in general to be minor or not to be needed for every file.
Now, for simple files, these should be everything you need, I"d expect that after some debugging and relearning, you'd have a much smoother experience with a recent version of Matlab than with a 10+ years old version. For shorter-term updates, I would recommend to avoid switching versions mid-project.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
The community reviewed whether to reopen this question 9 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am writing some interfaces for my design in SystemVerilog, I have many of them. I was wondering if there are some specific guidelines regarding how to organize them.
right now I have all of my interfaces in one file. I was wondering if I should place each one of them in a separate file or all in one file. And if there are some specific guidelines on how to name the file(s).
Thanks.
Although the answer might seem opinionated, tools are designed with one file per design unit in mind, and the name of the file should match name of the unit. So if the name of the interfacer is foo, the name of the file should be foo.sv This way the tool can search a directory for files without having to specify them individually. The *.sv extension lets the tool know the file is writing in the SystemVerilog language.
Having one file per unit makes debugging easier and simplifies code coverage analysis. There might be other reasons with respect to project management for adhering to one file per unit, but those do get more opinionated.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am posting this question despite it possibly being off-topic, since I can't find a better place to ask:
I am publishing a scientific paper and use some analysis code which I want to be publicly available. I wrote a general purpose analysis library (Matlab) and put it onto github. Then there is a little script that uses that library for the specific purpose of this very paper. What is the best way to publish that script?
I see the following options where to publish this script:
publish into a new repository with only one file which is referenced in the paper (isn't that an overkill?)
append analysis script as supplementary information to the paper (not very accessible and usable for other people)
add to the same repository as the library (does not make sense since the library is general purpose while the script is for a single specific purpose)
Happy about any feedback, re-directions or discussions.
I don't know if the best method, but here's what I did with one of my own Matlab libraries, SHCTools, to make it publicly available for a journal article:
Created new branch of the repository (as opposed to an entirely new repository). This way the two are co-located, but the paper-specific branch can remain stable allowing readers to replicate results even after the main repository changes significantly.
Added a notice to the main branch's README.md file linking to the new stable branch.
Added a folder to the new stable branch containing M-files that re-create the figures in may paper (you could do the same with examples).
Adding a script as a supplemental resource (perhaps inside an examples or contrib directory) would seem like an acceptable and reasonably standard arrangement.
For a free-standing script, perhaps consider publishing it as a gist; this is a secondary service of Github for simple standalone snippets.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
For the past several years, I've been making small (single file, 1-500 line) scripts (mostly bash & python) to automate random tasks (usually scientific data analysis). Most of these end up being one-offs, but sometimes I want to go back and revisit/change something, or end up with a rather unwieldy script that could benefit from some sort of version control. I should note that all of these scripts are done solely on my own, and don't necessarily need to be share-able.
Which type of versioning (SVN,CVS,git,Mercurial..) Has the simplest command structure/syntax for my use case? More importantly, the machines I connect to are behind rather finicky kerberos walls, so I'm not looking for any sophisticated server-based implementation.
I found this thread from 2010 asking a similar question, though it didn't really talk about specific options, just whether or not I should be using a single repository.
In short, which versioning system allows for simple same-directory approach with minimal bells & whistles (only checkouts and commits needed)?
Should I set up some sort of subversion/CVS/git repository and just throw everything in?
Yes.
For your use-case, I suppose, SVN can be best choice (with URL-based access to every object in repo you can easy and fast get access to any single file any revision of file and for your linear history "not the best" merge in SVN isn't problem). Local file:///-based repository will require minimum of maintenance. You can use single-repository, flat tree (all files in /trunk)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Essentially, I have an interesting Perl script that I want to put on Github / other places that I want to be re-distributable but I do not want anyone compiling it and then redistributing it (yes I know the source would be included with certain licenses - but I don't want it to ever be compiled at all).
Those who can figure out how to use CPAN, etc, to set it up - I want them to be able to use it and redistribute it in source format but is there a way of restricting the compilation and then redistribution. I only want to allow users to redistribute in source.
Your requirements are at odds with each other. The first step of running a Perl 5 program is compiling. Your best bet is the GPLv3, it requires anyone who distributes a compiled version to also provide a method to retrieve the source.
Most of the methods of making a binary out of a Perl 5 script (which I think you are confusing with compiling) aren't actually compiling. They are packaging. The source is still present in the binary and is compiled at run-time by an included copy of the perl binary.