New check: detect change of ownership about scorecard HOT 4 CLOSED

Just to clarify, are you saying I can start working on this issue now, but I should not worry about sharding at this time?

Not worry about right now. There are several other to pick from list - https://github.com/ossf/scorecard/issues?q=is%3Aissue+is%3Aopen+%22New+check%22 or https://github.com/ossf/scorecard/milestone/1
but whichever you pick, leave a comment in bug to avoid duplication/conflict. thanks @chrismcgehee for your contributions!

from scorecard.

I'm interested in taking this one on. Before I start, I'd like to discuss how to go about doing this.

I don't see anything on Github's API that would allow us to query for a repo's past owners. I think we'll need to store this data ourselves and have scorecard query for it. We could record the owners for the repos we track as part of the cron process and store it in GCS bucket. Then when scorecard runs, it could download the file(s) it needs from the bucket. Maybe not at first, but we will want to shard the data across files within the bucket so that scorecard can download a reasonable size chunk if it's only checking one repo.

If the repo being checked is not present in the saved data, we'd have to give an inconclusive result.

Feedback on this approach?

from scorecard.

I'm interested in taking this one on. Before I start, I'd like to discuss how to go about doing this.

I don't see anything on Github's API that would allow us to query for a repo's past owners. I think we'll need to store this data ourselves and have scorecard query for it. We could record the owners for the repos we track as part of the cron process and store it in GCS bucket. Then when scorecard runs, it could download the file(s) it needs from the bucket. Maybe not at first, but we will want to shard the data across files within the bucket so that scorecard can download a reasonable size chunk if it's only checking one repo.

If the repo being checked is not present in the saved data, we'd have to give an inconclusive result.

Feedback on this approach?

This is a good approach. But we are in the process of designing sharding and coming up with long-term plans to scale. I would recommend that we wait until then.

Thanks for picking up the issue and all your contributions @chrismcgehee!

from scorecard.

Just to clarify, are you saying I can start working on this issue now, but I should not worry about sharding at this time?

from scorecard.