# CII Best Practices Badge **URL:** \ **Category:** Improvement Ideas\ **Created:** [December 14, 2018, 7:28pm UTC](https://librepcb.discourse.group/t/cii-best-practices-badge/15 "2018-12-14T19:28:57Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![import](https://avatars.discourse-cdn.com/v4/letter/i/4da419/32.png) [@import](https://librepcb.discourse.group/u/import)\ **Post date:** [December 14, 2018, 7:28pm UTC](https://librepcb.discourse.group/t/cii-best-practices-badge/15/1 "2018-12-14T19:28:58Z")
_From @ubruhin on Thu Feb 15 2018 12:19:48 GMT+0000 (UTC)_ @dbrgn wrote: > Might be good to add the CII best practices badge to the README 🙂 > > [https://bestpractices.coreinfrastructure.org/](https://bestpractices.coreinfrastructure.org/) > > It’s quite some work to fill all the forms, but it can be done step by step. Imported from [CII Best Practices Badge · Issue #219 · LibrePCB/LibrePCB · GitHub](https://github.com/LibrePCB/LibrePCB/issues/219) _Copied from original issue: [CII Best Practices Badge · Issue #3 · LibrePCB/librepcb-rfcs · GitHub](https://github.com/LibrePCB/librepcb-rfcs/issues/3)_ ---
**Author:** ![import](https://avatars.discourse-cdn.com/v4/letter/i/4da419/32.png) [@import](https://librepcb.discourse.group/u/import)\ **Post date:** [December 14, 2018, 7:28pm UTC](https://librepcb.discourse.group/t/cii-best-practices-badge/15/2 "2018-12-14T19:28:58Z")
_From @dbrgn on Thu Feb 15 2018 12:21:50 GMT+0000 (UTC)_ If I have some time, I can go through the catalogue and list the things here that would need to be changed to get more points. (@ubruhin if you agree you can assign me this issue.) ---
**Author:** ![import](https://avatars.discourse-cdn.com/v4/letter/i/4da419/32.png) [@import](https://librepcb.discourse.group/u/import)\ **Post date:** [December 14, 2018, 7:28pm UTC](https://librepcb.discourse.group/t/cii-best-practices-badge/15/3 "2018-12-14T19:28:58Z")
_From @ubruhin on Thu Feb 15 2018 12:40:24 GMT+0000 (UTC)_ \> If I have some time, I can go through the catalogue and list the things here that would need to be changed to get more points. 👍 I already created the project so we have a point to start: [https://bestpractices.coreinfrastructure.org/projects/1652](https://bestpractices.coreinfrastructure.org/projects/1652) ---
**Author:** ![dbrgn](https://yyz2.discourse-cdn.com/free1/user_avatar/librepcb.discourse.group/dbrgn/32/25_2.png) [@dbrgn](https://librepcb.discourse.group/u/dbrgn)\ **Post date:** [December 14, 2018, 8:09pm UTC](https://librepcb.discourse.group/t/cii-best-practices-badge/15/4 "2018-12-14T20:09:45Z")
> [@import](#): > > I already created the project so we have a point to start: [BadgeApp](https://bestpractices.coreinfrastructure.org/projects/1652) It seems that now only you can change the entry. Is there a way to share that permission with others? ---
**Author:** ![ubruhin](https://avatars.discourse-cdn.com/v4/letter/u/c89c15/32.png) [@ubruhin](https://librepcb.discourse.group/u/ubruhin)\ **Post date:** [December 14, 2018, 8:55pm UTC](https://librepcb.discourse.group/t/cii-best-practices-badge/15/5 "2018-12-14T20:55:40Z")
Hmm the documentation says: > Project badge entries can always be edited by the badge entry owner (creator), BadgeApp administrators, and anyone who can commit to the GitHub repository (if it’s on GitHub). If you want someone else to be able to edit this badge entry, and you already have edit rights to this project badge entry, you can additional users with edit rights. Just enter “+” followed by a comma-separated list of integer user ids. Those users will then also be allowed to edit this project entry. If the GitHub thing doesn’t work, you can send me your user ID and I will add it. ---
**Author:** ![dbrgn](https://yyz2.discourse-cdn.com/free1/user_avatar/librepcb.discourse.group/dbrgn/32/25_2.png) [@dbrgn](https://librepcb.discourse.group/u/dbrgn)\ **Post date:** [December 14, 2018, 9:58pm UTC](https://librepcb.discourse.group/t/cii-best-practices-badge/15/6 "2018-12-14T21:58:40Z")
Nobody except for you has commit rights on Github 😉 My user ID should be the Github user name (dbrgn), right? ---
**Author:** ![ubruhin](https://avatars.discourse-cdn.com/v4/letter/u/c89c15/32.png) [@ubruhin](https://librepcb.discourse.group/u/ubruhin)\ **Post date:** [December 15, 2018, 3:45pm UTC](https://librepcb.discourse.group/t/cii-best-practices-badge/15/7 "2018-12-15T15:45:02Z")
> [@dbrgn](#): > > Nobody except for you has commit rights on Github You do have commit rights, but the master is protected 😉 > [@dbrgn](#): > > My user ID should be the Github user name (dbrgn), right? No, the text above mentions an integer user ID. ---
**Author:** ![dbrgn](https://yyz2.discourse-cdn.com/free1/user_avatar/librepcb.discourse.group/dbrgn/32/25_2.png) [@dbrgn](https://librepcb.discourse.group/u/dbrgn)\ **Post date:** [December 16, 2018, 12:05am UTC](https://librepcb.discourse.group/t/cii-best-practices-badge/15/8 "2018-12-16T00:05:59Z")
> [@ubruhin](#): > > You do have commit rights, but the master is protected 😉 Huh, you’re right, sorry… But I still don’t see the project 😕 My user id is 341. ---
**Author:** ![ubruhin](https://avatars.discourse-cdn.com/v4/letter/u/c89c15/32.png) [@ubruhin](https://librepcb.discourse.group/u/ubruhin)\ **Post date:** [December 16, 2018, 12:18am UTC](https://librepcb.discourse.group/t/cii-best-practices-badge/15/9 "2018-12-16T00:18:02Z")
Ok, I added you to the project. ---
**Author:** ![dbrgn](https://yyz2.discourse-cdn.com/free1/user_avatar/librepcb.discourse.group/dbrgn/32/25_2.png) [@dbrgn](https://librepcb.discourse.group/u/dbrgn)\ **Post date:** [December 16, 2018, 7:25pm UTC](https://librepcb.discourse.group/t/cii-best-practices-badge/15/10 "2018-12-16T19:25:53Z")
Ok, I went through the questionnaire. Some open questions for @ubruhin: - Should we establish a reporting process for responsible disclosure of security bugs (e.g. private e-mail to @ubruhin, optionally PGP-encrypted)? - There’s an item called “A test suite SHOULD be invocable in a standard way for that language”. Are there any conventions for Qt or QMake? I know that there’s a build configuration for Qt Creator, but maybe there’s a way to set up a “make unittest” command using QMake that can also easily be invoked from the command line (for people not using Qt Creator)? - Do we have any estimate for test coverage? - “It is SUGGESTED that projects be maximally strict with warnings in the software produced by the project, where practical.” -\> Do we fulfil that? Where are warnings configured? - Do we use any linting tool or static analysis besides compiler warnings? - I think that you fulfil [this requirement](https://tmp.dbrgn.ch/screenshots/20181216201434-f8q8czgt.png), do you agree? 🙂 Similarly, I assume [you know how things like buffer overflows work and how they can be exploited](https://tmp.dbrgn.ch/screenshots/20181216201603-829u2f9p.png)? We’re at 89% fulfilled right now! Main open issues right now are probably missing static code analysis (linting) and dynamic code analysis (fuzzing). I could imagine that fuzzing the library format could be quite interesting. ---
**Author:** ![ubruhin](https://avatars.discourse-cdn.com/v4/letter/u/c89c15/32.png) [@ubruhin](https://librepcb.discourse.group/u/ubruhin)\ **Post date:** [December 16, 2018, 7:58pm UTC](https://librepcb.discourse.group/t/cii-best-practices-badge/15/11 "2018-12-16T19:58:40Z")
> [@dbrgn](#): > > Ok, I went through the questionnaire. Thanks 👍 > [@dbrgn](#): > > Should we establish a reporting process for responsible disclosure of security bugs (e.g. private e-mail to @ubruhin, optionally PGP-encrypted)? We could do that. Where would it need to be documented? > [@dbrgn](#): > > Are there any conventions for Qt or QMake? I know that there’s a build configuration for Qt Creator, but maybe there’s a way to set up a “make unittest” command using QMake that can also easily be invoked from the command line (for people not using Qt Creator)? I don’t know, maybe “make test” is commonly used. But Qt Creator isn’t required anyway, just execute `./build/output/librepcb-unittests` as documented [here](https://github.com/LibrePCB/LibrePCB/blob/master/CONTRIBUTING.md). > [@dbrgn](#): > > Do we have any estimate for test coverage? Yes, my feeling says it’s around 1% 😁 > [@dbrgn](#): > > “It is SUGGESTED that projects be maximally strict with warnings in the software produced by the project, where practical.” -\> Do we fulfil that? Where are warnings configured? Yes, we use `-Wall` and `-Wextra` (defined in `common.pri`) and CI builds with `-Werror` so it fails if there are any warnings. > [@dbrgn](#): > > Do we use any linting tool or static analysis besides compiler warnings? No. > [@dbrgn](#): > > I think that you fulfil [this requirement](https://tmp.dbrgn.ch/screenshots/20181216201434-f8q8czgt.png), do you agree? 🙂 Similarly, I assume [you know how things like buffer overflows work and how they can be exploited](https://tmp.dbrgn.ch/screenshots/20181216201603-829u2f9p.png)? I would say yes 😉 ---
**Author:** ![dbrgn](https://yyz2.discourse-cdn.com/free1/user_avatar/librepcb.discourse.group/dbrgn/32/25_2.png) [@dbrgn](https://librepcb.discourse.group/u/dbrgn)\ **Post date:** [December 16, 2018, 9:55pm UTC](https://librepcb.discourse.group/t/cii-best-practices-badge/15/12 "2018-12-16T21:55:00Z")
> [@ubruhin](#): > > We could do that. Where would it need to be documented? I would suggest in the `README`, and maybe in combination with [https://securitytxt.org/](https://securitytxt.org/). > [@ubruhin](#): > > But Qt Creator isn’t required anyway, just execute `./build/output/librepcb-unittests` as documented [here](https://github.com/LibrePCB/LibrePCB/blob/master/CONTRIBUTING.md). Yep, that doesn’t fulfill the “well known way to invoke” though. But I agree that it’s probably sufficient. A make target would be nice, but it seems that it’s [not easy](https://stackoverflow.com/questions/3776476/how-to-add-custom-targets-in-a-qmake-generated-makefile). So I guess we’ll simply ignore this recommendation. > [@ubruhin](#): > > Yes, my feeling says it’s around 1% 😁 Well that’s sufficient for answering the questionnaire 😉 We’re now at 95% passing level, that’s already quite good. Open issues for passing: - Document vulnerability reporting process - Introduce static code analysis