* Adding missing documentation for Token-Permissions
* Make documentation for `actions` more accurate
Co-authored-by: Naveen <172697+naveensrinivasan@users.noreply.github.com>
Co-authored-by: laurentsimon <64505099+laurentsimon@users.noreply.github.com>
* Issue activity only counts if done by a maintainer
* -Using pointer so that if Github API doesn't return a value for a field, it can be nil
- Updating AuthorAssociation to use an enum
Co-authored-by: Azeem Shaikh <azeemshaikh38@gmail.com>
The io/ioutil package has been deprecated as of Go 1.16, see
https://golang.org/doc/go1.16#ioutil. This commit replaces the existing
io/ioutil functions with their new definitions in io and os packages.
Signed-off-by: Eng Zer Jun <zerjun@eta-hd.com>
Co-authored-by: laurentsimon <64505099+laurentsimon@users.noreply.github.com>
According to https://github.com/apps/lgtm-com
"LGTM is a code analysis platform for identifying vulnerabilities early and preventing
them from reaching production". It's used by `systemd`, `lxc` and a lot of other large
open source projects. The check is
still kind of broken in the sense that it fails to detect
projects where every PR is analyzed by LGTM before getting merged
but it's better than nothing I guess.
Co-authored-by: Naveen <172697+naveensrinivasan@users.noreply.github.com>
This commit commits the result of `make generate-docs`,
producing an updated `docs/checks.md` file, now that the
source documentation files have been changed.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
There are many source repository hosting services (forges),
not just GitHub. This generalizes the requirements, e.g., from:
> Determines if the project's GitHub workflows follow the principle of least privilege.
to:
> Determines if the project's workflows follow the principle of least privilege.
Scorecard doesn't currently *implement* checks in most cases for
systems other than GitHub, so acknowledge that as a limitation, instead
of implying that it's the one true way to implement secure software.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
Co-authored-by: Naveen <172697+naveensrinivasan@users.noreply.github.com>
* Improve text on Packaging
Make various improvements to the text on packaging.
* The original text assumes that only software developers install software
packages, which is absurd; end-users install software packages all
the time.
* The original text seemed to assume that there are only
language-level packages, but system-level packages & containers
are a thing :-). At least acknowledge them.
Also, this doesn't make sense in some cases
(e.g., software specific to one website that's updated through commits,
or IoT software where there are no "packages" - you
upload the entire image); that should be admitted.
* Fix main text to stop using "you/your" to mean "project developer".
There are at least two *different* readers: (1) developers of the project
being measured and (2) potential users of the project being measured.
Many users of scorecard will be #2, they'll
reading scorecard results to decide if they want to use the software
being measured. So don't say "you" and assume that "you" means
project developers. I left "you" meaning "project developers"
inside remediation, under the assumption that this was remdediation
text for project developers.
To be fair, *users* of software can also sometimes
take remediation steps; that might be worth adding as its own
section if we text to add there (e.g., `user_remediation`).
I have intentionally not run `make generate-docs` as that would add other
irrelevant changes. Instead, after this PR is accepted there should be a
`make generate-docs` & a pull of *that*.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
* Add note about filing an issue
Add note about filing an issue if scorecard fails to detect
the packaging mechanism, per review by @naveensrinivasan (thanks!).
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
* Improve explanation about multiple reviewers (and their lack)
The current text oversells the value of multiple
reviewers, and falsely assumes it's always possible.
I'm a *huge* fan of having a second reviewer, but it
obviously *can't* be done when there's only 1 active participant.
Even projects with multiple active participants find it
difficult in practice if there aren't many participants.
Also, multiple reviewers guarantee nothing; the other
"reviewers" might be sock puppets or other subverted accounts.
So yes, encourage review, but let's make it clear that it
can't prevent all problems & that some projects cannot currently
do it. Put the details in Code-Review, where it best belongs.
Also, projects *can* try to remediate the lack of active participants,
so give them some practical remediation steps.
Finally: "pull request" is a GitHub-specific term. GitLab, SourceForge,
and many other forges instead use the term "merge request". So in the
interest of not locking into one specific proprietary service, let's
include a more generic term.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
* Make fixes based on review
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
* Explain how to get top score in Contributors
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
Co-authored-by: Naveen <172697+naveensrinivasan@users.noreply.github.com>
* Warn when checks are prone to false negatives
Automated tools normally have some false negatives,
some false positives, or both. However, some scorecard criteria
are *especially* prone to false negatives (where a
project meets the criterion but the tool says it doesn't).
This commit adds warning text about false negatives for
criteria that are especially prone to false negatives.
In all cases the problem is that there are *many* ways to
implement the criterion, so while the tool may detect some
cases, there are countless other situations it will fail to detect.
While this doesn't *fix* the problem, warning the humans
will encourage them to double-check these criteria before
making decisions. Sometimes this is the best you can do, and
it's better than not having a warning.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
* Fix text per pull request feedback
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
Co-authored-by: laurentsimon <64505099+laurentsimon@users.noreply.github.com>
* Improve rationale for Binary-Artifacts
I'm fine with prohibiting binary executables, but
the *rationale* for doing this was completely unclear.
This commit rewrites the rationale to explain, in hopefully
a better way, why they can be a problem.
I prefer "executable" over "binary".
On digital computers, all data (including source code) are binaries :-).
In addition, some executables are simultaneously executables
and source code, e.g., shell scripts.
So I think what is meant here is a "generated binary".
I don't really think this merits a "High" level, but that's
a different dicussion.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
* Tweak Binary-Artifacts rationale
Tweak Binary-Artifacts text based on comments from
@naveensrinivasan.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
Co-authored-by: Naveen <172697+naveensrinivasan@users.noreply.github.com>
A lack of active maintenance isn't always an indicator of problems.
It'd be surprising if the JavaScript IsEven package got changes
every week.
Make that clearer in the check text.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
Co-authored-by: Azeem Shaikh <azeemshaikh38@gmail.com>
One reason to pin dependencies is that it's one way to
counter dependency confusion attacks; mention that.
Pinning dependencies is definitely not the *only* way, and
it's not even clear it's the best way, but it's a legitimate
reason to pin dependencies in applications.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
This fixes the current misleading text about the CII
Best Practices badge. It currently says that "This badge tells us the
repo maintainers are aware of best development practices." - but
merely being "aware" doesn't earn a passing badge.
There's a long list of requirements to earn a passing badge;
we should give a sense of them here.
Note that this only checks for "passing", not silver or gold.
Note: This replaces a previous (messed-up) pull request #1009.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
* Modify pinned dependency docs in checks.yaml
The previous changes about pinned dependencies
modified the generated file checks.md, not the source
file checks.yaml. This commit modifies the correct
source file checks.yaml instead. It also tweaks the
text further (while we're at it).
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
* Check in result of make generate-docs
We've modified checks.yaml to improve the pinned
dependency discussion. This checks in the result of
`make generate-docs` so that the docs are visible
on GitHub.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
Co-authored-by: Azeem Shaikh <azeemshaikh38@gmail.com>
