Skip to content

GitoxideLabs-related updates other than URLs in this repo #1632

Closed
@EliahKagan

Description

@EliahKagan

This repository was moved from Byron/gitoxide to GitoxideLabs/gitoxide when the GitoxideLabs organization was created, as described in #1406. Not all references have to be updated immediately and some never need to be updated, because Byron/gitoxide URLs redirect to the new URL, which I think will remain in place for a very long time (ideally, for at least as long as GitoxideLabs URLs themselves work). Nonetheless there is a benefit to referring people to the canonical URL.

#1624 makes these changes where applicable inside files in this repository, which also indirectly takes care of updating them in a number of other places; for example, information on crates.io will have the new repository URLs for subsequent crate releases. But there are a few more things that may benefit from being updated. I propose:

  • Update summary metadata in Codeberg and gitee mirrors
  • Maybe resolve newly possible future ambiguity in SECURITY.md (#1633)
  • Figure out under what conditions references in advisories should be updated
  • Don't update things where's there's clearly no benefit (e.g. links in issues)

Summary metadata in mirrors

The Codeberg mirror has the summary/about text:

A mirror of https://github.com/Byron/gitoxide

The gitee mirror has the summary/about text:

An idiomatic, lean, fast & safe pure Rust implementation of Git

I suggest updating them both to this, or something much like it:

An idiomatic, lean, fast & safe pure Rust implementation of Git - mirror of https://github.com/GitoxideLabs/gitoxide

Ambiguity in SECURITY.md

This is unrelated to hyperlinks, arising differently from moving the repository into the newly created GitoxdeLabs org. The second paragraph has been unambiguous, even when read by someone with very minimal familiarity with the project:

If this doesn't seem like the right approach or there are questions, please feel free to reach out to the @icloud.com email used in my commits.

In my opinion, this is a very useful thing to have. I furthermore recognize the benefit of having one fewer heavily indexed place with that email address, as well as the benefit of its indirectness to foregrounding the primary approach of making a draft advisory through the GitHub interface.

However, now that the repository is under an org rather than a specific user (you), people with very low familiarity with the project--which could happen if someone unfamiliar with this project discovers a vulnerability in gitoxide while using an application that uses it--may not immediately know who "my" is.

This is a very low risk, especially right now--right now, the risk is effectively zero, because there are no other actors with @icloud.com email addresses associated with any commits in the history of gitoxide's main branch.

References in advisories

There are three kinds of relevant advisories: repository-level GHSA advisories, global GHSA advisories (in the GitHub Advisory Database), and RUSTSEC advisories.

It seems to me that, when already editing an advisory for another reason, it would be a good idea to update the links, and otherwise they need not be updated. Exceptions to this could be made on an ad-hoc basis motivated by need or convenience.

I don't think we need an actual policy about this, but the above suggestion is not necessarily the only reasonable approach, and I will tend to lean toward following it unless I know I shouldn't.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueAn issue to track to track the progress of multiple PRs or issues

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions