profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/laurentsimon/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

ossf/scorecard 1969

Security Scorecards - Security health metrics for Open Source

google/fuzzbench 690

FuzzBench - Fuzzer benchmarking as a service.

ossf/allstar 648

GitHub App to set and enforce security policies

ossf/package-analysis 12

Open Source Package Analysis

laurentsimon/scorecard 1

Security Scorecards - Security health metrics for Open Source

laurentsimon/AFL 0

american fuzzy lop - a security-oriented fuzzer

laurentsimon/BLAKE2 0

BLAKE2 official implementations

laurentsimon/FourQlib 0

FourQlib is an efficient and portable cryptographic library that provides functions for computing elliptic curve based operations on the high-performance FourQ curve.

laurentsimon/fuzzbench 0

FuzzBench - Fuzzer benchmarking as a service.

laurentsimon/hacl-star 0

HACL*, a formally verified cryptographic library written in F*

PullRequestReviewEvent
PullRequestReviewEvent

issue commentossf/scorecard

BUG: check information in README.md and other docs should be programmatically generated from checks.md

we can do the same for keep the cron section of the readme up-to-date, by monitoring changes under cron/

laurentsimon

comment created time in 2 days

Pull request review commentossf/scorecard

📖 Improve text on Packaging

 checks:   Packaging:     risk: Medium     tags: supply-chain, security, releases-    short: Determines if the project is published as a package that other developers can install/download.+    short: Determines if the project is published as a package that others can easily download, install, easily update, and uninstall.     description:-      This check tries to determine if the project is published as a package that other developers can install/download.+      This check tries to determine if the project is published as a package that others can easily download, install, easily update, and uninstall.++      It's important that the project provide an easy way to+      download, install, update, and uninstall the software.+      It's particularly important to make it easy for users to+      receive security patches as updates.++      This is often done by creating a "package" that is+      easy to install and uninstall by a package manager.+      Many program language ecosystems have a generally-used packaging format+      supported by a language-level package manager+      tool and public package repository.+      Many operating system platforms also have at least one package format,+      tool, and public repository (in some cases the source repository+      generates system-independent source packages, which are then+      used by others to generate system executable packages).+      Container images are yet another way to package software.+      In some situations packaging is not sensible, but it's wise to package+      software in so many circumstances that it's worth checking for it. -      Packaging your project is essential for users to receive updates and security patches automatically.       A low score is considered `Medium` risk.        The check currently looks for [GitHub packaging workflows]( https://docs.github.com/en/packages/learn-github-packages/publishing-a-package)       and language-specific GitHub Actions that upload the package to a corresponding hub, e.g., [Npm](https://www.npmjs.com/).       There is a plan to add better support to query package manager hubs directly in the future, e.g., for [Npm](https://www.npmjs.com/), [PyPi](https://pypi.org/).+      A project may meet this criterion yet have a failing scorecard report;+      some widely-used tools are relatively easy to detect, but it's

add a line "If scorecard fails to detect the way you publish a package and you think scorecard should support your use case, please file an issue [...]"

david-a-wheeler

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

PR opened ossf/scorecard

🐛 fix k8 web hook
  • Please check if the PR fulfills these requirements
  • [] Tests for the changes have been added (for bug fixes / features)
  • [X] PR title follows the guidelines defined in https://github.com/ossf/scorecard/blob/main/CONTRIBUTING.md#pr-process
  • What kind of change does this PR introduce? (Bug fix, feature, docs update, ...) fix bug

  • What is the current behavior? (You can also link to an open issue here) https://github.com/ossf/scorecard/pull/1023/files#r710416794

  • What is the new behavior (if this is a feature change)? fix https://github.com/ossf/scorecard/pull/1023/files#r710416794

  • Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?) no

  • Other information:

+0 -2

0 comment

1 changed file

pr created time in 3 days

create barnchlaurentsimon/scorecard

branch : feat/rv3

created branch time in 3 days

push eventlaurentsimon/scorecard

laurentsimon

commit sha 34b97e37b3e94baa6b50cff7ef1f73ac5b4e5c64

✨ Update k8's transfer releasetest-v2 (#1023) * release-v1 transfer * v2 fix

view details

push time in 3 days

PullRequestReviewEvent

Pull request review commentossf/scorecard

✨ Update k8's transfer releasetest-v2

 spec:               value: "gs://ossf-scorecard-data-releasetest2"             - name: SCORECARD_BIGQUERY_TABLE               value: "scorecard_releasetest2"+            - name: SCORECARD_COMPLETION_THRESHOLD+              value: "1"+            - name: SCORECARD_WEBHOOK_URL

let me send a new PR.

laurentsimon

comment created time in 3 days

push eventossf/scorecard

laurentsimon

commit sha 34b97e37b3e94baa6b50cff7ef1f73ac5b4e5c64

✨ Update k8's transfer releasetest-v2 (#1023) * release-v1 transfer * v2 fix

view details

push time in 3 days

PR merged ossf/scorecard

✨ Update k8's transfer releasetest-v2
  • Please check if the PR fulfills these requirements
  • [] Tests for the changes have been added (for bug fixes / features)
  • [X] PR title follows the guidelines defined in https://github.com/ossf/scorecard/blob/main/CONTRIBUTING.md#pr-process
  • What kind of change does this PR introduce? (Bug fix, feature, docs update, ...) bug

  • What is the current behavior? (You can also link to an open issue here) not updated

  • What is the new behavior (if this is a feature change)? updated with transfer.release.yaml

  • Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?) no

  • Other information:

+8 -4

0 comment

2 changed files

laurentsimon

pr closed time in 3 days

push eventlaurentsimon/scorecard

laurentsimon

commit sha af355a257a76204fa698560ba8f3bfcd511611d5

remove warning

view details

push time in 3 days

push eventlaurentsimon/scorecard

laurentsimon

commit sha a723c1c3c3c3b103a0a02639ddd9206bc56e0d0b

release-v1 transfer

view details

laurentsimon

commit sha a3a02950a7f2c5c2331542dc70e312458737c5dc

v2 fix

view details

laurentsimon

commit sha 94ded91a4add36d03952f642539a391a358c5596

fix

view details

push time in 3 days

push eventlaurentsimon/scorecard

naveen

commit sha 1e4f7232e8719ca0e475ac13d85375d1e3e5a9c7

:seedling: Fixes permission for main.yml action https://github.com/ossf/scorecard/issues/942

view details

David A. Wheeler

commit sha 30cae86ab043623852322994c91ea66c1e68d3c0

📖 Warn when checks are prone to false negatives (#1019) * 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>

view details

naveen

commit sha 9e81b5f25e75a9e3c882674b056cea262b00076e

:book: Fixed the dependabot check message Fixed the dependabot warning message. https://github.com/ossf/scorecard/issues/1028

view details

naveen

commit sha e1a6e7dcad327042b18cf98fed19a309e89794fb

:book: Fixed the docs for dependabot

view details

push time in 3 days

push eventlaurentsimon/scorecard

naveen

commit sha 1e4f7232e8719ca0e475ac13d85375d1e3e5a9c7

:seedling: Fixes permission for main.yml action https://github.com/ossf/scorecard/issues/942

view details

David A. Wheeler

commit sha 30cae86ab043623852322994c91ea66c1e68d3c0

📖 Warn when checks are prone to false negatives (#1019) * 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>

view details

naveen

commit sha 9e81b5f25e75a9e3c882674b056cea262b00076e

:book: Fixed the dependabot check message Fixed the dependabot warning message. https://github.com/ossf/scorecard/issues/1028

view details

naveen

commit sha e1a6e7dcad327042b18cf98fed19a309e89794fb

:book: Fixed the docs for dependabot

view details

laurentsimon

commit sha 9e14f5dde42b06ad0d027a246b512cee2fccffc6

Merge branch 'main' into feat/transferv2

view details

push time in 3 days

PullRequestReviewEvent

issue commentossf/scorecard

Scorecard should NOT require linear history nor disabling stale review dismissal

Describe the bug Currently scorecard requires linear history and disabling stale review dismissal as part of Branch-Protection, and I believe that's a mistake. Remove these:

   "Warn: linear history disabled on branch 'main'",
   "Warn: Stale review dismissal disabled on branch 'main'",

Reproduction steps Steps to reproduce the behavior:

  1. Run on any repo that doesn't do this, e.g., https://github.com/coreinfrastructure/best-practices-badge - note that we once required squashing, but we stopped that.

Expected behavior No complaints if you don't require linear history or if stale review dismissal is enabled.

Additional context

Scorecard should only report problems if there is clear evidence that the problem will lead to security problems. It's fine to include approaches that reduce defects in general, since a subset of defects are unintentional vulnerabilities, so I can accept a broad rationale.

However, requiring linear history does not improve security. It's an aesthetic, like 2-space vs. 4-space indentation. Some people like linear histories because they seem "clean" to them, but that is a debatable aesthetic that is not the purpose of scorecard. Scorecard shouldn't require everyone implement projects according to some house/company policy, but instead should focus on criteria that improve security.

Linear histories have pros and cons. Here are a few cons:

  • It falsifies history, which means analysis of commits does not analyze the actual project history. "Linear history" could be more accurately described as "history falsification". That can lead to misleading results from later analysis.
  • It does not work well with cryptographically signed commits of many people. Many projects are far more distributed and have many branches that contain the work of many people. If each commit is signed and there are multiple commits, you can't really rebase and keep the cryptographic signatures. "Solutions" include dropping cryptographic signatures of commits (ouch!) or falsifying who wrote what (possibly illegal under the license + copyright law, and also interfering with the measurement of how many organizations are contributing).

good feedback, thanks

Similarly, there's a reason for dismissing stale reviews - they are stale. Some people want them dismissed because they're false, others don't. If anything, for security you don't want to consider a stale review as valid, so there's a better argument for enabling stale review if anything. I think it's better to let projects choose what works for them.

The GitHub configuration name "stale" is mis-leading. AFAIK, a review is considered stale if it's reviewed and then modified by the author, requiring the review to bed approved again. This helps prevents innocuous-looking reviews from being reviewed-then-modified to be malicious. There is a security gain to this. There are usability concerns with this, obviously: it slows down the dev/review process and I would buy the argument that it may have the opposite effect: review fatigue which would lead to less through reviews. We should at least log the config as Info instead of. Warn. What would the idea behavior look like (score/message)?

Added this for discussion for next meeting

david-a-wheeler

comment created time in 3 days

issue commentossf/scorecard

SAST not detected in CII Best Practices badge workflows

Examples of CI/CD to support (taken from another issue): .github/workflows (we support) .circleci .travis.yml .gitlab-ci.yml

david-a-wheeler

comment created time in 3 days

issue commentossf/scorecard

Feature: Pin dependencies for other CI/CD

Examples of CI/CDs: .github/workflows (we do support) .circleci .travis.yml .gitlab-ci.yml

laurentsimon

comment created time in 3 days

issue openedossf/scorecard

BUG: contributor checks does not validate number of companies per contributor

a contributor can forge their company association on GH. (tracked in another issue). In addition, the number of companies can be as large as possible. That makes it easier for a single user to commit 5 PRs and add 3 companies to their profile, hence getting a top score.

We should only take a single company per user.

created time in 4 days

push eventossf/scorecard

David A. Wheeler

commit sha 30cae86ab043623852322994c91ea66c1e68d3c0

📖 Warn when checks are prone to false negatives (#1019) * 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>

view details

push time in 4 days

PR merged ossf/scorecard

📖 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

+20 -8

1 comment

2 changed files

david-a-wheeler

pr closed time in 4 days

Pull request review commentossf/scorecard

📖 Improve explanation about multiple reviewers (and their lack)

 checks:        The check works by looking at the authors of recent commits       and checking the `Company` field on the GitHub user profile. A contributor-      must have at least 5 commits in the last 30 commits. The check succeeds if-      all contributors span at least 2 different organizations (companies).+      must have at least 5 commits in the last 30 commits.

note: the check currently gives the highest score if there are at least 3 contributors in the last 30 commits. Any number below that is score propportionally.

david-a-wheeler

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentossf/scorecard

📖 Improve explanation about multiple reviewers (and their lack)

 checks:        The check works by looking at the authors of recent commits       and checking the `Company` field on the GitHub user profile. A contributor-      must have at least 5 commits in the last 30 commits. The check succeeds if-      all contributors span at least 2 different organizations (companies).+      must have at least 5 commits in the last 30 commits.

maybe say a user is considered a contributor if they have at least 5 commits in the last 30 commits.

david-a-wheeler

comment created time in 4 days

PullRequestReviewEvent

push eventdavid-a-wheeler/scorecard

naveen

commit sha 1e4f7232e8719ca0e475ac13d85375d1e3e5a9c7

:seedling: Fixes permission for main.yml action https://github.com/ossf/scorecard/issues/942

view details

laurentsimon

commit sha b9e9675dfac6f9b76e30172b4648176fa4ad3086

Merge branch 'main' into false-negatives

view details

push time in 4 days