CII Best Practices Badge


#1

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 :slight_smile:

https://bestpractices.coreinfrastructure.org/

It’s quite some work to fill all the forms, but it can be done step by step.

Imported from https://github.com/LibrePCB/LibrePCB/issues/219

Copied from original issue: https://github.com/LibrePCB/librepcb-rfcs/issues/3


#2

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.)


#3

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.

:+1:

I already created the project so we have a point to start: https://bestpractices.coreinfrastructure.org/projects/1652


#4

It seems that now only you can change the entry. Is there a way to share that permission with others?


#5

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.


#6

Nobody except for you has commit rights on Github :wink: My user ID should be the Github user name (dbrgn), right?


#7

You do have commit rights, but the master is protected :wink:

No, the text above mentions an integer user ID.


#8

Huh, you’re right, sorry… But I still don’t see the project :confused:

My user id is 341.


#9

Ok, I added you to the project.


#10

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, do you agree? :slightly_smiling_face: Similarly, I assume you know how things like buffer overflows work and how they can be exploited?

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.


#11

Thanks :+1:

We could do that. Where would it need to be documented?

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.

Yes, my feeling says it’s around 1% :grin:

Yes, we use -Wall and -Wextra (defined in common.pri) and CI builds with -Werror so it fails if there are any warnings.

No.

I would say yes :wink:


#12

I would suggest in the README, and maybe in combination with https://securitytxt.org/.

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. So I guess we’ll simply ignore this recommendation.

Well that’s sufficient for answering the questionnaire :wink:

We’re now at 95% passing level, that’s already quite good.

Open issues for passing:

  • Document vulnerability reporting process
  • Introduce static code analysis