Products Openwall GNU/*/Linux   server OS Linux Kernel Runtime Guard John the Ripper   password cracker Free & Open Source for any platform in the cloud Pro for Linux Pro for macOS Wordlists   for password cracking passwdqc   policy enforcement Free & Open Source for Unix Pro for Windows (Active Directory) yescrypt   KDF & password hashing yespower   Proof-of-Work (PoW) crypt_blowfish   password hashing phpass   ditto in PHP tcb   better password shadowing Pluggable Authentication Modules scanlogd   port scan detector popa3d   tiny POP3 daemon blists   web interface to mailing lists msulogin   single user mode login php_mt_seed   mt_rand() cracker Services Publications Articles Presentations Resources Mailing lists Community wiki Source code repositories (GitHub) Source code repositories (CVSweb) File archive & mirrors How to verify digital signatures OVE IDs What's new

Date: Wed, 1 Apr 2020 19:42:38 -0400
From: Jeffrey Walton <noloader@...il.com>
To: oss-security@...ts.openwall.com
Subject: Deficient engineering processes

Hi Everyone,

Forgive my ignorance. I'm wondering how to handle deficient
engineering processes, and I hope folks can share their thoughts.

As I understand development lifecycles, there are 5 steps. The class I
took in college taught them as SADIE: Survey, Analysis, Design,
Implementation and Evaluation. I find a lot of projects have
deficiencies in Implementation and Evaluation.

Implementation is what most people think of with software. It is the
actual code. Implementation problems are usually handled through a bug
tracker. Implementation problems are usually instance problems. They
are an instance of a bigger class of problems the project may be
vulnerable to.

Evaluation is usually not handled. Evaluation is the feedback cycle,
and it is where postmortem analysis are supposed to be performed. The
postmortem analysis should reveal why an instance problem occurred.
Results from the analysis create changes, which are then fed back into
the the process and the cycle repeats.

For example, suppose a bug is reported for an undefined behavior
sanitizer finding. The developer may (or may not) fix the finding. At
the Evaluation phase, the postmortem should reveal why the bug
surfaced and why the project did not detect the defect. The postmortem
usually reveals a defective engineering process. For example, the
Continuous Integration pipeline may not include a job to build with
sanitizers.

My question is, how to convince someone that following standard
project management procedures is a good thing? How do we get them
onboard with improving their engineering processes? Especially the
evaluation phase, and leveraging a continuous integration pipeline to
detect errors before they are released to users?

I know the GNU Coding Standards does not help here. It lacks the
treatment of lifecycles and evaluation/feedback phase. It also lacks a
recommendation for a continuous integration pipeline so many GNU
projects do not use one. GNU Coding Standards also recommends "worse
practices", like encouraging memory leaks which breaks testing. (The
memory leaks are some of the worse advice I have seen in print.
Attempts to get it corrected have fallen on deaf ears).

Thanks in advance.

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.