GNU/consensus/markers
Contents
Introducing GNU Consensus Markers
We use semantic markers to enrich the metadata of reviewed software.
Markers are shown as labels and lead to project information about specific issues, how they affect the software and its usage, what is being done to address them, including open tickets and mailing-list discussions.
Usage
Markers use templates and semantic forms.
{{Marker SectionOrPageName}}
The Marker template displays a linked button leading to a section or page where detailed information about the issue at hand can be found.
Types of Markers
Bad Cryptography Marker
This marker indicates a problem with cryptography, either known vulnerabilities or potential issues with the cipher, including weak cryptography or suspect ciphers. An example would be for a system to rely on NIST curves instead of Curve25519, or a system using Curve25519 but with improper handling.
{{CRAPTO SectionOrPageName}}
Bizantine Failure Marker
This marker indicates the system is not Bizantine resilient, thus vulnerable to Bizantine Fault or Failure, where an attacker can confuse the network consensus over distributed properties, provoking a denial of service, from malfunction and delay to complete system collapse.
{{BIZANTINE SectionOrPageName}}
BOFH Marker
This marker indicates that the software requires system administrators who have access to private information, such as passwords or database access, that no external attacker could normally obtain. Depending on an administrator may be useful for non-technicians, e.g., for information recovery, but open all users of the system to vulnerabilities if the system is compromised.
BOFH means Bastard Operator From Hell, and is named after
{{BOFH SectionOrPageName}}
SPOF Marker
The Single Point of Failure marker indicates a potential vulnerability that would prevent the software from functioning properly, or at all, by compromising only a specific part of the system.
{{SPOF PageName}}
