Difference between revisions of "GNU/consensus/markers"

From LibrePlanet
< GNU‎ | consensus
Jump to: navigation, search
(First pass at GNU consensus markers for software weaknesses)
 
(Finish the sentence :P)
 
(3 intermediate revisions by the same user not shown)
Line 15: Line 15:
 
== Types of Markers ==
 
== Types of Markers ==
  
=== SPoF Marker ===
+
=== Bad Cryptography Marker ===
  
The Single Point of Failure marker indicates a potential vulnerability that would prevent the software from functioning properly, or at all.
+
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.
 +
 
 +
<nowiki>{{CRAPTO SectionOrPageName}}</nowiki>
 +
 
 +
[[Template:CRAPTO]]
 +
 
 +
=== Bizantine Failure Marker ===
  
<nowiki>{{SPOF #Spof}}</nowiki>
+
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.
<nowiki>{{SPOF PageName}}</nowiki>
+
 
 +
<nowiki>{{BIZANTINE SectionOrPageName}}</nowiki>
 +
 
 +
[[Template:BIZANTINE]]
  
=== Admin Marker ===
+
=== 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.
 
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.
  
<nowiki>{{ADMIN SectionOrPageName}}</nowiki>
+
BOFH means [http://bofh.ntk.net/BOFH/ Bastard Operator From Hell], and is named after the eponymous humorous series.
  
=== Bizantine Marker ===
+
<nowiki>{{BOFH SectionOrPageName}}</nowiki>
  
This marker indicates the system is vulnerable to Bizantine Failure, where a sophisticated attacker can isolate the user into believing she's still on the global network, while in fact she's acting within a restricted simulation controlled by the attacker.
+
[[Template:BOFH]]
  
<nowiki>{{BIZANTINE SectionOrPageName}}</nowiki>
+
=== SPOF Marker ===
  
=== Crypto 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.
  
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.
+
<nowiki>{{SPOF PageName}}</nowiki>
  
<nowiki>{{CRYPTO SectionOrPageName}}</nowiki>
+
[[Template:SPOF]]

Latest revision as of 08:30, 20 December 2015

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}}

Template:CRAPTO

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}}

Template:BIZANTINE

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 the eponymous humorous series.

{{BOFH SectionOrPageName}}

Template:BOFH

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}}

Template:SPOF