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.

Test Scenario: If a deployment has an HPA and min replicas of HPA are greater than 1. Now you scale replicas of the deployment to 1. Now the HPA will scale the deployment back to minReplicas and kube-saver will ignore scaling back to 1 for the second time.

Proposed solution:

1. Add HPA as a supported resource in rules.yaml. Make sure you match the .spec.minReplicas of HPA to scaleddown replicas of deployment.
2. If input resource is Namespace. Need to find HPA in Namespace and accordingly set .spec.minReplicas to input replicas. Make sure this is done before Deployment. You can ignore the situation if the input replicas set is 0.

• If a namespace has HPA for a deployment and the resource is Namespace and replicas is set to 0. Then HPA minReplicas is set to 1 and the deployment in the namespace is set to 0
• Support Upscaler functionality for HPA
• Added more test

issue: https://github.com/maheshrayas/kube-saver/issues/6

Support Resource name: deployment, deployments, Deployments statefulset, statefulsets, StatefulSet, StatefulSets, Statefulset, Statefulsets namespace, namespaces, Namespace, Namespaces

Using a Custom Cipher with NID_undef may lead to NULL encryption

| Details | | | ------------------- | ---------------------------------------------- | | Package | openssl-src | | Version | 300.0.9+3.0.5 | | URL | https://www.openssl.org/news/secadv/20221011.txt | | Date | 2022-10-11 | | Patched versions | >=300.0.10 | | Unaffected versions | <300.0.0 |

OpenSSL supports creating a custom cipher via the legacy EVP_CIPHER_meth_new() function and associated function calls. This function was deprecated in OpenSSL 3.0 and application authors are instead encouraged to use the new provider mechanism in order to implement custom ciphers.

OpenSSL versions 3.0.0 to 3.0.5 incorrectly handle legacy custom ciphers passed to the EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() and EVP_CipherInit_ex2() functions (as well as other similarly named encryption and decryption initialisation functions). Instead of using the custom cipher directly it incorrectly tries to fetch an equivalent cipher from the available providers. An equivalent cipher is found based on the NID passed to EVP_CIPHER_meth_new(). This NID is supposed to represent the unique NID for a given cipher. However it is possible for an application to incorrectly pass NID_undef as this value in the call to EVP_CIPHER_meth_new(). When NID_undef is used in this way the OpenSSL encryption/decryption initialisation function will match the NULL cipher as being equivalent and will fetch this from the available providers. This will succeed if the default provider has been loaded (or if a third party provider has been loaded that offers this cipher). Using the NULL cipher means that the plaintext is emitted as the ciphertext.

Applications are only affected by this issue if they call EVP_CIPHER_meth_new() using NID_undef and subsequently use it in a call to an encryption/decryption initialisation function. Applications that only use SSL/TLS are not impacted by this issue.

See advisory page for additional details.

use tokio::spawn to execute resources concurrently to other tasks. Currently all the tasks are done in sequence (async)

https://docs.rs/tokio/latest/tokio/fn.spawn.html