Release process

This project uses cargo-release in order to prepare new releases, tag and sign the relevant git commit, and publish the resulting artifacts to crates.io.
The release process follows the usual PR-and-review flow, allowing an external reviewer to have a final check before publishing.

Requirements

This guide requires:

• A web browser (and network connectivity)
• git
• GPG setup and personal key for signing
• cargo (suggested: latest stable toolchain from rustup)
• cargo-release (suggested: cargo install -f cargo-release)
• Write access to this GitHub project
• A verified account on crates.io
• Membership in the Fedora CoreOS Crates Owners group, which will give you upload access to crates.io

Release checklist

These steps show how to release version x.y.z on the origin remote (this can be checked via git remote -av).
Push access to the upstream repository is required in order to publish the new tag and the PR branch.

⚠️: if origin is not the name of the locally configured remote that points to the upstream git repository (i.e. [email protected]:coreos/openssh-keys.git), be sure to assign the correct remote name to the UPSTREAM_REMOTE variable.

• prepare environment:

  • RELEASE_VER=x.y.z
  • UPSTREAM_REMOTE=origin
  • git checkout -b pre-release-${RELEASE_VER}

• write release notes:

  • write release notes in docs/release-notes.md
  • git add docs/release-notes.md && git commit -m "docs/release-notes: update for release ${RELEASE_VER}"

• land the changes:

  • PR the changes, get them reviewed, approved and merged
  • if doing a branched release, also include a PR to merge the docs/release-notes.md changes into main

• make sure the project is clean:

  • Make sure cargo-release is up to date: cargo install cargo-release
  • cargo test --all-features
  • cargo clean
  • git clean -fd

• create release commit on a dedicated branch and tag it (the commit and tag will be signed with the GPG signing key you configured):

  • git checkout -b release-${RELEASE_VER}
  • cargo release --execute ${RELEASE_VER} (and confirm the version when prompted)

• open and merge a PR for this release:

  • git push ${UPSTREAM_REMOTE} release-${RELEASE_VER}
  • open a web browser and create a PR for the branch above
  • make sure the resulting PR contains exactly one commit
  • get the PR reviewed, approved and merged

• publish the artifacts (tag and crate):

  • git checkout v${RELEASE_VER}
  • verify that grep "^version = \"${RELEASE_VER}\"$" Cargo.toml produces output
  • git push ${UPSTREAM_REMOTE} v${RELEASE_VER}
  • cargo publish

• publish this release on GitHub:

  • find the new tag in the GitHub tag list, click the triple dots menu, and create a release for it
  • copy in the changelog from the release notes doc
  • publish release

• clean up the local environment (optional, but recommended):

  • cargo clean
  • git checkout main
  • git pull ${UPSTREAM_REMOTE} main
  • git push ${UPSTREAM_REMOTE} :release-${RELEASE_VER}
  • git branch -d release-${RELEASE_VER}

• Fedora packaging:

  • update the rust-openssh-keys spec file in Fedora
    • bump the Version
    • switch the Release back to 1%{?dist}
    • remove any patches obsoleted by the new release
    • update changelog
  • run spectool -g -S rust-openssh-keys.spec
  • run kinit [email protected]
  • run fedpkg new-sources $(spectool -S rust-openssh-keys.spec | sed 's:.*/::')
  • PR the changes in Fedora
  • once the PR merges to rawhide, merge rawhide into the other relevant branches (e.g. f38) then push those, for example:

    git checkout rawhide
    git pull --ff-only
    git checkout f38
    git merge --ff-only rawhide
    git push origin f38

  • on each of those branches run fedpkg build
  • once the builds have finished, submit them to bodhi, filling in:
    • rust-openssh-keys for Packages
    • selecting the build(s) that just completed, except for the rawhide one (which gets submitted automatically)
    • writing brief release notes like "New upstream release; see release notes at link to GitHub release"
    • leave Update name blank
    • Type, Severity and Suggestion can be left as unspecified unless it is a security release. In that case select security with the appropriate severity.
    • Stable karma and Unstable karma can be set to 2 and -1, respectively.

The Data type, which holds the representations for all the supported key types, currently stores all the data in some number of Vec<u8>s. It should be converted to use arrays instead.

The Writer struct is used to write our public keys to disk. It is essentially the opposite of the Reader struct. However, there is one key difference - Writer uses an internal representation of Vec, where as Reader uses an array. Writer should be modified to remove the heap allocations and bring the implementation more in line with Reader.

Now, the openssh-keys could parse SSH keys, I want to add generate keys and save to files functions.

Support types:

• ssh-rsa 1024/2048/4096
• ssh-dss
• ssh-ed25519
• ecdsa-ssh2-nistp256
• ecdsa-ssh2-nistp384
• ecdsa-ssh2-nistp521

Currently, we support reading and writing keys in the format described in RFC 4253. In general, ssh implementations support a couple other additional key formats. Supporting this formats is less important for public keys, since most of the time people use the RFC 4253 format, but if we end up supporting private keys, ssh-keygen actually defaults to different formats for different key types, so it's much more important to support them.

The formats we should generally work to support are -

• RFC 4253
• RFC 4716
• PEM PKCS8
• PEM

I'm not sure yet what the differences between PEM and PEM PKCS8 are. Also, as far as I can tell, all of these are supported between both public and private keys.

An additional part of the work detailed in this issue is to consider restructuring the API to support this. I'm not sure yet exactly what the best way to expose this functionality is.

The RustCrypto crates are not inter-compatible between different release branches, so mixing and matching is not supported and will lead to very cryptic compilation failures (something like "trait Digest not implemented for sha2 but trait Digest is implemented for sha2").

For example, it might happen that the dependencies are resolved to md-5 v0.9 and sha2 v0.10 (or vice versa) due to other dependencies in the tree, which will lead to failures. Crates should depend only on a consistent set of RustCrypto crates to avoid this.

c.f. https://bugzilla.redhat.com/show_bug.cgi?id=2217521
(afterburn started to fail to build once openssh-keys was updated to v0.6)

Release process

This project uses cargo-release in order to prepare new releases, tag and sign the relevant git commit, and publish the resulting artifacts to crates.io.
The release process follows the usual PR-and-review flow, allowing an external reviewer to have a final check before publishing.

Requirements

This guide requires:

• A web browser (and network connectivity)
• git
• GPG setup and personal key for signing
• cargo (suggested: latest stable toolchain from rustup)
• cargo-release (suggested: cargo install -f cargo-release)
• Write access to this GitHub project
• A verified account on crates.io
• Membership in the Fedora CoreOS Crates Owners group, which will give you upload access to crates.io

Release checklist

These steps show how to release version x.y.z on the origin remote (this can be checked via git remote -av).
Push access to the upstream repository is required in order to publish the new tag and the PR branch.

⚠️: if origin is not the name of the locally configured remote that points to the upstream git repository (i.e. [email protected]:coreos/openssh-keys.git), be sure to assign the correct remote name to the UPSTREAM_REMOTE variable.

• prepare environment:

  • RELEASE_VER=x.y.z
  • UPSTREAM_REMOTE=origin
  • git checkout -b pre-release-${RELEASE_VER}

• write release notes:

  • write release notes in docs/release-notes.md
  • git add docs/release-notes.md && git commit -m "docs/release-notes: update for release ${RELEASE_VER}"

• land the changes:

  • PR the changes, get them reviewed, approved and merged
  • if doing a branched release, also include a PR to merge the docs/release-notes.md changes into main

• make sure the project is clean:

  • Make sure cargo-release is up to date: cargo install cargo-release
  • git checkout main && git pull ${UPSTREAM_REMOTE} main
  • cargo test --all-features
  • cargo clean
  • git clean -fd

• create release commit on a dedicated branch and tag it (the commit and tag will be signed with the GPG signing key you configured):

  • git checkout -b release-${RELEASE_VER}
  • cargo release --execute ${RELEASE_VER} (and confirm the version when prompted)

• open and merge a PR for this release:

  • git push ${UPSTREAM_REMOTE} release-${RELEASE_VER}
  • open a web browser and create a PR for the branch above
  • make sure the resulting PR contains exactly one commit
  • get the PR reviewed, approved and merged

• publish the artifacts (tag and crate):

  • git checkout v${RELEASE_VER}
  • verify that grep "^version = \"${RELEASE_VER}\"$" Cargo.toml produces output
  • git push ${UPSTREAM_REMOTE} v${RELEASE_VER}
  • cargo publish

• publish this release on GitHub:

  • find the new tag in the GitHub tag list, click the triple dots menu, and create a release for it
  • copy in the changelog from the release notes doc
  • publish release

• clean up the local environment (optional, but recommended):

  • cargo clean
  • git checkout main
  • git pull ${UPSTREAM_REMOTE} main
  • git push ${UPSTREAM_REMOTE} :pre-release-${RELEASE_VER} :release-${RELEASE_VER}
  • git branch -d pre-release-${RELEASE_VER} release-${RELEASE_VER}

• Fedora packaging:

  • update the rust-openssh-keys spec file in Fedora
    • bump the Version
    • switch the Release back to 1%{?dist}
    • remove any patches obsoleted by the new release
    • update changelog
  • run spectool -g -S rust-openssh-keys.spec
  • run kinit [email protected]
  • run fedpkg new-sources $(spectool -S rust-openssh-keys.spec | sed 's:.*/::')
  • PR the changes in Fedora
  • once the PR merges to rawhide, merge rawhide into the other relevant branches (e.g. f38) then push those, for example:

    git checkout rawhide
    git pull --ff-only
    git checkout f38
    git merge --ff-only rawhide
    git push origin f38

  • on each of those branches run fedpkg build
  • once the builds have finished, submit them to bodhi, filling in:
    • rust-openssh-keys for Packages
    • selecting the build(s) that just completed, except for the rawhide one (which gets submitted automatically)
    • writing brief release notes like "New upstream release; see release notes at link to GitHub release"
    • leave Update name blank
    • Type, Severity and Suggestion can be left as unspecified unless it is a security release. In that case select security with the appropriate severity.
    • Stable karma and Unstable karma can be set to 2 and -1, respectively.

The API exposed by the library uses a lot of Vec<u8> and String instead of arrays and str. We should investigate if it makes sense to convert them to minimize heap allocations, at least for functions that provide the core functionality of the library.

Functions that allocate on the heap which should be investigated -

• read_keys
• from_rsa
• from_dsa
• data
• to_key_format
• fingerprint
• to_fingerprint_string
• fingerprint_md5
• to_fingerprint_md5_string

the authorized_keys file specification allows for options to be present at the beginning of a line in the authorized keys file. since one of the primary uses of this library is to parse authorized_keys files, the parser should keep track of them, reading them correctly when parsing and reproducing them faithfully when printing them out.

this issue was first reported as coreos/bugs#2229, but this is the root cause.

Release process

This project uses cargo-release in order to prepare new releases, tag and sign the relevant git commit, and publish the resulting artifacts to crates.io.
The release process follows the usual PR-and-review flow, allowing an external reviewer to have a final check before publishing.

Requirements

This guide requires:

• A web browser (and network connectivity)
• git
• GPG setup and personal key for signing
• cargo (suggested: latest stable toolchain from rustup)
• cargo-release (suggested: cargo install -f cargo-release)
• Write access to this GitHub project
• A verified account on crates.io
• Membership in the Fedora CoreOS Crates Owners group, which will give you upload access to crates.io

Release checklist

These steps show how to release version x.y.z on the origin remote (this can be checked via git remote -av).
Push access to the upstream repository is required in order to publish the new tag and the PR branch.

⚠️: if origin is not the name of the locally configured remote that points to the upstream git repository (i.e. [email protected]:coreos/openssh-keys.git), be sure to assign the correct remote name to the UPSTREAM_REMOTE variable.

• prepare environment:

  • RELEASE_VER=x.y.z
  • UPSTREAM_REMOTE=origin
  • git checkout -b pre-release-${RELEASE_VER}

• check Cargo.toml for unintended increases of lower version bounds:

  • git diff $(git describe --abbrev=0) Cargo.toml

• write release notes:

  • write release notes in docs/release-notes.md
  • git add docs/release-notes.md && git commit -m "docs/release-notes: update for release ${RELEASE_VER}"

• land the changes:

  • PR the changes, get them reviewed, approved and merged
  • if doing a branched release, also include a PR to merge the docs/release-notes.md changes into main

• make sure the project is clean:

  • Make sure cargo-release is up to date: cargo install cargo-release
  • cargo test --all-features
  • git checkout main && git pull ${UPSTREAM_REMOTE} main
  • cargo clean
  • git clean -fd

• create release commit on a dedicated branch and tag it (the commit and tag will be signed with the GPG signing key you configured):

  • git checkout -b release-${RELEASE_VER}
  • cargo release --execute ${RELEASE_VER} (and confirm the version when prompted)

• open and merge a PR for this release:

  • git push ${UPSTREAM_REMOTE} release-${RELEASE_VER}
  • open a web browser and create a PR for the branch above
  • make sure the resulting PR contains exactly one commit
  • get the PR reviewed, approved and merged

• publish the artifacts (tag and crate):

  • git checkout v${RELEASE_VER}
  • verify that grep "^version = \"${RELEASE_VER}\"$" Cargo.toml produces output
  • git push ${UPSTREAM_REMOTE} v${RELEASE_VER}
  • cargo publish

• publish this release on GitHub:

  • find the new tag in the GitHub tag list, click the triple dots menu, and create a release for it
  • copy in the changelog from the release notes doc
  • publish release

• clean up the local environment (optional, but recommended):

  • cargo clean
  • git checkout main
  • git pull ${UPSTREAM_REMOTE} main
  • git push ${UPSTREAM_REMOTE} :pre-release-${RELEASE_VER} :release-${RELEASE_VER}
  • git branch -d pre-release-${RELEASE_VER} release-${RELEASE_VER}

• Fedora packaging:

  • update the rust-openssh-keys spec file in Fedora
    • bump the Version
    • switch the Release back to 1%{?dist}
    • remove any patches obsoleted by the new release
    • update changelog
  • run spectool -g -S rust-openssh-keys.spec
  • run kinit [email protected]
  • run fedpkg new-sources $(spectool -S rust-openssh-keys.spec | sed 's:.*/::')
  • PR the changes in Fedora
  • once the PR merges to rawhide, merge rawhide into the other relevant branches (e.g. f38) then push those, for example:

    git checkout rawhide
    git pull --ff-only
    git checkout f38
    git merge --ff-only rawhide
    git push origin f38

  • on each of those branches run fedpkg build
  • once the builds have finished, submit them to bodhi, filling in:
    • rust-openssh-keys for Packages
    • selecting the build(s) that just completed, except for the rawhide one (which gets submitted automatically)
    • writing brief release notes like "New upstream release; see release notes at link to GitHub release"
    • leave Update name blank
    • Type, Severity and Suggestion can be left as unspecified unless it is a security release. In that case select security with the appropriate severity.
    • Stable karma and Unstable karma can be set to 2 and -1, respectively.

I was confused at first, as the crate and repo names don't match. This propagates to most of the in-source docs/comments. To make it worse, an ssh-keys crates actually exists.

Did you settle on the openssh-keys name? If so, mind renaming the repository as well?

Your PublicKey contains three members:

pub struct PublicKey {
    options: Option<String>,
    data: Data,
    comment: Option<String>,
}

We can get a copy of the data by calling data, but there is no way to access the other members from the outside. Would you mind public getters?

If enough of the heap allocation is removed from the core data structures and functions of this library, it should be possible to provide a no_std feature flag, so libraries and executables that are operating in a no_std environment can still use this library. It will likely remove some more complicated convenience functionality.

It's possible that this isn't a library that anyone will want to use in a no_std environment, but I think that if the work in #17 #18 #19 is complete, it should be relatively easy to allow this, so we might as well investigate it.

Release process

This project uses cargo-release in order to prepare new releases, tag and sign the relevant git commit, and publish the resulting artifacts to crates.io.
The release process follows the usual PR-and-review flow, allowing an external reviewer to have a final check before publishing.

Requirements

This guide requires:

• A web browser (and network connectivity)
• git
• GPG setup and personal key for signing
• cargo (suggested: latest stable toolchain from rustup)
• cargo-release (suggested: cargo install -f cargo-release)
• Write access to this GitHub project
• A verified account on crates.io
• Membership in the Fedora CoreOS Crates Owners group, which will give you upload access to crates.io

Release checklist

These steps show how to release version x.y.z on the origin remote (this can be checked via git remote -av).
Push access to the upstream repository is required in order to publish the new tag and the PR branch.

⚠️: if origin is not the name of the locally configured remote that points to the upstream git repository (i.e. [email protected]:coreos/openssh-keys.git), be sure to assign the correct remote name to the UPSTREAM_REMOTE variable.

• make sure the project is clean and prepare the environment:

  • Make sure cargo-release is up to date: cargo install cargo-release
  • cargo test --all-features
  • cargo clean
  • git clean -fd
  • RELEASE_VER=x.y.z
  • UPSTREAM_REMOTE=origin

• create release commit on a dedicated branch and tag it (the commit and tag will be signed with the GPG signing key you configured):

  • git checkout -b release-${RELEASE_VER}
  • cargo release --execute ${RELEASE_VER} (and confirm the version when prompted)

• open and merge a PR for this release:

  • git push ${UPSTREAM_REMOTE} release-${RELEASE_VER}
  • open a web browser and create a PR for the branch above
  • make sure the resulting PR contains exactly one commit
  • in the PR body, write a short changelog with relevant changes since last release
  • get the PR reviewed, approved and merged

• publish the artifacts (tag and crate):

  • git checkout v${RELEASE_VER}
  • verify that grep "^version = \"${RELEASE_VER}\"$" Cargo.toml produces output
  • git push ${UPSTREAM_REMOTE} v${RELEASE_VER}
  • cargo publish

• publish this release on GitHub:

  • find the new tag in the GitHub tag list, click the triple dots menu, and create a release for it
  • copy in the changelog from the release PR
  • publish release

• clean up the local environment (optional, but recommended):

  • cargo clean
  • git checkout main
  • git pull ${UPSTREAM_REMOTE} main
  • git push ${UPSTREAM_REMOTE} :release-${RELEASE_VER}
  • git branch -d release-${RELEASE_VER}

• Fedora packaging:

  • update the rust-openssh-keys spec file in Fedora
    • bump the Version
    • switch the Release back to 1%{?dist}
    • remove any patches obsoleted by the new release
    • update changelog
  • run spectool -g -S rust-openssh-keys.spec
  • run kinit [email protected]
  • run fedpkg new-sources $(spectool -S rust-openssh-keys.spec | sed 's:.*/::')
  • PR the changes in Fedora
  • once the PR merges to rawhide, merge rawhide into the other relevant branches (e.g. f35) then push those, for example:

    git checkout rawhide
    git pull --ff-only
    git checkout f35
    git merge --ff-only rawhide
    git push origin f35

  • on each of those branches run fedpkg build
  • once the builds have finished, submit them to bodhi, filling in:
    • rust-openssh-keys for Packages
    • selecting the build(s) that just completed, except for the rawhide one (which gets submitted automatically)
    • writing brief release notes like "New upstream release; see release notes at link to GitHub release"
    • leave Update name blank
    • Type, Severity and Suggestion can be left as unspecified unless it is a security release. In that case select security with the appropriate severity.
    • Stable karma and Unstable karma can be set to 2 and -1, respectively.

A comment containing whitespace will not be parsed completely.

fn main() {
    // this is an example ed25519 key generated for this issue with
    //   ssh-keygen -t ed25519 -a 100 -f issue_example -C "jrimbault's stuff"
    let key = "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGuu/zz89yZCqYOZ1Nrj/eSrLqLZyqg9iZL4iSntAOzf jrimbault's stuff";
    let key = openssh_keys::PublicKey::parse(key).unwrap();
    assert_eq!(key.comment, Some("jrimbault's"));
}

Is this intended behavior ?

It seems like this is coming from this section

I think either the remaining parts should be re-concatenated together, or you should do do 2 str::splice_once instead of 1 unconditional str::split_whitespace.

split_whitepace isn't appropriate for parsing in my opinion since it loses information.

Relevant RFC section: RFC 4253 §4.2, notice the comments plural.

I think it's worth checking out the possibility of reading and writing openssh private keys.

The original motivation of this library was to provide ssh key reading and writing for coreos-metadata and update-ssh-keys, and they only require public key management. I didn't include private key functionality at the time because I didn't want to have to deal with sensitive data.

There is a good argument that supporting private keys in the openssh format should be within the scope of this library though. Generally, these keys are handled in pairs, and providing that general functionality will expand the uses of this library beyond simple public key management.

Things to consider when making this -

• library security. Is there some way for the information to leak where we don't want it to?
• api security/usability. Should we provide functionality for the keys to be pulled apart, or should they be entirely opaque? How much should we hide from consumers of the library?
• other key formats. Private keys have this worse than public keys in the ssh ecosystem. There are two competing formats - PEM and an SSH-specific key format apparently based on RFC 4716. I'm going to detail supporting other key formats in #22.

Release process

This project uses cargo-release in order to prepare new releases, tag and sign the relevant git commit, and publish the resulting artifacts to crates.io.
The release process follows the usual PR-and-review flow, allowing an external reviewer to have a final check before publishing.

Requirements

This guide requires:

• A web browser (and network connectivity)
• git
• GPG setup and personal key for signing
• cargo (suggested: latest stable toolchain from rustup)
• cargo-release (suggested: cargo install -f cargo-release)
• Write access to this GitHub project
• A verified account on crates.io
• Membership in the Fedora CoreOS Crates Owners group, which will give you upload access to crates.io

Release checklist

These steps show how to release version x.y.z on the origin remote (this can be checked via git remote -av).
Push access to the upstream repository is required in order to publish the new tag and the PR branch.

⚠️: if origin is not the name of the locally configured remote that points to the upstream git repository (i.e. [email protected]:coreos/openssh-keys.git), be sure to assign the correct remote name to the UPSTREAM_REMOTE variable.

• prepare environment:

  • RELEASE_VER=x.y.z
  • UPSTREAM_REMOTE=origin
  • git checkout -b pre-release-${RELEASE_VER}

• check Cargo.toml for unintended increases of lower version bounds:

  • git diff $(git describe --abbrev=0) Cargo.toml

• write release notes:

  • write release notes in docs/release-notes.md
  • git add docs/release-notes.md && git commit -m "docs/release-notes: update for release ${RELEASE_VER}"

• land the changes:

  • PR the changes, get them reviewed, approved and merged
  • if doing a branched release, also include a PR to merge the docs/release-notes.md changes into main

• make sure the project is clean:

  • Make sure cargo-release is up to date: cargo install cargo-release
  • git checkout main && git pull ${UPSTREAM_REMOTE} main
  • cargo test --all-features
  • cargo clean
  • git clean -fd

• create release commit on a dedicated branch and tag it (the commit and tag will be signed with the GPG signing key you configured):

  • git checkout -b release-${RELEASE_VER}
  • cargo release --execute ${RELEASE_VER} (and confirm the version when prompted)

• open and merge a PR for this release:

  • git push ${UPSTREAM_REMOTE} release-${RELEASE_VER}
  • open a web browser and create a PR for the branch above
  • make sure the resulting PR contains exactly one commit
  • get the PR reviewed, approved and merged

• publish the artifacts (tag and crate):

  • git checkout v${RELEASE_VER}
  • verify that grep "^version = \"${RELEASE_VER}\"$" Cargo.toml produces output
  • git push ${UPSTREAM_REMOTE} v${RELEASE_VER}
  • cargo publish

• publish this release on GitHub:

  • find the new tag in the GitHub tag list, click the triple dots menu, and create a release for it
  • copy in the changelog from the release notes doc
  • publish release

• clean up the local environment (optional, but recommended):

  • cargo clean
  • git checkout main
  • git pull ${UPSTREAM_REMOTE} main
  • git push ${UPSTREAM_REMOTE} :pre-release-${RELEASE_VER} :release-${RELEASE_VER}
  • git branch -d pre-release-${RELEASE_VER} release-${RELEASE_VER}

• Fedora packaging:

  • update the rust-openssh-keys spec file in Fedora
    • bump the Version
    • switch the Release back to 1%{?dist}
    • remove any patches obsoleted by the new release
    • update changelog
  • run spectool -g -S rust-openssh-keys.spec
  • run kinit [email protected]
  • run fedpkg new-sources $(spectool -S rust-openssh-keys.spec | sed 's:.*/::')
  • PR the changes in Fedora
  • once the PR merges to rawhide, merge rawhide into the other relevant branches (e.g. f38) then push those, for example:

    git checkout rawhide
    git pull --ff-only
    git checkout f38
    git merge --ff-only rawhide
    git push origin f38

  • on each of those branches run fedpkg build
  • once the builds have finished, submit them to bodhi, filling in:
    • rust-openssh-keys for Packages
    • selecting the build(s) that just completed, except for the rawhide one (which gets submitted automatically)
    • writing brief release notes like "New upstream release; see release notes at link to GitHub release"
    • leave Update name blank
    • Type, Severity and Suggestion can be left as unspecified unless it is a security release. In that case select security with the appropriate severity.
    • Stable karma and Unstable karma can be set to 2 and -1, respectively.

Hi

rustc:

$ rustc --version
rustc 1.68.0 (2c8cc3432 2023-03-06) (Arch Linux rust 1:1.68.0-1)

nightly channel:

$ rustup default
nightly-x86_64-unknown-linux-gnu (default)

Error:

error[E0599]: the method `update` exists for struct `CoreWrapper<Md5Core>`, but its trait bounds were not satisfied
   --> /home/aaa/.cargo/registry/src/index.crates.io-6f17d22bba15001f/openssh-keys-0.6.0/src/lib.rs:611:12
    |
611 |         sh.update(&self.data());
    |            ^^^^^^ method cannot be called on `CoreWrapper<Md5Core>` due to unsatisfied trait bounds
    |
   ::: /home/aaa/.cargo/registry/src/index.crates.io-6f17d22bba15001f/digest-0.10.6/src/core_api/wrapper.rs:24:1
    |
24  | pub struct CoreWrapper<T>
    | -------------------------
    | |
    | doesn't satisfy `CoreWrapper<Md5Core>: sha2::Digest`
    | doesn't satisfy `CoreWrapper<Md5Core>: sha2::digest::FixedOutput`
    | doesn't satisfy `CoreWrapper<Md5Core>: sha2::digest::Reset`
    | doesn't satisfy `CoreWrapper<Md5Core>: sha2::digest::Update`
    |
    = note: the following trait bounds were not satisfied:
            `CoreWrapper<Md5Core>: sha2::digest::Update`
            which is required by `CoreWrapper<Md5Core>: sha2::Digest`
            `CoreWrapper<Md5Core>: sha2::digest::FixedOutput`
            which is required by `CoreWrapper<Md5Core>: sha2::Digest`
            `CoreWrapper<Md5Core>: sha2::digest::Reset`
            which is required by `CoreWrapper<Md5Core>: sha2::Digest`
    = help: items from traits can only be used if the trait is in scope
help: the following traits are implemented but not in scope; perhaps add a `use` for one of them:
    |
31  | use md5::Digest;
    |
31  | use md5::digest::DynDigest;
    |
31  | use md5::digest::Update;
    |
31  | use sha2::Digest;
    |
      and 2 other candidates