Once I tried to start a fair discussion... :)

[xhunaudio]

@jules :

Just a side note : 99.99999999999......% of the "Cyberprank malware" flaws described on this thread could be addressed with a simple MD5 checksum.

If in the future you are going to codesign SOUL packs/patches, please consider to handle that with care : try to make it as a simple, free and cross-platform procedure - otherwise the SOUL patches diffusion may be penalized (specially for freeware ones)...

[Vokbuz]

Erm.. no.. I "confirmed" that obviously anyone who can write to your files can change the content of those files. But I suspect any malicious attacker which had that kind of access would be busy encrypting your hard-disk for ransom rather than trying to make your DAW play a noise burst.

Yes: code-signing soul programs is certainly on our roadmap, and maybe in future, some (most?) SOUL back-end drivers or hardware devices might decide to reject programs that aren't signed. but that'll be up to the vendors to decide.

But given that we specifically designed SOUL's architecture to give it a huge head start over native code in terms of security, and since native executables themselves are only recently starting to get code-signed, I wouldn't really expect anyone to worry much about that aspect for some time. It'd be like code-signing WASM or GLSL. Sure, there will be situations where that makes sense, but people mainly trust the sandbox and host to prevent really egregious stuff getting through.

Everything you wrote is correct but you shifted the point from "because SOUL simply can't contain malware of any sort" to "it is very unlikely that it will contain that malware". My point is that SOUL code can potentially be malicious. If you don't argue with this, let's stop here.

[jules]

My point is that SOUL code can potentially be malicious. If you don't argue with this, let's stop here.

Sorry, no. You've not won that argument.

If by "malicious" you mean that an attacker could construct buffer overflows or other tricks to invoke their own native code, escape the sandbox and compromise the machine, then our whole design is aimed at making that impossible. Any VM for any language could have exploitable bugs, so I can't prove ours doesn't, but we claim that the underlying design is robust.

If by "malicious" you mean that someone could write code that makes a nasty noise, then sure.. we're not going to dictate who can write a program or what that program can do. It's up to a host to decide their policy for considering code safe to run, whether that's by only loading signed patches, or by just putting a big limiter on the output, or some other random criteria.

As far as the underlying tech goes, our job extends as far as preventing an attacker launching a dangerous attack, but not to put any other limits on the code it can run.

[wrl]

Just a side note : 99.99999999999......% of the "Cyberprank malware" flaws described on this thread could be addressed with a simple MD5 checksum.

Aha, but what stops an attacker from also modifying the known-good MD5 checksum you're comparing against?

[wrl]

If by "malicious" you mean that an attacker could construct buffer overflows or other tricks to invoke their own native code, escape the sandbox and compromise the machine, then our whole design is aimed at making that impossible. Any VM for any language could have exploitable bugs, so I can't prove ours doesn't, but we claim that the underlying design is robust.

Yeah, this is the threat vector here. At this point, there's enough work in capability-based security for all of the major platforms that you'll be able to couple a robust runtime design with the platform-provided security features for a solid multi-level defense.

As a matter of perspective, it's important to note that the days of a use-after-free or a buffer overrun suddenly giving full execution control to shellcode are largely over. If you take a look at any of the Pwn2Own results, the successful exploits against desktop software have to leverage multiple vulnerabilities. First, there's the initial foothold, which often is UAF or buffer-related – but this gets complicated by ASLR, so you need to couple a memory-write vulnerability with some information disclosure vulnerability – then if you're in a sandbox (which, in a browser you are), you need to find a way out of the sandbox (potentially a multi-step process as well).

A concern, certainly, but most of the low-hanging fruit is gone.

[Vokbuz]

If by "malicious" you mean that an attacker could construct buffer overflows or other tricks to invoke their own native code, escape the sandbox and compromise the machine, then our whole design is aimed at making that impossible.

If by "malicious" you mean that someone could write code that makes a nasty noise...

My example of attack was neither of these. You didn't read the whole discussion above, right?

It is not a surprise that "whole design is aimed at making that impossible" but this is what almost every software in the world is aimed at. Still people are able to escape two levels of sandboxes (browser + vm this browser runs in). Saying that SOUL can't have "malware of any sort" is either ignorance or marketing bs.

[xhunaudio]

@wrl : ...simply because the MD5 checksum code string (to cmpare to) is stored on MY own website But that's not the point. What I said (MD5 checksum) was just to point out what a FALSE problem is that (cyberprank) "malware" issue mentioned in this thread... I didn't say that because I'm a MD5 fan in particular.

Please (everybody) - this discussion is becoming a general nonsense... Please, we have the chance to talk about something very interesting here (HC, DSA) and we can take this opportunity to learn about how things like SOUL really work in detail, directly from its creators.

Again, I think you are all good guys and no one wants to deprive you of respect, but please stop with this out-of-mind "malware" grumbles. It will just kill any fair discussion here.

[mystran]

Just a side note : 99.99999999999......% of the "Cyberprank malware" flaws described on this thread could be addressed with a simple MD5 checksum.

Aha, but what stops an attacker from also modifying the known-good MD5 checksum you're comparing against?

I know this is offtopic, but PLEASE don't use MD5 for "security" as the algorithm was broken some 20 years ago and this isn't some theoretical thing.. you can essentially find collisions "on demand" as long as you can include a block of junk in your modified file. As a cryptohash, MD5 is completely useless these days.

edit: this also applies (at least potentially) to SHA-1 (although it takes somewhat more serious computation power to collide these, compared to MD5 which is just a total joke), so please use some modern hash

[wrl]

@wrl : ...simply because the MD5 checksum code string (to cmpare to) is stored on MY own website But that's not the point. What I said (MD5 checksum) was just to point out what a FALSE problem is that (cyberprank) "malware" issue mentioned in this thread...

If you're serious about security, this is bad advice and you shouldn't do it. Your validation scheme is now only as secure as your website, and furthermore assumes that the website will be up and available to access (which, according with the prevalence of studio computers kept off-line, isn't a safe bet in audio).

Just sign the code. Public-key cryptosystems without chain of trust are quite easy these days. Libsodium is small compared to just about everything else.

"Ah, but how do you protect against people just patching out the public key?" Firstly, you verify before you run it, or you resort to a chain of trust if you really need it. And then we're back to where we started in this discussion.

I know this is offtopic, but PLEASE don't use MD5 for "security" as the algorithm was broken some 20 years ago and this isn't some theoretical thing.. you can essentially find collisions "on demand" as long as you can include a block of junk in your modified file. As a cryptohash, MD5 is completely useless these days.

edit: this also applies (at least potentially) to SHA-1 (although it takes somewhat more serious computation power to collide these, compared to MD5 which is just a total joke), so please use some modern hash

As usual, mystran is 100% on the money. MD5 is broken, SHA1 is hanging on by a thread.
SHA2 is great, SHA3 is also great. BLAKE2b is as great as SHA3 (despite losing in the finals to Keccak) and is also blisteringly fast.

And, while we're here: don't hash user passwords, use PBKDF2 or scrypt or bcrypt or ARGON2.

[xhunaudio]

C'mon guys, I just made a kind provocation : I used indeed the term " 99.99999999999......% of the Cyberprank malware"...

I don't want to really use *specifically* a MD5 (the real point is that I have *nothing* to do with ROLI/JUCE/SOUL strategies and developments at all).

Again, I just mentioned that aspect (MD5) just to stop the strange "detour" the thread was taking - because some people made 1000 posts in the passed 2 days claiming that the entire trillions-dollars DSA/heterogeneous computing industry (Intel Corp, Microsoft Corp, etc...) is not secure because Trinity, Morpheus and Neo could make your plugin to emit "noisebursts"...

Let's stop with that and let's start a fair discussion, everyone's invited !

[Vertion]

Have you tried re-routing the MD5 hash to the OC3 optical line?

The only way SOUL will be adppted here is if its creators are willing to publicly renounce control over it so that it becomes a free standard, and that no less than 2 major DAWs adopt it. This forum would probably be the best place to build momentum for it by linking resources, tutorials, and examples to onboard the community.

[jules]

The only way SOUL will be adppted here is if its creators are willing to publicly renounce control over it so that it becomes a free standard, and that no less than 2 major DAWs adopt it.

The compiler is out under a permissive ISC license. The EULA allows anyone to freely build hardware or software that uses it. Waveform will ship with support for it in a few days. We're already talking to multiple hardware manufacturers about adding SOUL processing in commodity i/o hardware. (Hey, I also happen to own http://www.prismsound.com ). There are going to be some very cool special guests showing off SOUL integration in hardware devices at ADC next week. We're well-connected and we've got a lot going on!

Your point about wanting its creators to renounce control is mistaken though - on the contrary, that'd kill the whole thing. We want large companies to commit entire product lines to this technology over many years. For them, the idea of committing to a rudderless project would be a complete no-starter. Open-source, yes, but nobody would risk committing to a project that could suddenly go off in a random direction or be abandoned or splintered into competing factions.. They need to know exactly who's in charge, and to trust them, and they'll often even pay for the privilege of being involved in the roadmap.

Seriously, this project has been insanely difficult.. I'd never have bothered putting myself through the hassle of doing it if we didn't think it had a fighting chance of becoming a standard!

[Vokbuz]

Again, I think you are all good guys and no one wants to deprive you of respect, but please stop with this out-of-mind "malware" grumbles. It will just kill any fair discussion here.

Isn't it you who first wrote questionable (let's use this term) statement about malware in SOUL and contributed to discussion around it? I really don't want to be hostile, sorry if it sounds so. Do you suggest people to ignore questionable statements on the forum? I have nothing against SOUL (or any other technology) but let's not idealise it.

The thread (at least in the beginning) is an attempt to "sell"* us SOUL (pun is not intended) but you can't "sell" me anything with questionable "selling points".

* While I'm using the word "sell" I do not mean that you are somehow affiliated with ROLI or SOUL.

[jules]

Ah.. KVR.. Whenever I come here I'm reminded why I so rarely come here.

[KenjiDeVries]

I would love to see it broken down into a simple example: let's say I want to build an EQ like FabFilter.

a) What part is written in SOUL? Is it the calculation of filter coefficients? Or the the applying of the filter itself? Maybe the computation of the frequency spectrum that's in the background? The whole plugin?

b) What is the exact advantage of knowing SOUL is now compiled in the webbrowser or on a Avid HD interface in our ficitonal EQ example? Does SOUL now abandon my secret filter calculation formula and decides to compile it to a better performing but different filter specifically on Avid interfaces?

c) What about external libraries like the widely used Intel Performance Primitives to calculate the spectrum?

I get that SOUL is more of another abstraction layer but it's hard for me to see the big benefit besides implementing just another standard. I mean VST2 is also widely supported and free, still there are dozens of alternatives that need to be supported. Why should that change with SOUL? Probably just a knot in my brain