79 lines
5.0 KiB
HTML
79 lines
5.0 KiB
HTML
<h1 id="1-cissdebianlivebuilder">1. CISS.debian.live.builder</h1>
|
|
<p><strong>Centurion Intelligence Consulting Agency Information Security Standard</strong><br> <em>Debian Live Build Generator for hardened live environment and CISS Debian Installer</em><br> <strong>Master Version</strong>: 8.02<br> <strong>Build</strong>: V8.03.127.2025.06.02<br></p>
|
|
<h1 id="2-coding-style">2. Coding Style</h1>
|
|
<h2 id="21-pr">2.1. PR</h2>
|
|
<p>You'd make the life of the maintainers easier if you submit only <em>one</em> patch with <em>one</em> functional change per PR.</p>
|
|
<h2 id="22-documentation">2.2 Documentation</h2>
|
|
<p>Some people really read that ! New features would need to be documented in the appropriate section in <code>usage()</code> and in <code>~/docs/DOCUMENTATION.md</code>.</p>
|
|
<h2 id="23-coding">2.3. Coding</h2>
|
|
<h3 id="231-shell--bash">2.3.1. Shell / bash</h3>
|
|
<p>Bash is actually quite powerful—not only with respect to sockets. It's not as mighty as perl or python, but there are a lot of neat features. Here's how you make use of them. Besides those short hints here, there's a wealth of information there.</p>
|
|
<ul>
|
|
<li>Don't use backticks anymore, use <code>$(..)</code> instead</li>
|
|
<li>Use double square <code>[[]]</code> brackets (<em>conditional expressions)</em> instead of single square <code>[]</code> brackets</li>
|
|
<li>In double square brackets, avoid quoting at the right-hand side if not necessary. For regex matching (<code>=~</code>) you shouldn't quote at all.</li>
|
|
<li>The <a href="http://mywiki.wooledge.org/BashPitfalls">BashPitfalls</a> is a good read!</li>
|
|
<li>Whenever possible try to avoid <code>tr</code> <code>sed</code> <code>awk</code> and use bash internal functions instead, see e.g., <a href="http://www.cyberciti.biz/tips/bash-shell-parameter-substitution-2.html">bash shell parameter substitution</a>. It is slower as it forks, fopens and pipes back the result.</li>
|
|
<li><code>read</code> often can replace <code>awk</code>: <code>IFS=, read -ra a b c <<< "$line_with_comma"</code></li>
|
|
<li>Bash can also deal perfectly with regular expressions, see e.g., <a href="https://www.networkworld.com/article/2693361/unix-tip-using-bash-s-regular-expressions.html">here</a> and <a href="https://unix.stackexchange.com/questions/421460/bash-regex-and-https-regex101-com">here</a>. You can as well have a look @ <code>is_ipv4addr()</code> or <code>is_ipv6addr()</code>.</li>
|
|
<li>If you still need to use any of <code>tr</code>, <code>sed</code> and <code>awk</code>: try to avoid a mix of several external binaries e.g., if you can achieve the same with e.g. <code>awk</code>.</li>
|
|
<li>Be careful with very advanced bash features. Mac OS X is still using bash version 3 (<a href="http://tldp.org/LDP/abs/html/bashver4.html">differences</a>).</li>
|
|
<li>Always use a return value for a function/method. 0 means all is fine.</li>
|
|
<li>Make use of <a href="https://github.com/koalaman/shellcheck">shellcheck</a> if possible.</li>
|
|
<li>Follow the <a href="https://google.github.io/styleguide/shellguide.html">shellformat</a> Shell-Style Guide.</li>
|
|
</ul>
|
|
<h3 id="232-shell-specific">2.3.2. Shell specific</h3>
|
|
<ul>
|
|
<li>Security:
|
|
<ul>
|
|
<li>Watch out for any input especially (but not only) supplied from the server. Input should never be trusted.</li>
|
|
<li>Unless you're really sure where the values come from, variables need to be put in quotes.</li>
|
|
</ul></li>
|
|
</ul>
|
|
<h3 id="233-variables">2.3.3. Variables</h3>
|
|
<ul>
|
|
<li>Use <strong>"speaking variables"</strong> but don't overdo it with the length.</li>
|
|
<li>No <em>camelCase</em>, please. We distinguish between lowercase and uppercase only.
|
|
<ul>
|
|
<li>Global variables:
|
|
<ul>
|
|
<li>use them only when really necessary,</li>
|
|
<li>in CAPS,</li>
|
|
<li>initialize them (<code>declare -g VAR_EXAMPLE=""</code>),</li>
|
|
<li>SHOULD start with:
|
|
<ul>
|
|
<li><code>ARY_</code> for Arrays,</li>
|
|
<li><code>C_</code> for Variables defining colored outputs,</li>
|
|
<li><code>ERR_</code> for Error Codes Variables,</li>
|
|
<li><code>HMP_</code> for HashMap Arrays,</li>
|
|
<li><code>LOG_</code> for Logfile Variables,</li>
|
|
<li><code>PID_</code> for PID Variables,</li>
|
|
<li><code>PIPE_</code> for PIPE Variables,</li>
|
|
<li><code>VAR_</code> for Variables</li>
|
|
</ul></li>
|
|
</ul></li>
|
|
<li>Local variables:
|
|
<ul>
|
|
<li>are lower case,</li>
|
|
<li>declare them before usage (<code>declare</code> eq <code>local</code>),</li>
|
|
<li>initialize them (<code>declare var_example=""</code>),</li>
|
|
<li>SHOULD start with:
|
|
<ul>
|
|
<li><code>ary_</code> for Arrays,</li>
|
|
<li><code>c_</code> for Variables defining colored outputs,</li>
|
|
<li><code>err_</code> for Error Codes Variables,</li>
|
|
<li><code>hmp_</code> for HashMap Arrays,</li>
|
|
<li><code>log_</code> for Logfile Variables,</li>
|
|
<li><code>var_</code> for Variables.</li>
|
|
</ul></li>
|
|
</ul></li>
|
|
</ul></li>
|
|
</ul>
|
|
<h1 id="3-misc">3. Misc</h1>
|
|
<ul>
|
|
<li>Test before doing a PR! Best if you check with two bad and two good examples, which should then work as expected.</li>
|
|
</ul>
|
|
<hr />
|
|
<p><strong><a href="https://coresecret.eu/">no tracking | no logging | no advertising | no profiling | no bullshit</a></strong></p>
|
|
|