CII Best Practices LegerSMB issues
Work in progress, please feel free to join the effort
The intent is to get the Gold Badge for LedgerSMB and it`s sub projects. The first step to the Gold Badge is to pass the Silver Badge.
By June 2018 we have reach [the Standard Badge] and are closing in on the Silver Badge. We are on the first page (if you sort by % completed) only 10 places behind the Linux kernel
Some of the issues to pass are quite easy to implement, and some require a lot of work (80% coverage on test.. we are currently at 
contributor license assignments
"It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release." https://en.wikipedia.org/wiki/Dynamic_program_analysis https://www.owasp.org/index.php/Fuzzing
Report Summary www.ledgersmb.org : Missing Headers Strict-Transport-Security Content-Security-Policy X-Frame-Options X-XSS-Protection X-Content-Type-Options Referrer-Policy https://securityheaders.com/?q=https%3A%2F%2Fwww.ledgersmb.org ledgersmb.org: Missing Headers https://securityheaders.com/?q=https%3A%2F%2Fledgersmb.org%2F
Javascript scanning implemented (2020) : https://lgtm.com/projects/g/ledgersmb/LedgerSMB
We should add : Developer Certificate of Origin (DCO), https://developercertificate.org/ to the process and code
ehuelsmann: yea. that feels like a lot of red tape, really, to have to do that on every commit! Can't I just say that "I hereby solemly swear that any code I commit is really mine"?
hasorli: "git directly supports a "signed-off" feature using "commit -s"
ehuelsmann: yup. but then I have to remember to type git commit -s. I sometimes even forget [skip ci]. Forgetting skip ci isn't all that important, but it's annoying. Forgetting -s will be important.
jame_mx :I just usually sign tags ... ehuelsmann: Jjame_mx: right. but this isn't about signing code to ensure authenticity. It's to "sign off on code, meaning it's yours to give away"
jame_mx I rally don't see the difference; that's already in the license.
hasorli this MAY be implemented as a Contributor License Agreement (CLA)" : Apache does this: https://www.apache.org/licenses/ by email. We could to it by some way of writing "accept" in the commit log to a "sign document" for the CLA.
ehuelsmann hasorli: how about https://github.com/jitsi/cla-enforcer
ehuelsmann or even https://github.com/salesforce/dr-cla or http://clabot.github.io/#getting-your-own anyway, it seems we can do with other options which don't need to be there on every commit. there's very little room for a CLA in the Apache sense: there's no accepting org.
hasorli The boot idea looks like a nice route. I am not a fan of the paperwork process that some of the projects involve. If we can add some kind of digital signing process, with no single point of failure for the storage of the signed documents. (by example git solves that..)
ehuelsmann yea. I like that too. however, do we require people to set up gpg? or would having them agree to the bot's conditions through their GitHub authentication (logging their IP and maybe other stuff?) be enough? the other thing in the silver class that I'm more worried about (for quite some time already) is the "bus factor" we have many single points of failure.
hasorli A github login that are used for the commits should do.
ehuelsmann agreed.
hasorli Some of the "bus factor" are fixable - the easy one is control of the ledgersmb.org domain.
ehuelsmann actually control of ledgersmb.org is very easy: Gandi.net support creation of "organisations" so we could put all core members there.
hasorli If we fix the domain and the releasee keys we can tick off "project MUST be able to continue with minimal interruption if any one person is incapacitated or killed."
ehuelsmann I wanted to switch to signing the release with individual keys where the individual keys are listed in a document in the repository. preferably a document signed by multiple people in the core committee. then we would not need a "central" key anymore. the Subversion project requires multiple signatures from core committee members. all using their own key. I'm not sure we need multiple signatures. ideally, we don't.
hasorli I think one personal signature is ok.
ehuelsmann I would like to release a list of public keys to be included in every release from which "next" releases could be expected.
hasorli That solves the "single key" lock in. E ehuelsmann yea. I think that would be a good next step. also, if we script the setup of a release node, that removes the issue with a single release environment. I actually already started working on that, so that's not too far away.
hasorli I have not run the "truck-factor tool " - have you ?
hasorli Do we pass this: " If the project sites (website, repository, and download URLs) store passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., PBKDF2, Bcrypt or Scrypt). " E