Review the security policy with respect to the apps

[mattcaswell]

We should review the security policy with respect to the apps.

For example how should we handle server based apps such as s_server and ocsp? Do we consider these hardened security servers - or for test/demonstration purposes only? How should we treat security issues in them?

[romen]

After we review the security policy, we should also plan to add appropriate disclaimers as comments at the beginning of the code in apps/, pointing to the security policy and the intended usage/level of security guarantees for each app.

It's important for part of our communities to discover/be warned about the experimental/demonstrative/testing/unsafe nature of that code when perusing through their sources.

[baentsch]

As a suggested set of activities to move this issue to "Refinement" stage, what about these concrete steps:

• [ ] Add an explicit section to security policy file explaining that some parts of the code are considered "experimental" or "best effort" while others follow the strict security (disclosure & remediation) policy outlined in the (existing part) of the document; note: baseline statement to this effect already present in "LOW" category. I'd personally also add the disclaimer that all code not marked "experimental" is/remains fully supported in this regard.
• [ ] Decide which code components (directories? single files?) fit into the "experimental" category and as per suggestion by @romen add corresponding, explicit disclaimers (proposal "LIMITED SECURITY SUPPORT") to the code files of such components; for starters, this might be every app (until requests are raised to change this).
• [ ] As an optional step, develop a tool that extracts all components marked as per the above such as to be able to create a summary list of "lower security support tier" components (to be possibly listed in the new security policy or referenced from it).