CII Best Practices Badge

[import]

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/

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

Copied from original issue: CII Best Practices Badge · Issue #3 · LibrePCB/librepcb-rfcs · GitHub

[import]

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

[import]

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

[dbrgn]

@import

I already created the project so we have a point to start: BadgeApp

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

[ubruhin]

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.

[dbrgn]

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

[ubruhin]

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

[dbrgn]

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

[ubruhin]

Ok, I added you to the project.

[dbrgn]

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

[ubruhin]

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

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

I would say yes

[dbrgn]

@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/.

@ubruhin

But Qt Creator isn’t required anyway, just execute ./build/output/librepcb-unittests as documented here.

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.

@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