Update of "Experiment: mmmv_silkexec"
Not logged in

Artifact ID: 0d29e4aa0bdbf5673d4dc7bf5e75f4b8731171e7
Page Name:Experiment: mmmv_silkexec
Date: 2017-01-07 17:29:02
Original User: martin_vahi
Parent: f22d35648d20cd1e29eb23abe062958f33488cd2 (diff)
Next feb71f02c11be824a9429dbde798a39e346dcc87

A mmmv_silkexec application is wrapper to other applications, including other mmmv_silkexec applications. The purpose of the wrapping is to use extra tags and user specific configuration parameters for using the wrappable application.

The mmmv_silkexec consists of the following parts:

No technical solution is going to compensate for crappy work, because technical tools can be switched off or the original authors of software may leave edge cases out of consideration, but the main idea behind the mmmv_silkexec is to allow the execution of only those mmmv_silkexec applications that have been tested and/or verified by a trusted party. The executable mmmv_silkexec application must have only dependencies that have also been verified and/or tested by trusted parties. 

Different parties trust different other parties. Trust is a multidimensional value. A very kindhearted and not corrupt person can be totally untrustworthy from their capabilities point of view. On the other hand, sometimes, at some narrow contexts, enemies can be more trustworthy than friends. For example, enemies might have a good track record of fine skills and being rigorous and they might use some component, software package, at some security wise extremely critical role, while being very rigorous at the construction of their software component.

Given that the only proper way to verify/review code is a fully automated way, there has to be a way to subscribe to the testing/verification system of the trusted parties. To avoid a Denial of Service attack by hacking into the testing/verification systems of one of the trusted parties, the local settings of the mmmv_silkexec should treat a test failure of a formerly accepted component as a timed warning, where the warning state moves to a blocked/failed state with a delay. The delay gives the trusted party time to handle the hack.