I would also like to find out what people use Menuet for (my own interest is cross-development for micro-controllers).
Note that distributing programs closed-source can mean two things:
1.) You distribute an executable that is written in FASM. The downside here is that disassembly is easy, so an attacker can easily
obtain source-code that can be assembled with FASM, although it will not have your label-names, comments, etc..
The major downside is that the user can't be assured that your program is not malware, so the user will be hesitant to run
your program for fear that your program is covertly searching his hard-disk for credit-card numbers and/or passwords.
Another downside is that you have to program in FASM which is (for me) difficult, so this does not work well for light-weight
programs that aren't worth spending a lot of time on. Linux has Python, Perl, etc. for light-weight programs; nobody uses FASM.
2.) You distribute an encrypted binary-overlay (app) for a VM for a language designed specifically to be secure.
The upsides are that this should work to prevent attackers from obtaining any kind of source-code, and should assure the user
that your program is not malware (because your program can't access the hard-disk outside of the current directory).
The downsides are that HLL code is not as efficient as assembly-language, and (more importantly) Ville is strongly opposed
to corrupting Menuet with HLL code --- he is very proud of the fact that Menuet is all assembly-language.
What I have found, is that the FASM forum is very focused on code being open-source. This is so maintenance programmers
can obtain source-code. Their goal is to have somebody else be the "pioneer" who writes 95% of the program, then they
step in and write 5% of the program and claim credit for 100% of the program --- a "hostile fork."
I already discussed this on the FASM forum:
https://board.flatassembler.net/topic.php?t=21674
Revolution, and others, totally shot me down:
Personally, I think that Meltdown, RowHammer and Spectre are urban-legends. This isn't real. This is somebody's vague speculationrevolution wrote:You declare that SecureForth will be secure, but discuss only a small subset of actual security problems that happen. You haven't addressed anything for Meltdown, RowHammer or Spectre. Plus whatever future problems show up.
Banning assembly or HLL won't make your language secure. Things can be insecure, not because of the language, but things outside of the language. Things that you have no control over. And the language (any language) is used as leverage to exploit such problems. There is literally nothing that you can do, aside from deleting everything, that will make your code bypass all possible security problems.
about how a secure system could be attacked, and then pseudo-experts read about this in internet articles and begin to
represent themselves as experts on the subject, although they have not written any code, or even seen an successful attack done.
I think that it is possible to write an HLL that is secure in the sense that programs written in this HLL can be distributed
closed-source so attackers can't obtain the source-code, and users can be assured that the programs aren't malware.
I would think that Menuet users would be especially interested in a secure system that prevents attackers from obtaining source-code,
because Menuet has already been attacked --- Kolibri is a hostile-fork of Menuet --- this is why the 64-bit version of Menuet is
closed-source now. Users of Menuet aren't secure though. I started writing Simple51 in FASM for the 64-bit Menuet, but gave up on that,
one reason being that the Kolibri attackers could easily steal it (it was 64-bit, but almost all of the registers used were 8-bit or 16-bit
so it would be trivial to convert the program into 32-bit to run under Kolibri.