feat: add linter checks for naming conventions (#1487)
This PR provides extra checks for compliance of configuration options,
action names and action parameters with respect to use hyphens instead
of snake case when composite/compound keys are used.
The checks follows [this
guideline](https://juju.is/docs/sdk/styleguide#heading--naming).
In general, we raise warning, although I believe that charms should
provide strong consistency on the naming scheme adopted within the
charm. So if one uses mixed contentions (some keys have hyphens and
others have snake case), I would believe it is fair to error out. This
could be by passed by using `--force`, but that would produce a strong
nudge on charmers to NOT mix the two conventions.
chore(deps): update dependency cryptography to v42.0.2 (#1529)
[](https://renovatebot.com)
This PR contains the following updates:
| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| [cryptography](https://togithub.com/pyca/cryptography)
([changelog](https://cryptography.io/en/latest/changelog/)) | `==42.0.1`
-> `==42.0.2` |
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
### GitHub Vulnerability Alerts
#### [CVE-2024-0727](https://nvd.nist.gov/vuln/detail/CVE-2024-0727)
Issue summary: Processing a maliciously formatted PKCS12 file may lead
OpenSSL
to crash leading to a potential Denial of Service attack
Impact summary: Applications loading files in the PKCS12 format from
untrusted
sources might terminate abruptly.
A file in PKCS12 format can contain certificates and keys and may come
from an
untrusted source. The PKCS12 specification allows certain fields to be
NULL, but
OpenSSL does not correctly check for this case. This can lead to a NULL
pointer
dereference that results in OpenSSL crashing. If an application
processes PKCS12
files from an untrusted source using the OpenSSL APIs then that
application will
be vulnerable to this issue.
OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),
PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(),
PKCS12_unpack_authsafes()
and PKCS12_newpass().
We have also fixed a similar issue in SMIME_write_PKCS7(). However since
this
function is related to writing data we do not consider it security
significant.
The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.
---
### Release Notes
<details>
<summary>pyca/cryptography (cryptography)</summary>
###
[`v42.0.2`](https://togithub.com/pyca/cryptography/compare/42.0.1...42.0.2)
[Compare
Source](https://togithub.com/pyca/cryptography/compare/42.0.1...42.0.2)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "" in timezone Etc/UTC, Automerge - At
any time (no schedule defined).
🚦 **Automerge**: Enabled.
â™» **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Mend
Renovate](https://www.mend.io/free-developer-tools/renovate/). View
repository job log
[here](https://developer.mend.io/github/canonical/charmcraft).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4xNzMuMCIsInVwZGF0ZWRJblZlciI6IjM3LjE3My4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
