Topics

LibreOffice got a badge!


David A. Wheeler
 

I’m *delighted* to report that LibreOffice just got a best practices badge!

 

Details here:

https://bestpractices.coreinfrastructure.org/projects/307 for more.

 

I currently review all new passing badge forms (I hope to be unable to keep up in the future).  I think their badge entry is really good – it’s a great demo of what an entry *should* look like!  They provide a *lot* of justification text, many with URLs for the evidence, and the text really does justify the answers.  LibreOffice is a popular and well-known project, so I’m very happy that they provided so much clear justification.  Nice job!!

 

Here are a few interesting tidbits that might be worth thinking about in the future:

* (Basics) We ask that the FLOSS license be described using a SPDX license expression, but SPDX license expressions can’t fully express their situation, so they just describe in in text using SPDX license identifiers.  Here’s what they said: “Binaries under MPL-2.0, code contributions under MPL-2.0 and LGPL-3.0+”.  I don’t see a better approach; I think they did the best possible in the circumstance.  That *does* suggest that we should continue to allow text that doesn’t strictly meet the SPDX license expression syntax.

* (Basics) They *do* have a CPE name… for those who said no one would provide one J.

* (Quality) They don’t meet test_most (“It is SUGGESTED that the test suite cover most (or ideally all) the code branches, input fields, and functionality.”).  It’s not a MUST, so that’s allowed.  They’re clearly on their way; their justification is that “Currently (2016-08-16) about 44% https://lcov.libreoffice.org/”.  Testing cross-platform GUI programs is tricky, actually, so I respect their effort.

* (Analysis) They use both Coverity and cppcheck for source static code analysis, so they handily meet “static_analysis”.  However, they can’t meet “static_analysis_often” (“It is SUGGESTED that static source code analysis occur on every commit or at least daily.”) - at least with Coverity – because “Coverity runs longer than a day on our code :-D”.  That sounds like a reasonable justification to me!

 

Anyway, that’s great news, and my congrats to the LibreOffice team!

 

--- David A. Wheeler

 


Daniel Stenberg
 

On Thu, 25 Aug 2016, Wheeler, David A wrote:

* (Basics) They *do* have a CPE name... for those who said no one would provide one :).
Well I didn't say exactly that but I questioned the usefulness of this entry. Nobody told me how the CPE name looked like other than it starts with 'cpe' (including the CPE site and our best practices entry form).

I found 241(!) names in the CPE database matching my search, it wasn't and actually still isn't perfectly clear to me which of those names that are "mine" to fill in.

Looking at libreoffice's CPE entry, they've added a '*' wildcard for where the CPE database has different version numbers which makes me assume that I can do that as well... It would help a lot if this was actually documented somewhere and we could point to that documentation!

To save everyone from looking, the libreoffice CPE name is apparently:

"cpe:2.3:a:libreoffice:libreoffice:*:*:*:*:*:*:*:*"

Further, if I'm not mistaken, a CPE identifies a *product* and we're entering data as a *project* so should we add multiple CPE numbers if we have multiple products? At the very least the text for the form field should be clarified.

--

/ daniel.haxx.se


David A. Wheeler
 

Daniel Stenberg:
Well I didn't say exactly that but I questioned the usefulness of this entry.
Nobody told me how the CPE name looked like other than it starts with 'cpe'
(including the CPE site and our best practices entry form).
...
Looking at libreoffice's CPE entry, they've added a '*' wildcard for where the
CPE database has different version numbers which makes me assume that I
can do that as well... It would help a lot if this was actually documented
somewhere and we could point to that documentation!
The MITRE site has the spec:
https://cpe.mitre.org/specification/

But you're right, there are lots of problems. They point to NIST, but NIST doesn't make the info easy to find.

I think NIST is trying to switch to a different ID system, but that newer ID system uses large XML files (ugh!) and can only refer to specific versions - not to the software as a whole. That makes it harder to use for vulnerability-tracking purposes, so all the vulnerability database tools I know of only use CPEs. Cue the competing standards cartoon, please :-).

Further, if I'm not mistaken, a CPE identifies a *product* and we're entering
data as a *project* so should we add multiple CPE numbers if we have
multiple products? At the very least the text for the form field should be
clarified.
That's true. We could allow multiple CPE numbers, but that probably doesn't *really* address the issue. Currently I think it'd be easier for a larger (meta) project to create separate badge entries for each product, because many *other* things could also be different (repo, license, etc.). Not sure how to phrase that.

--- David A. Wheeler