This run took 4 seconds.
$ date
--- stdout ---
Tue Jun 11 08:08:12 UTC 2024
--- end ---
$ git clone file:///srv/git/wikimedia-irc-ircservserv.git repo --depth=1 -b master
--- stderr ---
Cloning into 'repo'...
--- stdout ---
--- end ---
$ git config user.name libraryupgrader
--- stdout ---
--- end ---
$ git config user.email tools.libraryupgrader@tools.wmflabs.org
--- stdout ---
--- end ---
$ git submodule update --init
--- stdout ---
--- end ---
$ grr init
--- stdout ---
Installed commit-msg hook.
--- end ---
$ git show-ref refs/heads/master
--- stdout ---
f5f4d952a11d2c2ace590a8d727f544d6e64a875 refs/heads/master
--- end ---
$ cargo-audit audit --json
--- stdout ---
{"database":{"advisory-count":628,"last-commit":"af76d4423761499f954411bb3071dcc72e6b0450","last-updated":"2024-06-05T08:00:17-06:00"},"lockfile":{"dependency-count":100},"settings":{"target_arch":null,"target_os":null,"severity":null,"ignore":[],"informational_warnings":["unmaintained","unsound","notice"]},"vulnerabilities":{"found":true,"count":8,"list":[{"advisory":{"id":"RUSTSEC-2020-0159","package":"chrono","title":"Potential segfault in `localtime_r` invocations","description":"### Impact\n\nUnix-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.\n\n### Workarounds\n\nNo workarounds are known.\n\n### References\n\n- [time-rs/time#293](https://github.com/time-rs/time/issues/293)","date":"2020-11-10","aliases":[],"related":["CVE-2020-26235","RUSTSEC-2020-0071"],"collection":"crates","categories":["code-execution","memory-corruption"],"keywords":["segfault"],"cvss":null,"informational":null,"references":[],"source":null,"url":"https://github.com/chronotope/chrono/issues/499","withdrawn":null,"license":"CC0-1.0"},"versions":{"patched":[">=0.4.20"],"unaffected":[]},"affected":null,"package":{"name":"chrono","version":"0.4.19","source":"registry+https://github.com/rust-lang/crates.io-index","checksum":"670ad68c9088c2a963aaa298cb369688cf3f9465ce5e2d4ca10e6e0098a1ce73","dependencies":[{"name":"libc","version":"0.2.94","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"num-integer","version":"0.1.44","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"num-traits","version":"0.2.14","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"time","version":"0.1.43","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"winapi","version":"0.3.9","source":"registry+https://github.com/rust-lang/crates.io-index"}],"replace":null}},{"advisory":{"id":"RUSTSEC-2024-0019","package":"mio","title":"Tokens for named pipes may be delivered after deregistration","description":"## Impact\n\nWhen using named pipes on Windows, mio will under some circumstances return invalid tokens that correspond to named pipes that have already been deregistered from the mio registry. The impact of this vulnerability depends on how mio is used. For some applications, invalid tokens may be ignored or cause a warning or a crash. On the other hand, for applications that store pointers in the tokens, this vulnerability may result in a use-after-free.\n\nFor users of Tokio, this vulnerability is serious and can result in a use-after-free in Tokio.\n\nThe vulnerability is Windows-specific, and can only happen if you are using named pipes. Other IO resources are not affected.\n\n## Affected versions\n\nThis vulnerability has been fixed in mio v0.8.11.\n\nAll versions of mio between v0.7.2 and v0.8.10 are vulnerable.\n\nTokio is vulnerable when you are using a vulnerable version of mio AND you are using at least Tokio v1.30.0. Versions of Tokio prior to v1.30.0 will ignore invalid tokens, so they are not vulnerable.\n\n## Workarounds\n\nVulnerable libraries that use mio can work around this issue by detecting and ignoring invalid tokens.\n\n## Technical details\n\nWhen an IO resource registered with mio has a readiness event, mio delivers that readiness event to the user using a user-specified token. Mio guarantees that when an IO resource is [deregistered](https://docs.rs/mio/latest/mio/struct.Registry.html#method.deregister), then it will never return the token for that IO resource again. However, for named pipes on windows, mio may sometimes deliver the token for a named pipe even though the named pipe has been previously deregistered.\n\nThis vulnerability was originally reported in the Tokio issue tracker: [tokio-rs/tokio#6369](https://github.com/tokio-rs/tokio/issues/6369) \nThis vulnerability was fixed in: [tokio-rs/mio#1760](https://github.com/tokio-rs/mio/pull/1760)\n\nThank you to [@rofoun](https://github.com/rofoun) and [@radekvit](https://github.com/radekvit) for discovering and reporting this issue.","date":"2024-03-04","aliases":["CVE-2024-27308","GHSA-r8w9-5wcg-vfj7"],"related":[],"collection":"crates","categories":[],"keywords":[],"cvss":null,"informational":null,"references":[],"source":null,"url":"https://github.com/tokio-rs/mio/security/advisories/GHSA-r8w9-5wcg-vfj7","withdrawn":null,"license":"CC0-1.0"},"versions":{"patched":[">=0.8.11"],"unaffected":["<0.7.2"]},"affected":{"arch":[],"os":["windows"],"functions":{"mio::windows::NamedPipe::new":[">=0.7.2, <=0.8.10"]}},"package":{"name":"mio","version":"0.7.11","source":"registry+https://github.com/rust-lang/crates.io-index","checksum":"cf80d3e903b34e0bd7282b218398aec54e082c840d9baf8339e0080a0c542956","dependencies":[{"name":"libc","version":"0.2.94","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"log","version":"0.4.14","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"miow","version":"0.3.7","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"ntapi","version":"0.3.6","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"winapi","version":"0.3.9","source":"registry+https://github.com/rust-lang/crates.io-index"}],"replace":null}},{"advisory":{"id":"RUSTSEC-2023-0044","package":"openssl","title":"`openssl` `X509VerifyParamRef::set_host` buffer over-read","description":"When this function was passed an empty string, `openssl` would attempt to call `strlen` on it, reading arbitrary memory until it reached a NUL byte.","date":"2023-06-20","aliases":["GHSA-xcf7-rvmh-g6q4"],"related":[],"collection":"crates","categories":["memory-exposure"],"keywords":[],"cvss":null,"informational":null,"references":[],"source":null,"url":"https://github.com/sfackler/rust-openssl/issues/1965","withdrawn":null,"license":"CC0-1.0"},"versions":{"patched":[">=0.10.55"],"unaffected":[]},"affected":{"arch":[],"os":[],"functions":{"openssl::x509::verify::X509VerifyParamRef::set_host":["<0.10.55, >=0.10.0"]}},"package":{"name":"openssl","version":"0.10.54","source":"registry+https://github.com/rust-lang/crates.io-index","checksum":"69b3f656a17a6cbc115b5c7a40c616947d213ba182135b014d6051b73ab6f019","dependencies":[{"name":"bitflags","version":"1.2.1","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"cfg-if","version":"1.0.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"foreign-types","version":"0.3.2","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"libc","version":"0.2.94","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"once_cell","version":"1.7.2","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"openssl-macros","version":"0.1.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"openssl-sys","version":"0.9.88","source":"registry+https://github.com/rust-lang/crates.io-index"}],"replace":null}},{"advisory":{"id":"RUSTSEC-2022-0013","package":"regex","title":"Regexes with large repetitions on empty sub-expressions take a very long time to parse","description":"The Rust Security Response WG was notified that the `regex` crate did not\nproperly limit the complexity of the regular expressions (regex) it parses. An\nattacker could use this security issue to perform a denial of service, by\nsending a specially crafted regex to a service accepting untrusted regexes. No\nknown vulnerability is present when parsing untrusted input with trusted\nregexes.\n\nThis issue has been assigned CVE-2022-24713. The severity of this vulnerability\nis \"high\" when the `regex` crate is used to parse untrusted regexes. Other uses\nof the `regex` crate are not affected by this vulnerability.\n\n## Overview\n\nThe `regex` crate features built-in mitigations to prevent denial of service\nattacks caused by untrusted regexes, or untrusted input matched by trusted\nregexes. Those (tunable) mitigations already provide sane defaults to prevent\nattacks. This guarantee is documented and it's considered part of the crate's\nAPI.\n\nUnfortunately a bug was discovered in the mitigations designed to prevent\nuntrusted regexes to take an arbitrary amount of time during parsing, and it's\npossible to craft regexes that bypass such mitigations. This makes it possible\nto perform denial of service attacks by sending specially crafted regexes to\nservices accepting user-controlled, untrusted regexes.\n\n## Affected versions\n\nAll versions of the `regex` crate before or equal to 1.5.4 are affected by this\nissue. The fix is include starting from `regex` 1.5.5.\n\n## Mitigations\n\nWe recommend everyone accepting user-controlled regexes to upgrade immediately\nto the latest version of the `regex` crate.\n\nUnfortunately there is no fixed set of problematic regexes, as there are\npractically infinite regexes that could be crafted to exploit this\nvulnerability. Because of this, we do not recommend denying known problematic\nregexes.\n\n## Acknowledgements\n\nWe want to thank Addison Crump for responsibly disclosing this to us according\nto the [Rust security policy][1], and for helping review the fix.\n\nWe also want to thank Andrew Gallant for developing the fix, and Pietro Albini\nfor coordinating the disclosure and writing this advisory.\n\n[1]: https://www.rust-lang.org/policies/security","date":"2022-03-08","aliases":["CVE-2022-24713","GHSA-m5pq-gvj9-9vr8"],"related":[],"collection":"crates","categories":["denial-of-service"],"keywords":[],"cvss":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","informational":null,"references":[],"source":null,"url":"https://groups.google.com/g/rustlang-security-announcements/c/NcNNL1Jq7Yw","withdrawn":null,"license":"CC0-1.0"},"versions":{"patched":[">=1.5.5"],"unaffected":[]},"affected":null,"package":{"name":"regex","version":"1.5.4","source":"registry+https://github.com/rust-lang/crates.io-index","checksum":"d07a8629359eb56f1e2fb1652bb04212c072a87ba68546a04065d525673ac461","dependencies":[{"name":"aho-corasick","version":"0.7.18","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"memchr","version":"2.4.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"regex-syntax","version":"0.6.25","source":"registry+https://github.com/rust-lang/crates.io-index"}],"replace":null}},{"advisory":{"id":"RUSTSEC-2023-0018","package":"remove_dir_all","title":"Race Condition Enabling Link Following and Time-of-check Time-of-use (TOCTOU)","description":"The remove_dir_all crate is a Rust library that offers additional features over the Rust\nstandard library fs::remove_dir_all function.\n\nIt was possible to trick a privileged process doing a recursive delete in an\nattacker controlled directory into deleting privileged files, on all operating systems.\n\nFor instance, consider deleting a tree called 'etc' in a parent directory\ncalled 'p'. Between calling `remove_dir_all(\"a\")` and remove_dir_all(\"a\")\nactually starting its work, the attacker can move 'p' to 'p-prime', and\nreplace 'p' with a symlink to '/'. Then the privileged process deletes 'p/etc'\nwhich is actually /etc, and now your system is broken. There are some\nmitigations for this exact scenario, such as CWD relative file lookup, but\nthey are not guaranteed - any code using absolute paths will not have that\nprotection in place.\n\nThe same attack could be performed at any point in the directory tree being\ndeleted: if 'a' contains a child directory called 'etc', attacking the\ndeletion by replacing 'a' with a link is possible.\n\nThe new code in this release mitigates the attack within the directory tree\nbeing deleted by using file-handle relative operations: to open 'a/etc', the\npath 'etc' relative to 'a' is opened, where 'a' is represented by a file\ndescriptor (Unix) or handle (Windows). With the exception of the entry points\ninto the directory deletion logic, this is robust against manipulation of the\ndirectory hierarchy, and remove_dir_all will only delete files and directories\ncontained in the tree it is deleting.\n\nThe entry path however is a challenge - as described above, there are some\npotential mitigations, but since using them must be done by the calling code,\nit is hard to be confident about the security properties of the path based\ninterface.\n\nThe new extension trait `RemoveDir` provides an interface where it is much\nharder to get it wrong.\n\n`somedir.remove_dir_contents(\"name-of-child\")`.\n\nCallers can then make their own security evaluation about how to securely get\na directory handle. That is still not particularly obvious, and we're going to\nfollow up with a helper of some sort (probably in the `fs_at` crate). Once\nthat is available, the path based entry points will get deprecated.\n\nIn the interim, processes that might run with elevated privileges should\nfigure out how to securely identify the directory they are going to delete, to\navoid the initial race. Pragmatically, other processes should be fine with the\npath based entry points : this is the same interface `std::fs::remove_dir_all`\noffers, and an unprivileged process running in an attacker controlled\ndirectory can't do anything that the attacker can't already do.","date":"2023-02-24","aliases":["GHSA-mc8h-8q98-g5hr"],"related":[],"collection":"crates","categories":[],"keywords":["TOCTOU"],"cvss":null,"informational":null,"references":["https://github.com/advisories/GHSA-mc8h-8q98-g5hr"],"source":null,"url":"https://github.com/XAMPPRocky/remove_dir_all/commit/7247a8b6ee59fc99bbb69ca6b3ca4bfd8c809ead","withdrawn":null,"license":"CC0-1.0"},"versions":{"patched":[">=0.8.0"],"unaffected":[]},"affected":{"arch":[],"os":[],"functions":{"remove_dir_all::ensure_empty_dir":["<0.8.0"],"remove_dir_all::remove_dir_all":["<0.8.0"],"remove_dir_all::remove_dir_contents":["<0.8.0"]}},"package":{"name":"remove_dir_all","version":"0.5.3","source":"registry+https://github.com/rust-lang/crates.io-index","checksum":"3acd125665422973a33ac9d3dd2df85edad0f4ae9b00dafb1a05e43a9f5ef8e7","dependencies":[{"name":"winapi","version":"0.3.9","source":"registry+https://github.com/rust-lang/crates.io-index"}],"replace":null}},{"advisory":{"id":"RUSTSEC-2020-0071","package":"time","title":"Potential segfault in the time crate","description":"### Impact\n\nThe affected functions set environment variables without synchronization. On Unix-like operating systems, this can crash in multithreaded programs. Programs may segfault due to dereferencing a dangling pointer if an environment variable is read in a different thread than the affected functions. This may occur without the user's knowledge, notably in the Rust standard library or third-party libraries.\n\nThe affected functions from time 0.2.7 through 0.2.22 are:\n\n- `time::UtcOffset::local_offset_at`\n- `time::UtcOffset::try_local_offset_at`\n- `time::UtcOffset::current_local_offset`\n- `time::UtcOffset::try_current_local_offset`\n- `time::OffsetDateTime::now_local`\n- `time::OffsetDateTime::try_now_local`\n\nThe affected functions in time 0.1 (all versions) are:\n\n- `time::at_utc`\n- `time::at`\n- `time::now`\n- `time::tzset`\n\nNon-Unix targets (including Windows and wasm) are unaffected.\n\n### Patches\n\nPending 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.\n\nUsers and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code.\n\nUsers 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.\n\n### Workarounds\n\nA possible workaround for crates affected through the transitive dependency in `chrono`, is to avoid using the default `oldtime` feature dependency of the `chrono` crate by disabling its `default-features` and manually specifying the required features instead.\n\n#### Examples:\n\n`Cargo.toml`: \n\n```toml\nchrono = { version = \"0.4\", default-features = false, features = [\"serde\"] }\n```\n\n```toml\nchrono = { version = \"0.4.22\", default-features = false, features = [\"clock\"] }\n```\n\nCommandline: \n\n```bash\ncargo add chrono --no-default-features -F clock\n```\n\nSources: \n - [chronotope/chrono#602 (comment)](https://github.com/chronotope/chrono/issues/602#issuecomment-1242149249) \n - [vityafx/serde-aux#21](https://github.com/vityafx/serde-aux/issues/21)","date":"2020-11-18","aliases":["CVE-2020-26235","GHSA-wcg3-cvx6-7396"],"related":[],"collection":"crates","categories":["code-execution","memory-corruption"],"keywords":["segfault"],"cvss":"CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","informational":null,"references":[],"source":null,"url":"https://github.com/time-rs/time/issues/293","withdrawn":null,"license":"CC0-1.0"},"versions":{"patched":[">=0.2.23"],"unaffected":["=0.2.0","=0.2.1","=0.2.2","=0.2.3","=0.2.4","=0.2.5","=0.2.6"]},"affected":{"arch":[],"os":["linux","redox","solaris","android","ios","macos","netbsd","openbsd","freebsd"],"functions":{"time::OffsetDateTime::now_local":["<0.2.23"],"time::OffsetDateTime::try_now_local":["<0.2.23"],"time::UtcOffset::current_local_offset":["<0.2.23"],"time::UtcOffset::local_offset_at":["<0.2.23"],"time::UtcOffset::try_current_local_offset":["<0.2.23"],"time::UtcOffset::try_local_offset_at":["<0.2.23"],"time::at":["^0.1"],"time::at_utc":["^0.1"],"time::now":["^0.1"]}},"package":{"name":"time","version":"0.1.43","source":"registry+https://github.com/rust-lang/crates.io-index","checksum":"ca8a50ef2360fbd1eeb0ecd46795a87a19024eb4b53c5dc916ca1fd95fe62438","dependencies":[{"name":"libc","version":"0.2.94","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"winapi","version":"0.3.9","source":"registry+https://github.com/rust-lang/crates.io-index"}],"replace":null}},{"advisory":{"id":"RUSTSEC-2021-0072","package":"tokio","title":"Task dropped in wrong thread when aborting `LocalSet` task","description":"When aborting a task with `JoinHandle::abort`, the future is dropped in the\nthread calling abort if the task is not currently being executed. This is\nincorrect for tasks spawned on a `LocalSet`.\n\nThis can easily result in race conditions as many projects use `Rc` or `RefCell`\nin their Tokio tasks for better performance.\n\nSee [tokio#3929][issue] for more details.\n\n[issue]: https://github.com/tokio-rs/tokio/issues/3929","date":"2021-07-07","aliases":["CVE-2021-38191","GHSA-2grh-hm3w-w7hv"],"related":[],"collection":"crates","categories":["memory-corruption"],"keywords":["race condition","send"],"cvss":null,"informational":null,"references":[],"source":null,"url":"https://github.com/tokio-rs/tokio/issues/3929","withdrawn":null,"license":"CC0-1.0"},"versions":{"patched":[">=1.5.1, <1.6.0",">=1.6.3, <1.7.0",">=1.7.2, <1.8.0",">=1.8.1"],"unaffected":["<0.3.0"]},"affected":{"arch":[],"os":[],"functions":{"tokio::task::JoinHandle::abort":["<=1.8.0, >=0.3.0"]}},"package":{"name":"tokio","version":"1.6.0","source":"registry+https://github.com/rust-lang/crates.io-index","checksum":"bd3076b5c8cc18138b8f8814895c11eb4de37114a5d127bafdc5e55798ceef37","dependencies":[{"name":"autocfg","version":"1.0.1","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"bytes","version":"1.0.1","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"libc","version":"0.2.94","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"memchr","version":"2.4.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"mio","version":"0.7.11","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"num_cpus","version":"1.13.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"once_cell","version":"1.7.2","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"parking_lot","version":"0.11.1","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"pin-project-lite","version":"0.2.6","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"signal-hook-registry","version":"1.3.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"tokio-macros","version":"1.2.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"winapi","version":"0.3.9","source":"registry+https://github.com/rust-lang/crates.io-index"}],"replace":null}},{"advisory":{"id":"RUSTSEC-2021-0124","package":"tokio","title":"Data race when sending and receiving after closing a `oneshot` channel","description":"If a `tokio::sync::oneshot` channel is closed (via the\n[`oneshot::Receiver::close`] method), a data race may occur if the\n`oneshot::Sender::send` method is called while the corresponding\n`oneshot::Receiver` is `await`ed or calling `try_recv`.\n\nWhen these methods are called concurrently on a closed channel, the two halves\nof the channel can concurrently access a shared memory location, resulting in a\ndata race. This has been observed to [cause memory corruption][corruption].\n\nNote that the race only occurs when **both** halves of the channel are used\nafter the `Receiver` half has called `close`. Code where `close` is not used, or where the\n`Receiver` is not `await`ed and `try_recv` is not called after calling `close`,\nis not affected.\n\nSee [tokio#4225][issue] for more details.\n\n[corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847\n[issue]: https://github.com/tokio-rs/tokio/issues/4225\n[`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.close","date":"2021-11-16","aliases":["CVE-2021-45710","GHSA-fg7r-2g4j-5cgr"],"related":[],"collection":"crates","categories":["memory-corruption","thread-safety"],"keywords":["race condition"],"cvss":null,"informational":null,"references":[],"source":null,"url":"https://github.com/tokio-rs/tokio/issues/4225","withdrawn":null,"license":"CC0-1.0"},"versions":{"patched":[">=1.8.4, <1.9.0",">=1.13.1"],"unaffected":["<0.1.14"]},"affected":{"arch":[],"os":[],"functions":{"tokio::sync::oneshot::Receiver::close":["<=1.13.0, >=0.1.14"]}},"package":{"name":"tokio","version":"1.6.0","source":"registry+https://github.com/rust-lang/crates.io-index","checksum":"bd3076b5c8cc18138b8f8814895c11eb4de37114a5d127bafdc5e55798ceef37","dependencies":[{"name":"autocfg","version":"1.0.1","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"bytes","version":"1.0.1","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"libc","version":"0.2.94","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"memchr","version":"2.4.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"mio","version":"0.7.11","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"num_cpus","version":"1.13.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"once_cell","version":"1.7.2","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"parking_lot","version":"0.11.1","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"pin-project-lite","version":"0.2.6","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"signal-hook-registry","version":"1.3.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"tokio-macros","version":"1.2.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"winapi","version":"0.3.9","source":"registry+https://github.com/rust-lang/crates.io-index"}],"replace":null}}]},"warnings":{"unmaintained":[{"kind":"unmaintained","package":{"name":"encoding","version":"0.2.33","source":"registry+https://github.com/rust-lang/crates.io-index","checksum":"6b0d943856b990d12d3b55b359144ff341533e516d94098b1d3fc1ac666d36ec","dependencies":[{"name":"encoding-index-japanese","version":"1.20141219.5","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"encoding-index-korean","version":"1.20141219.5","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"encoding-index-simpchinese","version":"1.20141219.5","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"encoding-index-singlebyte","version":"1.20141219.5","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"encoding-index-tradchinese","version":"1.20141219.5","source":"registry+https://github.com/rust-lang/crates.io-index"}],"replace":null},"advisory":{"id":"RUSTSEC-2021-0153","package":"encoding","title":"`encoding` is unmaintained","description":"Last release was on 2016-08-28. The [issue](https://github.com/lifthrasiir/rust-encoding/issues/127) inquiring as to the status of the crate has gone unanswered by the maintainer.\n\n## Possible alternatives\n\n- [encoding_rs](https://crates.io/crates/encoding_rs)","date":"2021-12-05","aliases":[],"related":[],"collection":"crates","categories":[],"keywords":[],"cvss":null,"informational":"unmaintained","references":[],"source":null,"url":"https://github.com/lifthrasiir/rust-encoding/issues/127","withdrawn":null,"license":"CC0-1.0"},"affected":null,"versions":{"patched":[],"unaffected":[]}}],"unsound":[{"kind":"unsound","package":{"name":"atty","version":"0.2.14","source":"registry+https://github.com/rust-lang/crates.io-index","checksum":"d9b39be18770d11421cdb1b9947a45dd3f37e93092cbf377614828a319d5fee8","dependencies":[{"name":"hermit-abi","version":"0.1.18","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"libc","version":"0.2.94","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"winapi","version":"0.3.9","source":"registry+https://github.com/rust-lang/crates.io-index"}],"replace":null},"advisory":{"id":"RUSTSEC-2021-0145","package":"atty","title":"Potential unaligned read","description":"On windows, `atty` dereferences a potentially unaligned pointer.\n\nIn practice however, the pointer won't be unaligned unless a custom global allocator is used.\n\nIn particular, the `System` allocator on windows uses `HeapAlloc`, which guarantees a large enough alignment.\n\n# atty is Unmaintained\n\nA Pull Request with a fix has been provided over a year ago but the maintainer seems to be unreachable.\n\nLast release of `atty` was almost 3 years ago.\n\n## Possible Alternative(s)\n\nThe below list has not been vetted in any way and may or may not contain alternatives;\n\n - [std::io::IsTerminal](https://doc.rust-lang.org/stable/std/io/trait.IsTerminal.html) - Stable since Rust 1.70.0\n - [is-terminal](https://crates.io/crates/is-terminal) - Standalone crate supporting Rust older than 1.70.0","date":"2021-07-04","aliases":["GHSA-g98v-hv3f-hcfr"],"related":[],"collection":"crates","categories":[],"keywords":["unaligned-read"],"cvss":null,"informational":"unsound","references":["https://github.com/softprops/atty/pull/51","https://github.com/softprops/atty/issues/57"],"source":null,"url":"https://github.com/softprops/atty/issues/50","withdrawn":null,"license":"CC0-1.0"},"affected":{"arch":[],"os":["windows"],"functions":{}},"versions":{"patched":[],"unaffected":[]}},{"kind":"unsound","package":{"name":"openssl","version":"0.10.54","source":"registry+https://github.com/rust-lang/crates.io-index","checksum":"69b3f656a17a6cbc115b5c7a40c616947d213ba182135b014d6051b73ab6f019","dependencies":[{"name":"bitflags","version":"1.2.1","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"cfg-if","version":"1.0.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"foreign-types","version":"0.3.2","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"libc","version":"0.2.94","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"once_cell","version":"1.7.2","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"openssl-macros","version":"0.1.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"openssl-sys","version":"0.9.88","source":"registry+https://github.com/rust-lang/crates.io-index"}],"replace":null},"advisory":{"id":"RUSTSEC-2023-0072","package":"openssl","title":"`openssl` `X509StoreRef::objects` is unsound","description":"This function returned a shared reference into an OpenSSL datastructure but did not account for interior mutability. OpenSSL may modify the data behind this reference, meaning accesses can race and the reference is unsound.\n\nUse of this function should be replaced with `X509StoreRef::all_certificates`.","date":"2023-11-23","aliases":["GHSA-xphf-cx8h-7q9g"],"related":[],"collection":"crates","categories":["memory-corruption"],"keywords":[],"cvss":null,"informational":"unsound","references":[],"source":null,"url":"https://github.com/sfackler/rust-openssl/issues/2096","withdrawn":null,"license":"CC0-1.0"},"affected":{"arch":[],"os":[],"functions":{"openssl::x509::store::X509StoreRef::objects":["<0.10.60, >=0.10.29"]}},"versions":{"patched":[">=0.10.60"],"unaffected":[]}},{"kind":"unsound","package":{"name":"tokio","version":"1.6.0","source":"registry+https://github.com/rust-lang/crates.io-index","checksum":"bd3076b5c8cc18138b8f8814895c11eb4de37114a5d127bafdc5e55798ceef37","dependencies":[{"name":"autocfg","version":"1.0.1","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"bytes","version":"1.0.1","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"libc","version":"0.2.94","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"memchr","version":"2.4.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"mio","version":"0.7.11","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"num_cpus","version":"1.13.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"once_cell","version":"1.7.2","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"parking_lot","version":"0.11.1","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"pin-project-lite","version":"0.2.6","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"signal-hook-registry","version":"1.3.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"tokio-macros","version":"1.2.0","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"winapi","version":"0.3.9","source":"registry+https://github.com/rust-lang/crates.io-index"}],"replace":null},"advisory":{"id":"RUSTSEC-2023-0005","package":"tokio","title":"`tokio::io::ReadHalf<T>::unsplit` is Unsound","description":"`tokio::io::ReadHalf<T>::unsplit` can violate the `Pin` contract\n\nThe soundness issue is described in the [tokio/issues#5372](https://github.com/tokio-rs/tokio/issues/5372)\n\nSpecific set of conditions needed to trigger an issue (a !Unpin type in ReadHalf)\nis unusual, combined with the difficulty of making any arbitrary use-after-free\nexploitable in Rust without doing a lot of careful alignment of data types in\nthe surrounding code.\n\nThe `tokio` feature `io-util` is also required to be enabled to trigger this\nsoundness issue.\n\nThanks to zachs18 reporting the issue to Tokio team responsibly and taiki-e\nand carllerche appropriately responding and fixing the soundness bug.\n\nTokio before 0.2.0 used `futures` 0.1 that did not have `Pin`, so it is not\naffected by this issue.","date":"2023-01-11","aliases":["GHSA-4q83-7cq4-p6wg"],"related":[],"collection":"crates","categories":["memory-exposure"],"keywords":[],"cvss":null,"informational":"unsound","references":[],"source":null,"url":"https://github.com/tokio-rs/tokio/issues/5372","withdrawn":null,"license":"CC0-1.0"},"affected":null,"versions":{"patched":[">=1.18.5, <1.19.0",">=1.20.4, <1.21.0",">=1.24.2"],"unaffected":["<0.2.0"]}}]}}
--- end ---
[DNM] there are no updates
$ git add .
--- stdout ---
--- end ---
$ git commit -F /tmp/tmpm5pt9poj
--- stdout ---
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
--- end ---