Hey,

Two years ago I added curl to the CII Best practices web site, claiming curl
meets 100% of their criteria. I think that's good checklist of things and
procedures that a good and sound open source project should do.

You can see it here:
https://bestpractices.coreinfrastructure.org/en/projects/63

(Ideally, I would like to see all third party dependencies we recommend for
users to also be at 100% there, but we're not there yet...)

Since my initial curl submission, there have been two new levels added: silver
and gold, for which there's an even stricter set of rules that a project needs
to fulfill to be able to claim compliance.

I've filled in the silver requirements we meet but at 93% silver, the
remaining four ones are simply points we don't easily fulfill at the moment. I
don't think we can become a "silver best practise" project without a
significant effort. For your information, I'm listing the requirements we
don't fulfill here with my comments on them.

1. The project SHOULD have a legal mechanism where all developers of
non-trivial amounts of project software assert that they are legally
authorized to make these contributions.

- This seems to basically require Signed-off-by: in every commit and that we
host a file saying so. Personally I don't feel that we need to start requiring
S-O-B lines so I'm leaning towards keeping this 'unmet'.

2. The project SHOULD have a "bus factor" of 2 or more. (URL required)

- There's no official nor standard way to measure this and this even requires
a URL (to what?). I'm sure we could find a way to measure it to say that it is
more than 2 if we really want to. As long as we have other silver requirements
still pending I don't think I'll bother with it.

3. The project MUST have FLOSS automated test suite(s) that provide at least
80% statement coverage if there is at least one FLOSS tool that can measure
this criterion in the selected language.

- This is really tough. We have thousands of system and unit tests and we've
been hovering around 75% coverage for a long time. I would of course *like* us
to have better coverage but I see no way way to reach 80% anytime soon.

4. The project MUST provide an assurance case that justifies why its security
requirements are met. The assurance case MUST include: a description of the
threat model, clear identification of trust boundaries, an argument that
secure design principles have been applied, and an argument that common
implementation security weaknesses have been countered.

- Nope. And it feels like boring work I'll rather not do anytime soon.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html