Somewhat related to #40357

This might be easier than #41126 (comment) since GitHub allows a repository to be marked as an archive, the integration with GitHub should be able to detect that the owner archived it.
Indeed, the GetRepository API call to GitHub (https://docs.github.com/en/rest/repos/repos#get-a-repository) has an archived attribute on the result, which also shows up in https://docs.github.com/en/rest/repos/repos#list-organization-repositories.

Seems like the mechanics for updating the data in pkg.go.dev should be able to easily detect this flag being set and put up a notice like GitHub does regarding archived repositories:

https://github.com/ossf/scorecard (https://securityscorecards.dev/) contains that information in their public API. In fact, all the Scorecard checks can be retrieved from https://deps.dev/, which is already queried from the frontend.

Therefore, there is no need to be dependent on GitHub API. Also, the archived repositories from other VCS hostings would be available if they are provided.

We could use this data to add an indicator.

As for the search ranking, it is unclear whether we should add an extra step for the workers to store the checks in the database or not.

@jba, what do you think about that?

For the sake of this discussion I'm going to point out two repositories that might be helpful here.

• https://github.com/gofrs/uuid (https://deps.dev/go/github.com%2Fgofrs%2Fuuid)
• https://github.com/satori/go.uuid (https://deps.dev/go/github.com%2Fsatori%2Fuuid/v1.2.0)

The first is a fork of the second, and the second seems to be out-of-date; unfortunately the author did not mark it as archived. I also linked their deps.dev references. Unfortunately the securityscorecards.dev site doesn't provide a website view to check dependencies with.

As another reference:

• https://github.com/gobuffalo/uuid (https://deps.dev/go/github.com%2Fgobuffalo%2Fuuid)

This repo is archived; but deps.dev does not seem to acknowledge that at all.

I agree it'd be great not to be tied to the GitHub API.

@BenjamenMeyer, thank you, the examples are very interesting indeed. I believe these issues could be reported to scorecards project to investigate further and change its data retrieval pipelines.

These examples show that it is not always a reliable source of information. It can contain both false negatives and false positives. It might be a significant disadvantage for using deps.dev as a source of information. Therefore, we cannot make a decision to deprecate any packages based on this information forcefully.

On the other side, there are advantages too: the resource is already integrated into the project, and it is cheap to use it. What we could do with this is show the same checks in pkg.go.dev as is, and highlight when they are absent.

Is it a good enough solution to improve the visibility of unmaintained projects?

Another, more restrictive solution for this problem could be a mechanism to force the deprecation of packages. It might require direct access to the repository hosting APIs, but also changing the go.mod files of the packages to provide deprecation comments with a reason. Probably, it is possible, but I don't understand the corner cases and the full cost of such a solution, so it seems hard to develop and maintain.

@goto1134 if an author takes the step to mark their repo as unmaintained/archived then that should be an indicator to things like deps.dev, pkg.go.dev, etc to mark as deprecated. If the status gets removed then those sites should again reflect that - example: the Go Gorilla projects that were marked archived as the authors stopped and didn't have anyone to turn it over to; another team came in and resurrected it in place with the former teams permission and took over, unarchiving them in the process.

I would not use time since the last commit as that can be a misnomer. I have some projects myself that are maintained and active but haven't had changes in years, mostly because they still do what they were intended to do.

If we could get sites like deps.dev to integrate that data awesome. If not, I'd suggest we try to pull it ourselves where possible. Perhaps with an "unknown" or "unavailable" value for other cases where the vcs isn't accessible or not yet integrated.