Hi! I started poking around krator and ran into a few issues with the Rust version and the UI tests. This should resolve them, and I fixed the naming of the CI steps noted here: https://github.com/krator-rs/krator/pull/51#discussion_r716937482

• Update and pin rust to 1.60, reblessing UI tests
• Fix step names for UI test job

This partially reverts commit 357f4ad2b083dbdb3c58e42abf641744a496ad11. The k8s openapi crate reverted their change to remove Option wrapped collections and so this will be another breaking change and new version bump for krator

https://github.com/cncf/foundation/blob/master/online-programs-guidelines.md

May not be applicable for everyone. Just ACK if you are familiar already.

https://github.com/cncf/toc/blob/main/process/project_proposals.adoc#introduction

May not be applicable for everyone. Just ACK if you are familiar already.

• Add Cargo Deny to build action
• Fix any warnings and errors from Cargo Deny
• Tokio bumped to 1.9.0
• Fix clippy warnings from 1.54.0

@soenkeliebau

Closes #46

Your FOSSA integration was successful! Attached in this PR is a badge and license report to track scan status in your README.

Below are docs for integrating FOSSA license checks into your CI:

• CircleCI
• TravisCI
• Jenkins
• Other

Determine if basic project website is needed or not applicable.

• Ensure LF footer is there and website guidelines followed
• Analytics transferred to [email protected]

This is used to be able to create your maintainers mailing list.

Envoy's Owners file, for example: https://github.com/envoyproxy/envoy/blob/main/OWNERS.md

• Link to file in onboarding issue.

In krator/src/runtime.rs, tokio::sync::Notify is expected to always return instantly after it has been notified, rather than its actual behavior of waiting for a new notification. This results in the task getting stuck in some cases waiting for events to happen when they already have. Change to using a RwLock<bool>, or something similar.

Our audit workflow has been failing since we bumped to edition 2021 since it was running with 1.55. This PR brings it to parity with our other workflows (always install latest stable).

This instructs cargo deny to ignore the two advisories related to the time crate:

#57 #58

See the first issue for my investigation and explanation for why I believe these do not impact Krator.

ansi_term is Unmaintained

| Details | | | ------------------- | ---------------------------------------------- | | Status | unmaintained | | Package | ansi_term | | Version | 0.12.1 | | URL | https://github.com/ogham/rust-ansi-term/issues/72 | | Date | 2021-08-18 |

The maintainer has adviced this crate is deprecated and will not receive any maintenance.

The crate does not seem to have much dependencies and may or may not be ok to use as-is.

Last release seems to have been three years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• anstyle
• nu-ansi-term
• yansi

See advisory page for additional details.

Potential segfault in localtime_r invocations

| Details | | | ------------------- | ---------------------------------------------- | | Package | chrono | | Version | 0.4.19 | | URL | https://github.com/chronotope/chrono/issues/499 | | Date | 2020-11-10 |

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

Workarounds

No workarounds are known.

References

• time-rs/time#293

See advisory page for additional details.

Potential segfault in the time crate

| Details | | | ------------------- | ---------------------------------------------- | | Package | time | | Version | 0.1.44 | | URL | https://github.com/time-rs/time/issues/293 | | Date | 2020-11-18 | | Patched versions | >=0.2.23 | | Unaffected versions | =0.2.0,=0.2.1,=0.2.2,=0.2.3,=0.2.4,=0.2.5,=0.2.6 |

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

The affected functions from time 0.2.7 through 0.2.22 are:

• time::UtcOffset::local_offset_at
• time::UtcOffset::try_local_offset_at
• time::UtcOffset::current_local_offset
• time::UtcOffset::try_current_local_offset
• time::OffsetDateTime::now_local
• time::OffsetDateTime::try_now_local

The affected functions in time 0.1 (all versions) are:

• at
• at_utc

Non-Unix targets (including Windows and wasm) are unaffected.

Patches

Pending a proper fix, the internal method that determines the local offset has been modified to always return None on the affected operating systems. This has the effect of returning an Err on the try_* methods and UTC on the non-try_* methods.

Users and library authors with time in their dependency tree should perform cargo update, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3. series.

Workarounds

No workarounds are known.

References

time-rs/time#293

See advisory page for additional details.