# packages

pkgId: bfe7ccfd1836d02fe8e124b3792f5d4f1c6bb62b402210d76f2526100f34b29e
name: python-cert-core
arch: src
version: 3.0.0
epoch: 0
release: 1
summary: Blockcerts core models for python
url: https://github.com/blockchain-certificates/cert-core
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cert-core-3.0.0-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://travis-ci.org/blockchain-certificates/cert-core.svg?branch=master)](https://travis-ci.org/blockchain-certificates/cert-core)
  [![PyPI version](https://badge.fury.io/py/cert-core.svg)](https://badge.fury.io/py/cert-core)


  This python library contains common Blockcerts models and accessors used by other Blockcerts python libraries.

  Subpackages:



  Parses different versions of Blockcerts JSON files into a common Certificate model.



  Blockchain certificate storage. This is used as a library in the cert-viewer project.

  The certificate storage interface is [simplekv](https://pypi.python.org/pypi/simplekv/). The default configurations
  use the FilesystemStore, which is highly recommended if you are getting started. This makes it easier to issue,
  copy, and view your Blockchain Certificates.



  The certificate storage location can be modified with the following configuration entries in your `conf.ini` file:

  - `cert_store_type`: which key-value backing store to use. Current supported values are:
    - `simplekv_fs`: (Default) file system store
    - `simplekv_gridfs`: (Advanced) gridfs store
  - `cert_store_path`: file system path if using `simplekv_fs`
  - `mongodb_uri`: mongo db uri (including db name) if using `simplekv_gridfs`


  Example File System config:

  ```
  cert_store_type = simplekv_fs
  cert_store_path = ./cert_data
  ```

  Example GridFS config (Advanced):

  ```
  cert_store_type = simplekv_gridfs
  mongodb_uri = mongodb://localhost:27017/test
  ```




  **Warning**

  Most users should ignore these instructions, which are only included as a temporary bridge for earlier users of blockcerts. We recommend migrating to the latest version of Blockcerts.



  Warning: avoid this option unless you are sure you need it. Earlier versions of the Blockchain Certificate
  required a separate storage of the certificate transaction id. That was managed in a `certificates` mongo db table.

  The `--v1_aware` flag allows support for these certificates.




  1. Ensure you have an python environment. [Recommendations](https://github.com/blockchain-certificates/cert-issuer/blob/master/docs/virtualenv.md)

  2. Git clone the repository and change to the directory

    ```bash
    git clone https://github.com/blockchain-certificates/cert-core.git && cd cert-core
    ```

  3. Run cert-core setup

    ```bash
    pip install .
    ```



  This project uses tox to validate against several python environments.

  1. Ensure you have an python environment. [Recommendations](https://github.com/blockchain-certificates/cert-issuer/blob/master/docs/virtualenv.md)

  2. Run tests
      ```
      ./run_tests.sh
      ```



  - [First time info](http://peterdowns.com/posts/first-time-with-pypi.html)
  - Publish script: `./release_package.sh`



  Contact us at [the Blockcerts community forum](http://community.blockcerts.org/).


pkgId: eb5ebaa4e1ac301cde12e9059ac87fd979e91ae4da2a326987772e215c491934
name: python-cert-host-scraper
arch: src
version: 0.9.4
epoch: 0
release: 1
summary: please add a summary manually as the author left a blank one
url: https://github.com/inverse/cert-host-scraper
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cert-host-scraper-0.9.4-1.src.rpm
checksum_type: sha256
description:
  ![CI](https://github.com/inverse/cert-host-scraper/workflows/CI/badge.svg)
  [![PyPI version](https://badge.fury.io/py/cert-host-scraper.svg)](https://badge.fury.io/py/cert-host-scraper)
  ![PyPI downloads](https://img.shields.io/pypi/dm/cert-host-scraper?label=pypi%20downloads)
  [![License](https://img.shields.io/github/license/inverse/cert-host-scraper.svg)](LICENSE)
  [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)

  Query the certificate transparency log from [crt.sh](https://crt.sh) by a given a keyword and returns the status code of the matched results. Optionally, filtering the results by status code.

  <img alt="Demo of cert-host-scraper" src="https://vhs.charm.sh/vhs-3n8rmkDw9BDCmq55P8YKAy.gif" width="800" />




  ```bash
  cert-host-scraper search your-domain.com [--status-code 200]
  ```



  With pipx:

  ```bash
  pipx install cert-host-scraper
  ```

  With pip:

  ```bash
  pip install cert-host-scraper
  ```



  Requires [poetry][0] and Python 3.10+.

  ```
  poetry install
  poetry run python -m cert_host_scraper.cli
  ```



  MIT

  [0]: https://python-poetry.org


pkgId: e6e43165d437a6d21b68cdf6974162eae78a67887ff7fe1c887bcc931110a5c3
name: python-cert-issuer
arch: src
version: 3.7.0
epoch: 0
release: 1
summary: Issues blockchain certificates using the Bitcoin blockchain
url: https://github.com/blockchain-certificates/cert-issuer
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cert-issuer-3.7.0-1.src.rpm
checksum_type: sha256
description:
  [![Verifiable Credential Compliance result](https://badgen.net/badge/Verifiable%20Credentials%20v1/compliant/green?icon=https://www.w3.org/Icons/WWW/w3c_home_nb-v.svg)](https://www.blockcerts.org/vc-compliance-report.html)
  [![Build Status](https://travis-ci.org/blockchain-certificates/cert-issuer.svg?branch=master)](https://travis-ci.org/blockchain-certificates/cert-issuer)
  [![PyPI version](https://badge.fury.io/py/cert-issuer.svg)](https://badge.fury.io/py/cert-issuer)



  The cert-issuer project issues blockchain certificates by creating a transaction from the issuing institution to the
  recipient on the Bitcoin or Ethereum blockchains. That transaction includes the hash of the certificate itself.

  Blockcerts v3 is released. This new version of the standard leverages the [W3C Verifiable Credentials specification](https://www.w3.org/TR/vc-data-model/), and documents are signed with [MerkleProof2019 LD signature](https://w3c-ccg.github.io/lds-merkle-proof-2019/). Use of [DIDs (Decentralized Identifiers)](https://www.w3.org/TR/did-core/) is also possible to provide more cryptographic proof of the ownership of the issuing address. See [section](#working-with-dids) down below

  Cert-issuer v3 is _not_ backwards compatible and does not support Blockcerts v2 issuances. If you need to work with v2, you need to install cert-issuer v2 or use the [v2](https://github.com/blockchain-certificates/cert-issuer/tree/v2) branch of this repo.
  You may expect little to no maintenance to the v2 code at this point.



  For development or testing using web requests, check out the documentation at [docs/web_resources.md](./docs/web_resources.md).





  This uses bitcoind in regtest mode. This route makes many simplifications to allow a quick start, and is intended for
  experimenting only.

  1. First ensure you have Docker installed. [See our Docker installation help](docs/docker_install.md).

  2. Clone the repo and change to the directory

     ```
     git clone https://github.com/blockchain-certificates/cert-issuer.git && cd cert-issuer
     ```

  3. From a command line in cert-issuer dir, build your docker container:

     ```
     docker build -t bc/cert-issuer:1.0 .
     ```

  4. Read before running!

     - Once you launch the docker container, you will make some changes using your personal issuing information. This flow mirrors what you would if you were issuing real certificates.
     - To avoid losing your work, you should create snapshots of your docker container. You can do this by running:

       ```
       docker ps -l
       docker commit <container for your bc/cert-issuer> my_cert_issuer
       ```

  5. When you're ready to run:

     ```
     docker run -it bc/cert-issuer:1.0 bash
     ```

  6. Copy the blockchain certificates you issued out of the docker container to a local directory
     ```
     docker cp <container for your bc/cert-issuer>:/etc/cert-issuer/data/blockchain_certificates/<your-certificate-guid>.json <path_to_local_dir>
     ```



  **Important**: this is a simplification to avoid using a USB, which needs to be inserted and removed during the
  standard certficate issuing process. Do not use these addresses or private keys for anything other than experimenting.

  Ensure your docker image is running and bitcoind process is started

  1. Creating a wallet first with `bitcoin-cli createwallet “<wallet name>”`

     ```
     bitcoin-cli createwallet "testwallet"
     ```

  2. Load wallet `bitcoin-cli loadwallet "<path to the directory of the created wallet>"`

     ```
     bitcoin-cli loadwallet "/root/.bitcoin/regtest/wallets/testwallet/"
     ```

     You can `bitcoin-cli listwallets` to check if your wallet is loaded

  3. Create an _issuing address_ and save the output as follows:

     ```
     issuer=`bitcoin-cli getnewaddress`
     ```

     ```
     sed -i.bak "s/<issuing-address>/$issuer/g" /etc/cert-issuer/conf.ini
     ```

     ```
     bitcoin-cli dumpprivkey $issuer > /etc/cert-issuer/pk_issuer.txt
     ```

     `sed` command allows us to quickly remove or replace the content without having to open a file.

  4. Don't forget to save snapshots so you don't lose your work (see step 4 of client setup)



  1.  Add your certificate to `/etc/cert-issuer/data/unsigned_certificates/`:

      To use a sample unsigned certificate as follows:

      ```
      cp /cert-issuer/examples/data-testnet/unsigned_certificates/verifiable-credential.json /etc/cert-issuer/data/unsigned_certificates/
      ```

      If you created your own unsigned certificate using cert-tools (assuming you placed it under `data/unsigned_certificates`):

      ```
      cp <cert-issuer-home>/data/unsigned_certificates/<your-cert-guid>.json /etc/cert-issuer/data/unsigned_certificates/
      ```

  2.  Make sure you have enough BTC in your issuing address. You're using bitcoind in regtest mode, so you can print money. This should give you 50 (fake) BTC:

      ```
      bitcoin-cli -generate 101
      ```

      ```
      bitcoin-cli getbalance
      ```

  3.  **(Optional)** If you see this error:

      ```
      Fee estimation failed. Fallbackfee is disabled. Wait a few blocks or enable -fallbackfee.
      ```

      You might have to allow fallback fee in your `bitcoin.conf` (use Vim as the text editor). Add this line to `bitcoin.conf`: `fallbackfee=0.00001`

      ```
      vi /root/.bitcoin/bitcoin.conf
      ```

      You have to kill bitcoind daemon using `ps aux` and `kill <pid>` , then start it again with `bitcoind -daemon=<path to bitcoin conf file>` to apply new changes.

  4.  Send the money to your issuing address. Note that bitcoin-cli's standard denomination is bitcoins not satoshis! (In our app, the standard unit is satoshis.) This command sends 5 bitcoins to the address:

      ```
      bitcoin-cli sendtoaddress $issuer 5
      ```

  5.  Issue the certificates on the blockchain. Add `--verification_method` with issuer's DID (learn more about Decentralized Identifiers [here](https://www.w3.org/TR/did-core/) and how to work with them [here](https://github.com/blockchain-certificates/cert-issuer/#working-with-dids))

      ```
      cert-issuer -c /etc/cert-issuer/conf.ini --verification_method "<issuer's URL/DID>"
      ```

      Or, you can add `verification_method=<issuer's URL/DID>` in `/etc/cert-issuer/conf.ini`:

      ```
      vi /etc/cert-issuer/conf.ini
      ```

      Then run:

      ```
      cert-issuer -c /etc/cert-issuer/conf.ini
      ```

  6.  Your Blockchain certificates are located in `/etc/cert-issuer/data/blockchain_certificates`. Copy these to your local machine, and add them to cert-viewer's `cert_data` folder to see your certificates in the Certificate Viewer.

      ```
      docker ps  // shows the docker containerId
      docker cp <containerId>:/etc/cert-issuer/data/blockchain_certificates <localPath>/cert-viewer/cert_data
      ```



  While it is possible to issue one certificate with one Bitcoin transaction, it is far more efficient to use one Bitcoin transaction to issue a batch of certificates.

  The issuer builds a Merkle tree of certificate hashes and registers the Merkle root as the OP_RETURN field in the Bitcoin transaction.

  Suppose the batch contains `n` certificates, and certificate `i` contains recipient `i`'s information. The issuer hashes each certificate and combines them into a Merkle tree:

  ![](img/merkle.png)

  The root of the Merkle tree, which is a 256-bit hash, is issued on the Bitcoin blockchain. The complete Bitcoin transaction outputs are described in 'Transaction structure'.

  The Blockchain Certificate given to recipient `i` contains a [2019 Merkle Proof Signature Suite](https://w3c-ccg.github.io/lds-merkle-proof-2019/)-formatted proof, proving that certificate `i` is contained in the Merkle tree.

  ![](img/blockchain_certificate_components.png)

  This receipt contains:

  - The Bitcoin transaction ID storing the Merkle root
  - The expected Merkle root on the blockchain
  - The expected hash for recipient `i`'s certificate
  - The Merkle path from recipient `i`'s certificate to the Merkle root, i.e. the path highlighted in orange above. `h_i -> … -> Merkle root`

  The [verification process](https://github.com/blockchain-certificates/cert-verifier-js#verification-process) performs computations to check that:

  - The hash of certificate `i` matches the value in the receipt
  - The Merkle path is valid
  - The Merkle root stored on the blockchain matches the value in the receipt

  These steps establish that the certificate has not been tampered with since it was issued.



  The Blockchain Certificate JSON contents without the `proof` node is the certificate that the issuer created. This is the value needed to hash for comparison against the receipt. Because there are no guarantees about ordering or formatting of JSON, first canonicalize the certificate (without the `proof`) against the JSON LD schema. This allows us to obtain a deterministic hash across platforms.

  The detailed steps are described in the [verification process](https://github.com/blockchain-certificates/cert-verifier-js#verification-process).



  How a batch is defined can vary, but it should be defined such that it changes infrequently. For example, “2016 MIT grads” would be preferred over “MIT grads” (the latter would have to be updated every year). The size of the batch is limited by the 100KB maximum transaction size imposed by the Bitcoin network. This will amount to a maximum of around 2,000 recipients per certificate batch.



  One Bitcoin transaction is performed for every batch of certificates. There is no limit to the number of certificates that may be included in a batch, so typically batches are defined in logical groups such as "Graduates of Fall 2017 Robotics Class".

  ![](/img/tx_out.png)

  The transaction structure is the following:

  - Input:
    - Minimal amount of bitcoin (currently ~$.80 USD) from Issuer's Bitcoin address
  - Outputs:
    - OP_RETURN field, storing a hash of the batch of certificates
    - Optional: change to an issuer address

  The OP_RETURN output is used to prove the validity of the certificate batch. This output stores data, which is the hash of the Merkle root of the certificate batch. At any time, we can look up this value on the blockchain to help confirm a claim.

  The Issuer Bitcoin address and timestamp from the transaction are also critical for the verification process. These are used to check the authenticity of the claim, as described in [verification process](https://github.com/blockchain-certificates/cert-verifier-js#verification-process).



  The Quick Start assumed you are issuing certificates in Bitcoin regtest mode, which doesn't actually write to a public blockchain. To actually write your transaction, you need to run in testnet (with test coins -- not real money) or mainnet (real money).

  We recommend starting in testnet before mainnet.

  By default, cert-issuer does not assume you have a bitcoin/ethereum node running locally, and it uses APIs to look up and broadcast transactions. There is API support for both testnet and mainnet chains.

  If you do want to use a local bitcoin node, [see details about installing and configuring a bitcoin node for use with cert-issuer](docs/bitcoind.md) before continuing.

  These steps walk you through issuing in testnet and mainnet mode. Note that the prerequisites and the configuration for the Bitcoin issuing and the Ethereum issuing differ.



  Decide which chain (Bitcoin or Ethereum) to issue to and follow the steps. Follow the steps for the chosen chain.



  By default, cert-issuer issues to the Bitcoin blockchain. Run the default setup script if this is the mode you want:

  ```
  python setup.py install

  ```

  To issue to the ethereum blockchain, run the following:

  ```
  python setup.py experimental --blockchain=ethereum

  ```



  See the docs here for helpful tips on creating / funding blockchain addresses: [docs/testnet_mainnet_addresses](./docs/testnet_mainnet_addresses.md)



  Edit your conf.ini file (the config file for this application). See [here](./docs/ethereum_configuration.md) for more details on Ethereum configuration.
  The private key for bitcoin should be the WIF format.

  ```
  issuing_address = <issuing-address>


  verification_method = <verification-method>

  chain=<bitcoin_regtest|bitcoin_testnet|bitcoin_mainnet|ethereum_goerli|ethereum_sepolia|ethereum_ropsten|ethereum_mainnet|mockchain>

  usb_name = </Volumes/path-to-usb/>
  key_file = <file-you-saved-pk-to>

  unsigned_certificates_dir=<path-to-your-unsigned-certificates>
  blockchain_certificates_dir=<path-to-your-blockchain-certificates>
  work_dir=<path-to-your-workdir>

  no_safe_mode



  ```

  Notes:

  - The `bitcoind` option is technically not required in `regtest` mode. `regtest` mode _only_ works with a local bitcoin node. The quick start in docker brushed over this detail by installing a regtest-configured bitcoin node in the docker container.
  - The Ethereum option does not support a local (test)node currently. The issuer will broadcast the transaction via the Etherscan API or an RPC of their choice.



  To issue and verify a Blockcerts document bound to a DID you need to:

  - generate a DID document referencing the public key source of the issuing address. The verification supports all the DID methods from the [DIF universal resolver](https://uniresolver.io/), but it is recommended you provide your own resolver to the verification library.
  - it is also expected that the DID document contains a `service` property configured similarly to as follows:
    ```
      "service": [
        {
          "id": "#service-1",
          "type": "IssuerProfile",
          "serviceEndpoint": "https://www.blockcerts.org/samples/3.0/issuer-blockcerts.json"
        }
      ]
    ```
  - reference the DID through the `issuer` property of the document to be issued as Blockcerts. Either directly as a string or as the `id` property of an object:
    ```
      "issuer": "did:ion:EiA_Z6LQILbB2zj_eVrqfQ2xDm4HNqeJUw5Kj2Z7bFOOeQ",
    ```
    or
    ```
      "issuer": {
        "id": "did:ion:EiA_Z6LQILbB2zj_eVrqfQ2xDm4HNqeJUw5Kj2Z7bFOOeQ",
        ... /* more custom data here. Note that the data from the distant Issuer Profile has display preference in Blockcerts Verifier */
      }
    ```
  - finally add to your `conf.ini` file the `verification_method` property pointing to the public key matching the issuing address:
    ```
    verification_method=did:ion:EiA_Z6LQILbB2zj_eVrqfQ2xDm4HNqeJUw5Kj2Z7bFOOeQ#key-1
    ```

  You may try to see the full example DID document by looking up `did:ion:EiA_Z6LQILbB2zj_eVrqfQ2xDm4HNqeJUw5Kj2Z7bFOOeQ` in the [DIF universal resolver](https://uniresolver.io/).


  Blockcerts implements ChainedProof2021 draft proposal (https://hackmd.io/@RYgJMHAGSlaLMaQzwYjvsQ/SJoDWwTdK).
  This means that cert-issuer can be used to sign with MerkleProof2019 a document that was already signed.

  Currently, only ordered proofs are supported, which means that the next MerkleProof2019 proof hashes the content of the document
  up until the previous proof.

  Depending on the nature of the initial proof, consumers might find themselves confronted to a
  JSONLD dereferencing error when the context is not preloaded by Blockcerts ecosystem.

  Please note that this may happen with context documents that are not proof context.

  In order to circumvent this issue, this library offers a way to specify specific context to be preloaded
  before issuance.

  Consumers will need to use both `--context_urls` and `--context_file_paths` properties at the same time, and values need to be specified in matching order.

  The path to the directory where consumers store directory is left at the discretion of said consumer,
  but you should know that it will be looked up relative to the execution path (CWD).


  ```
   python -m cert_issuer -c conf.ini --context_urls https://w3id.org/security/suites/ed25519-2020/v1 https://w3id.org/security/suites/multikey-2021/v1 --context_file_paths data/context/ed25519.v1.json data/context/multikey2021.v1.json
  ```


  Define in your conf.ini file something like this:

  ```
  context_urls=[https://w3id.org/security/suites/ed25519-2020/v1, https://w3id.org/security/suites/multikey-2021/v1]
  context_file_paths=[data/context/ed25519.v1.json, data/context/multikey2021.v1.json]
  ```


  You can create local copies of context file with the following command:
  ```
  curl https://w3id.org/security/suites/ed25519-2020/v1 -L >> data/context/ed25519.v1.json
  ```



  1. Add your certificates to data/unsigned_certs/

  2. If you've installed the package you can issue certificates by running:

  ```
  python cert-issuer -c conf.ini
  ```

  3. Output

  - The Blockchain Certificates will be located in data/blockchain_certificates.
  - If you ran in the mainnet or testnet mode, you can also see your transaction on a live blockchain explorer.
    - For Bitcoin, Blockchain.com has explorers for both [testnet](https://www.blockchain.com/explorer?view=btc-testnet) and [mainnet](https://www.blockchain.com/explorer?view=btc).
    - For Ethereum, Etherscan has explorers for [goerli](https://goerli.etherscan.io/), [sepolia](https://sepolia.etherscan.io/), [ropsten](https://ropsten.etherscan.io/) and [mainnet](https://etherscan.io/)
    - The transaction id is located in the Blockchain Certificate under `signature.anchors[0].sourceId`



  More information on contributing to the cert-issuer codebase can be found in [docs/contributing.md](./docs/contributing.md)



  - [Installing and using a local bitcoin node](docs/bitcoind.md)



  The files in examples/data-testnet contain results of previous runs.





  You can validate your transaction before sending by looking it up by rawtx at blockchain.info. Example:

  ```
  curl 'https://blockchain.info/rawtx/45a9306dfe99820eb346bb17ae0b64173ac11cac2d0e4227c7a7cacbcc0bad31?cors=true'
  ```

  For an Ethereum transaction, you'll need to use a different explorer, which might require an API key for raw JSON
  output. To view a transaction in a web browser, you might try something like this:

  - Ethereum Mainnet: https://etherscan.io/tx/0xf537d81667c8011e34e1f450e18fd1c5a8a10c770cd0acdc91a79746696f36a3
  - Ethereum Goerli (testnet): https://goerli.etherscan.io/tx/0xfb593f186a274f58f861e5186150bc692ed533c7af50efb094f756ccb81c7023
  - Ethereum Sepolia (testnet): https://sepolia.etherscan.io/tx/0xa5484369839ba54cd3be71271155fc1a76b52499607dcddbf682ee04534a3f95
  - Ethereum Ropsten (testnet): https://ropsten.etherscan.io/tx/0xf537d81667c8011e34e1f450e18fd1c5a8a10c770cd0acdc91a79746696f36a3



  If your install on Mac is failing with a message like the following, try the [workaround described in this thread](https://github.com/ethereum/pyethereum/issues/292) or the [workaround described here](https://github.com/pyca/cryptography/issues/2692#issuecomment-272773481).

  ```
  fatal error: 'openssl/aes.h'
        file not found

  ```



  Contact us at [the Blockcerts community forum](http://community.blockcerts.org/).


pkgId: 7e38496c68615bfc9ab9102e32644461bc3f2f776cb3e8d443be49061debd1f5
name: python-cert-schema
arch: src
version: 3.6.4
epoch: 0
release: 1
summary: Blockchain certificates JSON-LD context and JSON schemas
url: https://github.com/blockchain-certificates/cert-schema
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cert-schema-3.6.4-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://travis-ci.org/blockchain-certificates/cert-schema.svg?branch=master)](https://travis-ci.org/blockchain-certificates/cert-schema)
  [![PyPI version](https://badge.fury.io/py/cert-schema.svg)](https://badge.fury.io/py/cert-schema)



  Blockchain Certificate schemas implement those of [Verifiable Credentials](https://www.w3.org/TR/vc-data-model/). As with Verifiable Credentials, we've provided both a JSON-LD context and JSON schema. The purpose of the JSON-LD context is to map types to Internationalized Resource Identifiers (IRIs), providing semantic context for data. The JSON Schema is used for syntactic validation.

  This python package allows verification of a Blockchain Certificate against the JSON
  schemas as a convenience. This is not the same as verifying the contents of a certificate against what is stored
  on the blockchain. See the [cert-verifier-js](https://github.com/blockchain-certificates/cert-verifier-js) project.

  *   [Blockcerts JSON Schema](docs/schema-3.0-alpha.md)



  TODO update for V3 once cert-issuer issues one

  The following is a Blockchain Certificate issued on the testnet Bitcoin network.

  ```json
  {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.blockcerts.org/schema/3.0-alpha/context.json",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "urn:uuid:bbba8553-8ec1-445f-82c9-a57251dd731c",
    "type": [
      "VerifiableCredential"
    ],
    "issuer": "did:example:23adb1f712ebc6f1c276eba4dfa",
    "issuanceDate": "2010-01-01T19:73:24Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "alumniOf": {
        "id": "did:example:c276e12ec21ebfeb1f712ebc6f1"
      }
    },
    "signature": {
      "type": "MerkleProof2019",
      "created": "2020-01-21T12:32:11.693759",
      "proofValue": "z2LuLBVSfnVzaQtvzuA7EaPQsGEgYWeaMTH1p3uqAG3ESx9HYyFzFFrYsyPkZSbn1Ji5LN76jw6HBr3oiaa8KsQenCPqKk7dJvxEXsDnYvhuDHtsrSRbzHdJKd66jAowkzPxPFi3ivyAv7WRK1WV2VhegYVQEnCBTrGJWFUMFFXunTcus7ZyedQvS4sr61X2y8QuJ57ycB5JMEHvUgAVq3qh2g3ucehg2ERKLo98jmqTcsh9HThkECG3BTNYRD3QL7AHWPjxRbQNSA83QNYXcCNA7NaZnCWyjC17ZBj3xszp76XvqFRrLjQbRSbzjVTPtBSV8QjhxThT3KTfgwjRn5JeeXhYvebsTT9YGL3W4ufzFRDpH79n5KPiaj1BPbEUfUq7vf2dg26QWeZBi7ME56",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "ecdsa-koblitz-pubkey:0x7e30a37763e6Ba1fFeDE1750bBeFB4c60b17a1B3"
    }
  }
  ```



  - [First time info](https://web.archive.org/web/20180501071551/http://peterdowns.com/posts/first-time-with-pypi.html)
  - Publish script: `./release_package.sh`




  This project uses tox to validate against several python environments.

  1. Ensure you have an python environment. [Recommendations](https://github.com/blockchain-certificates/cert-issuer/blob/master/docs/virtualenv.md)

  2. Run tests
      ```
      ./run_tests.sh
      ```




  Note that json-schema-to-markdown doesn't handle ref schemas well, so you will
  need to manually update any 'undefined' references.

  `scripts/generate_markdown.js` builds the markdown-formatted schemas from json



  Contact us at [the Blockcerts community forum](http://community.blockcerts.org/).


pkgId: 8c09e86c1b95b7a626c6edf5dc58a54ad81ed73fb5c0c77748516b1f82f51e2a
name: python-certReport
arch: src
version: 3.1.4
epoch: 0
release: 1
url: https://github.com/Squiblydoo/certReport
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certReport-3.1.4-1.src.rpm
checksum_type: sha256
summary:
  This script supports the reporting of Authenticode Certificates by reducing the effort on individuals to report.

description:
  Greetings,
   We identified a malware signed with a SSL.com EV Code Signing Intermediate CA RSA R3 certificate.
  The malware sample is available on MalwareBazaar here: https://bazaar.abuse.ch/sample/89dc50024836f9ad406504a3b7445d284e97ec5dafdd8f2741f496cac84ccda9
  Here are the signature details:
  Name: A.P.Hernandez Consulting s.r.o.
  Issuer: SSL.com EV Code Signing Intermediate CA RSA R3
  Serial Number: 2941d5f8758501f9dbc4ba158058c3b5
  SHA256 Thumbprint: a982917ba6de9588f0f7ed554223d292524e832c1621acae9ad11c0573df54a5
  Valid From: 2024-01-25T16:51:40Z
  Valid Until: 2025-01-24T16:51:40Z
  The malware was tagged as exe, Pikabot and signed.
  MalwareBazaar submitted the file to multiple public sandboxes, the links to the sandbox results are below:
  Sandbox	 / Malware Family	 /  Verdict	 / Analysis URL
  Intezer 	 None 	 unknown 	 https://analyze.intezer.com/analyses/c4915ef4-198f-4aba-81ed-81b29cd4dce6?utm_source=MalwareBazaar
  Triage 	 pikabot 	 10 / 10	 https://tria.ge/reports/240222-pqlqkshb2w/
  VMRay 	 Pikabot 	 malicious 	 https://www.vmray.com/analyses/_mb/89dc50024836/report/overview.html


pkgId: 96e30388c9b973391a3d9aa51778d38297bf97507b7928917eb0ef6d4fbdacb2
name: python-cert_manager
arch: src
version: 2.4.0
epoch: 0
release: 1
summary: Python interface to the Sectigo Certificate Manager REST API
url: https://github.com/broadinstitute/python-cert_manager.git
rpm_license: BSD-3-Clause
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cert_manager-2.4.0-1.src.rpm
checksum_type: sha256
description:
  This library provides a [Python][1] interface to the [Sectigo][2] Certificate Manager REST API.  python-cert_manager is open sourced under the [BSD 3-Clause license](LICENSE.txt).

  ![checks](https://github.com/broadinstitute/python-cert_manager/workflows/checks/badge.svg?branch=main)



  `cert_manager` runs on [Python][1] >= 3.7



  There are many API endpoints under Certificate Manager, and this library currently supports a subset of those endpoints.  The current list of written and tested endpoint classes includes:

  * Organization (/organization)
  * Person (/person)
  * SSL (/ssl)
  * Client Administrator (/admin)
  * Domain (/domain)
  * Report (/report)

  Other endpoints we hope to add in the near future:

  * Code Signing Certificates (/csod)
  * Custom Fields (/customField)
  * Domain Control Validation (/dcv)
  * Device Certificates (/device)
  * Discovery (/discovery)
  * SMIME (/smime)



  You can use pip to install cert_manager:

  ```sh
  pip install cert_manager
  ```



  This is a simple example that just shows initializing the `Client` object and using it to query the `Organization` and `SSL` endpoints:

  ```python
  from cert_manager import Organization
  from cert_manager import Client
  from cert_manager import SSL

  client = Client(
      base_url="https://cert-manager.com/api",
      login_uri="SomeOrg",
      username="your_username",
      password="your_password",
  )

  org = Organization(client=client)
  ssl = SSL(client=client)

  print(ssl.types)
  print(org.all())
  ```

  The most common process you would do, however, is enroll and then collect a certificate you want to order from the Certificate Manager:

  ```python
  from time import sleep

  from cert_manager import Organization
  from cert_manager import Client
  from cert_manager import SSL

  client = Client(
      base_url="https://cert-manager.com/api",
      login_uri="SomeOrg",
      username="your_username",
      password="your_password",
  )


  org = Organization(client=client)

  ssl = SSL(client=client)

  cert_org = org.find(dept_name="MyDept")
  with open("host.csr", "r") as filep:
      csr = filep.read()

  result = ssl.enroll(cert_type_name="InCommon SSL (SHA-2)", csr=csr, term=365, org_id=cert_org[0]["id"])



  while(True):
      
      try:
          cert_pem = ssl.collect(cert_id=result["sslId"], cert_format="x509CO")
          print(cert_pem)
          break
      except PendingError:
          print("Certificate is still pending...sleeping for 60s")
          sleep(60)
          continue
      except Exception:
          
          break
  ```



  Pull requests to add functionality and fix bugs are always welcome.  Please check the CONTRIBUTING.md for specifics on contributions.



  We try to have a high level of test coverage on the code.  Therefore, when adding anything to the repo, tests should be written to test a new feature or to test a bug fix so that there won't be a regression.  This library is setup to be pretty simple to build a working development environment using [Docker][4].  Therefore, it is suggested that you have [Docker][4] installed where you clone this repository to make development easier.

  To start a development environment, you should be able to just run the `dev.sh` script.  This script will use the `Dockerfile` in this repository to build a [Docker][4] container with all the dependencies for development installed using [Pipenv][3].

  ```sh
  ./dev.sh
  ```

  The first time you run the script, it should build the [Docker][4] image and then drop you into the container's shell.  The directory where you cloned this repository should be volume mounted in to `/usr/src`, which should also be the current working directory.  From there, you can make changes as you see fit.  Tests can be run from the `/usr/src` directory by simply typing `green` as [green][5] has been setup to with the correct parameters.



  To generate the `CHANGELOG.md`, you will need [Docker][4] and a GitHub personal access token.  We currently use [github-changelog-generator](https://github.com/github-changelog-generator/github-changelog-generator) for this purpose.  The following should generate the file using information from GitHub:

  ```sh
  docker run -it --rm \
      -e CHANGELOG_GITHUB_TOKEN='yourtokenhere' \
      -v "$(pwd)":/working \
      -w /working \
      ferrarimarco/github-changelog-generator --verbose
  ```

  To generate the log for an upcoming release that has not yet been tagged, you can run a command to include the upcoming release version.  For example, `2.0.0`:

  ```sh
  docker run -it --rm \
      -e CHANGELOG_GITHUB_TOKEN='yourtokenhere' \
      -v "$(pwd)":/working \
      -w /working \
      ferrarimarco/github-changelog-generator --verbose --future-release 2.0.0 --unreleased
  ```

  As a note, this repository uses the default labels for formatting the `CHANGELOG.md`.  Label information can be found here: [Advanced-change-log-generation-examples](https://github.com/github-changelog-generator/github-changelog-generator/wiki/Advanced-change-log-generation-examples#section-options)



  Releases to the codebase are typically done using the [bump2version][6] tool.  This tool takes care of updating the version in all necessary files, updating its own configuration, and making a GitHub commit and tag.  We typically do version bumps as part of a PR, so you don't want to have [bump2version][6] tag the version at the same time it does the commit as commit hashes may change.  Therefore, to bump the version a patch level, one would run the command:

  ```sh
  bump2version --verbose --no-tag patch
  ```

  Once the PR is merged, you can then checkout the new `main` branch and tag it using the new version number that is now in `.bumpversion.cfg`:

  ```sh
  git checkout main
  git pull --rebase
  git tag 1.0.0 -m 'Bump version: 0.1.0 → 1.0.0'
  git push --tags
  ```

  [1]: https://www.python.org/ "Python"
  [2]: https://sectigo.com/ "Sectigo"
  [3]: https://pipenv.readthedocs.io/en/latest/ "Pipenv"
  [4]: https://www.docker.com/ "Docker"
  [5]: https://github.com/CleanCut/green "green"
  [6]: https://pypi.org/project/bump2version/ "bump2version"


pkgId: caf21bfc387a069f84f6a73578a7835061023cc2e62ac282e3162e33b82953a2
name: python-certauth
arch: src
version: 1.3.0
epoch: 0
release: 1
summary: Simple Certificate Authority for MITM proxies
url: https://github.com/ikreymer/certauth
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certauth-1.3.0-1.src.rpm
checksum_type: sha256
description:
  This package provides a small library, built on top of ``pyOpenSSL``, which allows for creating a custom certificate authority certificate,
  and genereating on-demand dynamic host certs using that CA certificate.
  It is most useful for use with a man-in-the-middle HTTPS proxy, for example, for recording or replaying web content.
  Trusting the CA created by this tool should be used with caution in a controlled setting to avoid security risks.


pkgId: a81918fe29012cf6f2a9310cbc04cf018966f373e355668013ad3445f912841a
name: python-certbot
arch: src
version: 2.11.0
epoch: 0
release: 1
summary: ACME client
url: https://github.com/certbot/certbot
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-2.11.0-1.src.rpm
checksum_type: sha256
description:
  The best way to get started is to use our `interactive guide <https://certbot.eff.org>`_. It generates instructions based on your configuration settings. In most cases, you’ll need `root or administrator access <https://certbot.eff.org/faq/#does-certbot-require-root-administrator-privileges>`_ to your web server to run Certbot.
  Certbot is meant to be run directly on your web server on the command line, not on your personal computer. If you’re using a hosted service and don’t have direct access to your web server, you might not be able to use Certbot. Check with your hosting provider for documentation about uploading certificates or using certificates issued by Let’s Encrypt.


pkgId: e995129a9c914c51041d7f5286e0075273b79f8b1a95210835905e06e68ef6f8
name: python-certbot-beget-plugin
arch: src
version: 1.0.0.dev9
epoch: 0
release: 1
summary: Beget DNS plugin for Certbot
url: https://github.com/Medan-rfz/certbot-beget-plugin
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-beget-plugin-1.0.0.dev9-1.src.rpm
checksum_type: sha256
description:
  ```ini

  beget_plugin_username = username
  beget_plugin_password = password
  ```

  ```bash
  certbot certonly --authenticator beget-plugin \
      --beget-plugin-credentials ~/.secrets/certbot/beget.ini \
      -d domain.com -d *.domain.com
  ```
  ```bash
  certbot certonly --authenticator beget-plugin \
      --beget-plugin-credentials ~/.secrets/certbot/beget.ini \
      -d xxx.yyy.domain.com -d *.yyy.domain.com
  ```


pkgId: a50ab8e69fd9ba448791ea12fdc451458e5cca3212c296da3717799df89e4c57
name: python-certbot-dns-azure
arch: src
version: 2.5.0
epoch: 0
release: 1
summary: Azure DNS Authenticator plugin for Certbot
url: https://github.com/binkhq/certbot-dns-azure
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-azure-2.5.0-1.src.rpm
checksum_type: sha256
description:
  [![Tests](https://github.com/terrycain/certbot-dns-azure/workflows/Release/badge.svg)](https://github.com/terrycain/certbot-dns-azure/actions)
  [![Python Version](https://img.shields.io/pypi/pyversions/certbot-dns-azure)](https://pypi.org/project/certbot-dns-azure/)
  [![PyPi Status](https://img.shields.io/pypi/status/certbot-dns-azure)](https://pypi.org/project/certbot-dns-azure/)
  [![Version](https://img.shields.io/pypi/v/certbot-dns-azure)](https://pypi.org/project/certbot-dns-azure/)
  [![Docs](https://readthedocs.org/projects/certbot-dns-azure/badge/?version=latest&style=flat)](https://docs.certbot-dns-azure.co.uk/en/latest/)

  AzureDNS Authenticator plugin for [Certbot](https://certbot.eff.org/).

  This plugin is built from the ground up and follows the development style and life-cycle
  of other `certbot-dns-*` plugins found in the
  [Official Certbot Repository](https://github.com/certbot/certbot). PR is open [here](https://github.com/certbot/certbot/pull/8727) though Certbot is not accepting plugin PR's at the moment.






  ```
  pip3 install certbot certbot-dns-azure
  ```



  ```
  sudo snap install certbot --classic
  sudo snap install --channel=stable certbot-dns-azure
  sudo snap set certbot trust-plugin-with-root=ok
  sudo snap connect certbot:plugin certbot-dns-azure
  ```



  Verify:

  ```
  $ certbot plugins --text

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  * dns-azure
  Description: Obtain certificates using a DNS TXT record (if you are using Azure
  for DNS).
  Interfaces: IAuthenticator, IPlugin
  Entry point: dns-azure = certbot_dns_azure.dns_azure:Authenticator

  ...
  ...
  ```

  Docs and instructions on configuration are [here](https://docs.certbot-dns-azure.co.uk/en/latest/)


pkgId: f7fb947563a253f8853950d98331a06fd9a36b8a12053848a822bfd5d17bd46b
name: python-certbot-dns-bunny
arch: src
version: 3.0.0
epoch: 0
release: 1
summary: Bunny.net DNS Authenticator plugin for Certbot
url: https://github.com/mwt/certbot-dns-bunny
rpm_license: BSD-2-Clause
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-bunny-3.0.0-1.src.rpm
checksum_type: sha256
description:
  This plugin enables DNS verification with certbot when using `Bunny.net`_ DNS. Full documentation is on `Read the Docs`_.


pkgId: 2a973875346f70bd4b65e6e7665a34436bba5672b2c61c891449b944e703a4ed
name: python-certbot-dns-constellix
arch: src
version: 0.3.0
epoch: 0
release: 1
summary: Constellix DNS Authenticator plugin for Certbot
url: https://github.com/digicert/dnstrust-constellix-certbot
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-constellix-0.3.0-1.src.rpm
checksum_type: sha256
description:
  The `certbot-dns-constellix` plugin is used to automate the process of a `dns-01` challenge in Certbot to allow the requesting and renewal of SSL certificates through the Constellix DNS API.

  This is done through the process of adding and removing TXT records to the appropriate domain in your Constellix DNS account.

  There are two different methods of installing, configuring and using the plugin depending on if you're using certbot installed through snapd or through your operating system's package manager.



  If you installed certbot using snapd, do the following to install and configure the plugin:



  Run the following commands to install the plugin with snapd.

  ```
  sudo snap install certbot-dns-constellix
  sudo snap set certbot trust-plugin-with-root=ok
  sudo snap connect certbot:plugin certbot-dns-constellix
  ```

  Verify that the plugin is installed by running `certbot plugins`. You should see the `dns-constellix` plugin in the list.



  The plugin requires an API key and secret key for the Constellix DNS API. The key will need to have permissions to add and remove records on the domain you want to issue certificates for.

  These will need to be added to a file, eg. `constellix.ini` in the following format:

  ```
  dns_constellix_apikey=5fb4e76f-ac91-43e5-f982458bc595
  dns_constellix_secretkey=47d99fd0-32e7-4e07-85b46d08e70b
  dns_constellix_endpoint=https://api.dns.constellix.com/v1
  ```



  You should secure this file from any unauthorised access. Anyone with access to these credentials and this file will be able to add and remove records from your domain. You should configure the file to not be readable by any other users on the system



  Once the plugin is installed and configured it can be used by specifying the plugin in the `certbot` command and the location of the credentials file.

  ```
  certbot certonly \
      --authenticator=dns-constellix \
      --dns-constellix-credentials=~./constellix.ini \
      -d example.com
  ```

  For more options please check the certbot documentation.



  If you installed certbot using your operating system's package manager (apt, yum, etc.) or directly with Python, you can install it using these instructions.



  Run the following commands to install the plugin using pip.

  ```
  sudo python3 -m pip install certbot-dns-constellix
  ```

  Verify that the plugin is installed by running `certbot plugins`. You should see the `dns-constellix` plugin in the list.



  The plugin requires an API key and secret key for the Constellix DNS API. The key will need to have permissions to add and remove records on the domain you want to issue certificates for.

  These will need to be added to a file, eg. `constellix.ini` in the following format:

  ```
  certbot-dns-constellix:dns_constellix_apikey=5fb4e76f-ac91-43e5-f982458bc595
  certbot-dns-constellix:dns_constellix_secretkey=47d99fd0-32e7-4e07-85b46d08e70b
  certbot-dns-constellix:dns_constellix_endpoint=https://api.dns.constellix.com/v1
  ```

  The extra `certbot-dns-constellix:` is required due to how older versions of Certbot load plugins.



  You should secure this file from any unauthorised access. Anyone with access to these credentials and this file will be able to add and remove records from your domain. You should configure the file to not be readable by any other users on the system



  Once the plugin is installed and configured it can be used by specifying the plugin in the `certbot` command and the location of the credentials file.

  ```
  certbot certonly \
      --authenticator=certbot-dns-constellix:dns-constellix \
      --certbot-dns-constellix:dns-constellix-credentials=~./constellix.ini \
      -d example.com
  ```

  The extra `certbot-dns-constellix:` is required due to how older versions of Certbot load plugins.

  For more options please check the certbot documentation.



  Copyright 2020 Constellix, a division of Tiggee LLC.

  Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.

  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  See the License for the specific language governing permissions and limitations under the License.


pkgId: a0fc0076bf8162e94aa2622d6ea6cb2f4c95a4146090ff5e45127735f02db9cf
name: python-certbot-dns-cpanel
arch: src
version: 0.4.0
epoch: 0
release: 1
summary: certbot plugin to allow acme dns-01 authentication & installation of a name managed in cPanel.
url: https://github.com/badjware/certbot-dns-cpanel
rpm_license: Apache Licence 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-cpanel-0.4.0-1.src.rpm
checksum_type: sha256
description:
  Plugin to allow acme dns-01 authentication of a name managed in cPanel. Useful for automating and creating a Let's Encrypt certificate (wildcard or not) for a service with a name managed by cPanel, but installed on a server not managed in cPanel.


  | Argument | Description |
  | --- | --- |
  | --certbot-dns-cpanel:cpanel-credentials &lt;file&gt; | cPanel credentials INI file **(required)** |
  | --certbot-dns-cpanel:cpanel-propagation-seconds &lt;seconds&gt; | The number of seconds to wait for DNS to propagate before asking the ACME server to verify the DNS record (Default: 30) |


  ``` bash
  pip install certbot-dns-cpanel
  ```


  Download the file `credentials.ini.example` and rename it to `credentials.ini`. Edit it to set your cPanel url, username and password.
  ```


  certbot_dns_cpanel:cpanel_url = https://cpanel.example.com:2083


  certbot_dns_cpanel:cpanel_username = user


  certbot_dns_cpanel:cpanel_password = hunter2
  ```


  You can now run certbot using the plugin and feeding the credentials file.
  For example, to get a wildcard certificate for *.example.com and example.com:
  ``` bash
  certbot certonly \
  --authenticator certbot-dns-cpanel:cpanel \
  --certbot-dns-cpanel:cpanel-credentials /path/to/credentials.ini \
  -d 'example.com' \
  -d '*.example.com'
  ```

  You can also specify a installer plugin with the `--installer` option:

  ``` bash
  certbot run \
  --authenticator certbot-dns-cpanel:cpanel \
  --installer apache \
  --certbot-dns-cpanel:cpanel-credentials /path/to/credentials.ini \
  -d 'example.com' \
  -d '*.example.com'
  ```

  You may also install the certificate onto a domain on your cPanel account:

  ```bash
  certbot run \
  --authenticator certbot-dns-cpanel:cpanel \
  --installer certbot-dns-cpanel:cpanel \
  --certbot-dns-cpanel:cpanel-credentials /path/to/credentials.ini \
  -d 'example.com' \
  -d '*.example.com'
  ```

  Depending on your provider you may need to use the `--certbot-dns-cpanel:cpanel-propagation-seconds` option to extend
  the DNS propagation time.


  A docker image [badjware/certbot-dns-cpanel](https://hub.docker.com/r/badjware/certbot-dns-cpanel), based on [certbot/certbot](https://hub.docker.com/r/certbot/certbot) is provided for your convenience:
  ``` bash
  docker run -it \
  -v /path/to/credentials.ini:/tmp/credentials.ini \
  badjware/certbot-dns-cpanel \
  certonly \
  --authenticator certbot-dns-cpanel:cpanel \
  --certbot-dns-cpanel:cpanel-credentials /tmp/credentials.ini \
  -d 'example.com' \
  -d '*.example.com'
  ```


  * https://documentation.cpanel.net/display/DD/Guide+to+cPanel+API+2
  * https://certbot.eff.org/docs/


pkgId: 86f94166b678a2df3589e86486d434fbf1505e56913c7d7f4dad771c1b96e2aa
name: python-certbot-dns-desec
arch: src
version: 1.2.1
epoch: 0
release: 1
summary: deSEC DNS Authenticator plugin for Certbot
url: https://github.com/desec-io/certbot-dns-desec
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-desec-1.2.1-1.src.rpm
checksum_type: sha256
description:
  ![main branch CI test status](https://github.com/desec-io/certbot-dns-desec/workflows/Tests/badge.svg?branch=main)
  [![pypi badge](https://img.shields.io/pypi/v/certbot-dns-desec.svg)](https://pypi.org/project/certbot-dns-desec/)

  Certbot plugin to obtain TLS certificates from Let's Encrypt for domains hosted with deSEC.io, using the DNS challenge
  challenge mechanism.




  To get certificates from Let's Encrypt, install certbot and this plugin.
  There are many ways to install certbot, this guide uses Python's `pip`:

  ```shell
  python3 -m pip install certbot certbot-dns-desec
  ```



  To get a Let's Encrypt certificate for your domain `$DOMAIN`,
  you need a deSEC API token `$TOKEN` with sufficient permission for performing the required DNS changes on your domain.
  Also make sure that your domain name has been delegated to deSEC
  (in other words: make sure that the parent registry has the right NS records).

  If you don't have a token yet, an easy way to obtain one is by logging into your account at
  [deSEC.io](https://desec.io).
  Navigate to "Token Management" and create a new one.
  It's good practice to restrict the token permissions as much as possible,
  e.g. by setting the maximum unused period to four months.
  This way, the token will expire if it is not continuously used to renew your certificate.
  Tokens can also be created
  [using the deSEC API](https://desec.readthedocs.io/en/latest/auth/tokens.html#creating-a-token).



  To issue and renew certificates using `certbot-dns-desec`, an access token to your deSEC account is required.
  To store such a token in a secure location, use, e.g.:

  ```shell
  DOMAIN=example.com
  TOKEN=your-desec-access-token
  sudo mkdir -p /etc/letsencrypt/secrets/
  sudo chmod 700 /etc/letsencrypt/secrets/
  echo "dns_desec_token = $TOKEN" | sudo tee /etc/letsencrypt/secrets/$DOMAIN.ini
  sudo chmod 600 /etc/letsencrypt/secrets/$DOMAIN.ini
  ```

  Adjust `$DOMAIN` and `$TOKEN` according to your domain and deSEC access token, respectively.
  The file location is just a suggestion and can be changed.

  With the credentials stored, you can request a wildcard certificate for your domain by using, e.g.,

  ```shell
  certbot certonly \
       --authenticator dns-desec \
       --dns-desec-credentials /etc/letsencrypt/secrets/$DOMAIN.ini \
       -d "$DOMAIN" \
       -d "*.$DOMAIN"
  ```

  In this command, `--authenticator dns-desec` activates the `certbot-dns-desec` plugin;
  the `--dns-desec-credentials` argument provides the deSEC access token location to the plugin.
  These flags can be combined with more sophisticated usages of certbot,
  e.g. to automatically reload servers after the renewal process.
  Such functionality is independent of this plugin; for details, see the certbot documentation.




  This plugin is activated by passing the ``--authenticator dns-desec`` argument to certbot.
  It accepts the following command line arguments:

  1. ``--dns-desec-credentials <file>`` Specifies the file holding the deSEC API credentials (required, see below).
  1. ``--dns-desec-propagation-seconds`` Waiting time for DNS to propagate before asking the ACME server to verify the
      DNS record.




  An example ``credentials.ini`` file:

      dns_desec_token = token

  Additionally, the URL of the deSEC API can be specified using the `dns_desec_endpoint` configuration option.
  `https://desec.io/api/v1/` is the default.



  To test certbot-dns-desec, create a virtual environment at `venv/` for this repository and activate it.
  Register a domain `$DOMAIN` with desec.io, and obtain a DNS management token `$TOKEN`. Then run

  ```shell
  python3 -m pip install .
  TOKEN=token-you-obtained-from-desec-io
  DOMAIN=domain-you-registered-at-desec-io
  EMAIL=youremail@example.com
  echo "dns_desec_token = $TOKEN" > desec-secret.ini
  chmod 600 desec-secret.ini
  ./venv/bin/certbot \
      --config-dir tmp/certbot/config \
      --logs-dir tmp/certbot/logs \
      --work-dir tmp/certbot/work \
      --test-cert \
      -d $DOMAIN -d "*.$DOMAIN" \
      --authenticator dns-desec \
      --dns-desec-credentials desec-secret.ini \
      --non-interactive --agree-tos \
      --email $EMAIL \
      certonly
  ```




  1. Make sure tests are okay (see GitHub actions)
  1. Commit all changes
  1. Clean up `dist/` folder
  1. Set up new release version: `RELEASE=x.y.z`
  1. Update version to `x.y.z` in `setup.py`
  1. Commit with message "Release Version vx.y.z": `git commit -p -m "Release Version v$RELEASE"`
  1. Tag commit using `git tag -as v$RELEASE -m "Release Version v$RELEASE"`
  1. Push
      1. branch: `git push`
      1. tag: `git push origin v$RELEASE`
  1. Set environment variables `GITHUB_TOKEN` to a GitHub token, `TWINE_USERNAME` and `TWINE_PASSWORD` to PyPi
      credentials.
  1. Publish using `python3 -m publish desec-io certbot-dns-desec`


pkgId: 43afc9472152c21d2423a06d7bc8620dd7b333cb346ea6478992e28a8be7008b
name: python-certbot-dns-directadmin
arch: src
version: 1.0.10
epoch: 0
release: 1
summary: Certbot plugin. Allows completing DNS01 challenge against a DirectAdmin Server
url: https://pypi.org/project/certbot-dns-directadmin/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-directadmin-1.0.10-1.src.rpm
checksum_type: sha256
description:
  ![Upload Python Package](https://github.com/cybercinch/certbot-dns-directadmin/workflows/Upload%20Python%20Package/badge.svg) [![PyPI version](https://badge.fury.io/py/certbot-dns-directadmin.svg)](https://badge.fury.io/py/certbot-dns-directadmin) [![Documentation Status](https://readthedocs.org/projects/certbot-dns-directadmin/badge/?version=latest)](https://certbot-dns-directadmin.readthedocs.io/en/latest/?badge=latest) ![PyPI - Downloads](https://img.shields.io/pypi/dw/certbot-dns-directadmin)
  ![Code Coverage](https://raw.githubusercontent.com/cybercinch/certbot-dns-directadmin/master/coverage.svg)


  Plugin to allow acme dns-01 authentication of a name managed in DirectAdmin. Useful for automating and creating a Let's Encrypt certificate (wildcard or not) for a service with a name managed by DirectAdmin, but installed on a server not managed in DirectAdmin.



  You may find the module documentation on [Read The Docs](https://certbot-dns-directadmin.readthedocs.io/ "certbot-dns-directadmin's Documentation")


pkgId: c4aa8cfc6493bf178d6b9445f0becaa35900ffd0408d86a11b093dfef1ff58bd
name: python-certbot-dns-dynu-dev
arch: src
version: 0.0.6
epoch: 0
release: 1
summary: Dynu DNS Authenticator plugin for Certbot
url: https://github.com/BigThunderSR/certbot-dns-dynu-dev
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-dynu-dev-0.0.6-1.src.rpm
checksum_type: sha256
description:
  Dynu DNS Authenticator plugin for [Certbot](https://certbot.eff.org/).
  This plugin is built from the ground up and follows the development style and life-cycle
  of other `certbot-dns-*` plugins found in the
  [Official Certbot Repository](https://github.com/certbot/certbot).
  This fork was created since <https://github.com/bikram990/certbot-dns-dynu/pull/7> is not being merged in the upstream project by the original author.
  This fork is also being used in the Home Assistant Let's Encrypt add-on via https://github.com/home-assistant/addons/pull/3556


pkgId: c3c68942bbea44f30af1385363a604bf96e0073d697fcb6db85970f6388c7227
name: python-certbot-dns-eurodns
arch: src
version: 1.8.1
epoch: 0
release: 1
summary: EuroDNS DNS Authenticator plugin for Certbot
url: https://github.com/EuroDNS/certbot-dns-eurodns
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-eurodns-1.8.1-1.src.rpm
checksum_type: sha256
description:
  EuroDNS_ DNS Authenticator plugin for certbot_.
  This plugin automates the process of completing a ``dns-01`` challenge by
  creating, and subsequently removing, TXT records using the `EuroDNS API`_.


pkgId: ba901a3767744ffdfe0f61956d52569ae2da900500f2ad25227c2216bbf3b730
name: python-certbot-dns-godaddy
arch: src
version: 2.8.0
epoch: 0
release: 1
summary: A certbot plugin that implements letsencrypt dns wildcard support for godaddy using lexicon
url: https://github.com/miigotu/certbot-dns-godaddy
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-godaddy-2.8.0-1.src.rpm
checksum_type: sha256
description:
  [![Version](https://img.shields.io/pypi/v/certbot-dns-godaddy.svg)](https://pypi.python.org/pypi/certbot-dns-godaddy) [![License: Apache](https://img.shields.io/pypi/l/certbot-dns-godaddy.svg)](https://github.com/miigotu/certbot-dns-godaddy/blob/master/LICENSE.txt) [![Docker image size](https://img.shields.io/docker/image-size/miigotu/certbot-dns-godaddy)](https://hub.docker.com/repository/docker/miigotu/certbot-dns-godaddy)
  [godaddy](https://www.godaddy.com/) DNS Authenticator plugin for [certbot](https://certbot.eff.org/).
  This plugin automates the process of completing a `dns-01` challenge by creating, and subsequently removing, `TXT` records using the godaddy [API](https://developer.godaddy.com/doc/endpoint/domains) via [lexicon](https://github.com/AnalogJ/lexicon).
  **Note:** This manual assumes certbot >=2.7.4 which has improved the naming scheme for external plugins.


pkgId: 53af650aeecf7454688cf386285535aa05e6a04233857e6dff61c2e044eacd6e
name: python-certbot-dns-hetzner
arch: src
version: 2.0.1
epoch: 0
release: 1
summary: Hetzner DNS Authenticator plugin for Certbot
url: https://github.com/ctrlaltcoop/certbot-dns-hetzner
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-hetzner-2.0.1-1.src.rpm
checksum_type: sha256
description:
  [![codecov](https://codecov.io/gh/ctrlaltcoop/certbot-dns-hetzner/branch/main/graph/badge.svg?token=3XJVTPZ0AM)](https://codecov.io/gh/ctrlaltcoop/certbot-dns-hetzner)
  ![Tests, Coverage](https://github.com/ctrlaltcoop/certbot-dns-hetzner/workflows/Tests,%20Coverage/badge.svg?branch=main)
  [![PyPI version](https://badge.fury.io/py/certbot-dns-hetzner.svg)](https://badge.fury.io/py/certbot-dns-hetzner)
  ![Supported Python](https://img.shields.io/pypi/pyversions/certbot-dns-hetzner)

  This certbot plugin automates the process of
  completing a dns-01 challenge by creating, and
  subsequently removing, TXT records using the Hetzner DNS API.





  Notice that this plugin is only supporting certbot>=2.0 from 2.0 onwards. For older certbot versions use 1.x releases.



  Install this package via pip in the same python environment where you installed your certbot.

  ```
  pip install certbot-dns-hetzner
  ```



  To start using DNS authentication for the Hetzner DNS API, pass the following arguments on certbot's command line:

  | Option                                                     | Description                                      |
  |------------------------------------------------------------|--------------------------------------------------|
  | `--authenticator dns-hetzner`                              | select the authenticator plugin (Required)       |
  | `--dns-hetzner-credentials`                                | Hetzner DNS API credentials INI file. (Required) |
  | `--dns-hetzner-propagation-seconds`                        | Seconds to wait for the TXT record to propagate  |




  From the hetzner DNS control panel at https://dns.hetzner.com go to "API Tokens" and add a personal access token.

  An example ``credentials.ini`` file:

  ```ini
  dns_hetzner_api_token = nohnah4zoo9Kiejee9aGh0thoopee2sa
  ```

  To acquire a certificate for `example.com`
  ```shell script
  certbot certonly \\
   --authenticator dns-hetzner \\
   --dns-hetzner-credentials /path/to/my/hetzner.ini \\
   -d example.com
  ```

  To acquire a certificate for ``*.example.com``
  ```shell script
     certbot certonly \\
       --authenticator dns-hetzner \\
       --dns-hetzner-credentials /path/to/my/hetzner.ini \\
       -d '*.example.com'
  ```



  If `certbot plugins` does not show the installed plugin, you might need to set `CERTBOT_PLUGIN_PATH`.
  ```
  CERTBOT_PLUGIN_PATH=/usr/local/lib/python3.9/site-packages/ certbot renew
  ```
  [See letsencrypt community thread](https://community.letsencrypt.org/t/how-do-i-make-certbot-find-use-an-installed-plugin/198647/5)



  Of course certbot, which examples and documentation I used to implement this plugin. And to https://github.com/m42e/certbot-dns-ispconfig which served as an excellent example and README template as well.


pkgId: 487823b2a0f61c3dcfbd06cca5b9ae56e1458bd7f94bd8c3add5d963f04aa549
name: python-certbot-dns-hostingnl
arch: src
version: 0.1.3
epoch: 0
release: 1
summary: please add a summary manually as the author left a blank one
url: https://pypi.org/project/certbot-dns-hostingnl/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-hostingnl-0.1.3-1.src.rpm
checksum_type: sha256
description:
  Hosting.nl DNS Authenticator Plugin

  Get your API token from [mijn.hosting.nl](https://mijn.hosting.nl/index.php?m=APIKeyGenerator).


pkgId: 7cce06878be6677ae6a5592697cd8cfb19dbb6886404229b04636f27c0378249
name: python-certbot-dns-infomaniak
arch: src
version: 0.2.3
epoch: 0
release: 1
summary: Infomaniak DNS Authenticator plugin for Certbot
url: https://github.com/infomaniak/certbot-dns-infomaniak
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-infomaniak-0.2.3-1.src.rpm
checksum_type: sha256
description:
  Infomaniak_ DNS Authenticator plugin for certbot_
  This plugin enables usage of Infomaniak public API to complete ``dns-01`` challenges.


pkgId: 0fdeb3d30d9d42f8c37c304074e1fe11b2fe0e82528ecae0c66d46d512ff3bf2
name: python-certbot-dns-ionos
arch: src
version: 2024.10.20
epoch: 0
release: 1
summary: IONOS DNS Authenticator plugin for Certbot
url: https://github.com/helgeerbe/certbot-dns-ionos
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-ionos-2024.10.20-1.src.rpm
checksum_type: sha256
description:
  [IONOS](https://www.ionos.de/) DNS Authenticator plugin for [Certbot](https://certbot.eff.org/)

  ![Ionos](https://www.ionos.co.uk/newsroom/wp-content/uploads/sites/7/2021/12/LOGO_IONOS_Blue_RGB-1.png)

  This plugin automates the process of completing a ``dns-01`` challenge by
  creating, and subsequently removing, TXT records using the [IONOS Remote API](https://developer.hosting.ionos.com/docs/dns).



  In the `System -> Remote Users` you have to have a user, with the following rights

  - Client Functions
  - DNS zone functions
  - DNS txt functions





  [![Get it from the Snap Store](https://snapcraft.io/static/images/badges/en/snap-store-black.svg)](https://snapcraft.io/certbot-dns-ionos)
  Snap version will be compatible with certbot 3.0. Thanks to [DorianCoding](https://github.com/DorianCoding) to make this plugin avalabe in the Snap Store.



  `pip install certbot-dns-ionos`



  To start using DNS authentication for ionos, pass the following arguments on certbot's command line:

  | Command args | Command definition |
  | --- | --- |
  |``--authenticator dns-ionos`` | select the authenticator plugin (Required) |
  |``--dns-ionos-credentials`` |ionos Remote User credentials INI file. (Required) |
  |``--dns-ionos-propagation-seconds``|waiting time for DNS to propagate before asking the ACME server to verify the DNS record. (Default: 10, Recommended: 60) |



  An example ``credentials.ini`` file:

  ```ini
  dns_ionos_prefix = myapikeyprefix
  dns_ionos_secret = verysecureapikeysecret
  dns_ionos_endpoint = https://api.hosting.ionos.com
  ```

  The key can be managed under the following link:  <https://developer.hosting.ionos.de/?source=IonosControlPanel>

  The path to this file can be provided interactively or using the
  `--dns-ionos-credentials` command-line argument. Certbot
  records the path to this file for use during renewal, but does not store the file's contents.

  > [!CAUTION]
  > You should protect these API credentials as you would the
  password to your ionos account. Users who can read this file can use these credentials to issue arbitrary API calls
  on your behalf. Users who can cause Certbot to run using these credentials can complete a ``dns-01`` challenge
  to acquire new certificates or revoke existing certificates for associated domains, even if those domains aren't
  being managed by this server.

  > [!WARNING]
  > Certbot will emit a warning if it detects that the credentials file can be accessed by other users on your system.
  The warning reads "Unsafe permissions on credentials configuration file", followed by the path to the
  credentials file. This warning will be emitted each time Certbot uses the credentials file, including for renewal,
  and cannot be silenced except by addressing the issue (e.g., by using a command like ``chmod 600`` to
  restrict access to the file and ``chmod 700`` to restrict access to the folder).



  To acquire a single certificate for both ``example.com`` and
  ``*.example.com``, waiting 900 seconds for DNS propagation:

  ```bash
  certbot certonly \
  --authenticator dns-ionos \
  --dns-ionos-credentials /etc/letsencrypt/.secrets/domain.tld.ini \
  --dns-ionos-propagation-seconds 900 \
  --server https://acme-v02.api.letsencrypt.org/directory \
  --agree-tos \
  --rsa-key-size 4096 \
  -d 'example.com' \
  -d '*.example.com'
  ```



  In order to create a docker container with a certbot-dns-ionos installation,
  create an empty directory with the following ``Dockerfile``:

  ```docker
  FROM certbot/certbot
  RUN pip install certbot-dns-ionos
  ```

  Proceed to build the image

  ```docker
  docker build -t certbot/dns-ionos .
  ```

  Once that's finished, the application can be run as follows::

  ```docker
  docker run --rm \
  -v /var/lib/letsencrypt:/var/lib/letsencrypt \
  -v /etc/letsencrypt:/etc/letsencrypt \
  --cap-drop=all \
  certbot/dns-ionos certonly \
  --authenticator dns-ionos \
  --dns-ionos-propagation-seconds 900 \
  --dns-ionos-credentials \
  /etc/letsencrypt/.secrets/domain.tld.ini \
  --no-self-upgrade \
  --keep-until-expiring --non-interactive --expand \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com -d '*.example.com'
  ```

  It is suggested to secure the folder as follows

  ```bash
  chown root:root /etc/letsencrypt/.secrets
  chmod 700 /etc/letsencrypt/.secrets
  ```

  The file 'domain.tld.ini' must be replaced with the version of the example 'credentials.ini' adapted to your provider.



  - 2024.10.19
    - Update for Certbot 2.11.0
    - Update README.md, changed from README.rst
    - Addition of a snap
    - Correction in case of API error
  - 2024.01.08
    - Update README.rst
    - Add Link to IONOS control panel and reference between credentials.ini and domain.tld.ini
  - 2023.11.13
    - Fix managed zone lookup to ensure correct domain is selected where there are two domains with the same ending e.g. example.com and thisisanexample.com (PR #22)
  - 2022.11.24
    - Remove zope to fix compatibility with Certbot 2.x (Fixes #19)
    - As a reminder, Certbot will default to issuing ECDSA certificates from release 2.0.0.
    - If you update from a prior certbot release, run the plugin once manually. You will be prompted to update RSA key type to ECDSA.
  - 2022.05.15
    - Added capability to handle multiple domain validations #16
  - 2021.09.20.post1
    - Fix version number
  - 2021.09.20
    - Fix #9 Domain not known when using subdomain



  It's important to note that this plugin targets [IONOS Developer DNS API](https://developer.hosting.ionos.com/docs/dns>).
  If you are using IONOS [Cloud DNS service](https://cloud.ionos.com/network/cloud-dns>),
  there is a different plugin provided by IONOS: <https://github.com/ionos-cloud/certbot-dns-ionos-cloud>


pkgId: d203f4f37541c27c9408abed06fc97bbc5d97ef3ca5acd5e5f1d30c4b63e11df
name: python-certbot-dns-ionos
arch: src
version: 2024.11.9
epoch: 0
release: 1
summary: IONOS DNS Authenticator plugin for Certbot
url: https://github.com/helgeerbe/certbot-dns-ionos
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-ionos-2024.11.9-1.src.rpm
checksum_type: sha256
description:
  [IONOS](https://www.ionos.de/) DNS Authenticator plugin for [Certbot](https://certbot.eff.org/)

  ![Ionos](https://www.ionos.co.uk/newsroom/wp-content/uploads/sites/7/2021/12/LOGO_IONOS_Blue_RGB-1.png)

  This plugin automates the process of completing a ``dns-01`` challenge by
  creating, and subsequently removing, TXT records using the [IONOS Remote API](https://developer.hosting.ionos.com/docs/dns).



  In the `System -> Remote Users` you have to have a user, with the following rights

  - Client Functions
  - DNS zone functions
  - DNS txt functions





  [![Get it from the Snap Store](https://snapcraft.io/static/images/badges/en/snap-store-black.svg)](https://snapcraft.io/certbot-dns-ionos)
  Snap version will be compatible with certbot 3.0. Thanks to [DorianCoding](https://github.com/DorianCoding) to make this plugin avalabe in the Snap Store.



  `pip install certbot-dns-ionos`



  To start using DNS authentication for ionos, pass the following arguments on certbot's command line:

  | Command args | Command definition |
  | --- | --- |
  |``--authenticator dns-ionos`` | select the authenticator plugin (Required) |
  |``--dns-ionos-credentials`` |ionos Remote User credentials INI file. (Required) |
  |``--dns-ionos-propagation-seconds``|waiting time for DNS to propagate before asking the ACME server to verify the DNS record. (Default: 10, Recommended: 60) |



  An example ``credentials.ini`` file:

  ```ini
  dns_ionos_prefix = myapikeyprefix
  dns_ionos_secret = verysecureapikeysecret
  dns_ionos_endpoint = https://api.hosting.ionos.com
  ```

  The key can be managed under the following link:  <https://developer.hosting.ionos.de/?source=IonosControlPanel>

  The path to this file can be provided interactively or using the
  `--dns-ionos-credentials` command-line argument. Certbot
  records the path to this file for use during renewal, but does not store the file's contents.

  > [!CAUTION]
  > You should protect these API credentials as you would the
  password to your ionos account. Users who can read this file can use these credentials to issue arbitrary API calls
  on your behalf. Users who can cause Certbot to run using these credentials can complete a ``dns-01`` challenge
  to acquire new certificates or revoke existing certificates for associated domains, even if those domains aren't
  being managed by this server.

  > [!WARNING]
  > Certbot will emit a warning if it detects that the credentials file can be accessed by other users on your system.
  The warning reads "Unsafe permissions on credentials configuration file", followed by the path to the
  credentials file. This warning will be emitted each time Certbot uses the credentials file, including for renewal,
  and cannot be silenced except by addressing the issue (e.g., by using a command like ``chmod 600`` to
  restrict access to the file and ``chmod 700`` to restrict access to the folder).



  To acquire a single certificate for both ``example.com`` and
  ``*.example.com``, waiting 900 seconds for DNS propagation:

  ```bash
  certbot certonly \
  --authenticator dns-ionos \
  --dns-ionos-credentials /etc/letsencrypt/.secrets/domain.tld.ini \
  --dns-ionos-propagation-seconds 900 \
  --server https://acme-v02.api.letsencrypt.org/directory \
  --agree-tos \
  --rsa-key-size 4096 \
  -d 'example.com' \
  -d '*.example.com'
  ```



  In order to create a docker container with a certbot-dns-ionos installation,
  create an empty directory with the following ``Dockerfile``:

  ```docker
  FROM certbot/certbot
  RUN pip install certbot-dns-ionos
  ```

  Proceed to build the image

  ```docker
  docker build -t certbot/dns-ionos .
  ```

  Once that's finished, the application can be run as follows::

  ```docker
  docker run --rm \
  -v /var/lib/letsencrypt:/var/lib/letsencrypt \
  -v /etc/letsencrypt:/etc/letsencrypt \
  --cap-drop=all \
  certbot/dns-ionos certonly \
  --authenticator dns-ionos \
  --dns-ionos-propagation-seconds 900 \
  --dns-ionos-credentials \
  /etc/letsencrypt/.secrets/domain.tld.ini \
  --no-self-upgrade \
  --keep-until-expiring --non-interactive --expand \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com -d '*.example.com'
  ```

  It is suggested to secure the folder as follows

  ```bash
  chown root:root /etc/letsencrypt/.secrets
  chmod 700 /etc/letsencrypt/.secrets
  ```

  The file 'domain.tld.ini' must be replaced with the version of the example 'credentials.ini' adapted to your provider.



  - 2024.11.09
    - Update for Certbot 3.0.0
  - 2024.10.20
    - fix: set long_description_content_type to text/markdown.
      This error breaks the upload to pypi
  - 2024.10.19
    - Update for Certbot 2.11.0
    - Update README.md, changed from README.rst
    - Addition of a snap
    - Correction in case of API error
  - 2024.01.08
    - Update README.rst
    - Add Link to IONOS control panel and reference between credentials.ini and domain.tld.ini
  - 2023.11.13
    - Fix managed zone lookup to ensure correct domain is selected where there are two domains with the same ending e.g. example.com and thisisanexample.com (PR #22)
  - 2022.11.24
    - Remove zope to fix compatibility with Certbot 2.x (Fixes #19)
    - As a reminder, Certbot will default to issuing ECDSA certificates from release 2.0.0.
    - If you update from a prior certbot release, run the plugin once manually. You will be prompted to update RSA key type to ECDSA.
  - 2022.05.15
    - Added capability to handle multiple domain validations #16
  - 2021.09.20.post1
    - Fix version number
  - 2021.09.20
    - Fix #9 Domain not known when using subdomain



  It's important to note that this plugin targets [IONOS Developer DNS API](https://developer.hosting.ionos.com/docs/dns>).
  If you are using IONOS [Cloud DNS service](https://cloud.ionos.com/network/cloud-dns>),
  there is a different plugin provided by IONOS: <https://github.com/ionos-cloud/certbot-dns-ionos-cloud>


pkgId: e02a044363f0e87b61494e8d51f7468d5c755763a77dc2cbeb9cdac18903fb14
name: python-certbot-dns-mijn-host
arch: src
version: 0.0.5
epoch: 0
release: 1
url: https://pypi.org/project/certbot-dns-mijn-host/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-mijn-host-0.0.5-1.src.rpm
checksum_type: sha256
summary:
  Certbot DNS plugin for mijn.host service, enabling the automation of DNS-01 challenges for issuing wildcard SSL certificates. This plugin simplifies the process of obtaining and renewing SSL certificates by integrating directly with the DNS API of mijn.host Service, making it ideal for system administrators and DevOps professionals managing secure web services.

description:
  <a href="https://mijn.host" target="_blank">
      <center>
          <img src="https://assets.eu.apidog.com/app/apidoc-image/custom/20240626/f1508b02-a360-4b89-b7a9-b939a9180c0e.png"
          alt="mijn.host"
          />
      </center>
  </a>



  The [mijn.host](https://mijn.host) DNS Certbot Plugin automates SSL/TLS certificate creation by enabling DNS-01 challenges using the mijn.host API. This plugin is designed to work with the Certbot tool, allowing seamless integration for automated certificate management.



  To use the plugin, you'll need the following:

  - A mijn.host account
  - An API key from mijn.host



  You can install the plugin using `pip`:

  ```bash
  pip install certbot-dns-mijn-host
  ```



  | Argument                            | Example           | Description                                                                                     |
  | ----------------------------------- | ----------------- | ----------------------------------------------------------------------------------------------- |
  | --authenticator                     | dns-mijn-host     | Specifies that Certbot should use this plugin. Use dns-mijnhost as the value.                   |
  | --dns-mijn-host-credentials         | ./credentials.ini | Points to the credentials file containing your mijn.host API key. Required.                     |
  | --dns-mijn-host-propagation-seconds | 60                | Sets the wait time in seconds before Certbot checks the TXT record. The default is 120 seconds. |



  ```ini
  dns_mijn_host_api_key = YOUR_API_KEY
  ```

  Make sure the file is stored securely and not accessible by unauthorized users.



  ```bash
  certbot certonly \
    --authenticator dns-mijn-host \
    --dns-mijn-host-credentials /path/to/credentials.ini \
    --dns-mijn-host-propagation-seconds 60 \
    --agree-tos \
    --rsa-key-size 4096 \
    -d 'example.com' \
    -d '*.example.com'
  ```

  The plugin will create a TXT record for the DNS-01 challenge in your mijn.host DNS zone. After the challenge is verified, the plugin will delete the TXT record.



  For local development and testing, it’s recommended to use a Python virtual environment:

  ```bash
  python -m venv .venv
  source .venv/bin/activate
  pip install -r requirements.txt
  python setup.py sdist bdist_wheel
  pip install -e .
  ```

  This will install the plugin in the local environment, allowing you to make changes without reinstalling.

  When running Certbot locally, you may need to specify --logs-dir, --config-dir, and --work-dir to avoid permission issues with global directories.



  If you encounter issues or have suggestions, please open an issue on the GitHub repository.



  This project is licensed under the Apache License 2.0. See the [LICENSE](./LICENSE) file for details.



  If you need to use a different DNS service, check out the [Certbot DNS plugins](https://eff-certbot.readthedocs.io/en/latest/using.html#dns-plugins) for other providers.


pkgId: 2d9b646c434eb466e0d431c6a5658b5a8e7cbb3d89b9385a26cdec7fc4e278a2
name: python-certbot-dns-netcup
arch: src
version: 1.4.4
epoch: 0
release: 1
summary: netcup DNS Authenticator plugin for Certbot
url: https://github.com/coldfix/certbot-dns-netcup
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-netcup-1.4.4-1.src.rpm
checksum_type: sha256
description:
  |Version| |License| |ImageSize|
  netcup_ DNS Authenticator plugin for certbot_.
  This plugin automates the process of completing a ``dns-01`` challenge by
  creating, and subsequently removing, ``TXT`` records using the netcup `CCP
  API`_ via lexicon_.
  **Note:** This manual assumes certbot ≥ v1.7, which has improved the naming
  scheme for external plugins. If you cannot upgrade, please also refer to the
  `Old option naming scheme`_ section below.


pkgId: 02713e7bb39f8fbb5d225a1d3c63a684f6c936ae0243c449007ec2083febe923
name: python-certbot-dns-njalla
arch: src
version: 1.0.0
epoch: 0
release: 1
summary: Njalla DNS Authenticator plugin for Certbot
url: https://pypi.org/project/certbot-dns-njalla/
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-njalla-1.0.0-1.src.rpm
checksum_type: sha256
description:
  This is a plugin for [Certbot](https://certbot.eff.org/) that uses the [Njalla](https://njal.la/) API
  to allow customers to prove control of a domain name.



  1. Obtain an Njalla API token (found in the [settings](https://njal.la/settings/api/))

  2. Install the plugin using `pip3 install certbot-dns-njalla`, or if you are using `sudo` with certbot use `sudo -H pip3 install certbot-dns-njalla`

  3. Create a `njalla.ini` config file with the following contents and apply `chmod 600 njalla.ini` on it:

     ```
     certbot_dns_njalla:dns_njalla_token=0000000000000000000000000000000000000000
     ```

     Replace the zeroes with your Njalla API key and ensure permissions are set
     to disallow access to other users.

  4. Run `certbot` and direct it to use the plugin for authentication and to use
     the config file previously created:
     ```
     certbot certonly -a certbot-dns-njalla:dns-njalla --certbot-dns-njalla:dns-njalla-credentials njalla.ini -d domain.com
     ```
     Add additional options as required to specify an installation plugin etc.



  - PyPI: https://pypi.org/project/certbot-dns-njalla/


pkgId: 8d19071d6d7b32ff79ae541a1c6c15dffb864b8e55cd8b82b7e7fe8304ba265d
name: python-certbot-dns-njalla
arch: src
version: 2.0.0
epoch: 0
release: 1
summary: Njalla DNS Authenticator plugin for Certbot
url: https://pypi.org/project/certbot-dns-njalla/
rpm_license: Apache License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-njalla-2.0.0-1.src.rpm
checksum_type: sha256
description:
  This is a plugin for [Certbot](https://certbot.eff.org/) that uses the [Njalla](https://njal.la/) API
  to allow customers to prove control of a domain name.





  Use this method if you have also installed `certbot` via `pip`.
  Install the plugin using

  ```commandline
  pip3 install certbot-dns-njalla
  ```

  If you are using `sudo` with certbot use `sudo -H pip3 install certbot-dns-njalla` instead.



  Use this method if you have also installed `certbot` via `snap`.

  ```commandline
  snap install certbot-dns-njalla
  ```

  Now connect the certbot installation with the njalla plugin installation.

  ```commandline
  sudo snap connect certbot:plugin certbot-dns-njalla
  ```



  1. Make sure the plugin is installed and connected. You can verify this by running `certbot plugins`. `dns-njalla` should be in the list.

  2. Obtain an Njalla API token (found in the [settings](https://njal.la/settings/api/))

  3. Create a `njalla.ini` config file with the following contents and apply `chmod 600 njalla.ini` on it:

     ```ini
     dns_njalla_token=<token>
     ```

     Replace `<token>` with your Njalla API key and ensure permissions are set
     to disallow access to other users.

  4. Run `certbot` and direct it to use the plugin for authentication and to use
     the config file previously created:

     ```sh
     certbot -a dns-njalla --dns-njalla-credentials njalla.ini -d domain.com
     ```

     Use `*.domain.com` if you want to generate it as a wildcard certificate.
     Add additional options as required to specify an installation plugin etc.

     Remember to use the `-i` flag if you want to use an additional installer plugin, like `-i apache` or `-i nginx`.





  Run the following command in the repository root (so you are in the folder containing the `setup.py`):

  ```sh
  pip3 install -e ./
  ```



  By default a snap is built automatically by snapcraft if there are changes in the git repo. But here is what to do to test the build locally.

  Do the basic setup described in the [certbot snap readme](https://github.com/certbot/certbot/tree/master/tools/snap#local-testing-and-development). (Mainly installing setting up lxd)
  Run the following command in the repository root (so you are in the folder containing the `setup.py`):

  ```sh
  sh generate_dnsplugins_snapcraft.sh
  snapcraft clean --use-lxd
  snapcraft --debug --use-lxd
  ```



  Execute the following command inside the root-directory

  ```sh
  python -m unittest discover -p '*_test.py'
  ```



  - PyPI: https://pypi.org/project/certbot-dns-njalla/


pkgId: c9c75904add2e697d8a542520148c0aec59180a4921ebe42f66bf3b5ea4a1b56
name: python-certbot-dns-simply
arch: src
version: 0.1.2
epoch: 0
release: 1
summary: Simply.com DNS Authenticator plugin for Certbot
url: https://github.com/JohNan/certbot-dns-simply
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-simply-0.1.2-1.src.rpm
checksum_type: sha256
description:
  Simply.com DNS Authenticator plugin for Certbot.



  ```sh
  pip install certbot-dns-simply
  ```



  To start using DNS authentication for the Simply.com DNS API, pass the following arguments on certbot's command line:

  | Option                       | Description                                         |
  |------------------------------|-----------------------------------------------------|
  | `--authenticator dns-simply` | select the authenticator plugin (Required)          |
  | `--dns-simply-credentials`   | Simply.com DNS API credentials INI file. (Required) |



  Username is the Simply.com account-number (Sxxxxxx) and the password is the API-KEY for the specific account.
  The API-Key assigned to your Simply.com account can be found in your Simply.com Controlpanel.
  Please make sure to use the absolute path - some users experienced problems with relative paths.

  An example `credentials.ini` file:

  ```ini
  dns_simply_account_name = Sxxxxxx
  dns_simply_api_key = DSHJdsjh2812872sahj
  ```


  To acquire a certificate for `example.com`

  ```bash
  certbot certonly \
   --authenticator dns-simply \
   --dns-simply-credentials /path/to/my/credentials.ini \
   -d example.com
  ```

  To acquire a certificate for ``*.example.com``
  ```bash
     certbot certonly \
       --authenticator dns-simply \
       --dns-simply-credentials /path/to/my/credentials.ini \
       -d '*.example.com'
  ```


pkgId: 60534c529e3cf3e6b332702b6b0c9b5d6bcc07c881909d2b2c15eecadc902230
name: python-certbot-dns-strato
arch: src
version: 0.2.2
epoch: 0
release: 1
summary: Strato DNS Authenticator plugin for Certbot
url: https://github.com/flixma/certbot-dns-strato
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-strato-0.2.2-1.src.rpm
checksum_type: sha256
description:
  This plugin is based on the [strato-certbot](https://github.com/Buxdehuda/strato-certbot) by [Buxdehuda](https://github.com/Buxdehuda).


pkgId: 674a70cde55fea4e2721435a921ea781d71541ffc1953b306a4368975841e9d9
name: python-certbot-dns-tencentcloud
arch: src
version: 2.0.2
epoch: 0
release: 1
summary: Tencent Cloud DNS Authenticator plugin for Certbot
url: https://github.com/frefreak/certbot-dns-tencentcloud
rpm_license: UNKNOWN
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dns-tencentcloud-2.0.2-1.src.rpm
checksum_type: sha256
description:
  This package provides a Certbot authenticator plugin
  that can complete the DNS-01 challenge using the Tencent Cloud API.




  Only Tested on python 3.8, should work on python 3.7 too and forward.

  - no plan to support python2
  - [dataclasses](https://docs.python.org/3/library/dataclasses.html) is used, so python 3.6 and down will not work. However you can try installing `dataclasses` from pypi.

  Use pip to install this package:
  ```
  sudo pip3 install certbot-dns-tencentcloud
  ```

  Verify the installation with Certbot:
  ```
  sudo certbot plugins
  ```
  You should see `dns-tencentcloud` in the output.




  To use this plugin, set the authenticator to `dns-tencentcloud` via the `-a` or `--authenticator` flag.
  You may also set this using Certbot's configuration file (defaults to `/etc/letsencrypt/cli.ini`).

  You will also need to provide a credentials file with your Tencent Cloud API key id and secret, like the following:
  ```
  dns_tencentcloud_secret_id  = TENCENTCLOUD_SECRET_ID
  dns_tencentcloud_secret_key = TENCENTCLOUD_SECRET_KEY
  ```
  The path to this file can be provided interactively or via the `--dns-tencentcloud-credentials` argument.

  You can also provide the credential using `TENCENTCLOUD_SECRET_ID`
  and `TENCENTCLOUD_SECRET_KEY` environment variables.

  **CAUTION:**
  Protect your API key as you would the password to your account.
  Anyone with access to this file can make API calls on your behalf.
  Be sure to **read the security tips below**.




  - `--dns-tencentcloud-credentials` path to Tencent Cloud credentials INI file (Required)
  - `--dns-tencentcloud-propagation-seconds` seconds to wait before verifying the DNS record (Default: 10)

  **NOTE:** Due to a [limitation in Certbot](https://github.com/certbot/certbot/issues/4351),
  these arguments *cannot* be set via Certbot's configuration file.




  When in root:

  ```
  certbot certonly \
    -a dns-tencentcloud \
    --dns-tencentcloud-credentials ~/.secrets/certbot/tencentcloud.ini \
    -d example.com
  ```

  or if providing credentials using environment variable:

  ```
  export TENCENTCLOUD_SECRET_ID=<your_secret_id> TENCENTCLOUD_SECRET_KEY=<your_secret_key>
  certbot certonly \
    -a dns-tencentcloud \
    -d example.com
  ```




  **Restrict access of your credentials file to the owner.**
  You can do this using `chmod 600`.
  Certbot will emit a warning if the credentials file
  can be accessed by other users on your system.

  **Use a separate key from your account's primary API key.**
  Make a separate user under your account,
  and limit its access to only allow DNS access
  and the IP address of the machine(s) that will be using it.



  1. Which strategy should I choose to limit my API key access to only allow DNS resolution related operation?

  We now use the new DNSPOD api so you need to give `QcloudDNSPodFullAccess` strategy (need to add record so write permission is necessary).

  2. renew certs for `*.abc.com` and `abc.com` at the same time sometimes show error about incorrect TXT records.

  It seems Let's Encrypt cache TXT records for at most 60 seconds, since DNSPod doesn't seem
  to allow setting TXT record's TTL below 60, in this case the best/safest way is to set
  `--dns-tencentcloud-propagation-seconds` longer than 60.

  3. Debug mode?

  ```
  --dns-tencentcloud-debug true
  ```


pkgId: 30261dc0b08051bb8304fc571f6d0644d20b8a69cc1ecd8fafb2b5bff109ba73
name: python-certbot-dnspod
arch: src
version: 0.1.4
epoch: 0
release: 1
summary: A certbot plugin for DNSPod
url: https://github.com/codeif/certbot-dnspod
rpm_license: BSD-3-Clause
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-dnspod-0.1.4-1.src.rpm
checksum_type: sha256
description:
  A certbot plugin for DNSPod



  ```
  pip install certbot-dnspod
  ```



  ```
  sudo certbot certonly \
  --authenticator certbot-dnspod \
  --certbot-dnspod-credentials ~/.secrets/certbot/dnspod.ini \
  -d example.com \
  -d *.example.com
  ```

  其中~/.secrets/certbot/dnspod.ini为配置文件路径，内容

  ```
  certbot_dnspod_token_id = <your token id>
  certbot_dnspod_token = <your token>
  ```

  chmod

  ```
  chmod 600 ~/.secrets/certbot/dnspod.ini
  ```



  官方插件是参数形式是
  ```
  --dns-cloudflare-credentials
  ```

  而第三方插件的参数是::

  ```
  --authenticator certbot-dnspod
  ```

  或者

  ```
  -a certbot-dnspod
  ```



  - [certbot命令行参数](https://eff-certbot.readthedocs.io/en/stable/using.html#certbot-command-line-options)
  - [编写一个certbot插件](https://certbot.eff.org/docs/contributing.html#writing-your-own-plugin)
  - [官方插件](https://certbot.eff.org/docs/using.html#dns-plugins)
  - [三方插件](https://certbot.eff.org/docs/using.html#third-party-plugins)
  - [poetry加自定义的entry_points](https://python-poetry.org/docs/pyproject/#plugins)


pkgId: 17ebed61080f81151b4407191f1acdbf5074143982a3c2e2edc01993b0d0fcdd
name: python-certbot-plugin-gandi
arch: src
version: 1.5.0
epoch: 0
release: 1
summary: Certbot plugin for authentication using Gandi LiveDNS
url: https://github.com/obynio/certbot-plugin-gandi
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-plugin-gandi-1.5.0-1.src.rpm
checksum_type: sha256
description:
  This is a plugin for [Certbot](https://certbot.eff.org/) that uses the Gandi
  LiveDNS API to allow [Gandi](https://www.gandi.net/)
  customers to prove control of a domain name.



  > /!\ Certbot 1.7.0 imposed breaking changes on this plugin, make sure to remove any prefix-based configuration

  1. Obtain a Gandi API token (see [Gandi LiveDNS API](https://doc.livedns.gandi.net/))

  2. Install the plugin using `pip install certbot-plugin-gandi`

  3. Create a `gandi.ini` config file with the following contents and apply `chmod 600 gandi.ini` on it:
     ```conf
     
     dns_gandi_token=PERSONAL_ACCESS_TOKEN
     ```
     Replace `PERSONAL_ACCESS_TOKEN` with your Gandi personal access token and ensure permissions are set
     to disallow access to other users. You can also use a Gandi LiveDNS API Key instead, see FAQ below.

  4. Run `certbot` and direct it to use the plugin for authentication and to use
     the config file previously created:
     ```
     certbot certonly --authenticator dns-gandi --dns-gandi-credentials /etc/letsencrypt/gandi/gandi.ini -d domain.com
     ```
     Add additional options as required to specify an installation plugin etc.

  Please note that this solution is usually not relevant if you're using Gandi's web hosting services as Gandi offers free automated certificates for all simplehosting plans having SSL in the admin interface.

  Be aware that the plugin configuration must be provided by CLI, configuration for third-party plugins in `cli.ini` is not supported by certbot for the moment. Please refer to [#4351](https://github.com/certbot/certbot/issues/4351), [#6504](https://github.com/certbot/certbot/issues/6504) and [#7681](https://github.com/certbot/certbot/issues/7681) for details.



  PyPI is the upstream distribution channel, other channels are not maintained by me.

  * PyPI: https://pypi.org/project/certbot-plugin-gandi/
  * Archlinux: https://aur.archlinux.org/packages/certbot-dns-gandi-git/
  * Debian: https://packages.debian.org/sid/main/python3-certbot-dns-gandi
  * Ubuntu: https://packages.ubuntu.com/kinetic/python3-certbot-dns-gandi
  * Snap: Not yet packaged. I'm lazy.

  Latests builds are also available on Launchpad: https://launchpad.net/ubuntu/+source/python-certbot-dns-gandi

  Be careful, installing this plugin with PyPI will also install certbot via PyPI which may conflict with any other certbot already installed on your system.



  This plugin is particularly useful when you need to obtain a wildcard certificate using dns challenges:

  ```
  certbot certonly --authenticator dns-gandi --dns-gandi-credentials /etc/letsencrypt/gandi/gandi.ini -d domain.com -d \*.domain.com --server https://acme-v02.api.letsencrypt.org/directory
  ```



  You can setup automatic renewal using `crontab` with the following job for weekly renewal attempts:

  ```
  0 0 * * 0 certbot renew -q --authenticator dns-gandi --dns-gandi-credentials /etc/letsencrypt/gandi/gandi.ini --server https://acme-v02.api.letsencrypt.org/directory
  ```



  * A [blog post](https://www.linux.it/~ema/posts/letsencrypt-the-manual-plugin-is-not-working/) by [@realEmaRocca](https://twitter.com/realEmaRocca) describing how to use this plugin on Debian



  > I don't have a personal access token, only a Gandi LiveDNS API Key

  Use the following configuration in your `gandi.ini` file instead:

  ```conf

  dns_gandi_api_key=APIKEY


  dns_gandi_sharing_id=SHARINGID
  ```
  Replace `APIKEY` with your Gandi API key and ensure permissions are set
  to disallow access to other users.

  > I have a warning telling me `Plugin legacy name certbot-plugin-gandi:dns may be removed in a future version. Please use dns instead.`

  Certbot had moved to remove 3rd party plugins prefixes since v1.7.0. Please switch to the new configuration format and remove any used prefix-based configuration.
  For the time being, you can still use prefixes, but if you do so and keep using prefix-based cli arguments, stay consistent and use prefix-based configuration in the ini file.


  * `--authenticator dns-gandi --dns-gandi-credentials`
  * `gandi.ini`

  ```

  dns_gandi_api_key=APIKEY



  dns_gandi_sharing_id=SHARINGID
  ```



  * `-a certbot-plugin-gandi:dns --certbot-plugin-gandi:dns-credentials`
  * `gandi.ini`

  ```
   
  certbot_plugin_gandi:dns_api_key=APIKEY


  certbot_plugin_gandi:dns_sharing_id=SHARINGID
  ```

  See [certbot/8131](https://github.com/certbot/certbot/pull/8131) and [certbot-plugin-gandi/23](https://github.com/obynio/certbot-plugin-gandi/issues/23) for details. Please make sure to update the configuration file to the new format.

  > I get a `Property "certbot_plugin_gandi:dns_api_key" not found (should be API key for Gandi account).. Skipping.`

  See above.

  > Why do you keep this plugin a third-party plugin ? Just merge it with certbot ?

  This Gandi plugin is a third party plugin mainly because this plugin is not officially backed by Gandi and because Certbot [does not accept](https://certbot.eff.org/docs/contributing.html?highlight=propagation#writing-your-own-plugin) new plugin submissions.

  ![no_submission](https://user-images.githubusercontent.com/2095991/101479748-fd9da280-3952-11eb-884f-491470718f4d.png)



  Huge thanks to Michael Porter for its [original work](https://gitlab.com/sudoliyang/certbot-plugin-gandi) !


pkgId: 975b2f9ecb791662154b02976a94681015486f3256c820420fc80bf194fa0bf4
name: python-certbot-regfish-hooks
arch: src
version: 2.0.0b1
epoch: 0
release: 1
summary: regfish pre and post validation hooks for certbot
url: https://pypi.org/project/certbot-regfish-hooks/
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-regfish-hooks-2.0.0b1-1.src.rpm
checksum_type: sha256
rpm_license:
  Copyright 2024 Maximilian Kaulmann  Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:  1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.  2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.  3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


pkgId: 30c952485b9fbc5e30a09d32c5594ea532a62ed34ba9fc31977a3b4d319b989b
name: python-certbot-standalone-nfq
arch: src
version: 0.1.3
epoch: 0
release: 1
summary: Certbot HTTP authenticator that works with any web server.
url: https://pypi.org/project/certbot-standalone-nfq/
rpm_license: GPL-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certbot-standalone-nfq-0.1.3-1.src.rpm
checksum_type: sha256
description:
  [![certbot-standalone-nfq](https://snapcraft.io/certbot-standalone-nfq/badge.svg)](https://snapcraft.io/certbot-standalone-nfq)

  HTTP authenticator plugin for [Certbot](https://certbot.eff.org/) which is compatible with any web server! (Linux only and `root` is required.)



  It works by asking the Linux kernel to temporarily divert incoming port 80 HTTP traffic into
  a queue. The Certbot plugin then picks out the Let's Encrypt validation requests from the
  queue and responds to them. All other traffic reaches its original destination, totally
  unchanged. This all happens very quickly and no traffic disruptions occur.



  - Avoids messing about with any webserver configuration, meaning that it can work well
    with tricky webservers like Apache Tomcat.
  - Avoids having a proxy in front of your normal webserver, which means all source addresses
    (and indeed every network packet) are totally preserved!

  It is inspired [by this community thread](https://community.letsencrypt.org/t/using-nfqueue-on-linux-as-a-novel-webserver-agnostic-http-authenticator).





  Using the `certbot` snap is the easiest way to use this plugin. See [here](https://certbot.eff.org/instructions?ws=other&os=snap) for instructions on installing Certbot via `snap`.

  ```bash
  sudo snap install certbot-standalone-nfq
  sudo snap set certbot trust-plugin-with-root=ok
  sudo snap connect certbot:plugin certbot-standalone-nfq
  ```



  A source tarball [is available](https://pypi.org/project/certbot-standalone-nfq/#files).

  | How did you install Certbot?                                                                          | How to install the plugin                             |
  |-------------------------------------------------------------------------------------------------------|-------------------------------------------------------|
  | From `snap`                                                                                           | Don't use `pip`! Use the snap instructions above.     |
  | Using the [official Certbot `pip` instructions](https://certbot.eff.org/instructions?ws=other&os=pip) | `sudo /opt/certbot/bin/pip install certbot-standalone-nfq` |
  | From `apt`, `yum`, `dnf` or any other distro package manager. (Requires Certbot 1.25.0 or newer.)     | `pip install certbot-standalone-nfq`                       |



  `certbot-standalone-nfq` should just work without having to configure anything:

  ```bash
  certbot certonly -a standalone-nfq \
  -d "example.com" -d "www.example.com" \
  --dry-run
  ```

  If (for some reason, like port forwarding shenanigans) your web server is listening on
  a port other than 80, you can use the `--http-01-port` argument of Certbot to change
  the port that the plugin will divert the traffic from.


pkgId: 891fcc122b71cb9db76c37044406f3f44799ee439868d5d0c16db68393460d0b
name: python-certego-saas
arch: src
version: 0.7.11
epoch: 0
release: 1
summary: Certego SaaS
url: https://github.com/certego/certego-saas
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certego-saas-0.7.11-1.src.rpm
checksum_type: sha256
description:
  [![PyPI version](https://badge.fury.io/py/certego-saas.svg)](https://badge.fury.io/py/certego-saas)
  [![PyPI Supported Python Versions](https://img.shields.io/pypi/pyversions/certego-saas.svg)](https://pypi.python.org/pypi/certego-saas/)

  [![Lint & Tests](https://github.com/certego/certego-saas/workflows/Lint%20&%20Tests/badge.svg)](https://github.com/certego/certego-saas/actions)
  [![codecov](https://codecov.io/gh/certego/certego-saas/branch/main/graph/badge.svg?token=XnTODgn1G7)](https://codecov.io/gh/certego/certego-saas)
  [![Language grade: Python](https://img.shields.io/lgtm/grade/python/g/certego/certego-saas.svg?logo=lgtm&logoWidth=18)](https://lgtm.com/projects/g/certego/certego-saas/context:python)
  [![CodeFactor](https://www.codefactor.io/repository/github/certego/certego-saas/badge)](https://www.codefactor.io/repository/github/certego/certego-saas)



  Requires python version >=3.8.

  ```bash
  $ pip3 install certego_saas
  ```

  - For development/testing, `pip3 install certego_saas[dev]`.



  - Code reference: [`example_project`](https://github.com/certego/certego-saas/tree/main/example_project).
  - Documentation: https://certego-certego-saas.readthedocs-hosted.com/



  - [Dragonfly](https://dragonfly.certego.net/)
  - [IntelOwl](https://github.com/intelowlproject/IntelOwl)



  MIT © [certego](https://github.com/certego)


pkgId: 0e356d27d4a799a144d7cb2d1d75b7903b72e1c46c6d8f1cd3dfa2a57802954d
name: python-certgrinder
arch: src
version: 0.19.2
epoch: 0
release: 1
summary: The client part of the Certgrinder project
url: https://pypi.org/project/certgrinder/
rpm_license: BSD 3-Clause License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certgrinder-0.19.2-1.src.rpm
checksum_type: sha256
description:
  [![Checked with mypy](../docs/badges/mypy_badge.svg)](http://mypy-lang.org/)
  [![Checked with flake8](../docs/badges/flake8-OK-green.svg)](http://flake8.pycqa.org/en/latest/)
  [![Codestyle black](../docs/badges/black.svg)](https://github.com/psf/black/)
  [![PyPI](https://img.shields.io/pypi/v/certgrinder.svg)](https://pypi.org/project/certgrinder/)
  [![PyPI downloads](https://img.shields.io/pypi/dm/certgrinder.svg)](https://pypi.org/project/certgrinder/)

  This is the client part of the [Certgrinder project](https://certgrinder.readthedocs.io/en/latest/introduction.html). The package is called ``certgrinder``. It can be installed [from pypi](https://pypi.org/project/certgrinder/).

  It is meant to be used with the [certgrinderd](https://pypi.org/project/certgrinderd/) server package.

  Documentation can be found at ReadTheDocs: https://certgrinder.readthedocs.io/en/latest/certgrinder.html


pkgId: 3634635219f130fed75eeabf6e9112e1185b1c003f588cac6c707bc9682a3183
name: python-certgrinderd
arch: src
version: 0.19.2
epoch: 0
release: 1
summary: The server part of the Certgrinder project
url: https://pypi.org/project/certgrinderd/
rpm_license: BSD 3-Clause License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certgrinderd-0.19.2-1.src.rpm
checksum_type: sha256
description:
  [![Checked with mypy](../docs/badges/mypy_badge.svg)](http://mypy-lang.org/)
  [![Checked with flake8](../docs/badges/flake8-OK-green.svg)](http://flake8.pycqa.org/en/latest/)
  [![Codestyle black](../docs/badges/black.svg)](https://github.com/psf/black/)
  [![PyPI](https://img.shields.io/pypi/v/certgrinderd.svg)](https://pypi.org/project/certgrinderd/)
  [![PyPI downloads](https://img.shields.io/pypi/dm/certgrinderd.svg)](https://pypi.org/project/certgrinderd/)

  This is the server part of the [Certgrinder project](https://certgrinder.readthedocs.io/en/latest/introduction.html). The package is called ``certgrinderd``. It can be installed [from pypi](https://pypi.org/project/certgrinderd/).

  It is meant to be used with the [certgrinder](https://pypi.org/project/certgrinder/) client package.

  Documentation can be found at ReadTheDocs: https://certgrinder.readthedocs.io/en/latest/certgrinderd.html


pkgId: c7e138b4c22dc18aa63e62f5bd0f8003a73956878c8ffbe4e8441a3c06f71968
name: python-certifi
arch: src
version: 2024.8.30
epoch: 0
release: 1
summary: Python package for providing Mozilla's CA Bundle.
url: https://github.com/certifi/python-certifi
rpm_license: MPL-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certifi-2024.8.30-1.src.rpm
checksum_type: sha256
description:
  Certifi provides Mozilla's carefully curated collection of Root Certificates for
  validating the trustworthiness of SSL certificates while verifying the identity
  of TLS hosts. It has been extracted from the `Requests`_ project.


pkgId: 6e3c6959f53e23ab3ce05cd6b092f4588b4f223ed9ba656606bf052883fdf96e
name: python-certifi-debian
arch: src
version: 2021.1.10
epoch: 0
release: 1
summary: Python package for providing Debian like CA Bundle path.
url: https://certifiio.readthedocs.io/en/latest/
rpm_license: MPL-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certifi-debian-2021.1.10-1.src.rpm
checksum_type: sha256
description:
  `Certifi-debian` provides a fork of https://github.com/certifi/python-certifi but use
  distro bundle for validating the trustworthiness of SSL certificates while
  verifying the identity of TLS hosts. It has been extracted from the `Requests`
  project.


pkgId: eb81af83527a1297cd9128685b8e0588b988df5dcf7cfcc2f0dc8c2b6e0999cb
name: python-certifi-linux
arch: src
version: 1.0.0
epoch: 0
release: 1
summary: Certifi patch for using Linux cert trust stores
url: https://github.com/m-birke/certifi-linux
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certifi-linux-1.0.0-1.src.rpm
checksum_type: sha256
description:
  **Table of Contents**
  - [About](#about)
  - [Installation](#installation)
  - [Usage](#usage)
  - [Compatibility](#compatibility)
  - [Implementation](#implementation)
  - [Related Projects](#related-projects)
  - [Credits](#credits)
  - [License](#license)

  **WHAT:** `certifi-linux` wraps [certifi](https://pypi.org/project/certifi/), but instead of distributing a certificate like `certifi` does, it uses the Linux system trust store.
  **WHY?** The [requests](https://pypi.org/project/requests/) module depends on `certifi` and uses it for TLS. `certifi` distributes the collection of root certificates provided by Mozilla for Python deployments. In some cases, especially in an enterprise setup it is necessary to use the certificates which are shipped with the OS.

  `certifi-linux` is purposed for **Linux**! For Windows take a look at [pip-system-certs](https://gitlab.com/alelec/pip-system-certs).
  ```console
  pip install certifi-linux
  ```

  `certifi-linux` just needs to be installed. Afterwards `certifi.where()` or `$ python3 -m certifi` will return the path to the system store. Hence all dependent projects like `requests` will do as well.

  I am trying to keep tests up to date with [endoflife](https://endoflife.date/).
  Tested distros are:
  - alpine:3,
  - ubuntu:focal, ubuntu:jammy, ubuntu:mantic,
  - debian:buster, debian:bullseye, debian:bookworm,
  - fedora:33, fedora:34, fedora:38, fedora:39,
  - centos:stream9,
  - (manually) rhel:37, rhel:38
  Yet untested: Arch, Slackware, OpenWRT, FreeBSD, SUSE, gentoo, ...

  `certifi-linux` monkey patches `certif.where` and `certifi.contents` by using [wrapt](https://pypi.org/project/wrapt/). When called, it searches in the defined set of possible certificate bundle paths for a match.

  Tested: yes✅, no❌
  | Cert Bundle Path                     | Linux Distribution                                                               |
  | ------------------------------------ | -------------------------------------------------------------------------------- |
  | `/etc/ssl/cert.pem`                  | fedora >= 3.4✅, RHEL✅, alpine✅, centOS Stream✅, Arch❌, OpenWRT❌, FreeBSD❌ |
  | `/etc/pki/tls/cert.pem`              | fedora <= 3.3✅                                                                  |
  | `/etc/ssl/certs/ca-certificates.crt` | Debian✅, Ubuntu✅                                                               |
  | `/etc/ssl/ca-bundle.pem`             | openSUSE❌                                                                       |

  The idea behind `certifi-linux` is the same as behind [certifi-system-store](https://github.com/tiran/certifi-system-store/). `certifi-system-store` replaces the dist-info of certifi with its own dist-info. This approach needs a specific order of installation for a succesful patch. When installed as a dependency among a whole set of dependencies this is hard to ensure and replacing dist-infos can mess up virtual environments.
  [pip-system-certs](https://gitlab.com/alelec/pip-system-certs) solves the same problem with a different approach. It monkey patches the `requests.adapters.HTTPAdapter` and uses `ssl.create_default_context` to load the OS certs. This works fine on Windows but has shown limitations on Linux as it does not work in some cases.
  Viewed from the outside, [certifi-debian](https://pypi.org/project/certifi-debian/) is doing the exact same thing like `certifi-linux` but just for debian. [certifi-system-store-wrapper](https://pypi.org/project/certifi-system-store-wrapper/) also does the same but with the necessity to set an environment variable.

  Credits go to the developers of `certifi-system-store` and `pip-system-certs` as `certifi-linux` is highly influenced by these two projects.

  `certifi-linux` is distributed under the terms of the [MIT](https://spdx.org/licenses/MIT.html) license.


pkgId: 4903aaeeffbeef51e8a0ca49745f2dac985744687b0aaee4fdc165df111e56aa
name: python-certificate-check
arch: src
version: 1.3.0
epoch: 0
release: 1
summary: please add a summary manually as the author left a blank one
url: https://pypi.org/project/certificate-check/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certificate-check-1.3.0-1.src.rpm
checksum_type: sha256
description:
  **Usage**:

  ```console
  $ certificate-check [OPTIONS] FILENAME
  ```

  **Arguments**:

  * `FILENAME`: The certificate file to use (must finish with .cer)  [required]

  **Options**:

  * `--keep / --no-keep`: Keeps the downloaded CRL file  [default: no-keep]
  * `--install-completion`: Install completion for the current shell.
  * `--show-completion`: Show completion for the current shell, to copy it or customize the installation.
  * `--help`: Show this message and exit.


pkgId: 35aaeca91643fef515993c54ec5684e234c0048cff1f3ae3958d14c3d0b3f446
name: python-certificates
arch: src
version: 2.0.0
epoch: 0
release: 1
summary: Generate event certificates easily.
url: https://github.com/cassiobotaro/certificates
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certificates-2.0.0-1.src.rpm
checksum_type: sha256
description:
  Generate event certificates easily.



  * Inkscape (`apt install inkscape`)



  Use the package manager [pip](https://pip.pypa.io/en/stable/) to install certificates.

  ```bash
  pip install certificates
  ```



  `certificates participants.csv template.svg`

  ```
  usage: certificates [-h] [--output OUTPUT] participants template

  positional arguments:
    participants          csv filaname containing participants
    template              certificate template in svg format used to build

  optional arguments:
    -h, --help            show this help message and exit
    --output OUTPUT, -o OUTPUT
                          destination of the generated certificates
  ```


  Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

  Please make sure to update tests as appropriate.


  [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)


pkgId: 03850d4908d98b53dd04ee35cb502a1e7f0feb13ab1cab0ebd6229e628e0fc53
name: python-certipy
arch: src
version: 0.2.1
epoch: 0
release: 1
summary: Utility to create and sign CAs and certificates
url: https://github.com/LLNL/certipy
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certipy-0.2.1-1.src.rpm
checksum_type: sha256
description:
  A simple python tool for creating certificate authorities and certificates on
  the fly.



  Certipy was made to simplify the certificate creation process. To that end,
  Certipy exposes methods for creating and managing certificate authorities,
  certificates, signing and building trust bundles. Behind the scenes Certipy:

  * Manages records of all certificates it creates
    * External certs can be imported and managed by Certipy
    * Maintains signing hierarchy
  * Persists certificates to files with appropriate permissions





  Creating a certificate authority:

  Certipy defaults to writing certs and certipy.json into a folder called `out`
  in your current directory.

  ```
  $ certipy foo
  FILES {'ca': '', 'cert': 'out/foo/foo.crt', 'key': 'out/foo/foo.key'}
  IS_CA True
  SERIAL 0
  SIGNEES None
  PARENT_CA
  ```

  Creating and signing a key-cert pair:

  ```
  $ certipy bar --ca-name foo
  FILES {'ca': 'out/foo/foo.crt', 'key': 'out/bar/bar.key', 'cert': 'out/bar/bar.crt'}
  IS_CA False
  SERIAL 0
  SIGNEES None
  PARENT_CA foo
  ```

  Removal:

  ```
  certipy --rm bar
  Deleted:
  FILES {'ca': 'out/foo/foo.crt', 'key': 'out/bar/bar.key', 'cert': 'out/bar/bar.crt'}
  IS_CA False
  SERIAL 0
  SIGNEES None
  PARENT_CA foo
  ```



  Creating a certificate authority:

  ```
  from certipy import Certipy

  certipy = Certipy(store_dir='/tmp')
  certipy.create_ca('foo')
  record = certipy.store.get_record('foo')
  ```

  Creating and signing a key-cert pair:

  ```
  certipy.create_signed_pair('bar', 'foo')
  record = certipy.store.get_record('bar')
  ```

  Creating trust:

  ```
  certipy.create_ca_bundle('ca-bundle.crt')


  certipy.create_ca_bundle_for_names('ca-bundle.crt', ['bar'])
  ```

  Removal:

  ```
  record = certipy.remove_files('bar')
  ```

  Records are dicts with the following structure:

  ```
  {
    'serial': 0,
    'is_ca': true,
    'parent_ca': 'ca_name',
    'signees': {
      'signee_name': 1
    },
    'files': {
      'key': 'path/to/key.key',
      'cert': 'path/to/cert.crt',
      'ca': 'path/to/ca.crt',
    }
  }
  ```

  The `signees` will be empty for non-CA certificates. The `signees` field
  is stored as a python `Counter`. These relationships are used to build trust
  bundles.

  Information in Certipy is generally passed around as records which point to
  actual files. For most `_record` methods, there are generally equivalent
  `_file` methods that operate on files themselves. The former will only affect
  records in Certipy's store and the latter will affect both (something happens
  to the file, the record for it should change, too).



  Certipy is released under BSD license. For more details see the LICENSE file.

  LLNL-CODE-754897

rpm_license:
  BSD 3-Clause License  Copyright (c) 2018, Lawrence Livermore National Security, LLC All rights reserved.  Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:  * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.  * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.  * Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


pkgId: cc9191f4b21e395033f213607074727a1ba69a5d0f47c3abd411a91904297226
name: python-certomancer
arch: src
version: 0.12.3
epoch: 0
release: 1
summary: PKI testing tool
url: https://github.com/MatthiasValvekens/certomancer
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certomancer-0.12.3-1.src.rpm
checksum_type: sha256
description:
  <p align="center">
    <img width="300" height="300" src="images/certomancer.svg" alt="logo">
  </p>

  ![status](https://github.com/MatthiasValvekens/certomancer/workflows/pytest/badge.svg)
  [![PyPI version](https://img.shields.io/pypi/v/certomancer)](https://pypi.org/project/certomancer/)
  ![Python versions](https://shields.io/pypi/pyversions/certomancer)
  [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)

  Quickly construct, mock & deploy PKI test configurations using simple declarative configuration.
  Includes CRL, OCSP and time stamping service provisioning.

  Requires Python 3.7 or later.



  Certomancer is [available on PyPI](https://pypi.org/project/certomancer/). See `example.yml` for an example config file.

  ```bash
  $ pip install 'certomancer[web-api]'
  $ certomancer --config example.yml animate
  ```

  This will run the Certomancer Animator WSGI app on your local machine, behind a development web
  server. Point your browser to `http://localhost:9000` and take a look around.
  For more information, see the [documentation](#Documentation) below.




  To build and install an (unreleased) development version, you can proceed as follows.

  ```bash
  $ git clone https://github.com/MatthiasValvekens/certomancer
  $ cd certomancer
  $ python -m build
  $ pip install dist/certomancer*.whl
  ```




  There's a demo on asciinema.org, demonstrating some of the core features of Certomancer. See link below.

  [![asciicast](https://asciinema.org/a/406798.svg)](https://asciinema.org/a/406798)




  I gave a lightning talk on testing & mocking PKI services in the [Testing & Automation devroom](https://fosdem.org/2022/schedule/track/testing_and_automation/) at [FOSDEM 2022](https://fosdem.org/2022/). Certomancer was (of course) featured in the presentation.
  If you want to learn more, or watch the recording, have a look at [the talk page](https://fosdem.org/2022/schedule/event/mockery_of_trust/) for further info. Slides are included as well.




   * Certomancer's core APIs are stateless: the same request should always return the same result.
     This property makes it very useful for automated testing.
     * Note that "the same result" does not necessarily mean "byte-for-byte equal".
       This is because some signing schemes (like ECDSA) involve random nonces. In addition to that,
       time is also a factor in certain cases (but Certomancer does permit time manipulation).
   * Declarative, YAML-based configuration.
   * Minimal input validation, so you can generate deliberately broken certificates if you need to.
   * ``requests-mock`` integration.
   * Attribute certificate support (`0.7.0` and up)
   * Ultra-lightweight WSGI application: the Certomancer Animator serves CRLs, OCSP responses,
     timestamps and more. This component requires Werkzeug, and optionally Jinja2 for the index view.
     Other than a web server and WSGI application server, there are no application dependencies.
   * Plugin framework to support arbitrary certificate / CRL extensions and additional services.
     These plugins are compatible with the WSGI and ``requests-mock`` integrations without
     additional configuration.
   * Certomancer is composable: since the Certomancer Animator is a bare-bones WSGI application,
     you can plug it into whatever web application framework you want with minimal overhead.
     Hence, for particularly complicated scenarios where the plugin API or existing integrations aren't
     sufficient, it is very easy to use Certomancer as a library, or wrap it as a component
     of some other WSGI application.
   * With [pyca/cryptography](https://github.com/pyca/cryptography) installed, Certomancer can also
     output PKCS#12 files if your tests require those.
   * With [python-pkcs11](https://github.com/danni/python-pkcs11) installed, Certomancer can write
     keys and certificates to PKCS#11 tokens as well.



  Certomancer is a testing tool for developers that write software to interface with public-key
  infrastructure. **It is *NOT* intended to be used to manage production PKI deployments.**
  Certomancer is very much garbage-in garbage-out, and happily ignores validation &
  security best practices in favour of allowing you to abuse your codebase in the worst possible ways.
  Consider yourself warned.




   * [Configuration](docs/config.md)
   * [CLI commands](docs/cli.md)
   * [Plugin API](docs/plugins.md)
   * [Deploying Certomancer](docs/deploy.md)


pkgId: d6781d1884388bec4336676041925432f607d987d5f4b4a5d4a9f62924eb5eab
name: python-certora-cli
arch: src
version: 7.17.2
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-7.17.2-1.src.rpm
checksum_type: sha256
description:
  Commit 501a551.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: a1222187d3e4222e0b07135a06d92e5bc07c85b0508a098bec00b18013f9dd30
name: python-certora-cli
arch: src
version: 7.20.1
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-7.20.1-1.src.rpm
checksum_type: sha256
description:
  Commit 2777ee3.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: 07861393f8064954a10324424f0f43f159babc395ceb6d0286ed06bc9aa9fd88
name: python-certora-cli
arch: src
version: 7.20.3
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-7.20.3-1.src.rpm
checksum_type: sha256
description:
  Commit 7b9a1c7.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: 5d4b20e0e024b627d393bbe988f998201ca83891844b37cfd9e263b74213ded0
name: python-certora-cli-alpha-CERT-7596-Execute-Cargo-Build
arch: src
version: 20241126.15.53.751402
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-alpha-CERT-7596_Execute_Cargo_Build
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-alpha-CERT-7596-Execute-Cargo-Build-20241126.15.53.751402-1.src.rpm
checksum_type: sha256
description:
  Commit a466a95.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: 2f8a4893162a0f521a8d72647526aef5d47f4d171766ce01be70a09282cad83e
name: python-certora-cli-alpha-master
arch: src
version: 20241012.14.47.334420
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-alpha-master
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-alpha-master-20241012.14.47.334420-1.src.rpm
checksum_type: sha256
description:
  Commit bc6c5dd.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: b8dc9484990df52402221d242aedd0179e827d8a30bb3a6ff620a189aad5059f
name: python-certora-cli-alpha-master
arch: src
version: 20241112.11.2.177326
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-alpha-master
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-alpha-master-20241112.11.2.177326-1.src.rpm
checksum_type: sha256
description:
  Commit f7f5527.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: b9df76852085d6d0e002099a9ca851fa04fe071d0b1f230b42e4b569f928cc8e
name: python-certora-cli-alpha-master
arch: src
version: 20241114.9.6.125199
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-alpha-master
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-alpha-master-20241114.9.6.125199-1.src.rpm
checksum_type: sha256
description:
  Commit e917ab1.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: c7d5832f75a1a13d4fe78f7d358476d8767dec52df3c86c3f6c5bb5a9a0c77c5
name: python-certora-cli-alpha-master
arch: src
version: 20241118.11.36.520636
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-alpha-master
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-alpha-master-20241118.11.36.520636-1.src.rpm
checksum_type: sha256
description:
  Commit b0aa4bc.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: 8a1cb652f5cf854b9cc5c10569c2cc10d0541d7d60a60eddd873c3d39cebed58
name: python-certora-cli-alpha-master
arch: src
version: 20241124.14.33.155915
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-alpha-master
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-alpha-master-20241124.14.33.155915-1.src.rpm
checksum_type: sha256
description:
  Commit dc5187a.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: 8ebc2edf18ee877a7009a0925ab3c71717d757e1936eb5a2e6df104495c95897
name: python-certora-cli-alpha-master
arch: src
version: 20241202.19.15.265743
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-alpha-master
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-alpha-master-20241202.19.15.265743-1.src.rpm
checksum_type: sha256
description:
  Commit 53901c3.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: 7921e974e80a1414dfc698c55f8086d7830b939ac90bd8a51921a38e0e2385a9
name: python-certora-cli-alpha-master
arch: src
version: 20241208.12.5.440577
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-alpha-master
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-alpha-master-20241208.12.5.440577-1.src.rpm
checksum_type: sha256
description:
  Commit 352bd54.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: e6c39cc67199afb3211bec2eb407b2b7688ca714a9f99c2bb6c0cf732c46c68e
name: python-certora-cli-alpha-rahav-CERT-7552-set-branch-in-alpha
arch: src
version: 20241121.11.51.504154
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-alpha-rahav-CERT-7552_set_branch_in_alpha
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
checksum_type: sha256
description:
  Commit b1586b7.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.

location_href:
  Packages/python-certora-cli-alpha-rahav-CERT-7552-set-branch-in-alpha-20241121.11.51.504154-1.src.rpm


pkgId: 80cb1bf4c5640ca2c230e2c1e7a18033678a139eba48b6c2d8e034d4942e0f22
name: python-certora-cli-alpha-rahav-cert-7153-5
arch: src
version: 20241117.12.29.240079
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-alpha-rahav-cert_7153_5
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-alpha-rahav-cert-7153-5-20241117.12.29.240079-1.src.rpm
checksum_type: sha256
description:
  Commit de6777f.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: 33fa21559ed02b76e13041e3a2614c8da7e33418be2e8b988cb6fc826fc02a7e
name: python-certora-cli-alpha-rahav-cert-7153-5
arch: src
version: 20241118.16.5.481867
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-alpha-rahav-cert_7153_5
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-alpha-rahav-cert-7153-5-20241118.16.5.481867-1.src.rpm
checksum_type: sha256
description:
  Commit 03029a3.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: d908bc74780861de587cc44a77a69e81a40d4264b4fa9657ea23fae9cbc5d92f
name: python-certora-cli-beta
arch: src
version: 7.18.1
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-beta
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-beta-7.18.1-1.src.rpm
checksum_type: sha256
description:
  Commit 29d7233.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: b0657b721c7b6611984e9a26f8cc5fc453c588b08a2f3b7064a2b3cd34e0938d
name: python-certora-cli-beta
arch: src
version: 7.20.0
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-beta
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-beta-7.20.0-1.src.rpm
checksum_type: sha256
description:
  Commit a952dab.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: 7c77d05d6ef09591fb3ca890eb20d256455501ebc819cfa3201649b6f438bcf1
name: python-certora-cli-beta
arch: src
version: 7.21.0
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-beta
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-beta-7.21.0-1.src.rpm
checksum_type: sha256
description:
  Commit 7756b14.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: a4064fa9f8b8e8daf9bfb871d6660b44d3f8293242d2849c0d1d035680e1c390
name: python-certora-cli-beta
arch: src
version: 7.21.1
epoch: 0
release: 1
summary: Runner for the Certora Prover
url: https://pypi.org/project/certora-cli-beta
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certora-cli-beta-7.21.1-1.src.rpm
checksum_type: sha256
description:
  Commit 03eae31.                    Build and Run scripts for executing the Certora Prover on Solidity smart contracts.


pkgId: 1155dc25c40f3b4c33f51a6a0fa9353149f635acf0357eae01ec6828cc047008
name: python-certpeek
arch: src
version: 2024.9.1
epoch: 0
release: 1
summary: Peeks at certificates exposed by other hosts.
url: https://github.com/magnuswatn/certpeek
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certpeek-2024.9.1-1.src.rpm
checksum_type: sha256
description:
  Certpeek peeks at the certificates exposed by SSL/TLS enabled hosts. Perfect for a quick look for debugging.

  And, it support tunneling through a HTTP proxy!

  <p align="center"><img width="707" alt="Certpeek in action" src="https://github.com/magnuswatn/certpeek/blob/main/certpeek.png?raw=true"></p>

  Usage:
  ```
  Usage: certpeek [OPTIONS] HOST

    Peeks at certificates exposed by other hosts.

  Options:
    --version          Show the version and exit.
    --proxy TEXT       Proxy to use.
    --servername TEXT  Custom SNI name to send in handshake.
    --no-servername    Do not send SNI in the handshake.
    --print-pem        Print certs in PEM format.
    --first-only       Only process the first retrieved cert.
    --openssl-format   Print cert info like OpenSSL.
    -h, --help         Show this message and exit.
  ```

  Install with pip:

  ```
  pip install certpeek
  ```

  or with pipx:
  ```
  pipx install certpeek
  ```

rpm_license:
  MIT License  Copyright (c) Magnus Watn  Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:  The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


pkgId: 6822c81c8cb76468c8bed3e38c3c6f8ae35900d6e0ce08c6220c006995c1287f
name: python-certspy
arch: src
version: 0.9.0
epoch: 0
release: 1
summary: A Python client for the crt.sh website to retrieve subdomains information
url: https://github.com/santosomar/certspy
rpm_license: BSD 3-Clause License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certspy-0.9.0-1.src.rpm
checksum_type: sha256
description:
  ![Python](https://img.shields.io/badge/python-3670A0?style=for-the-badge&logo=python&logoColor=ffdd54) ![Dependabot](https://img.shields.io/badge/dependabot-025E8C?style=for-the-badge&logo=dependabot&logoColor=white)

  CertSPY is a Python client for interfacing with the [crt.sh](https://crt.sh/) website, allowing users to retrieve information on subdomains from SSL certificate transparency logs.

  Certificate Transparency (CT) is an open framework aimed at improving the safety of SSL/TLS certificates by creating an open and auditable log of all certificates issued by certificate authorities. It allows for the detection of mistakenly or maliciously issued certificates. In the context of reconnaissance (recon), cybersecurity experts and ethical hackers can utilize CT logs as a rich source of information for mapping the internet landscape. They can extract data about the existence of subdomains of a target domain, revealing potential targets for further investigation or penetration testing. This kind of intel can be vital in identifying vulnerable endpoints, tracking the issuance of new certificates, and generally maintaining a strong security posture against potential cyber threats. The tool crafted in the script leverages CT logs accessible through the crt.sh platform to facilitate such recon efforts, aiding in the timely identification of potential security vulnerabilities.



  - Query subdomain information from crt.sh.
  - Support for wildcard and expired certificate queries.
  - Command-line interface for easy usage.
  - Option to save results to a file.
  - Ability to display only the common names of certificates.




  You can install CertSPY using the `pip` command:

  ```sh
  pip install certspy
  ```



  - Python 3.x
  - `requests` library



  You can use the client from the command line with the following syntax:

  ```sh
  certspy.py secretcorp.org
  ```

  This will query the crt.sh website for subdomains of `secretcorp.org` and pretty print the JSON output to the console.

  ```sh
  $ python3 certspy.py -h
  usage: certspy.py [-h] [--no-wildcard] [--include-expired] [--common-name-only] [--output OUTPUT] domain

      CertSPY: A Python client for the crt.sh website to retrieve subdomains information.
      Author: Omar Santos (@santosomar).

  positional arguments:
    domain                Domain to search for

  optional arguments:
    -h, --help            show this help message and exit
    --no-wildcard         Do not prepend a wildcard to the domain.
    --include-expired     Include expired certificates in the search.
    --common-name-only    Show only the hostnames in the common name field of the certificate.
    --output OUTPUT, -o OUTPUT
                          Save output to a JSON file. You need to specify the path and name of the output file.
  ```

  For example:

  ```sh
  $ certspy secretcorp.org
  [
      {
          "issuer_ca_id": 183267,
          "issuer_name": "C=US, O=Let's Encrypt, CN=R3",
          "common_name": "secretcorp.org",
          "name_value": "secretcorp.org",
          "id": 10254588889,
          "entry_timestamp": "2023-08-30T08:49:46.284",
          "not_before": "2023-08-30T07:49:06",
          "not_after": "2023-11-28T07:49:05",
          "serial_number": "046cb5a18ef41e26f9867cfdb61d28452047"
      },
      {
          "issuer_ca_id": 183267,
          "issuer_name": "C=US, O=Let's Encrypt, CN=R3",
          "common_name": "mail.secretcorp.org",
          "name_value": "mail.secretcorp.org",
          "id": 10039294064,
          "entry_timestamp": "2023-08-01T04:19:56.363",
          "not_before": "2023-08-01T03:19:55",
          "not_after": "2023-10-30T03:19:54",
          "serial_number": "049b42b3d9dfad81b882209188f2dd3416e4"
      },
      {
          "issuer_ca_id": 183267,
          "issuer_name": "C=US, O=Let's Encrypt, CN=R3",
          "common_name": "app1.secretcorp.org",
          "name_value": "app1.secretcorp.org",
          "id": 10038384450,
          "entry_timestamp": "2023-08-01T01:00:56.816",
          "not_before": "2023-08-01T00:00:56",
          "not_after": "2023-10-30T00:00:55",
          "serial_number": "046bbf0c4112b9c2a1a8b30d8e50c8050264"
      },
      {
          "issuer_ca_id": 183267,
          "issuer_name": "C=US, O=Let's Encrypt, CN=R3",
          "common_name": "app1.secretcorp.org",
          "name_value": "app1.secretcorp.org",
          "id": 10101930727,
          "entry_timestamp": "2023-08-01T01:00:56.476",
          "not_before": "2023-08-01T00:00:56",
          "not_after": "2023-10-30T00:00:55",
          "serial_number": "046bbf0c4112b9c2a1a8b30d8e50c8050264"
      },
      {
          "issuer_ca_id": 183267,
          "issuer_name": "C=US, O=Let's Encrypt, CN=R3",
          "common_name": "internal.secretcorp.org",
          "name_value": "internal.secretcorp.org",
          "id": 10139355714,
          "entry_timestamp": "2023-07-31T22:56:26.114",
          "not_before": "2023-07-31T21:56:25",
          "not_after": "2023-10-29T21:56:24",
          "serial_number": "04f8357ed61e079460ed7d0bdb767ac49652"
      },
      {
          "issuer_ca_id": 183267,
          "issuer_name": "C=US, O=Let's Encrypt, CN=R3",
          "common_name": "internal.secretcorp.org",
          "name_value": "internal.secretcorp.org",
          "id": 10101183289,
          "entry_timestamp": "2023-07-31T22:56:25.812",
          "not_before": "2023-07-31T21:56:25",
          "not_after": "2023-10-29T21:56:24",
          "serial_number": "04f8357ed61e079460ed7d0bdb767ac49652"
      },
      {
          "issuer_ca_id": 183267,
          "issuer_name": "C=US, O=Let's Encrypt, CN=R3",
          "common_name": "cloud.secretcorp.org",
          "name_value": "cloud.secretcorp.org",
          "id": 10138072059,
          "entry_timestamp": "2023-07-31T20:15:24.822",
          "not_before": "2023-07-31T19:15:24",
          "not_after": "2023-10-29T19:15:23",
          "serial_number": "03efca1ae2f0688ac75231e58a0401716f0f"
      },
      <output omitted for brevity>
  ]
  ```

  To show only the common names of the certificates, you can use the `--common-name-only` flag:

  ```sh
  $ certspy secretcorp.org --common-name-only
  [
      "secretcorp.org",
      "mail.secretcorp.org",
      "app1.secretcorp.org",
      "internal.secretcorp.org",
      "cloud.secretcorp.org",
      <output omitted for brevity>
  ]
  ```

  To save the results to a file, you can use the `--output` flag:

  ```sh
  $ certspy secretcorp.org --output results.json
  ```




  Feel free to fork the repository and submit pull requests. For bug reports and feature requests, please create an issue in the GitHub issue tracker.



  See [LICENSE](LICENSE) for more details.


pkgId: 7da2d713d9f871cc7a9d453202614618c95fb913b0f71f3bfe892432bbd6259c
name: python-certstream
arch: src
version: 1.12
epoch: 0
release: 1
summary: CertStream is a library for receiving certificate transparency list updates in real time.
url: https://github.com/CaliDog/certstream-python/
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-certstream-1.12-1.src.rpm
checksum_type: sha256
description:
  Certstream is a library to connect to the certstream network (certstream.calidog.io).

  It supports automatic reconnection when networks issues occur, and should be stable for long-running jobs.


pkgId: 3e57e1d08175c9a0dfaa9520fd53ace49a98bf1c9f18b17abfb2ad68162e1022
name: python-ceruleo
arch: src
version: 3.0.6
epoch: 0
release: 1
summary: Remaining useful life estimation utilities
url: https://github.com/lucianolorenti/ceruleo
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-ceruleo-3.0.6-1.src.rpm
checksum_type: sha256
description:
  [![Coverage Status](https://coveralls.io/repos/github/lucianolorenti/ceruleo/badge.svg?branch=main&service=github)](https://coveralls.io/github/lucianolorenti/ceruleo?branch=main)
  [![Documentation](https://img.shields.io/badge/documentation-dev-brightgreen)](https://lucianolorenti.github.io/ceruleo/)
  ![pypi](https://img.shields.io/pypi/v/ceruleo)
  ![python-version](https://img.shields.io/badge/python-3.8%20%7C%203.9%20%7C%203.10-blue)
  [![status](https://joss.theoj.org/papers/c879c234d7741885576ddc682416b41f/status.svg)](https://joss.theoj.org/papers/c879c234d7741885576ddc682416b41f)

  **CeRULeo** is a Python package that provides a flexible environment designed to make working with predictive maintenance task both easy and intuitive.

  It is recommended to use pip  for installation. Please make sure the latest version is installed:
  ```bash
  pip install ceruleo            # normal install
  pip install --upgrade ceruleo  # or update if needed
  ```
  Alternatively, you could clone and install it from the sources:
  ```bash
  git clone https://github.com/lucianolorenti/ceruleo.git
  cd ceruleo
  pip install .
  ```

  We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
  * Reporting a bug
  * Discussing the current state of the code
  * Submitting a fix
  * Proposing new features
  Please feel free to open an [issue](https://github.com/lucianolorenti/ceruleo/issues/new/choose) if you have any questions, find any bugs, or have any ideas.
  Further information on how to contribute can be found by clicking  [here](https://github.com/lucianolorenti/ceruleo/blob/main/CONTRIBUTING.md).
  Made with <3 @   <a href="https://www.dei.unipd.it/">
           <img alt="University of Padova" src="https://github.com/lucianolorenti/ceruleo/blob/main/docs/images/unipd_logo.png?raw=true" width=100 />
        </a>


pkgId: 0ca381a1a2d57fa26800e8ade9380062d6a8041cc642fe625fd3f81b0a47ab0f
name: python-cesloi
arch: src
version: 0.6.11
epoch: 0
release: 1
summary: An simple Python SDK base on mirai-api-http v2
url: https://github.com/RF-Tar-Railt/Cesloi
rpm_license: AGPL 3.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cesloi-0.6.11-1.src.rpm
checksum_type: sha256
description:
  |Licence| |PyPI| |PyPI - Python Version|
  一个简易(?)，基于
  ```mirai-api-http v2`` <https://github.com/project-mirai/mirai-api-http>`__
  的 Python SDK。
  **本项目适用于 mirai-api-http 2.0 以上版本**\ 。
  项目仍处于开发阶段，部分内容可能会有较大改变
  注: mirai-api-http 需要启用ws adapter和http adapter


pkgId: 6f3aa3983d731c009aa52041bf1aa35c2971dc86c84a3cff7641abee6a14a027
name: python-cesnet-datazoo
arch: src
version: 0.1.10
epoch: 0
release: 1
summary: A toolkit for large network traffic datasets
url: https://github.com/CESNET/cesnet-datazoo
rpm_license: BSD-3-Clause
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cesnet-datazoo-0.1.10-1.src.rpm
checksum_type: sha256
description:
  <p align="center">
      <img src="https://raw.githubusercontent.com/CESNET/cesnet-datazoo/main/docs/images/datazoo.svg" width="450">
  </p>

  [![](https://img.shields.io/badge/license-BSD-blue.svg)](https://github.com/CESNET/cesnet-datazoo/blob/main/LICENCE)
  [![](https://img.shields.io/badge/docs-cesnet--datazoo-blue.svg)](https://cesnet.github.io/cesnet-datazoo/)
  [![](https://img.shields.io/badge/python->=3.10-blue.svg)](https://pypi.org/project/cesnet-datazoo/)
  [![](https://img.shields.io/pypi/v/cesnet-datazoo)](https://pypi.org/project/cesnet-datazoo/)


  The goal of this project is to provide tools for working with large network traffic datasets and to facilitate research in the traffic classification area. The core functions of the `cesnet-datazoo` package are:

  - A common API for downloading, configuring, and loading of three public datasets of encrypted network traffic.
  - Extensive configuration options for:
      - Selection of train, validation, and test periods.
      - Selection of application classes and splitting classes between *known* and *unknown*.
      - Data transformations, such as feature scaling.
  - Built on suitable data structures for experiments with large datasets. There are several caching mechanisms to make repeated runs faster, for example, when searching for the best model configuration.
  - Datasets are offered in multiple sizes to give users an option to start the experiments at a smaller scale (also faster dataset download, disk space, etc.). The default is the `S` size containing 25 million samples.

  :brain: :brain: See a related project [CESNET Models](https://github.com/CESNET/cesnet-models) providing pre-trained neural networks for traffic classification. :brain: :brain:

  :notebook: :notebook: Example Jupyter notebooks are included in a separate [CESNET Traffic Classification Examples](https://github.com/CESNET/cesnet-tcexamples) repo. :notebook: :notebook:


  The `cesnet-datazoo` package currently provides three datasets with details in the following table (you might need to scroll the table horizontally to see all datasets).

  1. CESNET-TLS22
  2. CESNET-QUIC22
  3. CESNET-TLS-Year22

  | Name                               | CESNET-TLS22                                                                                                                                                                                   | CESNET-QUIC22                                                                                                                                             | CESNET-TLS-Year22                                                                                                                                                                              |
  | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | _Protocol_                         | TLS                                                                                                                                                                                            | QUIC                                                                                                                                                      | TLS                                                                                                                                                                                            |
  | _Published in_                     | 2022                                                                                                                                                                                           | 2023                                                                                                                                                      | 2023                                                                                                                                                                                           |
  | _Collection duration_              | 2 weeks                                                                                                                                                                                        | 4 weeks                                                                                                                                                   | 1 year                                                                                                                                                                                         |
  | _Collection period_                | 4.10.2021 - 17.10.2021                                                                                                                                                                         | 31.10.2022 - 27.11.2022                                                                                                                                   | 1.1.2022 - 31.12.2022                                                                                                                                                                          |
  | _Application count_                | 191                                                                                                                                                                                            | 102                                                                                                                                                       | 180                                                                                                                                                                                            |
  | _Available samples_                | 141392195                                                                                                                                                                                      | 153226273                                                                                                                                                 | 507739073                                                                                                                                                                                      |
  | _Available dataset sizes_          | XS, S, M, L                                                                                                                                                                                    | XS, S, M, L                                                                                                                                               | XS, S, M, L                                                                                                                                                                                    |
  | _Cite_                             | [https://doi.org/10.1016/j.comnet.2022.109467](https://doi.org/10.1016/j.comnet.2022.109467)                                                                                                   | [https://doi.org/10.1016/j.dib.2023.108888](https://doi.org/10.1016/j.dib.2023.108888)                                                                    | [https://doi.org/10.1038/s41597-024-03927-4](https://doi.org/10.1038/s41597-024-03927-4)                                                                                                       |
  | _Zenodo URL_                       | [https://zenodo.org/record/7965515](https://zenodo.org/record/7965515)                                                                                                                         | [https://zenodo.org/record/7963302](https://zenodo.org/record/7963302)                                                                                    | [https://zenodo.org/records/10608607](https://zenodo.org/records/10608607)                                                                                                                     |
  | _Related papers_                   |                                                                                                                                                                                                | [https://doi.org/10.23919/TMA58422.2023.10199052](https://doi.org/10.23919/TMA58422.2023.10199052)                                                        |                                                                                                                                                                                                |



  Install the package from pip with:

  ```bash
  pip install cesnet-datazoo
  ```

  or for editable install with:

  ```bash
  pip install -e git+https://github.com/CESNET/cesnet-datazoo
  ```




  ```py
  from cesnet_datazoo.datasets import CESNET_QUIC22
  from cesnet_datazoo.config import DatasetConfig, AppSelection

  dataset = CESNET_QUIC22("/datasets/CESNET-QUIC22/", size="XS")
  dataset_config = DatasetConfig(
      dataset=dataset,
      apps_selection=AppSelection.ALL_KNOWN,
      train_period_name="W-2022-44",
      test_period_name="W-2022-45",
  )
  dataset.set_dataset_config_and_initialize(dataset_config)
  train_dataframe = dataset.get_train_df()
  val_dataframe = dataset.get_val_df()
  test_dataframe = dataset.get_test_df()
  ```

  The [`DatasetConfig`](https://cesnet.github.io/cesnet-datazoo/reference_dataset_config/) class handles the configuration of datasets, and calling `set_dataset_config_and_initialize` initializes train, validation, and test sets with the desired configuration.
  Data can be read into Pandas DataFrames as shown here or via PyTorch DataLoaders. See [`CesnetDataset`](https://cesnet.github.io/cesnet-datazoo/reference_cesnet_dataset/) reference.

  See more examples in the [documentation](https://cesnet.github.io/cesnet-datazoo/getting_started/).



  * [DataZoo: Streamlining Traffic Classification Experiments](https://doi.org/10.1145/3630050.3630176) <br>
  Jan Luxemburk and Karel Hynek <br>
  CoNEXT Workshop on Explainable and Safety Bounded, Fidelitous, Machine Learning for Networking (SAFE), 2023



  This project was supported by the Ministry of the Interior of the Czech Republic, grant No. VJ02010024: Flow-Based Encrypted Traffic Analysis.


pkgId: ba73089145007f1bb6e9cf4cb285e4332316bcca723ced554605748b3496a68c
name: python-cesnet-models
arch: src
version: 0.3.0
epoch: 0
release: 1
summary: Pre-trained neural networks for encrypted traffic classification
url: https://github.com/CESNET/cesnet-models
rpm_license: BSD-3-Clause
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cesnet-models-0.3.0-1.src.rpm
checksum_type: sha256
description:
  <p align="center">
      <img src="https://raw.githubusercontent.com/CESNET/cesnet-models/main/docs/images/models.svg" width="450">
  </p>

  [![](https://img.shields.io/badge/license-BSD-blue.svg)](https://github.com/CESNET/cesnet-models/blob/main/LICENCE)
  [![](https://img.shields.io/badge/docs-cesnet--models-blue.svg)](https://cesnet.github.io/cesnet-models/)
  [![](https://img.shields.io/badge/python->=3.10-blue.svg)](https://pypi.org/project/cesnet-models/)
  [![](https://img.shields.io/pypi/v/cesnet-models)](https://pypi.org/project/cesnet-models/)


  The goal of this project is to provide neural network architectures for traffic classification and their pre-trained weights.

  The newest network architecture is named Multi-modal CESNET v2 (mm-CESNET-v2) and is visualized in the following picture. See the [getting started](https://cesnet.github.io/cesnet-models/getting_started/) page and [models](https://cesnet.github.io/cesnet-models/reference_models/) reference for more information.

  :frog: :frog: See a related project [CESNET DataZoo](https://github.com/CESNET/cesnet-datazoo) providing large TLS and QUIC traffic datasets. :frog: :frog:

  :notebook: :notebook: Example Jupyter notebooks are included in a separate [CESNET Traffic Classification Examples](https://github.com/CESNET/cesnet-tcexamples) repo. :notebook: :notebook:


  <p align="center">
      <img src="https://raw.githubusercontent.com/CESNET/cesnet-models/main/docs/images/model-mm-cesnet-v2.png" width="450">
  </p>



  Install the package from pip with:

  ```bash
  pip install cesnet-models
  ```

  or for editable install with:

  ```bash
  pip install -e git+https://github.com/CESNET/cesnet-models
  ```



  Models from the following papers are included:

  * [Fine-grained TLS services classification with reject option](https://doi.org/10.1016/j.comnet.2022.109467) <br>
  Jan Luxemburk and Tomáš Čejka <br>
  Computer Networks, 2023

  * [Encrypted traffic classification: the QUIC case](https://doi.org/10.23919/TMA58422.2023.10199052) <br>
  Jan Luxemburk and Karel Hynek <br>
  2023 7th Network Traffic Measurement and Analysis Conference (TMA)


pkgId: bd38716ec70c86b1a3469751e98e03d263fdda9eff438b53b06221ca5146cfa0
name: python-ceviche
arch: src
version: 0.1.3
epoch: 0
release: 1
summary: Ceviche
url: https://github.com/fancompute/ceviche
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-ceviche-0.1.3-1.src.rpm
checksum_type: sha256
description:
  Electromagnetic Simulation Tools + Automatic Differentiation.  Code for paper [Forward-Mode Differentiation of Maxwell's Equations](https://arxiv.org/abs/1908.10507).

  <img src="/img/horizontal-color.png" title="ceviche" alt="ceviche">



  `ceviche` provides two core electromagnetic simulation tools for solving Maxwell's equations:

  - finite-difference frequency-domain (FDFD)

  - finite-difference time-domain (FDTD)

  Both are written in `numpy` / `scipy` and are compatible with the [HIPS autograd package](https://github.com/HIPS/autograd), supporting forward-mode and reverse-mode automatic differentiation.

  This allows you to write code to solve your E&M problem, and then use automatic differentiation on your results.

  As a result, you can do gradient-based optimization, sensitivity analysis, or plug your E&M solver into a machine learning model without having to go through the tedious process of deriving your derivatives by hand.



  There is a comprehensive ceviche tutorial available at [this link](https://github.com/fancompute/workshop-invdesign) with several ipython notebook examples:
  1. [Running FDFD simulations in ceviche.](https://nbviewer.jupyter.org/github/fancompute/workshop-invdesign/blob/master/01_First_simulation.ipynb)
  2. [Performing inverse design of a mode converter.](https://nbviewer.jupyter.org/github/fancompute/workshop-invdesign/blob/master/02_Invdes_intro.ipynb)
  3. [Adding fabrication constraints and device parameterizations.](https://nbviewer.jupyter.org/github/fancompute/workshop-invdesign/blob/master/03_Invdes_parameterization.ipynb)
  4. [Inverse design of a wavelength-division multiplexer and advanced topics.](https://nbviewer.jupyter.org/github/fancompute/workshop-invdesign/blob/master/04_Invdes_wdm_scheduling.ipynb)

  There are also a few examples in the `examples/*` directory.



  There are many ways to install `ceviche`.

  The easiest is by

      pip install ceviche

  But to install from a local copy, one can instead do

      git clone https://github.com/twhughes/ceviche.git
      pip install -e ceviche
      pip install -r ceviche/requirements.txt

  from the main directory.

  Alternatively, just download it:

      git clone https://github.com/twhughes/ceviche.git

  and then import the package from within your python script

  ```python
  import sys
  sys.path.append('path/to/ceviche')
  ```





  The `ceviche` directory contains everything needed.

  To get the FDFD and FDTD simulators, import directly `from ceviche import fdtd, fdfd_ez, fdfd_hz`

  To get the differentiation, import `from ceviche import jacobian`.

  `constants.py` contains some constants `EPSILON_0`, `C_0`, `ETA_0`, `Q_E`, which are needed throughout the package

  `utils.py` contains a few useful functions for plotting, autogradding, and various other things.

  `optimizers.py` contains optimizer functions for doing inverse design.

  `viz.py` are functions that help with plotting fields and sructures.

  `modes.py` contains a mode sorter (WIP) that can be used to create waveguide mode profiles for the simulation, for example.



  There are many demos in the `examples` directory, which will give you a good sense of how to use the package.



  Tests are located in `tests`.  To run, `cd` into `tests` and

      python -m unittest

  to run all or

      python specific_test.py

  to run a specific one.  Some of these tests involve visual inspection of the field plots rather than error checking on values.

  To run all of the gradient checking functions, run

      chmod +x test/test_all_gradients.sh
      tests/test_all_gradients.sh



  If you use this for your research or work, please cite

      @article{hughes2019forward,
        title={Forward-Mode Differentiation of Maxwell’s Equations},
        author={Hughes, Tyler W and Williamson, Ian AD and Minkov, Momchil and Fan, Shanhui},
        journal={ACS Photonics},
        volume={6},
        number={11},
        pages={3010--3016},
        year={2019},
        publisher={ACS Publications}
      }

  Our logo was created by [@nagilmer](http://nadinegilmer.com/)


pkgId: aa7320474e4b0ee4b251d82e4288a9fc2e5b3f70a5cd64f0bb2cf7c803686a17
name: python-cexprtk
arch: src
version: 0.4.1
epoch: 0
release: 1
url: https://github.com/mjdrushton/cexprtk
rpm_license: CPL
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cexprtk-0.4.1-1.src.rpm
checksum_type: sha256
summary:
  Mathematical expression parser: cython wrapper around the 'C++ Mathematical Expression Toolkit Library'

description:
  For information about expressions supported by `cexprtk` please refer to the original C++ [ExprTK][] documentation:


  Class representing mathematical expression.
  * Following instantiation, the expression is evaluated calling the expression or invoking its `value()` method.
  * The variable values used by the Expression can be modified through the `variables` property of the `Symbol_Table` instance associated with the expression. The `Symbol_Table` can be accessed using the `Expression.symbol_table` property.

  The `unknown_symbol_resolver_callback` argument  to the `Expression`
  constructor accepts a callable which is invoked  whenever a symbol (i.e. a
  variable or a constant), is not found in the `Symbol_Table` given by the
  `symbol_table` argument. The `unknown_symbol_resolver_callback` can be
  used to provide a value for the missing value or to set an error condition.
  The callable should have following signature:
  ```python
  	def callback(symbol_name):
  ```
  Where `symbol_name` is a string identifying the missing symbol.
  The callable should return a tuple of the form:
  ```python
  	(HANDLED_FLAG, USR_SYMBOL_TYPE, SYMBOL_VALUE, ERROR_STRING)
  ```
  Where:
  * `HANDLED_FLAG` is a boolean:
  	+ `True` indicates that callback was able handle the error condition and that `SYMBOL_VALUE` should be used for the missing symbol.
  	+ `False`, flags and error condition, the reason why the unknown symbol could not be resolved by the callback is described by `ERROR_STRING`.
  * `USR_SYMBOL_TYPE` gives type of symbol (constant or variable) that should be added to the `symbol_table` when unkown symbol is resolved. Value should be one of those given in `cexprtk.USRSymbolType`. e.g.
  	+ `cexprtk.USRSymbolType.VARIABLE`
  	+ `cexprtk.USRSymbolType.CONSTANT`
  * `SYMBOL_VALUE`, floating point value that should be used when resolving missing symbol.
  * `ERROR_STRING` when `HANDLED_FLAG` is `False` this can be used to describe error condition.

  Instantiate `Expression` from a text string giving formula and `Symbol_Table`
  instance encapsulating variables and constants used by the expression.
  __Parameters:__
  * __expression__ (*str*) String giving expression to be calculated.
  * __symbol_table__ (*Symbol_Table*) Object defining variables and constants.
  * __unknown_symbol_resolver_callback__ (*callable*)  See description above.

  If an expression contains a `return []` statement, the returned values are accessed using this method.
  A python list is returned which may contain real values, strings or vectors.
  **Note:** the expression should be evaluated by calling `value()` before trying to access results.
  __Returns:__
  * (*list*) List of values produced by expression's `return` statement.

  Evaluate expression using variable values currently set within associated `Symbol_Table`
  __Returns:__
  * (*float*) Value resulting from evaluation of expression.

  Equivalent to calling `value()` method.
  __Returns:__
  * (*float*) Value resulting from evaluation of expression.

  Read only property that returns `Symbol_Table` instance associated with this expression.
  __Returns:__


pkgId: 96466919a36b71240a56df982666a11ade2ae95e83f57231056055045b481cd5
name: python-cf-api
arch: src
version: 1.0.0
epoch: 0
release: 1
summary: Python Interface for Cloud Foundry APIs
url: https://github.com/hsdp/python-cf-api
rpm_license: Apache License Version 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cf-api-1.0.0-1.src.rpm
checksum_type: sha256
description:
  This module provides a pure Python interface to the Cloud Foundry APIs.



  You can install from PIP

  `pip install cf-api`

  or view it on [PyPI](https://pypi.python.org/pypi/cf_api).



  See the docs at [https://cf-api.readthedocs.io/en/latest/](https://cf-api.readthedocs.io/en/latest/) or in the [./docs](docs) directory and the [./examples](examples) directory.



  *Version 1.x*
  - Support both Python 2.7/3.6-3.8
  - Remove `cf_api.dropsonde` module in favor of the `dropsonde` module.
  - Add CF API version 3 support
  - Add `Dockerfile` example

  *Version 0.x*
  - Supports Python 2.7



  The following examples should be enough to get you started using this library.

  ```python


  from getpass import getpass
  import cf_api
  import json

  cloud_controller = 'https://api.yourcloudfoundry.com'
  deploy_client_id = 'cf'
  deploy_client_secret = ''
  verify_ssl = True
  username = 'youser'
  password = getpass('Password: ').strip()

  cc = cf_api.new_cloud_controller(
      cloud_controller,
      client_id=deploy_client_id,
      client_secret=deploy_client_secret,
      username=username,
      password=password,
  ).set_verify_ssl(verify_ssl)



  req = cc.organizations()
  res = req.get()
  orgs = res.resources
  for r in orgs:
      print('org', r.guid, r.name)



  res = cc.spaces().get()
  spaces = res.resources
  for r in spaces:
      print('space', r.guid, r.name)




  res = cc.apps().get()
  apps = res.resources
  for r in apps:
      print('app', r.guid, r.name)




  org_name = 'your_org'
  space_name = 'your_space'
  app_name = 'your_app'


  res = cc.organizations().get_by_name(org_name)

  your_org = res.resource


  res = cc.request(your_org.spaces_url).get_by_name(space_name)
  your_space = res.resource


  res = cc.request(your_space.apps_url).get_by_name(app_name)
  your_app = res.resource
  print('your_app', your_app)







  res = cc.apps(your_app.guid).get()


  your_same_app = res.resource
  print('your_same_app', your_same_app)



  your_stack = 'some_stack'
  res = cc.stacks().get_by_name(your_stack)
  stack = res.resource



  your_buildpack = 'some_buildpack'
  command = 'python server.py'
  res = cc.apps().set_params(
      name=app_name,
      space_guid=your_space.guid,
      stack_guid=stack.guid,
      buildpack=your_buildpack,
      command=command,
      health_check_type='port',
      health_check_timeout=60,
      instances=2,
      memory=512,
      disk_quota=512
  ).post()
  print('new app', res.data)



  my_zipfile = '/tmp/app.zip'
  with open(my_zipfile, 'r') as f:
      res = cc.apps(your_app.guid, 'bits')\
          .set_query(async='true')\
          .add_field('resources', json.dumps([]))\
          .add_file('application', 'application.zip', f, 'application/zip')\
          .put()
      print(res.data)
  ```



  To get start running `cf_api` in Docker, just build the provided [Dockerfile](./Dockerfile)

  ```
  you@yourhost:~/python-cf-api$ docker build -t python-cf-api:latest .
  ```

  and run it using the following syntax.

  ```
  you@yourhost:~/python-cf-api$ docker run --rm -it -v $PWD:/src -w /src python-cf-api:latest python3
  Python 3.8.1
  [GCC 9.2.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import cf_api
  >>> # play with it here
  ```



  The following example shows how to use the Cloud Foundry version 3 API.

  ```python
  import cf_api

  cc = cf_api.new_cloud_controller()
  req = cc.v3.apps()
  res = req.get()
  print(res.resource.guid)
  ```

  - The `cc.v3` attribute returns a `CloudController` instance that is configured
    to wrap requests and responses in V3 compatible classes, namely `V3CloudControllerRequest`
    and `V3CloudControllerResponse`. These objects work similarly to their v2 counterparts,
    `CloudControllerRequest` and `CloudControllerResponse`.
  - The `V3CloudControllerResponse` provides `resource` and `resources` which return
    an instance or list of instances of `V3Resource` objects which support the
    common API object keys such as `name`, `guid`, `space_guid`, and `org_guid`, etc.
  - The `cc.v3.get_all_resources()` function supports both v2 and v3 pagination.
  - The `cc.v3.request()` function supports _both_ relative URLs and absolute URLs,
    for example `/v3/apps` and `http://localhost/v3/apps`, respectively. See `request()`
    function documentation for more information.



  The library is also configurable via environment variables.

  | Variable | Description |
  | --- | --- |
  | `PYTHON_CF_URL` | This is the cloud controller base URL. **Do not include a trailing slash on the URL.**
  | `PYTHON_CF_CLIENT_ID` | This is the UAA client ID the library should use.
  | `PYTHON_CF_CLIENT_SECRET` | This is the UAA client secret the library should use.
  | `PYTHON_CF_IGNORE_SSL` | This indicates whether to verify SSL certs. Default is false. Set to `true` to ignore SSL verification.
  | `CF_DOCKER_PASSWORD` | This variable optionally provides the Docker user's password if a docker image is being used. This variable is not necessarily required to use a docker image.

  An example library usage with these variables set would look like this:

  ```python





  import cf_api


  cc = cf_api.new_cloud_controller()
  res = cc.apps().get()



  uaa = cf_api.new_uaa()

  ```



  The following functions may be used to implement login with Cloud Foundry via Authorization Codes.

  The function `get_openid_connect_url()` shows how to build UAA URL to which the user can be
  redirected in order to log in.

  The function `verify_code()` can be used when the user successfully logs in and UAA redirects back
  to redirect_uri with the `code` attached. Pass the code and original redirect_uri into this function
  in order to get the OAuth2 Token and to also verify the signature of the JWT.

  This particular example applies to OpenID Connect.

  ```python
  import cf_api

  cc = 'https://api.yourcloudfoundry.com'
  client_id = 'yourclient'
  client_secret = 'yoursecret'
  response_type = 'code'

  def get_openid_connect_url(redirect_uri):
      return cf_api\
          .new_uaa(cc=cc, client_id=client_id, client_secret=client_secret, no_auth=True)\
          .authorization_code_url(response_type, scope='openid', redirect_uri=redirect_uri)


  def verify_code(code, redirect_uri):
      uaa = cf_api.new_uaa(cc=cc, client_id=client_id, client_secret=client_secret, no_auth=True)
      res = uaa.authorization_code(code, response_type, redirect_uri)
      data = res.data
      uaa.verify_token(data['id_token'], audience=uaa.client_id)
      return data
  ```



  The `cf_api.deploy_manifest` module may be used to deploy a Cloud Foundry app. The
  following snippet demonstrates the usage for deploying an app.

  ```bash
  cd path/to/your/project
  python -m cf_api.deploy_manifest \
    --cloud-controller https://api.yourcloudfoundry.com \
    -u youser -o yourg -s yourspace \
    -m manifest.yml -v -w



  ```

  This module may also be used programmatically.

  ```python
  from __future__ import print_function
  import cf_api
  from getpass import getpass
  from cf_api.deploy_manifest import Deploy

  cc = cf_api.new_cloud_controller(
      'https://api.yourcloudfoundry.com',
      username='youruser',
      password=getpass().strip(),
      client_id='cf',
      client_secret='',
      verify_ssl=True
  )

  manifest_filename = 'path/to/manifest.yml'

  apps = Deploy.parse_manifest(manifest_filename, cc)

  for app in apps:
      app.set_debug(True)
      app.set_org_and_space('yourorg', 'yourspace')
      print (app.push())
      
  ```



  The `cf_api.deploy_service` module may be used to deploy a Cloud Foundry service to a space. The
  following snippet demonstrates the usage for deploying a service.

  ```bash
  cd path/to/your/project
  python -m cf_api.deploy_service \
    --cloud-controller https://api.yourcloudfoundry.com \
    -u youser -o yourg -s yourspace \
    --name your-custom-service-name --service-name cf-service-type \
    --service-plan cf-service-type-plan -v -w
  ```

  This module may also be used programmatically.

  ```python
  from __future__ import print_function
  import cf_api
  from getpass import getpass
  from cf_api.deploy_service import DeployService

  cc = cf_api.new_cloud_controller(
      'https://api.yourcloudfoundry.com',
      username='youruser',
      password=getpass().strip(),
      client_id='cf',
      client_secret='',
      verify_ssl=True
  )

  service = DeployService(cc)\
      .set_debug(True)\
      .set_org_and_space('yourorg', 'yourspace')

  result = service.create('my-custom-db', 'database-service', 'small-database-plan')
  print(result)
  ```



  The `cf_api.deploy_space` module provides a convenience interface for working with Cloud Foundry
  spaces. The module provides read-only (i.e. GET requests only) support for the Cloud Controller API
  endpoints scoped to a specific space i.e. /v2/spaces/<space_guid>/(routes|service_instances|apps).
  The following snippet demonstrates the usage for listing apps for in a space.

  ```bash
  cd path/to/your/project
  python -m cf_api.deploy_space \
    --cloud-controller https://api.yourcloudfoundry.com \
    -u youser -o yourg -s yourspace apps
  ```

  This module may also be used programmatically.

  ```python
  from __future__ import print_function
  import cf_api
  from getpass import getpass
  from cf_api.deploy_space import Space

  cc = cf_api.new_cloud_controller(
      'https://api.yourcloudfoundry.com',
      username='youruser',
      password=getpass().strip(),
      client_id='cf',
      client_secret='',
      verify_ssl=True
  )

  space = Space(cc, org_name='yourorg', space_name='yourspace')


  space.create()


  space.destroy()


  apps_in_the_space = space.request('apps').get()


  space.deploy_manifest('/path/to/manifest.yml') # push the app
  space.wait_manifest('/path/to/manifest.yml') # wait for the app to start
  space.destroy_manifest('/path/to/manifest.yml') # destroy the app

  app = space.get_app_by_name('yourappname') # find an application by its name within the space


  space.get_deploy_service().create('my-custom-db', 'database-service', 'small-database-plan')
  service = space.get_service_instance_by_name('my-custom-db') # find a service by its name within the space
  ```



  The `cf_api.logs_util` module may be used to tail Cloud Foundry application logs. Both
  `recentlogs` and `stream` modes are supported. The following snippet demonstrates the usage for
  listing recent logs and tailing app logs simultaneously.

  ```bash
  cd path/to/your/project
  python -m cf_api.logs_util \
    --cloud-controller https://api.yourcloudfoundry.com \
    -u youser -o yourg -s yourspace -a yourapp \
    -r -t
  ```

  This module may also be used programmatically.

  ```python
  from __future__ import print_function
  import cf_api
  from getpass import getpass
  from cf_api import dropsonde_util

  cc = cf_api.new_cloud_controller(
      'https://api.yourcloudfoundry.com',
      username='youruser',
      password=getpass().strip(),
      client_id='cf',
      client_secret='',
      verify_ssl=True,
      init_doppler=True
  )

  app_guid = 'your-app-guid'
  app = cc.apps(app_guid).get().resource


  logs = cc.doppler.apps(app.guid, 'recentlogs').get().multipart


  logs = [dropsonde_util.parse_envelope_protobuf(log) for log in logs]

  print(logs)


  ws = cc.doppler.ws_request('apps', app.guid, 'stream')
  try:
      ws.connect()
      ws.watch(lambda m: print(dropsonde_util.parse_envelope_protobuf(m)))
  except Exception as e:
      print(e)
  finally:
      ws.close()
  ```


pkgId: a29bbc7bfdf175695cc15cd0f26834376705f7f8297517588135177c950416ed
name: python-cf-changelog
arch: src
version: 1.0.6
epoch: 0
release: 1
summary: Conflict-Free Changelog manager
url: https://gitlab.com/salekpawel/cf_changelog
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cf-changelog-1.0.6-1.src.rpm
checksum_type: sha256
description:
  Simple tool to support changelog modifications on different git branches without conflicts on merging.
  Written in python, installable with pip.


  1. Install it from pip:
  ```bash
  pip install cf_changelog
  ```
  2. Create some changelog on different branches entries using:
  ```bash
  cf_changelog add
  ```
  It is required to run this from root of your repository.
  This will invoke standard text editor (or notepad/vim if standard editor is not configured), where you can fill a template with new features, bug fixes etc.

  Windows example:

  ![Windows_example of editor with changelog entry](img/windows_template_screenshot.png)

  This is simple yaml format. You can use as many types of entries as you wish (New, Bugfix, Changed, Fixed, etc.). Each type should contain a flat list.
  The most important thing is that you don't have to remember anything specific related to this tool, just fill in a template.

  3. Commit newly created files.
  4. Repeat 2 and 3 on different branches as many times as you need.
  5. Merge all branches.
  6. On merged branch run:

  ```bash
  cf_changelog release X.Y.Z
  ```
  where X.Y.Z is description of version you want to see in final changelog.

  7. Commit registered changes in git repository (by default: Changelog.md and changelog directory).
  8. Enjoy your updated changelog.


    - `add` command creates files with unique names by default in changelog/sources. Since file names are unique there will be no conflict on merge.
    - `release` command parses those "source" files and adds them on the begining of Changelog.md. Then copies "source" files to "archive" just to keep them in history.
  Those commands calls `git add` on created and modified files to remind you that you have to commit them.


    - Manual tests on Windows passed
    - Manual tests on Ubuntu passed


pkgId: 2986d56bede498bdcffc1c560fd032338125bfbb1d1314fbf7040b44056b40a9
name: python-cf-deploy
arch: src
version: 0.1.52
epoch: 0
release: 1
summary: A package to automate CloudFormation deployments
url: https://pypi.org/project/cf-deploy/
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cf-deploy-0.1.52-1.src.rpm
checksum_type: sha256
description:
  cf-deploy is a package to automate CloudFormation deployments. It simplifies the deployment process by allowing you to use YAML configuration files to define your stack parameters and resources.

  Features:
  - Merge multiple configuration files to create a single CloudFormation stack
  -


  To install cf-deploy, run the following command:

  ```bash
  pip install cf-deploy
  ```

  To use cf-deploy, create a YAML configuration file with your CloudFormation stack settings. You can use a base configuration file to define common settings and override or extend them with environment-specific configuration files.

  Here's a sample base configuration file, base.yaml:

  ```yaml
  region: us-west-2
  template: s3://my-bucket/my-template.yaml
  deployment_stages:
    - dev
    - prod
  ```
  And a sample environment-specific configuration file, dev.yaml:

  ```yaml
  name: my-stack-dev
  prefix: dev-
  parameters:
    Stage: dev
    InstanceType: t2.micro
  ```


  To deploy a CloudFormation stack using cf-deploy, run the following command:

  ```bash
  cf-deploy -b base.yaml -c dev.yaml
  ```

  This command will merge the base configuration file (base.yaml) with the environment-specific configuration file (dev.yaml) and deploy the resulting CloudFormation stack.


pkgId: 9098e389c88b2a473d323e379bc32c0cdab62cc01970e1c1d18d969a69a1cb81
name: python-cf-ips-to-hcloud-fw
arch: src
version: 1.0.14
epoch: 0
release: 1
summary: Update Hetzner Cloud firewall rules with Cloudflare IP ranges
url: https://github.com/jkreileder/cf-ips-to-hcloud-fw
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cf-ips-to-hcloud-fw-1.0.14-1.src.rpm
checksum_type: sha256
description:
  [![codecov](https://codecov.io/gh/jkreileder/cf-ips-to-hcloud-fw/graph/badge.svg?token=PCP1F2XWAT)](https://codecov.io/gh/jkreileder/cf-ips-to-hcloud-fw)
  [![OpenSSF Best Practices](https://www.bestpractices.dev/projects/8275/badge)](https://www.bestpractices.dev/projects/8275)
  [![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/jkreileder/cf-ips-to-hcloud-fw/badge)](https://scorecard.dev/viewer/?uri=github.com/jkreileder/cf-ips-to-hcloud-fw)
  [![CodeQL](https://github.com/jkreileder/cf-ips-to-hcloud-fw/actions/workflows/codeql.yaml/badge.svg)](https://github.com/jkreileder/cf-ips-to-hcloud-fw/actions/workflows/codeql.yaml)
  [![Python package](https://github.com/jkreileder/cf-ips-to-hcloud-fw/actions/workflows/python-package.yaml/badge.svg)](https://github.com/jkreileder/cf-ips-to-hcloud-fw/actions/workflows/python-package.yaml)
  [![Docker build](https://github.com/jkreileder/cf-ips-to-hcloud-fw/actions/workflows/docker.yaml/badge.svg)](https://github.com/jkreileder/cf-ips-to-hcloud-fw/actions/workflows/docker.yaml)
  [![PyPI - Version](https://img.shields.io/pypi/v/cf-ips-to-hcloud-fw)](https://pypi.org/project/cf-ips-to-hcloud-fw/)
  [![PyPI - Python Version](https://img.shields.io/pypi/pyversions/cf-ips-to-hcloud-fw?logo=python)](https://pypi.org/project/cf-ips-to-hcloud-fw/)

  This tool, `cf-ips-to-hcloud-fw`, helps you keep your Hetzner Cloud firewall
  rules up-to-date with the current Cloudflare IP ranges.



  - [Overview](#overview)
  - [Installation](#installation)
    - [Using Python](#using-python)
      - [Using pipx (Recommended)](#using-pipx-recommended)
      - [Using pip](#using-pip)
    - [Docker and Kubernetes](#docker-and-kubernetes)
  - [Configuration](#configuration)
    - [Preparing the Hetzner Cloud Firewall](#preparing-the-hetzner-cloud-firewall)
    - [Configuring the Application](#configuring-the-application)



  `cf-ips-to-hcloud-fw` fetches the current [Cloudflare IP
  ranges](https://www.cloudflare.com/ips/) and updates your Hetzner Cloud firewall
  rules using the [hcloud
  API](https://docs.hetzner.cloud/#firewall-actions-set-rules).

  The tool specifically targets **incoming** firewall rules and **replaces** the
  networks with Cloudflare networks if their description contains
  `__CLOUDFLARE_IPS_V4__`, `__CLOUDFLARE_IPS_V6__` or `__CLOUDFLARE_IPS__`.

  | Text in rule description | Cloudflare IP ranges |
  | ------------------------ | -------------------- |
  | `__CLOUDFLARE_IPS_V4__`  | IPv4 only            |
  | `__CLOUDFLARE_IPS_V6__`  | IPv6 only            |
  | `__CLOUDFLARE_IPS__`     | IPv4 + IPv6          |

  Note: Having both `__CLOUDFLARE_IPS_V4__` and `__CLOUDFLARE_IPS_V6__` in a rule
  description is equivalent to having `__CLOUDFLARE_IPS__` there.





  To install `cf-ips-to-hcloud-fw` using Python, we recommend using
  [`pipx`](https://pipx.pypa.io/).  `pipx` is a tool for installing and running
  Python applications in isolated environments.



  1. Install `cf-ips-to-hcloud-fw` using pipx:

      ```shell
      pipx install cf-ips-to-hcloud-fw
      ```

  2. Verify the installation:

      ```shell
      cf-ips-to-hcloud-fw -h
      ```

  You should see the usage information for `cf-ips-to-hcloud-fw`.

  To upgrade `cf-ips-to-hcloud-fw`, run:

  > [!TIP]
  > To upgrade `cf-ips-to-hcloud-fw`, run `pipx upgrade cf-ips-to-hcloud-fw`.



  We strongly recommend using a virtual environment when installing Python
  packages with pip. This helps to avoid conflicts between packages and allows you
  to manage packages on a per-project basis.

  1. Create a virtual environment:

      ```shell
      python3 -m venv cf-ips-to-hcloud-fw-venv
      ```

  2. Install `cf-ips-to-hcloud-fw` into the virtual environment:

      ```shell
      ./cf-ips-to-hcloud-fw-venv/bin/pip3 install cf-ips-to-hcloud-fw
      ```

  3. Verify the installation:

      ```shell
      ./cf-ips-to-hcloud-fw-venv/bin/cf-ips-to-hcloud-fw -h
      ```

  You should see the usage information for `cf-ips-to-hcloud-fw`.

  > [!TIP]
  > To upgrade `cf-ips-to-hcloud-fw` in your virtual environment, run
  > `./cf-ips-to-hcloud-fw-venv/bin/pip3 install --upgrade cf-ips-to-hcloud-fw`.



  As an alternative, `cf-ips-to-hcloud-fw` can be run using Docker or a Kubernetes
  CronJob.  Simply mount your configuration file as `/usr/src/app/config.yaml`.

  Here's an example using Docker:

  ```shell
  docker run --rm \
    --mount type=bind,source=$(pwd)/config.yaml,target=/usr/src/app/config.yaml,readonly \
    jkreileder/cf-ips-to-hcloud-fw:1.0.14
  ```

  (Add `--pull=always` if you use a rolling image tag.)

  Docker images for `cf-ips-to-hcloud-fw` are available for both `linux/amd64` and
  `linux/arm64` architectures.  The Docker images support the following tags:

  - `1`: This tag always points to the latest `1.x.x` release.
  - `1.0`: This tag always points to the latest `1.0.x` release.
  - `1.0.14`: This tag points to the specific `1.0.14` release.
  - `main`: This tag points to the most recent development version of
    `cf-ips-to-hcloud-fw`. Use this at your own risk as it may contain unstable
    changes.

  You can find the Docker images at:

  - [Docker Hub](https://hub.docker.com/r/jkreileder/cf-ips-to-hcloud-fw)
  - [Quay.io](https://quay.io/repository/jkreileder/cf-ips-to-hcloud-fw)
  - [GitHub Packages](https://github.com/jkreileder/cf-ips-to-hcloud-fw/pkgs/container/cf-ips-to-hcloud-fw)

  Here's an example of how to create a Kubernetes Secret for your
  [configuration](#configuration):

  ```yaml
  apiVersion: v1
  kind: Secret
  metadata:
    name: cf-ips-to-hcloud-fw-config
  type: Opaque
  stringData:
    config.yaml: |
      - token: API_TOKEN_FOR_PROJECT_1
        firewalls:
          - firewall-1
          - firewall-2
      - token: API_TOKEN_FOR_PROJECT_2
        firewalls:
          - default
  ```

  And here's an example of a Kubernetes CronJob that uses the Secret:

  ```yaml
  apiVersion: batch/v1
  kind: CronJob
  metadata:
    name: cf-ips-to-hcloud-fw
  spec:
    schedule: "0 * * * *" # Run every hour
    jobTemplate:
      spec:
        template:
          spec:
            securityContext:
              runAsNonRoot: true
              runAsUser: 65534
            containers:
              - name: cf-ips-to-hcloud-fw
                image: jkreileder/cf-ips-to-hcloud-fw:1.0.14
                
                securityContext:
                  allowPrivilegeEscalation: false
                  readOnlyRootFilesystem: true
                  capabilities:
                    drop:
                      - ALL
                volumeMounts:
                  - name: config-volume
                    mountPath: /usr/src/app/config.yaml
                    subPath: config.yaml
            volumes:
              - name: config-volume
                secret:
                  secretName: cf-ips-to-hcloud-fw-config
            restartPolicy: OnFailure
  ```





  To prepare your Hetzner Cloud Firewall:

  1. **Set the rule descriptions**: Include `__CLOUDFLARE_IPS_V4__`,
     `__CLOUDFLARE_IPS_V6__`, or `__CLOUDFLARE_IPS__` in the description of any
     incoming firewall rule where you want to insert Cloudflare networks. This
     will be used as a marker to identify which rules should be updated with the
     Cloudflare IP ranges.

  2. **Generate an API token**: You'll need an API token with write permissions
     for the project that contains the firewall. This token will be used to
     authenticate your requests to the Hetzner Cloud API. You can generate a token
     in the Hetzner Cloud Console by going to "Security" > "API Tokens" >
     "Generate API Token".



  To configure the application, you'll need to create a `config.yaml` file with
  your API tokens and the names of the firewalls you want to update:

  ```yaml
  - token: API_TOKEN_FOR_PROJECT_1 # Token with read-write permissions for a Hetzner Cloud project
    firewalls:
      - firewall-1
      - firewall-2
  - token: API_TOKEN_FOR_PROJECT_2 # Token with read-write permissions for another Hetzner Cloud project
    firewalls:
      - default
  ```


pkgId: f8bbdd6fef5e37c3c8ee05c011b1385a3818f746fef349eac19f5f6fb3a9e5e2
name: python-cf-xarray
arch: src
version: 0.9.5
epoch: 0
release: 1
summary: A convenience wrapper for using CF attributes on xarray objects
url: https://pypi.org/project/cf-xarray/
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cf-xarray-0.9.5-1.src.rpm
checksum_type: sha256
description:
  A lightweight convenience wrapper for using CF attributes on xarray objects.
  For example you can use ``.cf.mean("latitude")`` instead of ``.mean("lat")`` if appropriate attributes are set! This allows you to write code that does not require knowledge of specific dimension or coordinate names particular to a dataset.
  See more in the `introductory notebook <https://cf-xarray.readthedocs.io/en/latest/examples/introduction.html>`_.
  Try out our Earthcube 2021 Annual Meeting notebook `submission <https://binder.pangeo.io/v2/gh/malmans2/cf-xarray-earthcube/main?filepath=DC_01_cf-xarray.ipynb>`_.

rpm_license:
[cell repeats an earlier one in this file: 10254 characters]


pkgId: f0d08ba2e76ee12a28bd319e41bdcc9c78487db7c46a737a9cfdb90c2fe529e3
name: python-cf2tf
arch: src
version: 0.8.0
epoch: 0
release: 1
summary: Convert Cloudformation Templates to Terraform.
url: https://github.com/DontShaveTheYak/cf2tf
rpm_license: GPL-3.0-only
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cf2tf-0.8.0-1.src.rpm
checksum_type: sha256
description:
  <!-- PROJECT SHIELDS -->
  <!--
  *** I'm using markdown "reference style" links for readability.
  *** Reference links are enclosed in brackets [ ] instead of parentheses ( ).
  *** See the bottom of this document for the declaration of the reference variables
  *** for contributors-url, forks-url, etc. This is an optional, concise syntax you may use.
  *** https://www.markdownguide.org/basic-syntax/#reference-style-links
  -->
  [![Python][python-shield]][pypi-url]
  [![Latest][version-shield]][pypi-url]
  [![Tests][test-shield]][test-url]
  [![Coverage][codecov-shield]][codecov-url]
  [![License][license-shield]][license-url]
  <!-- [![Contributors][contributors-shield]][contributors-url]
  [![Forks][forks-shield]][forks-url]
  [![Stargazers][stars-shield]][stars-url]
  [![Issues][issues-shield]][issues-url] -->

  <!-- PROJECT LOGO -->
  <br />
  <p align="center">
    <!-- <a href="https://github.com/DontShaveTheYak/cf2tf">
      <img src="images/logo.png" alt="Logo" width="80" height="80">
    </a> -->

    <h3 align="center">Cloudformation 2 Terraform</h3>

    <p align="center">
      Convert your Cloudformation templates to Terraform.
      <!-- <br />
      <a href="https://github.com/DontShaveTheYak/cf2tf"><strong>Explore the docs »</strong></a>
      <br /> -->
      <br />
      <!-- <a href="https://github.com/DontShaveTheYak/cf2tf">View Demo</a>
      · -->
      <a href="https://github.com/DontShaveTheYak/cf2tf/issues">Report Bug</a>
      ·
      <a href="https://github.com/DontShaveTheYak/cf2tf/issues">Request Feature</a>
      ·
      <!-- <a href="https://la-tech.co/post/hypermodern-cloudformation/getting-started/">Guide</a> -->
    </p>
  </p>



  <!-- TABLE OF CONTENTS -->
  <details open="open">
    <summary>Table of Contents</summary>
    <ol>
      <li>
        <a href="#about-the-project">About The Project</a>
      </li>
      <li>
        <a href="#getting-started">Getting Started</a>
        <ul>
          <li><a href="#prerequisites">Prerequisites</a></li>
          <li><a href="#installation">Installation</a></li>
        </ul>
      </li>
      <li><a href="#usage">Usage</a></li>
      <li><a href="#roadmap">Roadmap</a></li>
      <li><a href="#contributing">Contributing</a></li>
      <!-- <li><a href="#license">License</a></li> -->
      <li><a href="#contact">Contact</a></li>
      <li><a href="#acknowledgements">Acknowledgements</a></li>
    </ol>
  </details>



  <!-- [![Product Name Screen Shot][product-screenshot]](https://example.com) -->

  `cf2tf` is a CLI tool that attempts to convert Cloudformation to Terraform. We say attempt because it's not really possible to make the conversion with 100% accuracy (currently) because of several reasons mostly around converting a Map value in Cloudformation to the [correct value in HCL](https://github.com/hashicorp/hcl/issues/294#issuecomment-446388342).





  Cloudformation 2 Terraform requires python >= 3.8



  cf2tf is available as an easy to install pip package.
  ```sh
  pip install cf2tf
  ```

  If you are a [Homebrew](https://brew.sh/) user, can you install via brew:

  ```
  $ brew install cf2tf
  ```



  To convert a template to terraform.
  ```sh
  cf2tf my_template.yaml
  ```

  This above command will dump all the terraform resources to stdout. You might want to save the results:
  ```sh
  cf2tf my_template.yaml > main.tf
  ```

  If you prefer to have each resource in its own file then:
  ```sh
  cf2tf my_template.yaml -o some_dir
  ```
  If `some_dir` doesn't exist, then it will be created for you. Then each resource type will be saved to a specific file (variables.tf, outputs.tf etc.).



  - Better conversion of Cloudformation Maps to Terraform (Maps, Block and json)
  - Allow overides for specific resources
  - Handle more advanced Cloudformation parameter types like SSM/Secrets manager
  - Better handling of Recources/Properties that failed conversion
  - Only download files needed, not entire terraform source code (200MB)

  See the [open issues](https://github.com/DontShaveTheYak/cf2tf/issues) for a list of proposed features (and known issues).



  Contributions are what make the open-source community such an amazing place to learn, inspire, and create. Any contributions you make are **greatly appreciated**.



  This project uses poetry to manage dependencies and pre-commit to run formatting, linting and tests. You will need to have both installed to your system as well as python 3.11.

  1. Fork the Project
  2. Setup the environment.
     This project uses vscode devcontainer to provide a completly configured development environment. If you are using vscode and have the remote container extension installed, you should be asked to use the devcontainer when you open this project inside of vscode.

     If you are not using devcontainers then you will need to have python installed. Install the `poetry`, `nox`, `nox_poetry` and `pre-commit` packages. Then run `poetry install` and `pre-commit install` commands.

     Most of the steps can be found in the [Dockerfile](.devcontainer/Dockerfile).
  2. Create your Feature Branch (`git checkout -b feature/AmazingFeature`)
  3. Commit your Changes (`git commit -m 'Add some AmazingFeature'`)
  4. Push to the Branch (`git push origin feature/AmazingFeature`)
  5. Open a Pull Request

  <!-- ## License

  Distributed under the Apache-2.0 License. See [LICENSE.txt](./LICENSE.txt) for more information. -->



  Levi - [@shady_cuz](https://twitter.com/shady_cuz)

  <!-- ACKNOWLEDGEMENTS -->

  * [Cloud-Radar](https://github.com/DontShaveTheYak/cloud-radar) - A unit/functional testing framework for Cloudformation templates.
  * [cfn_tools from cfn-flip](https://github.com/awslabs/aws-cfn-template-flip) - Used to convert template from yml to python dict.
  * [Best-README-Template](https://github.com/othneildrew/Best-README-Template) - The name says it all.

  <!-- MARKDOWN LINKS & IMAGES -->
  <!-- https://www.markdownguide.org/basic-syntax/#reference-style-links -->
  [python-shield]: https://img.shields.io/pypi/pyversions/cf2tf?style=for-the-badge
  [version-shield]: https://img.shields.io/pypi/v/cf2tf?label=latest&style=for-the-badge
  [pypi-url]: https://pypi.org/project/cf2tf/
  [test-shield]: https://img.shields.io/github/actions/workflow/status/DontShaveTheYak/cf2tf/test.yml?label=Tests&style=for-the-badge
  [test-url]: https://github.com/DontShaveTheYak/cf2tf/actions?query=workflow%3ATests+branch%3Amaster
  [codecov-shield]: https://img.shields.io/codecov/c/gh/DontShaveTheYak/cf2tf/master?color=green&style=for-the-badge&token=bfF18q99Fl
  [codecov-url]: https://codecov.io/gh/DontShaveTheYak/cf2tf
  [contributors-shield]: https://img.shields.io/github/contributors/DontShaveTheYak/cf2tf.svg?style=for-the-badge
  [contributors-url]: https://github.com/DontShaveTheYak/cf2tf/graphs/contributors
  [forks-shield]: https://img.shields.io/github/forks/DontShaveTheYak/cf2tf.svg?style=for-the-badge
  [forks-url]: https://github.com/DontShaveTheYak/cf2tf/network/members
  [stars-shield]: https://img.shields.io/github/stars/DontShaveTheYak/cf2tf.svg?style=for-the-badge
  [stars-url]: https://github.com/DontShaveTheYak/cf2tf/stargazers
  [issues-shield]: https://img.shields.io/github/issues/DontShaveTheYak/cf2tf.svg?style=for-the-badge
  [issues-url]: https://github.com/DontShaveTheYak/cf2tf/issues
  [license-shield]: https://img.shields.io/github/license/DontShaveTheYak/cf2tf.svg?style=for-the-badge
  [license-url]: https://github.com/DontShaveTheYak/cf2tf/blob/master/LICENSE.txt
  [product-screenshot]: images/screenshot.png


pkgId: 68ad25043571f47565d7a9233072ec66e12f1e4e35024da32ff6b9ca36dbb0fb
name: python-cf2tf
arch: src
version: 0.9.0
epoch: 0
release: 1
summary: Convert Cloudformation Templates to Terraform.
url: https://github.com/DontShaveTheYak/cf2tf
rpm_license: GPL-3.0-only
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cf2tf-0.9.0-1.src.rpm
checksum_type: sha256
description:
  <!-- PROJECT SHIELDS -->
  <!--
  *** I'm using markdown "reference style" links for readability.
  *** Reference links are enclosed in brackets [ ] instead of parentheses ( ).
  *** See the bottom of this document for the declaration of the reference variables
  *** for contributors-url, forks-url, etc. This is an optional, concise syntax you may use.
  *** https://www.markdownguide.org/basic-syntax/#reference-style-links
  -->
  [![Python][python-shield]][pypi-url]
  [![Latest][version-shield]][pypi-url]
  [![Tests][test-shield]][test-url]
  [![Coverage][codecov-shield]][codecov-url]
  [![License][license-shield]][license-url]
  <!-- [![Contributors][contributors-shield]][contributors-url]
  [![Forks][forks-shield]][forks-url]
  [![Stargazers][stars-shield]][stars-url]
  [![Issues][issues-shield]][issues-url] -->

  <!-- PROJECT LOGO -->
  <br />
  <p align="center">
    <!-- <a href="https://github.com/DontShaveTheYak/cf2tf">
      <img src="images/logo.png" alt="Logo" width="80" height="80">
    </a> -->

    <h3 align="center">Cloudformation 2 Terraform</h3>

    <p align="center">
      Convert your Cloudformation templates to Terraform.
      <!-- <br />
      <a href="https://github.com/DontShaveTheYak/cf2tf"><strong>Explore the docs »</strong></a>
      <br /> -->
      <br />
      <!-- <a href="https://github.com/DontShaveTheYak/cf2tf">View Demo</a>
      · -->
      <a href="https://github.com/DontShaveTheYak/cf2tf/issues">Report Bug</a>
      ·
      <a href="https://github.com/DontShaveTheYak/cf2tf/issues">Request Feature</a>
      ·
      <!-- <a href="https://la-tech.co/post/hypermodern-cloudformation/getting-started/">Guide</a> -->
    </p>
  </p>



  <!-- TABLE OF CONTENTS -->
  <details open="open">
    <summary>Table of Contents</summary>
    <ol>
      <li>
        <a href="#about-the-project">About The Project</a>
      </li>
      <li>
        <a href="#getting-started">Getting Started</a>
        <ul>
          <li><a href="#prerequisites">Prerequisites</a></li>
          <li><a href="#installation">Installation</a></li>
        </ul>
      </li>
      <li><a href="#usage">Usage</a></li>
      <li><a href="#roadmap">Roadmap</a></li>
      <li><a href="#contributing">Contributing</a></li>
      <!-- <li><a href="#license">License</a></li> -->
      <li><a href="#contact">Contact</a></li>
      <li><a href="#acknowledgements">Acknowledgements</a></li>
    </ol>
  </details>



  <!-- [![Product Name Screen Shot][product-screenshot]](https://example.com) -->

  `cf2tf` is a CLI tool that attempts to convert Cloudformation to Terraform. We say attempt because it's not really possible to make the conversion with 100% accuracy (currently) because of several reasons mostly around converting a Map value in Cloudformation to the [correct value in HCL](https://github.com/hashicorp/hcl/issues/294#issuecomment-446388342).





  Cloudformation 2 Terraform requires python >= 3.8



  cf2tf is available as an easy to install pip package.
  ```sh
  pip install cf2tf
  ```

  If you are a [Homebrew](https://brew.sh/) user, can you install via brew:

  ```
  $ brew install cf2tf
  ```



  To convert a template to terraform.
  ```sh
  cf2tf my_template.yaml
  ```

  This above command will dump all the terraform resources to stdout. You might want to save the results:
  ```sh
  cf2tf my_template.yaml > main.tf
  ```

  If you prefer to have each resource in its own file then:
  ```sh
  cf2tf my_template.yaml -o some_dir
  ```
  If `some_dir` doesn't exist, then it will be created for you. Then each resource type will be saved to a specific file (variables.tf, outputs.tf etc.).



  - Better conversion of Cloudformation Maps to Terraform (Maps, Block and json)
  - Allow overides for specific resources
  - Handle more advanced Cloudformation parameter types like SSM/Secrets manager
  - Better handling of Recources/Properties that failed conversion
  - Only download files needed, not entire terraform source code (200MB)

  See the [open issues](https://github.com/DontShaveTheYak/cf2tf/issues) for a list of proposed features (and known issues).



  Contributions are what make the open-source community such an amazing place to learn, inspire, and create. Any contributions you make are **greatly appreciated**.



  This project uses poetry to manage dependencies and pre-commit to run formatting, linting and tests. You will need to have both installed to your system as well as python 3.12.

  1. Fork the Project
  2. Setup the environment.
     This project uses vscode devcontainer to provide a completly configured development environment. If you are using vscode and have the remote container extension installed, you should be asked to use the devcontainer when you open this project inside of vscode.

     If you are not using devcontainers then you will need to have python installed. Install the `poetry`, `nox`, `nox_poetry` and `pre-commit` packages. Then run `poetry install` and `pre-commit install` commands.

     Most of the steps can be found in the [Dockerfile](.devcontainer/Dockerfile).
  2. Create your Feature Branch (`git checkout -b feature/AmazingFeature`)
  3. Commit your Changes (`git commit -m 'Add some AmazingFeature'`)
  4. Push to the Branch (`git push origin feature/AmazingFeature`)
  5. Open a Pull Request

  <!-- ## License

  Distributed under the Apache-2.0 License. See [LICENSE.txt](./LICENSE.txt) for more information. -->



  Levi - [@shady_cuz](https://twitter.com/shady_cuz)

  <!-- ACKNOWLEDGEMENTS -->

  * [Cloud-Radar](https://github.com/DontShaveTheYak/cloud-radar) - A unit/functional testing framework for Cloudformation templates.
  * [cfn_tools from cfn-flip](https://github.com/awslabs/aws-cfn-template-flip) - Used to convert template from yml to python dict.
  * [Best-README-Template](https://github.com/othneildrew/Best-README-Template) - The name says it all.

  <!-- MARKDOWN LINKS & IMAGES -->
  <!-- https://www.markdownguide.org/basic-syntax/#reference-style-links -->
  [python-shield]: https://img.shields.io/pypi/pyversions/cf2tf?style=for-the-badge
  [version-shield]: https://img.shields.io/pypi/v/cf2tf?label=latest&style=for-the-badge
  [pypi-url]: https://pypi.org/project/cf2tf/
  [test-shield]: https://img.shields.io/github/actions/workflow/status/DontShaveTheYak/cf2tf/test.yml?label=Tests&style=for-the-badge
  [test-url]: https://github.com/DontShaveTheYak/cf2tf/actions?query=workflow%3ATests+branch%3Amaster
  [codecov-shield]: https://img.shields.io/codecov/c/gh/DontShaveTheYak/cf2tf/master?color=green&style=for-the-badge&token=bfF18q99Fl
  [codecov-url]: https://codecov.io/gh/DontShaveTheYak/cf2tf
  [contributors-shield]: https://img.shields.io/github/contributors/DontShaveTheYak/cf2tf.svg?style=for-the-badge
  [contributors-url]: https://github.com/DontShaveTheYak/cf2tf/graphs/contributors
  [forks-shield]: https://img.shields.io/github/forks/DontShaveTheYak/cf2tf.svg?style=for-the-badge
  [forks-url]: https://github.com/DontShaveTheYak/cf2tf/network/members
  [stars-shield]: https://img.shields.io/github/stars/DontShaveTheYak/cf2tf.svg?style=for-the-badge
  [stars-url]: https://github.com/DontShaveTheYak/cf2tf/stargazers
  [issues-shield]: https://img.shields.io/github/issues/DontShaveTheYak/cf2tf.svg?style=for-the-badge
  [issues-url]: https://github.com/DontShaveTheYak/cf2tf/issues
  [license-shield]: https://img.shields.io/github/license/DontShaveTheYak/cf2tf.svg?style=for-the-badge
  [license-url]: https://github.com/DontShaveTheYak/cf2tf/blob/master/LICENSE.txt
  [product-screenshot]: images/screenshot.png


pkgId: b6b8fdb80dba6aed089195e23835705a63b6928db316686b9ab5a4cb34de7c8b
name: python-cf_extension_core
arch: src
version: 0.2.7
epoch: 0
release: 1
summary: Provides common functionality for Custom resources in CloudFormation.
url: https://pypi.org/project/cf_extension_core/
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cf_extension_core-0.2.7-1.src.rpm
checksum_type: sha256
description:
  - Helper to enable all types of resource types for create/update/read/list operations
  - Heavily inspired to use dynamodb for resource management.  Supports all native create/read/update/list/delete operations for any resource.
  - Dynamic identifier generation to support any resource identifier use case.  Read Only resources or real resource creation.


  - Due to us using dynamodb as a backend, we need extra permissions to store/retrieve state information from dynamo.  These permissions should be added in addition to any other required permissions by each handler.

    - dynamodb:CreateTable
    - dynamodb:PutItem
    - dynamodb:DeleteItem
    - dynamodb:GetItem
    - dynamodb:UpdateItem
    - dynamodb:UpdateTable
    - dynamodb:DescribeTable
    - dynamodb:Scan



  - High level commands
     ```
      curl -sSL https://install.python-poetry.org | python3 -
      export PATH="~/.local/bin:$PATH"
      poetry --version
      poetry add boto3

      poetry add --group dev  pytest

      poetry install --no-root
      poetry build
      poetry config pypi-token.pypi ""
      poetry publish
    ```
  - Generating Stubs after all 3rd party stubs are installed
      ```
      find src/ -type f -name '*.pyi' -exec rm {} +
      stubgen src/ -o src/  --include-private
      ```
    - Do not run again after manually changed.
    - Build system updated to validate stubs via `stubtest`


pkgId: 5df4355811cbe127dedfca9fb3871f203b66c2bb80e7eb1fefccfceb2b9139a5
name: python-cfapyx
arch: src
version: 2024.11.27
epoch: 0
release: 1
url: https://pypi.org/project/cfapyx/
rpm_license: {file = "LICENSE"}
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfapyx-2024.11.27-1.src.rpm
checksum_type: sha256
summary:
  The pure-Python implementation of the CF Aggregation conventions, including the Xarray engine to enable reading CFA-netCDF files.

description:
  ![CFAPyX long logo: Blue, Green and White squares arranged in Diamond formation](https://github.com/cedadev/CFAPyX/blob/main/docs/source/_images/CFAPyX_long.jpg)

  CFA python Xarray module for using CFA files with xarray.

  See the [Documentation](https://cedadev.github.io/CFAPyX/) for more details.
  cfapyx on [Github](https://github.com/cedadev/CFAPyX)

  For use with the Xarray module as an additional backend.

  > **_NOTE:_** The `create` functionality was added to version 2024.10.11 and is currently in alpha release. Please report any unexpected errors or issues using the GitHub Issues tab for this repository.



  ```
  pip install cfapyx
  ```



  ```
  import xarray as xr

  ds = xr.open_dataset('cfa_file.nca', engine='CFA')


  ```


pkgId: 6f9123a3e7fc38a8ca3a99c23d8dd0142bd38ca1f54aeadd92c43aa5c31e41ce
name: python-cfbd
arch: src
version: 4.5.2
epoch: 0
release: 1
summary: College Football Data API
url: https://github.com/CFBD/cfbd-python
rpm_license: UNKNOWN
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfbd-4.5.2-1.src.rpm
checksum_type: sha256
description:
      This is an API for accessing all sorts of college football data.  Please note that API keys should be supplied with \&quot;Bearer \&quot; prepended (e.g. \&quot;Bearer your_key\&quot;). API keys can be acquired from the CollegeFootballData.com website.  # noqa: E501


pkgId: 6a4ba6f4265389d722cb631f2ab9efa009b77005687702a7e6baa59594ec097c
name: python-cfbfastR-py
arch: src
version: 0.0.28
epoch: 0
release: 1
summary: Retrieve American football data in Python
url: https://github.com/saiemgilani/cfbfastR-py
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfbfastR-py-0.0.28-1.src.rpm
checksum_type: sha256
description:
  <!-- badges: start -->

  ![Lifecycle:experimental](https://img.shields.io/badge/lifecycle-experimental-orange.svg?style=for-the-badge&logo=github)
  [![PyPI](https://img.shields.io/pypi/v/cfbfastR-py?label=cfbfastR-py&logo=python&style=for-the-badge)](https://pypi.org/project/cfbfastR-py/)
  ![Contributors](https://img.shields.io/github/contributors/saiemgilani/cfbfastR-py?style=for-the-badge)
  [![Twitter
  Follow](https://img.shields.io/twitter/follow/cfbfastR?color=blue&label=%40cfbfastR&logo=twitter&style=for-the-badge)](https://twitter.com/cfbfastR)

  <!-- badges: end -->


  See [CHANGELOG.md](https://cfbfastR-py.sportsdataverse.org/CHANGELOG) for details.

  The goal of [cfbfastR-py](https://cfbfastR-py.sportsdataverse.org) is to provide the community with a python package for working with American Football data as a companion to the [cfbfastR](https://saiemgilani.github.io/cfbfastR) R package. Beyond data aggregation and tidying ease, one of the multitude of services that [cfbfastR-py](https://cfbfastR-py.sportsdataverse.org) provides is for benchmarking open-source expected points and win probability metrics.



  cfbfastR-py can be installed via pip:

  ```bash
  pip install cfbfastR-py
  ```

  or from the repo (which may at times be more up to date):

  ```bash
  git clone https://github.com/saiemgilani/cfbfastR-py
  cd cfbfastR-py
  pip install -e .
  ```



  -   [Saiem Gilani](https://twitter.com/saiemgilani)
  <a href="https://twitter.com/saiemgilani" target="blank"><img src="https://img.shields.io/twitter/follow/saiemgilani?color=blue&label=%40saiemgilani&logo=twitter&style=for-the-badge" alt="@saiemgilani" /></a>
  <a href="https://github.com/saiemgilani" target="blank"><img src="https://img.shields.io/github/followers/saiemgilani?color=eee&logo=Github&style=for-the-badge" alt="@saiemgilani" /></a>




  To cite the [**`cfbfastR-py`**](https://cfbfastR-py.sportsdataverse.org) Python package in publications, use:

  BibTex Citation
  ```bibtex
  @misc{saiemgilani2021cfbfastRpy,
    author = {Gilani, Saiem},
    title = {cfbfastR-py: The SportsDataverse's Python Package for American Football Data.},
    url = {https://cfbfastR-py.sportsdataverse.org},
    season = {2021}
  }
  ```


pkgId: 9d3771f0ae6e6123d1b25d1d94a73dc70bae7e3f12a87078e45e3b14a3750577
name: python-cfblog
arch: src
version: 0.2.16
epoch: 0
release: 1
summary: Awesome CMS for Django
url: https://github.com/Coverfox/cfblog/
rpm_license: BSD
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfblog-0.2.16-1.src.rpm
checksum_type: sha256
description:
  It is a blog engine with a peculiar CMS feature, that allows very complex
  content to be easily created.


pkgId: 21b9f1283221acec26f4ac7ad42f5e19fc217a1ed55d10c66902f46d76b2638a
name: python-cfchecker
arch: src
version: 4.1.0
epoch: 0
release: 1
summary: The NetCDF Climate Forecast Conventions compliance checker
url: http://cfconventions.org/compliance-checker.html
rpm_license: BSD License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfchecker-4.1.0-1.src.rpm
checksum_type: sha256
description:
  The CF Checker is a utility that checks the contents of a NetCDF file complies with the Climate and Forecasts (CF) Metadata Convention.



  * The package runs on [**Linux**](http://en.wikipedia.org/wiki/Linux)
    and [**Mac OS**](http://en.wikipedia.org/wiki/Mac_OS) operating systems.

  * [Python 3.x](https://www.python.org/)

  * [netcdf4-python](https://pypi.python.org/pypi/netCDF4) at version 1.2.5 or newer. This package requires [netCDF](https://www.unidata.ucar.edu/software/netcdf/), [HDF5](https://www.hdfgroup.org/solutions/hdf5/) and [zlib](ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-4) libraries.

  * [cfunits-python](https://bitbucket.org/cfpython/cfunits-python) package version 3.0.0 or newer

  * [numpy](https://pypi.python.org/pypi/numpy) version 1.15 or newer



  To install from [PyPI](https://pypi.python.org/pypi/cfchecker):

      pip install cfchecker

  Alternatively, to install from source:

  1. Download the cfchecker package from [cfchecker releases](https://github.com/cedadev/cf-checker/releases)

  2. Unpack the library:

          tar -zxf cfchecker-${version}.tar.gz

          cd cfchecker-${version}

  3. Install the package:

     * To install to a central location:

              python setup.py install

     * To install to a non standard location:

              python setup.py install --prefix=<directory>

       If directory you are installing into is not on PYTHONPATH you will need to add it.



  `cfchecks [-a <area-types.xml>] [-r <regions.xml>] [-s <std_names.xml>] [-v <CFVersion>] [-x] [-t <cache_time_days>] file1 [file2...]`

  For further details and for other available command line options please see the help by running `cfchecks -h`



  The following parameters can be set on the command-line or through environment variables:

  1. `CF_STANDARD_NAMES` or (CL option `-s`) : The path or URL to the CF standard names table
  2. `CF_AREA_TYPES` or (CL option `-a`) : The path or URL to the CF area types table
  3. `CF_REGION_NAMES` or (CL option `-r`): The path or URL to the CF region names table




  In the release tarball there is a `test_files` directory containing a `test.sh` script which runs a series of test files through the CF Checker and confirms the checker is working as expected.  It is a very elementary system, which will be rewritten soon.  Before running it you will need to edit the location of the cfchecks script in the `tests.sh` file:

      cfchecker="<location of cfchecks>"

  Then just run the `tests.sh` script:

      ./tests.sh


pkgId: 230a91c1fac45d39e1ed92c73534220a5c58e03bf895411caeab231a07a35eae
name: python-cfclient
arch: src
version: 2024.11
epoch: 0
release: 1
summary: Bitcraze Cazyflie quadcopter client
url: http://www.bitcraze.io
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfclient-2024.11-1.src.rpm
checksum_type: sha256
description:
  The Crazyflie PC client enables flashing and controlling the Crazyflie.
  It implements the user interface and high-level control (for example gamepad handling).
  The communication with Crazyflie and the implementation of the CRTP protocol to control the Crazyflie is handled by the [cflib](https://github.com/bitcraze/crazyflie-lib-python) project.


  See the [installation instructions](docs/installation/install.md) in the GitHub docs folder.



  Check out the [Bitcraze crazyflie-client-python documentation](https://www.bitcraze.io/documentation/repository/crazyflie-clients-python/master/) on our website.


  Go to the [contribute page](https://www.bitcraze.io/contribute/) on our website to learn more.


  Run the automated build locally to test your code

  	python3 tools/build/build


pkgId: b1e40a5737e94285b1d2cf6c9783fbdbf7f013814fc09293a780846b8857a630
name: python-cfde-submit
arch: src
version: 0.2.5
epoch: 0
release: 1
summary: A command line tool for submitting CFDE Datasets
url: https://github.com/nih-cfde/cfde-submit
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfde-submit-0.2.5-1.src.rpm
checksum_type: sha256
description:
  This is a client to interact with the Globus Automate Flows for CFDE use cases.
  Both a Python API and a CLI tool are available.


pkgId: aa3c5483e82b2b6b9f699a856eb383f51ed31b693df010425bfc6ea36486ac56
name: python-cfdiclient
arch: src
version: 1.5.9
epoch: 0
release: 1
summary: Cliente Python Web Service del SAT para la descarga masiva de CFDIs
url: https://github.com/luisiturrios1/python-cfdiclient
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfdiclient-1.5.9-1.src.rpm
checksum_type: sha256
description:
  Cliente Python Web Service del SAT para la descarga masiva de xml



  https://www.sat.gob.mx/consultas/42968/consulta-y-recuperacion-de-comprobantes-(nuevo)



  En Windows requiere Microsoft Visual C++ Compiler for Python 2.7

  ```bash
  pip install cfdiclient
  ```



  ```python
  import base64
  import datetime
  import os
  import time

  from cfdiclient import (Autenticacion, DescargaMasiva, Fiel, SolicitaDescarga,
                          VerificaSolicitudDescarga)

  RFC = 'IUAL9406031K4'
  FIEL_CER = 'asd.cer'
  FIEL_KEY = 'df.key'
  FIEL_PAS = ''
  FECHA_INICIAL = datetime.date(2020, 1, 1)
  FECHA_FINAL = datetime.date(2020, 6, 24)
  PATH = 'Inputs/IUAL9406031K4/'

  cer_der = open(os.path.join(PATH, FIEL_CER), 'rb').read()
  key_der = open(os.path.join(PATH, FIEL_KEY), 'rb').read()

  fiel = Fiel(cer_der, key_der, FIEL_PAS)

  auth = Autenticacion(fiel)

  token = auth.obtener_token()

  print('TOKEN: ', token)

  descarga = SolicitaDescarga(fiel)







  solicitud = descarga.solicitar_descarga(
      token, RFC, FECHA_INICIAL, FECHA_FINAL, rfc_receptor=RFC, tipo_solicitud='CFDI'
  )

  print('SOLICITUD:', solicitud)

  while True:

      token = auth.obtener_token()

      print('TOKEN: ', token)

      verificacion = VerificaSolicitudDescarga(fiel)

      verificacion = verificacion.verificar_descarga(
          token, RFC, solicitud['id_solicitud'])

      print('SOLICITUD:', verificacion)

      estado_solicitud = int(verificacion['estado_solicitud'])

      
      
      
      
      
      
      

      if estado_solicitud <= 2:

          
          
          time.sleep(60)

          continue

      elif estado_solicitud >= 4:

          print('ERROR:', estado_solicitud)

          break

      else:
          

          for paquete in verificacion['paquetes']:

              descarga = DescargaMasiva(fiel)

              descarga = descarga.descargar_paquete(token, RFC, paquete)

              print('PAQUETE: ', paquete)

              with open('{}.zip'.format(paquete), 'wb') as fp:

                  fp.write(base64.b64decode(descarga['paquete_b64']))

          break
  ```





  ```python
  from cfdiclient import Autenticacion
  from cfdiclient import Fiel

  FIEL_KEY = 'Claveprivada_FIEL_XAXX010101000_20180918_134149.key'
  FIEL_CER = 'XAXX010101000.cer'
  FIEL_PAS = 'contrasena'
  cer_der = open(FIEL_CER, 'rb').read()
  key_der = open(FIEL_KEY, 'rb').read()
  fiel = Fiel(cer_der, key_der, FIEL_PAS)

  auth = Autenticacion(fiel)

  token = auth.obtener_token()

  print(token)
  ```



  ```python
  import datetime
  from cfdiclient import SolicitaDescarga
  from cfdiclient import Fiel

  FIEL_KEY = 'Claveprivada_FIEL_XAXX010101000_20180918_134149.key'
  FIEL_CER = 'XAXX010101000.cer'
  FIEL_PAS = 'contrasena'
  cer_der = open(FIEL_CER, 'rb').read()
  key_der = open(FIEL_KEY, 'rb').read()

  fiel = Fiel(cer_der, key_der, FIEL_PAS)

  descarga = SolicitaDescarga(fiel)

  token = 'eyJh'
  rfc_solicitante = 'XAXX010101000'
  fecha_inicial = datetime.datetime(2018, 1, 1)
  fecha_final = datetime.datetime(2018, 12, 31)
  rfc_emisor = 'XAXX010101000'
  rfc_receptor = 'XAXX010101000'

  result = descarga.solicitar_descarga(token, rfc_solicitante, fecha_inicial, fecha_final, rfc_emisor=rfc_emisor)
  print(result)

  result = descarga.solicitar_descarga(token, rfc_solicitante, fecha_inicial, fecha_final, rfc_receptor=rfc_receptor)
  print(result)

  ```



  ```python
  from cfdiclient import VerificaSolicitudDescarga
  from cfdiclient import Fiel

  FIEL_KEY = 'Claveprivada_FIEL_XAXX010101000_20180918_134149.key'
  FIEL_CER = 'XAXX010101000.cer'
  FIEL_PAS = 'contrasena'
  cer_der = open(FIEL_CER, 'rb').read()
  key_der = open(FIEL_KEY, 'rb').read()

  fiel = Fiel(cer_der, key_der, FIEL_PAS)

  v_descarga = VerificaSolicitudDescarga(fiel)

  token = 'eyJhbGci'
  rfc_solicitante = 'XAXX010101000'
  id_solicitud = '6331caae-c253-406f-9332-126f89cc474a'
  result = v_descarga.verificar_descarga(token, rfc_solicitante, id_solicitud)
  print(result)

  ```



  ```python
  from cfdiclient import DescargaMasiva
  from cfdiclient import Fiel

  FIEL_KEY = 'Claveprivada_FIEL_XAXX010101000_20180918_134149.key'
  FIEL_CER = 'XAXX010101000.cer'
  FIEL_PAS = 'contrasena'
  cer_der = open(FIEL_CER, 'rb').read()
  key_der = open(FIEL_KEY, 'rb').read()

  fiel = Fiel(cer_der, key_der, FIEL_PAS)

  descarga = DescargaMasiva(fiel)

  token = 'eyJhbG'
  rfc_solicitante = 'XAXX010101000'
  id_paquete = '2d8bbdf1-c36d-4b51-a57c-c1744acdd89c_01'
  result = descarga.descargar_paquete(token, rfc_solicitante, id_paquete)
  print(result)

  ```



  ```python
  from cfdiclient import Validacion

  validacion = Validacion()
  rfc_emisor = 'XAXX010101000'
  rfc_receptor = 'XAXX010101000'
  total = '1000.41'
  uuid = '0XXX0X00-000-0XX0-XX0X-000X0X0XXX00'

  estado = validacion.obtener_estado(rfc_emisor, rfc_receptor, total, uuid)

  print(estado)

  ```


pkgId: 49f7a3ce855d65ce3da3c41b7de4d5832bd933ccf3967203d97e0a571c470121
name: python-cfdm
arch: src
version: 1.11.1.0
epoch: 0
release: 1
summary: A Python reference implementation of the CF data model
url: https://ncas-cms.github.io/cfdm
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfdm-1.11.1.0-1.src.rpm
checksum_type: sha256
description:
      Data            : air_temperature(time(12), latitude(64), longitude(128)) K
      Cell methods    : time(12): mean (interval: 1.0 month)
      Dimension coords: time(12) = [0450-11-16 00:00:00, ..., 0451-10-16 12:00:00] noleap
  The **cfdm** package can
  * read field and domain constructs from netCDF and CDL datasets,
  * create new field and domain constructs in memory,
  * write and append field and domain constructs to netCDF datasets on disk,
  * read, write, and manipulate UGRID mesh topologies,
  * read, write, and create coordinates defined by geometry cells,
  * read and write netCDF4 string data-type variables,
  * read, write, and create netCDF and CDL datasets containing hierarchical groups,
  * inspect field and domain constructs,
  * test whether two constructs are the same,
  * modify field and domain construct metadata and data,
  * create subspaces of field and domain constructs,
  * incorporate, and create, metadata stored in external files, and
  * read, write, and create data that have been compressed by convention
    (i.e. ragged or gathered arrays, or coordinate arrays compressed
    by subsampling), whilst presenting a view of the data in its
    uncompressed form.


pkgId: accb07710c1d4b0d98b774d79edc852cc75f3b5f94c58f6a77afaba6c49319b1
name: python-cfdna
arch: src
version: 2.3.1
epoch: 0
release: 1
summary: Python package for fragment manipulation for cfDNA
url: https://github.com/kylessmith/cfdna
rpm_license: GPL-2.0-or-later
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfdna-2.3.1-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://travis-ci.org/kylessmith/cfdna.svg?branch=master)](https://travis-ci.org/kylessmith/cfdna) [![PyPI version](https://badge.fury.io/py/cfdna.svg)](https://badge.fury.io/py/cfdna)

  This is a Python package for easy and efficient cell-free
  DNA analysis.

  All citations should reference to [original paper][paper].




  If you dont already have numpy and scipy installed, it is best to download
  `Anaconda`, a python distribution that has them included.
  ```
      https://continuum.io/downloads
  ```

  Create environment and pip install:
  ```
      conda create -n cfdna python=3.11.3
  	conda activate cfdna
  	pip install cfdna==2.0.5
  ```

  Dependencies can be installed by:

  ```
      pip install -r requirements.txt
  ```

  PyPI install, presuming you have all its requirements installed:
  ```
      pip install cfdna
  ```



  ```python
  import cfdna as cf
  import numpy as np


  cfdata = cf.cfDNA()
  frags = cf.io.readBAM("test.bam")


  cf.proc.call_cnv_pipline(cfdata, frags)


  cf.pl.plot_cnv(cfdata, "test.bam")
  ```

  Run from the commadline:

  ```
      python -m cfdna callCNVs --bam test.bam --segs --genome hg19 --bin_size 100000
  ```

  This will output a .png plot and seg file.

  [paper]: https://www.cell.com/cancer-cell/pdfExtended/S1535-6108(21)00501-8


pkgId: d85b773c0545e479876418f8676b0089786645696473f60956aa9e7595cb5282
name: python-cfdp
arch: src
version: 2.1.0
epoch: 0
release: 1
summary: CCSDS File Delivery Protocol
url: https://pypi.org/project/cfdp/
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfdp-2.1.0-1.src.rpm
checksum_type: sha256
description:
  The CCSDS File Delivery Protocol (CFDP) was developed by the
  [Consultative Committee for Space Data Systems (CCSDS)](https://public.ccsds.org).
  The CFDP protocol provides reliable transfer of files from one endpoint to
  another and has been designed to work well over space links that suffer
  from outtakes and long delays. The basic operation of CFDP is to transfer a
  file from a sender to a receiver (both referred to as CFDP entities). The
  sender and receiver must be configured and running at the same time to perform
  a file transfer. It can be used to perform  space to ground, ground to space,
  space to space, and ground to ground file transfers. For example it can be used
  to transfer science data from satellite over mission control to the science
  center in an automated fashion with minimal to no human intervention.

  This Python module is an implementation of the CCSDS File Delivery Protocol.
  It supports all features as outlined in the latest version of the [CFDP Blue Book](docs/727x0b5.pdf). These are:

  - Class 1 (unacknowledged) file transfer
  - Class 2 (acknowledged) file transfer
  - Filestore requests
  - Proxy operations
  - Directory listing request
  - Native filestore implementation
  - UDP as default transport layer (optional ZMQ)



  Clone the repository and then install via pip:

  ```
  $ pip install cfdp
  ```

  > Depending on the transport layer to use with CFDP, one needs to install additional dependencies.



  Find the detailed documentation [here](docs/README.md).



  The protocol is tested for cross-support as outlined in CCSDS CFDP Yellow Book.
  See [tests/README.md](tests/README.md) for details.



  - Issue Tracker: https://gitlab.com/librecube/lib/python-cfdp/-/issues
  - Source Code: https://gitlab.com/librecube/lib/python-cfdp

  To learn more on how to successfully contribute please read the contributing
  information in the [LibreCube guidelines](https://gitlab.com/librecube/org/guidelines).



  If you are having issues, please let us know. Reach us at
  [Matrix](https://app.element.io/#/room/#librecube.org:matrix.org)
  or via [Email](mailto:info@librecube.org).



  The project is licensed under the MIT license. See the [LICENSE](./LICENSE.txt) file for details.


pkgId: 75e9736cabd896cc70a229399349d4d2a40fba060ed2da512c477e85fe9084b2
name: python-cfdtools
arch: src
version: 0.5.4
epoch: 0
release: 1
summary: Tools for mesh and solution management in CFD
url: https://github.com/jgressier/cfdtools
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfdtools-0.5.4-1.src.rpm
checksum_type: sha256
description:
  [![PyPi Version](https://img.shields.io/pypi/v/cfdtools.svg?style=flat)](https://pypi.org/project/cfdtools)
  [![PyPI pyversions](https://img.shields.io/pypi/pyversions/cfdtools.svg?style=flat)](https://pypi.org/pypi/cfdtools/)
  [![GitHub stars](https://img.shields.io/github/stars/jgressier/cfdtools.svg?style=flat&logo=github&label=Stars&logoColor=white)](https://github.com/jgressier/cfdtools)
  [![PyPi downloads](https://img.shields.io/pypi/dm/cfdtools.svg?style=flat)](https://pypistats.org/packages/cfdtools)
  [![codecov](https://img.shields.io/codecov/c/github/jgressier/cfdtools.svg?style=flat)](https://codecov.io/gh/jgressier/cfdtools)
  [![Codacy Badge](https://app.codacy.com/project/badge/Grade/d32cf67a5fa242c88bb1568277f1d60e)](https://app.codacy.com/gh/jgressier/cfdtools/dashboard?utm_source=gh&utm_medium=referral&utm_content=&utm_campaign=Badge_grade)[![Doc](https://readthedocs.org/projects/cfdtools/badge/?version=latest)](https://readthedocs.org/projects/cfdtools/)
  [![Slack](https://img.shields.io/static/v1?logo=slack&label=slack&message=contact&style=flat)](https://join.slack.com/t/isae-opendev/shared_invite/zt-obqywf6r-UUuHR4_hc5iTzyL5bFCwpw
  )

  - readers: IC3, VTK, GMSH, CGNS
  - writers: IC3, VTK
  - generic options for command line writers: extrusion
  - generic format command line: `cfdinfo`
  - specific IC3 command line: `ic3brief`
  - specific VTK command line: `vtkbrief`, `vtkpack`

  ```bash
  pip install cfdtools
  ```

  see [requirements.txt](https://github.com/jgressier/cfdtools/blob/master/requirements.txt)

rpm_license:
  MIT License  Copyright (c) 2022 Jérémie GRESSIER  Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:  The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


pkgId: 9cf4673a4de7d788a901b1a76b4e8195403c59e33c41080ee64b523590048835
name: python-cff2toml
arch: src
version: 3.2.2
epoch: 0
release: 1
url: https://pypi.org/project/cff2toml/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cff2toml-3.2.2-1.src.rpm
checksum_type: sha256
summary:
  A module to synchronize metadata between TOML and CFF files, including between pyproject.toml and CITATION.cff files.

description:
  **Table of Contents**
  - [Installation](#installation)
  - [Usage](#usage)
  - [Limitations](#limitations)
  - [Roadmap](#roadmap)
  - [License](#license)

  ```console
  pip install cff2toml
  ```

  ```console
  cff2toml --help
  ```
  This package offers a CLI and classes to manipulate metadata in CFF and TOML files.
  One common use case is to synchronize metadata between pyproject.toml and CITATION.cff files in a Python project.

  Here is how you view the version in both CITATION.cff and pyproject.toml,
  assuming they are in the same directory
  ```
  cff2toml view version
  ```
  You can also view other common metadata. See the help.

  Here is how you change the version in both CITATION.cff and pyproject.toml,
  assuming they are in the same directory
  ```
  cff2toml change version 2.30.1
  ```
  You can also change other common metadata. See the help.

  The tool is in early and active development, so it should not be used yet for production systems. The CLI only supports version and license at the moment, but the underlying libraries support more.

  1. Improve CLI tool to view and change other metadata fields.
  2. Improve documentation of the underlying classes.
  3. Fix the output order so that it creates a more useful semantic ordering of propreties (not alphabetical).

  `cff2toml` is distributed under the terms of the [Apache 2.0](https://spdx.org/licenses/Apache-2.0.html) license

  Contributions in the form of feature requests, bug reports, bug fixes, tests, and feature implementations are welcome. To contribute code, please fork the project, and then do a pull request.


  To build the tool locally, please follow the general advice from [here](https://packaging.python.org/en/latest/tutorials/packaging-projects/).
  ```
  python3 -m pip install --upgrade build
  python3 -m build
  ```

  To deploy the tool, use the Github Action defined in .github/workflows/python-publish.yml


pkgId: c2749e274dd3d91f91818fe94eb956bb2a7be74e9bdfcdd7122b48d456798b92
name: python-cfgdict
arch: src
version: 1.1.3
epoch: 0
release: 1
summary: A lightweight dict-like config library with validation support
url: http://github.com/gseismic/cfgdict
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfgdict-1.1.3-1.src.rpm
checksum_type: sha256
description:
  A lightweight dict-like config library with validation support


  - Supports nested dictionary structures
  - Provides configuration validation with customizable rules
  - Includes utility functions for flattening and reconstructing dictionaries
  - Easy-to-use API for creating and managing configurations
  - Support reading from environ by `!env ENV_XXX`, inspired by https://github.com/drkostas/yaml-config-wrapper



  You can install cfgdict directly from GitHub using pip:

  ```bash
  pip install cfgdict
  ```

  ```bash
  pip install git+https://github.com/gseismic/cfgdict.git
  ```


  ```python

  import os


  from cfgdict import Config, Field, Schema

  config_schema = [
      dict(name='API_KEY', required=True, type='str'),
      Field('n_step', required=True, type='int', gt=0),
      Field('learning_rate', required=True,
            rules=dict(type='float', gt=0, max=1), gt=1e-3),
      Field('nest', required=True,
            schema=Schema(
                Field('gamma', required=True, type='float', min=0, max=1),
                Field('epsilon', required=True, type='float', min=0, max=1),
                Field('verbose_freq', required=True, type='int', gt=0))
            )
  ]

  os.environ['API_KEY'] = 'secret-xxxxxx'

  cfg_dict = {
      'API_KEY': '!env API_KEY',
      'n_step': 3,
      'learning_rate': 0.1,
      'nest': {
          'gamma': 0.99,
          'epsilon': 0.1,
          'verbose_freq': 10
      }
  }

  config = Config.from_dict(cfg_dict, schema=config_schema, strict=True)
  print(config.to_dict())
  print(config.schema)

  ```



  ```python
  import os
  from cfgdict.v1 import Config

  config_schema = [
      dict(field='API_KEY', required=True, rules=dict(type='str')),
      dict(field='n_step', required=True, default=3, rules=dict(type='int', gt=0)),
      dict(field='learning_rate', required=True, default=0.1, rules=dict(type='float', gt=0, max=1)),
      dict(field='nest.gamma', required=True, default=0.99, rules=dict(type='float', min=0, max=1)),
      dict(field='nest.epsilon', required=True, default=0.1, rules=dict(type='float', min=0, max=1)),
      dict(field='nest.verbose_freq', required=True, default=10, rules=dict(type='int', gt=0)),
  ]

  os.environ['API_KEY'] = 'secret'



  cfg_dict = {
      'API_KEY': '!env API_KEY',
      'n_step': 3,
      'learning_rate': 0.1,
      'nest': {
          'gamma': 0.99,
          'epsilon': 0.1,
          'verbose_freq': 10
      }
  }

  cfg = Config.from_dict(cfg_dict, schema=config_schema, strict=True)
  print(cfg.to_dict())


  cfg = make_config(cfg_dict, config_schema, strict=True)
  print(cfg.to_dict())


  cfg = make_config(cfg_dict, config_schema, strict=True, to_dict=True, logger=None, verbose=False)
  print(cfg) # python-dict


  cfg = make_config(cfg_dict, config_schema, strict=True, to_dict=True, to_dict_flatten=True)
  print(cfg) # python-dict


  cfg = make_config(cfg_dict, config_schema, strict=True, to_dict=True, to_dict_flatten=True, to_dict_sep='.')
  print(cfg) # python-dict
  ```



  ```python
  from cfgdict.v1 import flatten_dict, unflatten_dict

  nested_dict = {
      'a': 1,
      'b': {
          'c': 2,
          'd': {
              'e': 3
          }
      },
      'f': 4
  }

  flattened = flatten_dict(nested_dict)
  print(f'Flattened: {flattened}')


  unflattened = unflatten_dict(flattened)
  print(f'Unflattened: {unflattened}')

  ```



  cfgdict supports the following validation rules:

  - `type`: Specify field type (e.g., 'int', 'float', 'str', etc.)
  - `required`: Whether the field is required (True/False)
  - `default`: Default value if not provided

  Comparison operators:
  - `eq`: Equal to
  - `ne`: Not equal to
  - `gt`: Greater than
  - `ge`: Greater than or equal to
  - `lt`: Less than
  - `le`: Less than or equal to
  - `min`: Minimum value (inclusive)
  - `max`: Maximum value (inclusive)
  - `custom`: Custom validation function
  - `len`: Length of the field (e.g., 'str', 'list', 'dict')
  - `choices`: Choices of the field (e.g., 'str', 'list', 'dict')
  - `pattern`: Regular expression pattern for string validation
  - `unique`: Ensure all elements in a list are unique
  - `contains`: Ensure a value is in a list
  - `range`: Range of the field (e.g., 'int', 'float')
  - `allowed_values`: Allowed values for the field (e.g., 'str', 'list', 'dict')
  - `disallowed_values`: Disallowed values for the field (e.g., 'str', 'list', 'dict')

  Example usage:

  ```python
  config_schema = [
      dict(field='age', required=True, rules=dict(type='int', ge=18, lt=100)),
      dict(field='score', required=False, default=0, rules=dict(type='float', min=0, max=100)),
      dict(field='status', required=True, rules=dict(type='str', ne='inactive')),
  ]
  ```

  In this example:
  - 'age' must be an integer, greater than or equal to 18, and less than 100
  - 'score' is optional with a default of 0, must be a float between 0 and 100 (inclusive)
  - 'status' is required and must be a string not equal to 'inactive'


  set `verbose=True`

  cfgdict supports nested configurations:

  ```python
  from cfgdict.v1 import Config

  nested_schema = [
      dict(field='database.host', required=True, rules=dict(type='str')),
      dict(field='database.port', required=True, rules=dict(type='int', min=1, max=65535)),
      dict(field='api.version', required=True, rules=dict(type='str')),
      dict(field='api.endpoints.users', required=True, rules=dict(type='str')),
      dict(field='api.endpoints.products', required=True, rules=dict(type='str')),
  ]

  nested_config = Config.from_dict({
      'database': {
          'host': 'localhost',
          'port': 5432
      },
      'api': {
          'version': 'v1',
          'endpoints': {
              'users': '/api/v1/users',
              'products': '/api/v1/products'
          }
      }
  }, schema=nested_schema, verbose=True)


  print(config.to_dict())
  ```


  You can extend the validation system with custom rules:

  ```python
  from cfgdict.v1 import Config, ConfigValidationError

  def validate_even(value):
      if value % 2 != 0:
          raise ConfigValidationError(f"Value {value} is not even")

  config_schema = [
      dict(field='even_number', required=True, rules=dict(type='int', custom=validate_even))
  ]

  config = Config.from_dict({'even_number': 4}, schema=config_schema)
   

  ```


  For more usage examples, please refer to:
  - [tests/test_config_v1.py](./tests/test_config_v1.py)
  - [tests/test_config_v2.py](./tests/test_config_v2.py)
  - [tests/test_utils.py](./tests/test_utils.py)


  - [ ] nested Schema/Field


  - 2024-09-26 support read from env


  We welcome issue reports and pull requests. If you have any suggestions or improvements, please feel free to contribute.


  This project is licensed under the MIT License. See the [LICENSE](./LICENSE) file for details.


pkgId: 30ab00914ca44c6f3c6624e57106bf9bafb5a88d8bd6f06d6b8027b07445286d
name: python-cfgenvy
arch: src
version: 2.2.2
epoch: 0
release: 1
summary: Configuration from Environment embedded in yaml.
url: https://github.com/pennsignals/cfgenvy
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfgenvy-2.2.2-1.src.rpm
checksum_type: sha256
description:
  [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)

  [![Release](https://github.com/pennsignals/cfgenvy/workflows/release/badge.svg)](https://github.com/pennsignals/cfgenvy/actions?query=workflow%3Arelease)

  [![Test](https://github.com/pennsignals/cfgenvy/workflows/test/badge.svg)](https://github.com/pennsignals/cfgenvy/actions?query=workflow%3Atest)

  Keep secrets out of env variables in production by using env files. Merge env files into configuration dynamically. Keep env file and env variable handling out of the application by making application dependent only on the configuration file. Prefer deserilization from yaml over configuration of partially initialized objects.

  An argument parser that accepts:

  - A required yaml file for configuration/deserialization.
  - An optional env file for secrets.

  Features:

  - MIT license
  - Interpolate environment variables directly into yaml configuration.
  - Optional replacement of environment variables with an environment variable file.
  - Use C Yaml safe load/dump or yaml safe load/dump.
  - Pass in env to parser with os.environ as a default.
  - Pass in argv to parser with sys.argv[1:] as a default.
  - Yaml type registration functions.

  Relative configargparse, python-dotenv, envyaml, and yamlenv:

  - Dependency injection through depth-first deserialization of yaml is better than two-pass, breadth-first initialization followed by a configuration.
  - Contract for env variables is between configuration file and env xor the env file, the app no longer cares much about env or secrets as it uses the interpolated configuration file.
  - No ${MY_VAR:my-default} --unexpected env var syntax for default values, an expensive pattern match, and allows typos of MY_VAR to pass silently--.
  - No "N/A" or null default when environment variable does not exist --allows configuration errors to pass silently to become runtime errors--.
  - Env file is optional, but when provided it does not merge with existing environment variables --better tracability in production deployment--.
  - Yaml type registration retains the registered yaml tag in a closure.
  - Env yaml type registration retains the registered env variable set in a closure.



      pip install "."



  Setup virtual environment:

      python3.10 -m venv .venv

  Or setup homebrew environment:

      brew install python@3.12
      python3.12 -m venv .venv

  Once virtual environment is setup:

      . .venv/bin/activate
      pip install -U pip setuptools wheel
      pip install -e ".[dev]"
      pre-commit install

  Session:

      . .venv/bin/activate
      ...
      pytest
      ...
      pre-coommit run --all-files
      ...
      git commit -m 'Message'
      ...
      deactivate



      docker compose up test
      docker compose up pre-commit
      docker compose up build-wheel && docker compose up install-wheel
      ...
      docker compose down

rpm_license:
  MIT License  Copyright (c) 2021 Penn Signals  Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:  The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


pkgId: 1889d0df301c9707e49f44b9a49ac52d9a5a8ec2a733c1f6fda23c332a57ffe0
name: python-cfgopt
arch: src
version: 0.8.0
epoch: 0
release: 1
summary: You only configure your deep learning experiment once with cfgopt.
url: http://github.com/tjyuyao/cfgopt
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfgopt-0.8.0-1.src.rpm
checksum_type: sha256
description:
  <p align="center"><img src="https://github.com/tjyuyao/cfgopt/raw/main/cfgopt.png" alt="Logo"></p>



  `cfgopt` is a solution for elegance of configuring complicated deep learning projects. Here, you configure everything only once in json, without need to write configuration and commandline parsing boilerplate code in python anymore. The solution is extremly simple, elegant, and compact. Without any 3rd-party dependency, the core implementation of `cfgopt` is only around 200 LOC, and *will be* (todo) fully tested.



  - **2022/06/21** `cfgopt` code released.



  **Installation**

  ```
  pip install cfgopt
  ```

  **Basic Usage**

  Generally, you should have some json **c**on**f**i**g** files in a folder, and a python program that import `cfgopt` to parse them. The program can have command line **opt**ions that update specific field in the parsed results for this running. This is also why this library is called "cfgopt".

  To be concrete, you have two choices using `cfgopt`:

  - Use the `cfgopt.parse_configs(cfg_root)` API, just pass in the directory path of all the configuration files, and explore with the results! Or you should read the examples described in the [Features](https://github.com/tjyuyao/cfgopt#features) section.
  - Use `cfgoptrun` command directly or wrap `cfgopt.main()` function, for details please refer to the follow-up [main function](https://github.com/tjyuyao/cfgopt#main-function) section.



  <details><summary><h3>basic json binding</h3></summary><p>

  `cfgopt` has a main api `parse_configs(cfg_root)` that accepts the path of *a folder of json files*. All files will be (recursively) load in python and added to a root `dict`, keeping the hierarchy and data types unchanged, with some exceptions described in follow-up sections.

  > Feature first added in `v0.1`.

  </p></details>

  <details><summary><h3>block-level reference</h3></summary><p>

  `cfgopt` release you from repeating yourself with a mountain pile of configuration files by borrowing the concept of `block-level reference and embedding` in many modern note-taking apps such as `Logseq`, or more well-known `hyperlinks` for webpages.

  **The `cfg://` format URI:**

  `cfgopt` follows and expands string values matching a special syntax `cfg://<file-path>/<intra-file-uri>` in the configuration files during parsing. This is one of the most repealing feature for `cfgopt`. You can also specify *relative* uri which contains no substring ".json" in it.

  **Example:**

  **file structure**

  ```shell
  .
  └── test_blockref_in_list
      ├── cfg
      │   ├── data.json
      │   └── recipes.json
      └── test_blockref_in_list.py
  ```

  **data.json**:

  ```json
  {
      "data1": {
          "meta": {
              "location": "/data/1/loc"
          }
      },
      "data2": {
          "meta": {
              "location": "/data/2/loc"
          }
      }
  }
  ```

  **recipes.json**:

  ```json
  {
      "recipe1": {
          "use_data": [
              "cfg://data.json/data1"
          ]
      },
      "recipe2": {
          "use_data": [
              "cfg://data.json/data1",
              "cfg://data.json/data2"
          ]
      }
  }
  ```

  **test_blockref_in_list.py**
  ```python
  import cfgopt

  def test_blockref_in_list():
      cfg = cfgopt.parse_configs(cfg_root='test_blockref_in_list/cfg')

      
      assert cfg["recipes.json"]["recipe2"]["use_data"][1]["meta"]["location"] == "/data/2/loc"
      assert cfg["recipes.json"]["recipe2/use_data/1/meta/location"] == "/data/2/loc"
      assert cfg["recipes.json/recipe2/use_data/1/meta/location"] == "/data/2/loc"
  ```

  > `__hostname__` in URI will be translated into what you get by executing `hostname` in shell. Since `v0.5.5`.
  > Relative URI support added in `v0.3.0`.
  > Feature first added in `v0.1`.

  </p></details>

  <details><summary><h3>command-line update</h3></summary><p>

  `cfgopt` will automatically parse command line options matching the python regex format `^--(.*?)=(.*)`, and interpret it as an update of the parsed configuration folder. The right hand side of `=` should be valid json, and you might need to take care of shell escaping your special characters.

  For example, you can write `--train.json/max_epochs=100` or `--train.json/max_epochs="100"`, since your shell would escape double-quotes, you will get an integer `100` in both cases.

  But if you write `--train.json/resume=\"/path/to/ckpt\"` or `--train.json/resume='"/path/to/ckpt"'`, you should probably get a string value, which depends on your shell implementation.

  > Unmatched uri/keys are treated as errors since `v0.7.0`. Regex format updated as `^--(.*?)=(.*)` to match the first `=` symbol since `v0.7.2`.

  > Behavior changed to update existing uri before expansion and then update thereafter, this makes both features, i.e., command-line specifying expansion and assigning values after expansion, work. Since `v0.5.0`.

  > Updated regex format from `^--(.*)=(.*)` to `^--(.*\.json.*)=(.*)` in `v0.2`. But then changed back since `v0.4.3`, be careful that unmatched uri/keys would just be ignored without warning.

  > Feature first added in `v0.1`.

  </p></details>

  <details><summary><h3>json objects inheritance</h3></summary><p>

  Users can specify a json dict, that contains a `__base__` field, linking to another base json dict objects with the `cfg://` reference format (described in [block-level reference](https://github.com/tjyuyao/cfgopt#block-level-reference)). Then the current dict would inherit the base object, and also has its own values in normal fields. This feature is also critical to eliminate repeating, with which now you can develop multiple simillar configs from some prototypes.

  > TODO: an example.

  > Bugfix: changed from referencing to deepcopying the base dict in `v0.2`.

  > Feature first added in `v0.1`.

  </p></details>

  <details><summary><h3>parse python objects</h3></summary><p>

  `cfgopt` has a extremly flexible feature, that parse an json dict to ALMOST any python objects defined in user's code or any code python can find in `PYTHON_PATH`.

  Users can specify a json dict, that contains `__module__` and `__class__` field. The `__module__` field will be imported by `importlib.import_module()` during parsing, and `__class__` field naming any python `callable` in the imported module will be passed to `functools.partial()` along with other fields as keyword arguments. Finally, the mapped "dict" in python would be directly callable to instantiate corresponding class or get result of corresponding functions.

  **pseudo-code of parsing:**
  ```python
  module = importlib.import_module(data["__module__"])
  klass = getattr(module, data["__class__"])
  data["__class__"] = partial(klass, **{k:v for k, v in data.items() if not k.startswith("__")})
  ```

  > **NOTE**: The python object should not use VAR_POSITIONAL and POSITIONAL_ONLY arguments, and keywords arguments are always recommended than positional arguments.

  By default, when arguments has nested object that is meant to be constructed by `cfgopt` and you call a higher level object, the nested ones in arguments will be **automatically and recursively instantiated** as long as **all its required arguments are defined**. If you want certain object not to be automatically created, add a `"__as_type__": true` field alongside the `__class__` field.

  Let us refer to these "dict"s with `__class__` and `__module__` fields as **python object builders**. You can call into these builders with extra arguments to instantiate them. You can also pass only partial arguments for multiple times, and it won't actually instantiate until all required arguments are ready, similar to above. This is very handy to pass around the builder everywhere deep into the code to collect scattered arguments. For example define a bachnorm builder, and pass it as argument to your networks, the latter can pass the channel argument when it is figured out from the preceding layer. The builder can be used multiple times.

  You can also create a builder from python code, by using `cfgopt.PartialClass()` function, very similar to standard `functools.partial()`, but again it allows being called multiple times until all required args are given.

  > TODO: an example.

  > `__as_type__` keyword added in `v0.5.3`.

  > Important Feature: `PartialClass` and lazily instantiation since `v0.5.0`.

  > Supported auto instantiate of nested python objects since `v0.4.0`.

  > API enhance: user now can directly call the mapped "dict" object instead of its `__class__` field in `v0.2`.

  > Feature first added in `v0.1`.

  </p></details>

  <details><summary><h3>main function</h3></summary><p>

  ```python
  import argparse
  import cfgopt

  def main():
      parser = argparse.ArgumentParser()
      parser.add_argument(
          "recipe",
          help="a main function uri to be execute."
      )
      parser.add_argument(
          "-d", "--cfgdir",
          default="cfg",
          help="config directory that maps to cfg:// root. (default: `cfg`)"
      )
      args, unknown_args = parser.parse_known_args()
      cfgs = cfgopt.parse_configs(
          cfg_root=args.cfgdir,
          args=unknown_args,
          args_root=args.recipe,
      )
      _main = cfgs[args.recipe]
      return _main(recursive=False)

  if __name__ == "__main__":
      main()
  ```

  This example `main()` function accepts the first argument as a previous described `cfg://`-format uri, that parses a python callable function, and call it as the main function. This is also implemented as `cfgopt.main()`, and user can use `cfgoptrun` command direct from shell, or just import this main function and call it in usercode with extra python arguments.

  > TODO: an example.

  > Behaviour changed: `cfgoptrun` interprets commandline arguments as relative path to `recipe` instead of absolute(full) uri since `v0.6.0`.

  > Add `cfgoptrun` command (entrypoint) in `v0.2`.

  > Feature first added in `v0.1`.

  </p></details>


pkgId: 6d4c3ae1bdfa0488c6bc3c0c1ee83223ef308bb5813d87ef6285ed309c90609c
name: python-cfgrib
arch: src
version: 0.9.14.1
epoch: 0
release: 1
url: https://github.com/ecmwf/cfgrib
rpm_license: Apache License Version 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfgrib-0.9.14.1-1.src.rpm
checksum_type: sha256
summary:
  Python interface to map GRIB files to the NetCDF Common Data Model following the CF Convention using ecCodes.

description:
  Python interface to map GRIB files to the
  `Unidata's Common Data Model v4 <https://docs.unidata.ucar.edu/netcdf-java/current/userguide/common_data_model_overview.html>`_
  following the `CF Conventions <http://cfconventions.org/>`_.
  The high level API is designed to support a GRIB engine for `xarray <http://xarray.pydata.org/>`_
  and it is inspired by `netCDF4-python <http://unidata.github.io/netcdf4-python/>`_
  and `h5netcdf <https://github.com/shoyer/h5netcdf>`_.
  Low level access and decoding is performed via the
  `ECMWF ecCodes library <https://confluence.ecmwf.int/display/ECC/>`_ and
  the `eccodes python package <https://pypi.org/project/eccodes>`_.
  Features with development status **Beta**:
  - enables the ``engine='cfgrib'`` option to read GRIB files with *xarray*,
  - reads most GRIB 1 and 2 files including heterogeneous ones with ``cfgrib.open_datasets``,
  - supports all modern versions of Python 3.9, 3.8, 3.7 and PyPy3,
  - the 0.9.6.x series with support for Python 2 will stay active and receive critical bugfixes,
  - works wherever *eccodes-python* does: *Linux*, *MacOS* and *Windows*
  - conda-forge package on all supported platforms,
  - reads the data lazily and efficiently in terms of both memory usage and disk access,
  - allows larger-than-memory and distributed processing via *xarray* and *dask*,
  - supports translating coordinates to different data models and naming conventions,
  - supports writing the index of a GRIB file to disk, to save a full-file scan on open,
  - accepts objects implementing a generic *Fieldset* interface as described in `ADVANCED_USAGE.rst`.
  Work in progress:
  - **Beta** install a ``cfgrib`` utility that can convert a GRIB file ``to_netcdf``
    with a optional conversion to a specific coordinates data model,
    see `#40 <https://github.com/ecmwf/cfgrib/issues/40>`_.
  - **Alpha/Broken** support writing carefully-crafted ``xarray.Dataset``'s to a GRIB1 or GRIB2 file,
    see the *Advanced write usage* section below, `#18 <https://github.com/ecmwf/cfgrib/issues/18>`_
    and `#156 <https://github.com/ecmwf/cfgrib/issues/156>`_.
  Limitations:
  - relies on *ecCodes* for the CF attributes of the data variables,
  - relies on *ecCodes* for anything related to coordinate systems / ``gridType``,
    see `#28 <https://github.com/ecmwf/cfgrib/issues/28>`_.


pkgId: 2144bfff0178eb162f23fe47abb5e4001bd0d2bd7e5f6e8f5c9ef1eae9719067
name: python-cfile
arch: src
version: 0.4.0
epoch: 0
release: 1
summary: A C code generator written in Python 3
url: https://github.com/cogu/cfile
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfile-0.4.0-1.src.rpm
checksum_type: sha256
description:
  A C code generator written in Python 3.



  ```python
  import cfile

  C = cfile.CFactory()
  code = C.sequence()
  code.append(C.sysinclude("stdio.h"))
  code.append(C.blank())
  char_ptr_type = C.type("char", pointer=True)
  code.append(C.declaration(C.function("main", "int",
                                       params=[C.variable("argc", "int"),
                                               C.variable("argv", char_ptr_type, pointer=True)
                                               ])))
  main_body = C.block()
  main_body.append(C.statement(C.func_call("printf", C.str_literal(r"Hello World\n"))))
  main_body.append(C.statement(C.func_return(0)))
  code.append(main_body)
  writer = cfile.Writer(cfile.StyleOptions())
  print(writer.write_str(code))
  ```

  Output

  ```C
     

     int main(int argc, char** argv)
     {
        printf("Hello World!\n");
        return 0;
     }
  ```

  Here's the same example again but this time we change the formatting style of the output:

  - Opening brace on same line
  - Pointer alignment to the right

  ```python
  import cfile

  C = cfile.CFactory()
  code = C.sequence()
  code.append(C.sysinclude("stdio.h"))
  code.append(C.blank())
  char_ptr_type = C.type("char", pointer=True)
  code.append(C.declaration(C.function("main", "int",
                                       params=[C.variable("argc", "int"),
                                               C.variable("argv", char_ptr_type, pointer=True)
                                               ])))
  main_body = C.block()
  main_body.append(C.statement(C.func_call("printf", C.str_literal(r"Hello World\n"))))
  main_body.append(C.statement(C.func_return(0)))
  code.append(main_body)
  style = cfile.StyleOptions(break_before_braces=cfile.BreakBeforeBraces.ATTACH,
                             pointer_alignment=cfile.Alignment.RIGHT)
  writer = cfile.Writer(style)
  print(writer.write_str(code))
  ```

  Output

  ```C
     

     int main(int argc, char **argv) {
        printf("Hello World!\n");
        return 0;
     }
  ```



  Starting from version 0.3.2 you need to wrap functions, variables, structs and typedefs inside `C.declaraton` to actually declare them.
  Before v0.3.2 these elements were implicitly declared when encountered in the code sequence.

  Not using `C.declaration` will only print the name when used on variables, functions or typedefs.

  For structs it will have the following meaning:

  - without declaration: Will only forward declare the struct type.
  - With declaration: Will fully declare the struct and its members.

  Example

  ```python
  import cfile

  C = cfile.CFactory()

  code = C.sequence()
  mystruct = C.struct("mystruct",
                      members=[C.struct_member("field_1", "int"),
                               C.struct_member("field_2", "int")])
  code.append(C.statement(mystruct))  # Forward declaration
  code.append(C.blank())
  code.append(C.statement(C.declaration(mystruct)))  # Struct declaration
  writer = cfile.Writer(cfile.StyleOptions())
  print(writer.write_str(code))
  ```

  Output

  ```C
  struct mystruct;

  struct mystruct
  {
      int field_1;
      int field_2;
  };
  ```

  When declaring typedefs of structs you can wrap the struct declaration inside the declaration of the typedef.

  Example

  ```python
  import cfile

  C = cfile.CFactory()

  code = C.sequence()
  mystruct = C.struct("mystruct",
                      members=[C.struct_member("field_1", "int"),
                               C.struct_member("field_2", "int")])
  code.append(C.statement(C.declaration(C.typedef("mystruct_t", C.declaration(mystruct)))))
  writer = cfile.Writer(cfile.StyleOptions(break_before_braces=cfile.BreakBeforeBraces.ATTACH))
  print(writer.write_str(code))
  ```

  Output

  ```C
  typedef struct mystruct {
      int field_1;
      int field_2;
  } mystruct_t;
  ```

  There's some basic support for struct initializers. By rearranging the code from the example above we can
  declare a new struct variable named `instance` with initializer.

  ```python
  import cfile

  C = cfile.CFactory()
  code = C.sequence()
  struct = C.struct("mystruct",
                    members=[C.struct_member("field_1", "int"),
                             C.struct_member("field_2", "int")])
  struct_type = C.typedef("my_struct_t", C.declaration(struct))
  code.append(C.statement(C.declaration(struct_type)))
  code.append(C.blank())
  code.append(C.statement(C.declaration(C.variable("instance", struct_type), [0, 0])))

  writer = cfile.Writer(cfile.StyleOptions(break_before_braces=cfile.BreakBeforeBraces.ATTACH))
  print(writer.write_str(code))
  ```

  Output

  ```C
  typedef struct mystruct {
      int field_1;
      int field_2;
  } my_struct_t;

  my_struct_t instance = {0, 0};
  ```



  Python 3.10+ (Needed for modern type hinting support).



  Documentation will be written at a later date.

  For currently supported style options see class StyleOptions in cfile.style module.



  See [Changelog document](CHANGELOG.md).



  **v0.2:** No longer maintained.

  **v0.4:** Stable version (bug-fixes only).

  **v0.5:** Development track.


pkgId: 7b4809b5847569f67fd1e315930201012db4e21df1b6191a1018674dab1bf94d
name: python-cfinterface
arch: src
version: 1.8.0
epoch: 0
release: 1
summary: Interface for handling custom formatted files
url: https://pypi.org/project/cfinterface/
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfinterface-1.8.0-1.src.rpm
checksum_type: sha256
description:
  ![tests](https://github.com/rjmalves/cfi/workflows/tests/badge.svg)
  [![codecov](https://codecov.io/gh/rjmalves/cfi/branch/main/graph/badge.svg?token=86ZXJGB854)](https://codecov.io/gh/rjmalves/cfi)

  Python package that contains a framework for dealing with custom file formats, modulating reading, data formatting and writing in a scalable and modular way.



  `cfinterface` is a framework for designing low-level interfaces that depends on complex text or binary file parsing. It provides components for modeling lines, registers, blocks and sections in a declarative way and aggregate these blocks as components for defining files.

  Suppose that a complex text file needs to be parsed and the contents of lines with a specific identifier must be extracted and validated. For instance, the line follows the format:

  ```
  DATA_HIGH  ID001   sudo.user  10/20/2025  901.25
  ```

  If `DATA_HIGH` is the identifier that specifies the lines to be read, than one can model it with the `Register` class in the `cfinterface` framework.

  ```python
  class DataHigh(Register):
      IDENTIFIER = "DATA_HIGH"
      IDENTIFIER_DIGITS = 9
      LINE = Line(
          [
              LiteralField(size=6, starting_position=11),
              LiteralField(size=9, starting_position=19),
              DatetimeField(size=10, starting_position=30, format="%M/$d/%Y"),
              FloatField(size=6, starting_position=42, decimal_digits=2),
          ]
      )
  ```

  A `Register` depends on the definition of a `Line` object, that is composed of `Field` objects. By modeling these elements on a declarative way, the user gains access to reading / writing functions on the fly, and the `Register` may be added to a `RegisterFile` object, so that it can be read / written together with many other registers to files.

  Despite the `Register` model, files can also be composed of `Blocks` and `Sections`, and their interfaces can be done to `text` or `binary` formats. For more information, the docs are available [here](https://rjmalves.github.io/cfinterface).



  `cfinterface` requires python >= 3.10. It this requirement is met, than one may install the framework with

  ```
  python -m pip install cfinterface
  ```



  Guides, tutorials and references may be found at the package's official site: https://rjmalves.github.io/cfinterface

rpm_license:
  MIT License  Copyright (c) 2022 Rogerio Alves  Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:  The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


pkgId: 6b9925fd926532a482ea442bcebe95226273aff9533cd0697a53e03b9622074b
name: python-cfl-data-utils
arch: src
version: 0.13.1
epoch: 0
release: 1
summary: Utilities for the Data and Analytics team at Chetwood Financial
url: https://github.com/chetwoodfinancial/data-utilities
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfl-data-utils-0.13.1-1.src.rpm
checksum_type: sha256
description:
  Full documentation can be found [here](https://chetwoodfinancial.github.io/data-utilities/build/html/index.html)



  This can be installed like any other package, from PyPi:

  ```bash
  pip install cfl-data-utils
  ```



  This package has the following requirements:

  - Python `>= 3.6`



  All dependencies are listed in `setup.py` as per the expected standard. These packages should be installed as part of the installation process.



  `blessings` is a Unix-only package, and does not work on Windows. This has been accounted for and it is not imported if the OS is Windows, however should this cuase an error an issue should be raised as detail below.









  If any issues arise when using/as a result of this package, raise an issue on GitHub with the following details:

  - Steps to reproduce
  - Expected result
  - Actual result
  - Environment setup
  - Any other information which may be useful



  If you have functions which you often copy and paste between scripts or reuse (in any volume), then feel free to create a pull request or send a request via Slack/Email/etc.


pkgId: 05f88e5b43453d22459241fbce6317aa318015f17b7ab72435b8ef821a6ae512
name: python-cflib
arch: src
version: 0.1.27
epoch: 0
release: 1
summary: Crazyflie python driver
url: https://github.com/bitcraze/crazyflie-lib-python
rpm_license: GPLv3
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cflib-0.1.27-1.src.rpm
checksum_type: sha256
description:
  cflib is an API written in Python that is used to communicate with the Crazyflie
  and Crazyflie 2.0 quadcopters. It is intended to be used by client software to
  communicate with and control a Crazyflie quadcopter. For instance the [Crazyflie PC client](https://www.github.com/bitcraze/crazyflie-clients-python)  uses the cflib.

  See [below](#platform-notes) for platform specific instruction.
  For more info see our [documentation](https://www.bitcraze.io/documentation/repository/crazyflie-lib-python/master/).


  See the [installation instructions](docs/installation/install.md) in the github docs folder.



  Check out the [Bitcraze crazyflie-lib-python documentation](https://www.bitcraze.io/documentation/repository/crazyflie-lib-python/master/) on our website.


  Go to the [contribute page](https://www.bitcraze.io/contribute/) on our website to learn more.


  Run the automated build locally to test your code

  	python3 tools/build/build


pkgId: a14f9a904dcdac4a3692257c26bf98ea14803bca131508713ca940d29e7b90af
name: python-cfmtoolbox
arch: src
version: 0.4.0
epoch: 0
release: 1
summary: A plugin-based toolbox for working with cardinality-based feature models
url: https://github.com/KIT-TVA/cfmtoolbox/
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfmtoolbox-0.4.0-1.src.rpm
checksum_type: sha256
description:
  [![Versions][versions-image]][versions-url]
  [![PyPI][pypi-image]][pypi-url]
  [![License][license-image]][license-url]

  [versions-image]: https://img.shields.io/pypi/pyversions/cfmtoolbox
  [versions-url]: https://github.com/KIT-TVA/cfmtoolbox/blob/main/pyproject.toml
  [pypi-image]: https://img.shields.io/pypi/v/cfmtoolbox
  [pypi-url]: https://pypi.org/project/cfmtoolbox/
  [license-image]: https://img.shields.io/pypi/l/cfmtoolbox
  [license-url]: https://github.com/KIT-TVA/cfmtoolbox/blob/main/LICENSE

  The CFM Toolbox is a plugin-based framework for working with cardinality-based feature models.
  The framework ships with a set of core plugins, but can also easily be extended with third-party and custom plugins.

  [Read the documentation](https://kit-tva.github.io/cfmtoolbox/) to learn more.



  - **Easily extensible**: Designed to be easily extensible with third-party and custom plugins
  - **Core plugins**: Core plugins provide essential functionality for working with CFMs
  - **Command-line interface**: The included CLI allows for easy automation of tasks
  - **Cross-platform**: Written in Python, the toolbox runs on all major operating systems
  - **FeatureIDE import**: XML-based FeatureIDE feature models can easily be imported
  - **UVL import and export**: Universal Variability Language files are supported out of the box


pkgId: 3f3979bd3bbd9fd5aac3bb4c0f6b8e08fd1d0444c368d4087d00959dfd054777
name: python-cfn-ci-helper
arch: src
version: 2023.8.30.post0
epoch: 0
release: 1
summary: A Cloudformation CI Helper System
url: https://github.com/chalbersma/cfn-ci-helper
rpm_license: UNKNOWN
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfn-ci-helper-2023.8.30.post0-1.src.rpm
checksum_type: sha256
description:
  Cloudformation CI Helper, a series of helpers to help you deploy a cloudformation
  template(s) as a part of a CI pipeline in a reasonably safe manner.


pkgId: 84aa62a9c93a0506fd8a97089e817e27a27f400a00baf3eff2a2b7d729c52a63
name: python-cfn-custom-resource
arch: src
version: 1.0.1
epoch: 0
release: 1
summary: A helper lib for lambda based Custom Resources (AWS CloudFormation)
url: https://bitbucket.org/atlassian/cfn-custom-resource
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfn-custom-resource-1.0.1-1.src.rpm
checksum_type: sha256
description:
  Python helper library for creation of Lambda based [Custom Resource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html)
  for AWS CloudFormation. The library allows the author to focus on the logic of creation/update/removal of the Custom
  Resource instead of the details of the request/response format that CloudFormation expects.




  To install simply use pip:

      pip install cfn-custom-resource




  Here's how a basic Custom Resource can be created:

      from cfn_custom_resource import lambda_handler, create, update, delete

  	@create()
  	def create(event, context):
  	  

  	  
  	  

  	  return resource_id, output_attributes

  	@update()
  	def update(event, context):
  	  
  	  

  	  return resource_id, output_attributes

  	@delete()
  	def delete(event, context):
  	  

  	  return

  Check [the wiki](https://bitbucket.org/atlassian/cfn-custom-resource/wiki/Home) for more details.




  See [CONTRIBUTING.md](https://bitbucket.org/atlassian/cfn-custom-resource/src/master/CONTRIBUTING.md)




  Copyright (c) 2018 Atlassian and others.
  Apache 2.0 licensed, see [LICENSE](https://bitbucket.org/atlassian/cfn-custom-resource/src/master/LICENSE) file.


pkgId: 7a1483983aba57f89b40aa4aed710483bcacdd0ae2f716619a03eb5e657d0bb5
name: python-cfn-flip
arch: src
version: 1.3.0
epoch: 0
release: 1
summary: Convert AWS CloudFormation templates between JSON and YAML formats
url: https://github.com/awslabs/aws-cfn-template-flip
rpm_license: Apache2
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfn-flip-1.3.0-1.src.rpm
checksum_type: sha256
description:
  [![Build Status](https://www.travis-ci.org/awslabs/aws-cfn-template-flip.svg?branch=master)](https://www.travis-ci.org/awslabs/aws-cfn-template-flip)
  [![PyPI version](https://badge.fury.io/py/cfn-flip.svg)](https://badge.fury.io/py/cfn-flip)
  [![Codecov Test Coverage](https://codecov.io/gh/awslabs/aws-cfn-template-flip/branch/master/graphs/badge.svg?style=flat)](https://codecov.io/gh/awslabs/aws-cfn-template-flip)
  [![Snap Status](https://build.snapcraft.io/badge/awslabs/aws-cfn-template-flip.svg)](https://build.snapcraft.io/user/awslabs/aws-cfn-template-flip)

  [![Get it from the Snap Store](https://snapcraft.io/static/images/badges/en/snap-store-white.svg)](https://snapcraft.io/cfn-flip)





  AWS CloudFormation Template Flip is a tool that converts [AWS CloudFormation](https://aws.amazon.com/cloudformation/) templates between [JSON](http://json.org/) and [YAML](http://yaml.org) formats, making use of the YAML format's short function syntax where possible.

  The term "Flip" is inspired by the well-known Unix command-line tool [flip](https://ccrma.stanford.edu/~craig/utility/flip/) which converts text files between Unix, Mac, and MS-DOS formats.



  AWS CloudFormation Template Flip can be installed using [pip](https://pip.pypa.io/en/stable/):

  ```bash
  pip install cfn-flip
  ```



  AWS CloudFormation Template Flip is both a command line tool and a python library.

  Note that the command line tool is spelled `cfn-flip` with a hyphen, while the python package is `cfn_flip` with an underscore.



  ```
  Usage: cfn-flip [OPTIONS] [INPUT] [OUTPUT]

    AWS CloudFormation Template Flip is a tool that converts AWS
    CloudFormation templates between JSON and YAML formats, making use of the
    YAML format's short function syntax where possible."

  Options:
    -i, --input [json|yaml]   Specify the input format. Overrides -j and -y
                              flags.
    -o, --output [json|yaml]  Specify the output format. Overrides -j, -y, and
                              -n flags.
    -j, --json                Convert to JSON. Assume the input is YAML.
    -y, --yaml                Convert to YAML. Assume the input is JSON.
    -c, --clean               Performs some opinionated cleanup on your
                              template.
    -l, --long                Use long-form syntax for functions when converting
                              to YAML.
    -n, --no-flip             Perform other operations but do not flip the
                              output format.
    --version                 Show the version and exit.
    --help                    Show this message and exit.
  ```


  cfn-flip will detect the format of the input template and convert JSON to YAML and YAML to JSON, respectively.

  Examples:

  * Reading from `stdin` and outputting to `stdout`:

      ```bash
      cat examples/test.json | cfn-flip
      ```

  * Reading from a file and outputting to `stdout`:

      ```bash
      cfn-flip examples/test.yaml
      ```

  * Reading from a file and outputting to another file:

      ```bash
      cfn-flip examples/test.json output.yaml
      ```

  * Reading from a file and cleaning up the output

      ```bash
      cfn-flip -c examples/test.json
      ```



  To use AWS CloudFormation Template Flip from your own python projects, import one of the functions `flip`, `to_yaml`, or `to_json` as needed.

  ```python
  from cfn_flip import flip, to_yaml, to_json

  """
  All functions expect a string containing serialised data
  and return a string containing serialised data
  or raise an exception if there is a problem parsing the input
  """



  some_yaml_or_json = flip(some_json_or_yaml)


  some_json = to_json(some_yaml)


  some_yaml = to_yaml(some_json)




  clean_yaml = to_yaml(some_json, clean_up=True)
  ```



  You can configure some parameters like:

  `max_col_width`: Maximum columns before breakline. Default value is 200
  To change the configuration you can use:

  **Environment Variable**

  Linux/Unix:
  `export CFN_MAX_COL_WIDTH=120`

  Windows: `SET CFN_MAX_COL_WIDTH=120`

  **Python**

  ```python

  from cfn_tools._config import config
  from cfn_flip import flip, to_yaml, to_json

  """
  All functions expect a string containing serialised data
  and return a string containing serialised data
  or raise an exception if there is a problem parsing the input
  """


  config['max_col_width'] = "120"



  some_yaml_or_json = flip(some_json_or_yaml)


  some_json = to_json(some_yaml)


  some_yaml = to_yaml(some_json)




  clean_yaml = to_yaml(some_json, clean_up=True)

  ```


pkgId: f946e437f10242d9cefc78534b81918fe5dfb18310a9bab964d867620e1e395c
name: python-cfn-lambda-handler
arch: src
version: 1.4.0
epoch: 0
release: 1
url: https://github.com/mixja/cfn-lambda-handler
rpm_license: ISC
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfn-lambda-handler-1.4.0-1.src.rpm
checksum_type: sha256
summary:
  This package provides a decorator for Python Lambda functions handling AWS CloudFormation custom resources.


pkgId: 146a8b841d9a6ef01b5db8ac7aa5df4ee63e9b78f5e6e98494dcbf17b37d7dc1
name: python-cfn-lint
arch: src
version: 1.12.4
epoch: 0
release: 1
summary: Checks CloudFormation templates for practices and behaviour that could potentially be improved
url: https://github.com/aws-cloudformation/cfn-lint
rpm_license: MIT no attribution
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfn-lint-1.12.4-1.src.rpm
checksum_type: sha256
description:
  <img alt="[cfn-lint logo]" src="https://github.com/aws-cloudformation/cfn-python-lint/blob/main/logo.png?raw=true" width="150" align="right">

  [![Testing](https://github.com/aws-cloudformation/cfn-python-lint/actions/workflows/test.yaml/badge.svg?branch=main)](https://github.com/aws-cloudformation/cfn-python-lint/actions/workflows/test.yaml)
  [![PyPI version](https://badge.fury.io/py/cfn-lint.svg)](https://badge.fury.io/py/cfn-lint)
  [![PyPI downloads](https://pepy.tech/badge/cfn-lint/week)](https://pypistats.org/packages/cfn-lint)
  [![PyPI downloads](https://pepy.tech/badge/cfn-lint/month)](https://pypistats.org/packages/cfn-lint)
  [![codecov](https://codecov.io/gh/aws-cloudformation/cfn-lint/branch/main/graph/badge.svg)](https://codecov.io/gh/aws-cloudformation/cfn-python-lint)
  [![Discord Shield](https://img.shields.io/discord/981586120448020580?logo=discord)](https://discord.gg/KENDm6DHCv)

  Validate AWS CloudFormation yaml/json templates against the [AWS CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html) and additional checks. Includes checking valid values for resource properties and best practices.



  This is an attempt to provide validation for AWS CloudFormation templates properties and
  their values. For values things can get pretty complicated (mappings, joins, splits,
  conditions, and nesting those functions inside each other) so it's a best effort to
  validate those values but the promise is to not fail if we can't understand or translate
  all the things that could be going on.



  We encourage you to contribute to `cfn-lint`! Please check out the [Contributing Guidelines](https://github.com/aws-cloudformation/cfn-lint/blob/main/CONTRIBUTING.md) for more information on how to proceed.



  Join us on Discord! Connect & interact with CloudFormation developers &
  experts, find channels to discuss and get help for cfn-lint, CloudFormation registry, StackSets,
  Guard and more:

  [![Join our Discord](https://discordapp.com/api/guilds/981586120448020580/widget.png?style=banner3)](https://discord.gg/9zpd7TTRwq)



  The Serverless Application Model (SAM) is supported by the linter. The template is
  transformed using [AWS SAM](https://github.com/awslabs/serverless-application-model) before the linter processes the template.

  _To get information about the [SAM Transformation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/transform-aws-serverless.html), run the linter with `--info`_



  Python 3.8+ is supported.



  `pip install cfn-lint`. If pip is not available, run
  `python setup.py clean --all` then `python setup.py install`.



  `cfn-lint` has optional dependencies based on certain features you may need.

  * `pip install cfn-lint[full]` for installing all the optional dependencies. This will install all the dependencies for graph, junit, and sarif.
  * `pip install cfn-lint[graph]` for installing `pydot` to draw and output template graphs
  * `pip install cfn-lint[junit]` for installing the packages to output the `junit` format
  * `pip install cfn-lint[sarif]` for installing the packages to output the `sarif` format




  `brew install cfn-lint`



  In `cfn-lint` source tree:

  ```shell
  docker build --tag cfn-lint:latest .
  ```

  In repository to be linted:

  ```shell
  docker run --rm -v `pwd`:/data cfn-lint:latest /data/template.yaml
  ```



  There are IDE plugins available to get direct linter feedback from you favorite editor:

  - [Atom](https://atom.io/packages/atom-cfn-lint)
  - [Emacs](https://www.emacswiki.org/emacs/CfnLint)
  - NeoVim 0.2.0+/Vim 8
    - [ALE](https://github.com/w0rp/ale#supported-languages)
    - [Coc](https://github.com/joenye/coc-cfn-lint)
    - [Syntastic](https://github.com/speshak/vim-cfn)
  - [Sublime](https://packagecontrol.io/packages/SublimeLinter-contrib-cloudformation)
  - [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=kddejong.vscode-cfn-lint)
  - [IntelliJ IDEA](https://plugins.jetbrains.com/plugin/10973-cfn-lint)







  - `cfn-lint template.yaml`
  - `cfn-lint -t template.yaml`

  Multiple files can be linted by either specifying multiple specific files:

  - `cfn-lint template1.yaml template2.yaml`
  - `cfn-lint -t template1.yaml template2.yaml`

  or by using wildcards (globbing):

  Lint all `yaml` files in `path`:

  - `cfn-lint path/*.yaml`

  Lint all `yaml` files in `path` and all subdirectories (recursive):

  - `cfn-lint path/**/*.yaml`

  _Note_: If using sh/bash/zsh, you must enable globbing.
  (`shopt -s globstar` for sh/bash, `setopt extended_glob` for zsh).



  `cfn-lint` will return a non zero exit if there are any issues with your template. The value is dependent on the severity of the issues found. For each level of discovered error `cfn-lint` will use bitwise OR to determine the final exit code. This will result in these possibilities.

  - 0 is no issue was found
  - 2 is an error
  - 4 is a warning
  - 6 is an error and a warning
  - 8 is an informational
  - 10 is an error and informational
  - 12 is an warning and informational
  - 14 is an error and a warning and an informational



  `cfn-lint` allows you to configure exit codes. You can provide the parameter `--non-zero-exit-code` with a value of `informational`, `warning`, `error`, or `none`. `cfn-lint` will determine the exit code based on the match severity being the value of the parameter `--non-zero-exit-code` and higher. The exit codes will remain the same as above.

  The order of severity is as follows:

  1. `informational` _default_
  1. `warning`
  1. `error`
  1. `none` _Exit code will always be 0 unless there is a syntax error_



  The template to be linted can also be passed using standard input:

  - `cat path/template.yaml | cfn-lint -`



  - `cfn-lint -r us-east-1 ap-south-1 -- template.yaml`
  - `cfn-lint -r us-east-1 ap-south-1 -t template.yaml`





  From a command prompt run `cfn-lint <path to template>` to run standard linting of the template.



  It will look for a configuration file in the following locations (by order of preference):

  - `.cfnlintrc`, `.cfnlintrc.yaml` or `.cfnlintrc.yml` in the current working directory
  - `~/.cfnlintrc` for the home directory

  In that file you can specify settings from the parameter section below.

  Example:

  ```yaml
  templates:
    - test/fixtures/templates/good/**/*.yaml
  ignore_templates:
    - codebuild.yaml
  include_checks:
    - I
  custom_rules: custom_rules.txt
  ```



  Optional parameters:

  | Command Line               | Metadata             | Options                                        | Description                                                                                                                                                                                                                                           |
  | -------------------------- | -------------------- | ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | -h, --help                 |                      |                                                | Get description of cfn-lint                                                                                                                                                                                                                           |
  | -z, --custom-rules         |                      | filename                                       | Text file containing user-defined custom rules. See [here](#Custom-Rules) for more information                                                                                                                                                        |
  | -t, --template             |                      | filename                                       | Alternative way to specify Template file path to the file that needs to be tested by cfn-lint                                                                                                                                                         |
  | -f, --format               | format               | quiet, parseable, json, junit, pretty, sarif   | Output format                                                                                                                                                                                                                                         |
  | -l, --list-rules           |                      |                                                | List all the rules                                                                                                                                                                                                                                    |
  | -r, --regions              | regions              | [REGIONS [REGIONS ...]], ALL_REGIONS           | Test the template against many regions. [Supported regions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html)                                                                                                |
  | -b, --ignore-bad-template  | ignore_bad_template  |                                                | Ignores bad template errors                                                                                                                                                                                                                           |
  | --ignore-templates         |                      | IGNORE_TEMPLATES [IGNORE_TEMPLATES ...]        | Ignore templates from being scanned                                                                                                                                                                                                                   |
  | -a, --append-rules         | append_rules         | [RULESPATH [RULESPATH ...]]                    | Specify one or more rules paths using one or more --append-rules arguments. Each path can be either a directory containing python files, or an import path to a module.                                                                               |
  | -i, --ignore-checks        | ignore_checks        | [IGNORE_CHECKS [IGNORE_CHECKS ...]]            | Only check rules whose ID do not match or prefix these values. Examples: <br />- A value of `W` will disable all warnings<br />- `W2` disables all Warnings for Parameter rules.<br />- `W2001` will disable rule `W2001`                             |
  | -e, --include-experimental | include_experimental |                                                | Whether rules that still in an experimental state should be included in the checks                                                                                                                                                                    |
  | -c, --include-checks       |                      | INCLUDE_CHECKS [INCLUDE_CHECKS ...]            | Include rules whose id match these values                                                                                                                                                                                                             |
  | -m, --mandatory-checks     |                      |                                                | Rules to check regardless of ignore configuration                                                                                                                                                                                                     |
  | --non-zero-exit-code       |                      | informational (default), warning, error, none] | Exit code will be non zero from the specified rule class and higher                                                                                                                                                                                   |
  | -x, --configure-rule       |                      | CONFIGURE_RULES [CONFIGURE_RULES ...]          | Provide configuration for a rule. Format RuleId:key=value. Example: E3012:strict=true                                                                                                                                                                 |
  | -D, --debug                |                      |                                                | Specify to enable debug logging. Debug logging outputs detailed information about rules processing, useful for debugging rules.                                                                                                                       |
  | -I, --info                 |                      |                                                | Specify to enable logging. Outputs additional information about the template processing.                                                                                                                                                              |
  | -u, --update-specs         |                      |                                                | Update the [CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html). You may need sudo to run this. You will need internet access when running this command              |
  | -o, --override-spec        |                      | filename                                       | Spec-style file containing custom definitions. Can be used to override CloudFormation specifications. More info [here](#customize-specifications)                                                                                                     |
  | -g, --build-graph          |                      |                                                | Creates a file in the same directory as the template that models the template's resources in [DOT format](<https://en.wikipedia.org/wiki/DOT_(graph_description_language)>)                                                                           |
  | -s, --registry-schemas     |                      |                                                | one or more directories of [CloudFormation Registry](https://aws.amazon.com/blogs/aws/cloudformation-update-cli-third-party-resource-support-registry/) [Resource Schemas](https://github.com/aws-cloudformation/aws-cloudformation-resource-schema/) |
  | -v, --version              |                      |                                                | Version of cfn-lint                                                                                                                                                                                                                                   |



  To maintain backwards compatibility `info` rules are not included by default. To include these rules you will need to include `-c I` or `--include-checks I`





  Inside the root level Metadata key you can configure cfn-lint using the supported parameters.

  ```yaml
  Metadata:
    cfn-lint:
      config:
        regions:
          - us-east-1
          - us-east-2
        ignore_checks:
          - E2530
  ```



  Inside a resources Metadata key you can configure cfn-lint to ignore checks. This will filter out failures for the resource in which the Metadata belongs. Keep in mind that [`AWS::Serverless` resources may lose metadata during the Serverless transform](https://github.com/awslabs/serverless-application-model/issues/450#issuecomment-643420308)

  ```yaml
  Resources:
    myInstance:
      Type: AWS::EC2::Instance
      Metadata:
        cfn-lint:
          config:
            ignore_checks:
              - E3030
      Properties:
        InstanceType: nt.x4superlarge
        ImageId: ami-abc1234
  ```



  cfn-lint applies configurations from several sources. The rules at lower levels are overridden by those at higher levels.

  1. cfnlintrc configurations
  2. Template Metadata configurations
  3. CLI parameters



  Certain rules support configuration properties. You can configure these rules by using `configure_rules` parameter.

  From the command line the format is `RuleId:key=value`, for example: `E3012:strict=true`.
  From the cfnlintrc or Metadata section the format is

  ```yaml
  Metadata:
    cfn-lint:
      config:
        configure_rules:
          RuleId:
            key: value
  ```

  The configurable rules have a non-empty Config entry in the table [here](docs/rules.md#rules-1).



  There are [getting started guides](/docs/getting_started) available in the documentation section to help with integrating `cfn-lint` or creating rules.



  This linter checks the AWS CloudFormation template by processing a collection of Rules, where every rule handles a specific function check or validation of the template.

  This collection of rules can be extended with custom rules using the `--append-rules` argument.

  More information describing how rules are set up and an overview of all the Rules that are applied by this linter are documented [here](docs/rules.md).



  The linter supports the creation of custom one-line rules which compare any resource with a property using pre-defined operators. These custom rules take the following format:

  ```
  <Resource Type> <Property[*]> <Operator> <Value> [Error Level] [Custom Error Message]
  ```



  A separate custom rule text file must be created.

  The example below validates `example_template.yml` does not use any EC2 instances of size `m4.16xlarge`

  _custom_rule.txt_

  ```
  AWS::EC2::Instance InstanceType NOT_EQUALS "m4.16xlarge" WARN "This is an expensive instance type, don't use it"
  ```

  _example_template.yml_

  ```yaml
  AWSTemplateFormatVersion: "2010-09-09"
  Resources:
    myInstance:
      Type: AWS::EC2::Instance
      Properties:
        InstanceType: m4.16xlarge
        ImageId: ami-asdfef
  ```

  The custom rule can be added to the [configuration file](#Config-File) or ran as a [command line argument](#Parameters)

  The linter will produce the following output, running `cfn-lint example_template.yml -z custom_rules.txt`:

  ```
  W9001  This is an expensive instance type, don't use it
  mqtemplate.yml:6:17
  ```

  More information describing how custom rules are setup and an overview of all operators available is documented [here](docs/custom_rules.md).



  The linter follows the [AWS CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html) by default. However, for your use case specific requirements might exist. For example, within your organisation it might be mandatory to use [Tagging](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/).

  The linter provides the possibility to implement these customized specifications using the `--override-spec` argument.

  More information about how this feature works is documented [here](docs/customize_specifications.md)



  If you'd like cfn-lint to be run automatically when making changes to files in your Git repository, you can install [pre-commit](https://pre-commit.com/) and add the following text to your repositories' `.pre-commit-config.yaml`:

  ```yaml
  repos:
    - repo: https://github.com/aws-cloudformation/cfn-lint
      rev: v1.12.4 # The version of cfn-lint to use
      hooks:
        - id: cfn-lint
          files: path/to/cfn/dir/.*\.(json|yml|yaml)$
  ```

  If you are using a `.cfnlintrc` and specifying the `templates` or `ignore_templates` we would recommend using the `.cfnlintrc` exlusively to determine which files should be scanned and then using:

  ```yaml
  repos:
    - repo: https://github.com/aws-cloudformation/cfn-lint
      rev: v1.12.4 # The version of cfn-lint to use
      hooks:
        - id: cfn-lint-rc
  ```

  _Note: When mixing .cfnlintrc ignore_templates and files option in your .pre-commit-config.yaml cfn-lint may return a file not found error_

  - If you exclude the `files:` line above, every json/yml/yaml file will be checked.
  - You can see available cfn-lint versions on the [releases page](https://github.com/aws-cloudformation/cfn-python-lint/releases).


pkgId: c5a5263124a967bc7bd850779fdf2718c7f28385337765fde97b814ffe1df8a9
name: python-cfn-lint
arch: src
version: 1.14.1
epoch: 0
release: 1
summary: Checks CloudFormation templates for practices and behaviour that could potentially be improved
url: https://github.com/aws-cloudformation/cfn-lint
rpm_license: MIT no attribution
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfn-lint-1.14.1-1.src.rpm
checksum_type: sha256
description:
  <img alt="[cfn-lint logo]" src="https://github.com/aws-cloudformation/cfn-python-lint/blob/main/logo.png?raw=true" width="150" align="right">

  [![Testing](https://github.com/aws-cloudformation/cfn-python-lint/actions/workflows/test.yaml/badge.svg?branch=main)](https://github.com/aws-cloudformation/cfn-python-lint/actions/workflows/test.yaml)
  [![PyPI version](https://badge.fury.io/py/cfn-lint.svg)](https://badge.fury.io/py/cfn-lint)
  [![PyPI downloads](https://pepy.tech/badge/cfn-lint/week)](https://pypistats.org/packages/cfn-lint)
  [![PyPI downloads](https://pepy.tech/badge/cfn-lint/month)](https://pypistats.org/packages/cfn-lint)
  [![codecov](https://codecov.io/gh/aws-cloudformation/cfn-lint/branch/main/graph/badge.svg)](https://codecov.io/gh/aws-cloudformation/cfn-python-lint)
  [![Discord Shield](https://img.shields.io/discord/981586120448020580?logo=discord)](https://discord.gg/KENDm6DHCv)

  Validate AWS CloudFormation yaml/json templates against the [AWS CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html) and additional checks. Includes checking valid values for resource properties and best practices.



  This is an attempt to provide validation for AWS CloudFormation templates properties and
  their values. For values things can get pretty complicated (mappings, joins, splits,
  conditions, and nesting those functions inside each other) so it's a best effort to
  validate those values but the promise is to not fail if we can't understand or translate
  all the things that could be going on.



  We encourage you to contribute to `cfn-lint`! Please check out the [Contributing Guidelines](https://github.com/aws-cloudformation/cfn-lint/blob/main/CONTRIBUTING.md) for more information on how to proceed.



  Join us on Discord! Connect & interact with CloudFormation developers &
  experts, find channels to discuss and get help for cfn-lint, CloudFormation registry, StackSets,
  Guard and more:

  [![Join our Discord](https://discordapp.com/api/guilds/981586120448020580/widget.png?style=banner3)](https://discord.gg/9zpd7TTRwq)



  The Serverless Application Model (SAM) is supported by the linter. The template is
  transformed using [AWS SAM](https://github.com/awslabs/serverless-application-model) before the linter processes the template.

  _To get information about the [SAM Transformation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/transform-aws-serverless.html), run the linter with `--info`_



  Python 3.8+ is supported.



  `pip install cfn-lint`. If pip is not available, run
  `python setup.py clean --all` then `python setup.py install`.



  `cfn-lint` has optional dependencies based on certain features you may need.

  * `pip install cfn-lint[full]` for installing all the optional dependencies. This will install all the dependencies for graph, junit, and sarif.
  * `pip install cfn-lint[graph]` for installing `pydot` to draw and output template graphs
  * `pip install cfn-lint[junit]` for installing the packages to output the `junit` format
  * `pip install cfn-lint[sarif]` for installing the packages to output the `sarif` format




  `brew install cfn-lint`



  In `cfn-lint` source tree:

  ```shell
  docker build --tag cfn-lint:latest .
  ```

  In repository to be linted:

  ```shell
  docker run --rm -v `pwd`:/data cfn-lint:latest /data/template.yaml
  ```



  There are IDE plugins available to get direct linter feedback from you favorite editor:

  - [Atom](https://atom.io/packages/atom-cfn-lint)
  - [Emacs](https://www.emacswiki.org/emacs/CfnLint)
  - NeoVim 0.2.0+/Vim 8
    - [ALE](https://github.com/w0rp/ale#supported-languages)
    - [Coc](https://github.com/joenye/coc-cfn-lint)
    - [Syntastic](https://github.com/speshak/vim-cfn)
  - [Sublime](https://packagecontrol.io/packages/SublimeLinter-contrib-cloudformation)
  - [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=kddejong.vscode-cfn-lint)
  - [IntelliJ IDEA](https://plugins.jetbrains.com/plugin/10973-cfn-lint)







  - `cfn-lint template.yaml`
  - `cfn-lint -t template.yaml`

  Multiple files can be linted by either specifying multiple specific files:

  - `cfn-lint template1.yaml template2.yaml`
  - `cfn-lint -t template1.yaml template2.yaml`

  or by using wildcards (globbing):

  Lint all `yaml` files in `path`:

  - `cfn-lint path/*.yaml`

  Lint all `yaml` files in `path` and all subdirectories (recursive):

  - `cfn-lint path/**/*.yaml`

  _Note_: If using sh/bash/zsh, you must enable globbing.
  (`shopt -s globstar` for sh/bash, `setopt extended_glob` for zsh).



  `cfn-lint` will return a non zero exit if there are any issues with your template. The value is dependent on the severity of the issues found. For each level of discovered error `cfn-lint` will use bitwise OR to determine the final exit code. This will result in these possibilities.

  - 0 is no issue was found
  - 2 is an error
  - 4 is a warning
  - 6 is an error and a warning
  - 8 is an informational
  - 10 is an error and informational
  - 12 is an warning and informational
  - 14 is an error and a warning and an informational



  `cfn-lint` allows you to configure exit codes. You can provide the parameter `--non-zero-exit-code` with a value of `informational`, `warning`, `error`, or `none`. `cfn-lint` will determine the exit code based on the match severity being the value of the parameter `--non-zero-exit-code` and higher. The exit codes will remain the same as above.

  The order of severity is as follows:

  1. `informational` _default_
  1. `warning`
  1. `error`
  1. `none` _Exit code will always be 0 unless there is a syntax error_



  The template to be linted can also be passed using standard input:

  - `cat path/template.yaml | cfn-lint -`



  - `cfn-lint -r us-east-1 ap-south-1 -- template.yaml`
  - `cfn-lint -r us-east-1 ap-south-1 -t template.yaml`





  From a command prompt run `cfn-lint <path to template>` to run standard linting of the template.



  It will look for a configuration file in the following locations (by order of preference):

  - `.cfnlintrc`, `.cfnlintrc.yaml` or `.cfnlintrc.yml` in the current working directory
  - `~/.cfnlintrc` for the home directory

  In that file you can specify settings from the parameter section below.

  Example:

  ```yaml
  templates:
    - test/fixtures/templates/good/**/*.yaml
  ignore_templates:
    - codebuild.yaml
  include_checks:
    - I
  custom_rules: custom_rules.txt
  ```



  Optional parameters:

  | Command Line               | Metadata             | Options                                        | Description                                                                                                                                                                                                                                           |
  | -------------------------- | -------------------- | ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | -h, --help                 |                      |                                                | Get description of cfn-lint                                                                                                                                                                                                                           |
  | -z, --custom-rules         |                      | filename                                       | Text file containing user-defined custom rules. See [here](#Custom-Rules) for more information                                                                                                                                                        |
  | -t, --template             |                      | filename                                       | Alternative way to specify Template file path to the file that needs to be tested by cfn-lint                                                                                                                                                         |
  | -f, --format               | format               | quiet, parseable, json, junit, pretty, sarif   | Output format                                                                                                                                                                                                                                         |
  | -l, --list-rules           |                      |                                                | List all the rules                                                                                                                                                                                                                                    |
  | -r, --regions              | regions              | [REGIONS [REGIONS ...]], ALL_REGIONS           | Test the template against many regions. [Supported regions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html)                                                                                                |
  | -b, --ignore-bad-template  | ignore_bad_template  |                                                | Ignores bad template errors                                                                                                                                                                                                                           |
  | --ignore-templates         |                      | IGNORE_TEMPLATES [IGNORE_TEMPLATES ...]        | Ignore templates from being scanned                                                                                                                                                                                                                   |
  | -a, --append-rules         | append_rules         | [RULESPATH [RULESPATH ...]]                    | Specify one or more rules paths using one or more --append-rules arguments. Each path can be either a directory containing python files, or an import path to a module.                                                                               |
  | -i, --ignore-checks        | ignore_checks        | [IGNORE_CHECKS [IGNORE_CHECKS ...]]            | Only check rules whose ID do not match or prefix these values. Examples: <br />- A value of `W` will disable all warnings<br />- `W2` disables all Warnings for Parameter rules.<br />- `W2001` will disable rule `W2001`                             |
  | -e, --include-experimental | include_experimental |                                                | Whether rules that still in an experimental state should be included in the checks                                                                                                                                                                    |
  | -c, --include-checks       |                      | INCLUDE_CHECKS [INCLUDE_CHECKS ...]            | Include rules whose id match these values                                                                                                                                                                                                             |
  | -m, --mandatory-checks     |                      |                                                | Rules to check regardless of ignore configuration                                                                                                                                                                                                     |
  | --non-zero-exit-code       |                      | informational (default), warning, error, none] | Exit code will be non zero from the specified rule class and higher                                                                                                                                                                                   |
  | -x, --configure-rule       |                      | CONFIGURE_RULES [CONFIGURE_RULES ...]          | Provide configuration for a rule. Format RuleId:key=value. Example: E3012:strict=true                                                                                                                                                                 |
  | -D, --debug                |                      |                                                | Specify to enable debug logging. Debug logging outputs detailed information about rules processing, useful for debugging rules.                                                                                                                       |
  | -I, --info                 |                      |                                                | Specify to enable logging. Outputs additional information about the template processing.                                                                                                                                                              |
  | -u, --update-specs         |                      |                                                | Update the [CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html). You may need sudo to run this. You will need internet access when running this command              |
  | -o, --override-spec        |                      | filename                                       | Spec-style file containing custom definitions. Can be used to override CloudFormation specifications. More info [here](#customize-specifications)                                                                                                     |
  | -g, --build-graph          |                      |                                                | Creates a file in the same directory as the template that models the template's resources in [DOT format](<https://en.wikipedia.org/wiki/DOT_(graph_description_language)>)                                                                           |
  | -s, --registry-schemas     |                      |                                                | one or more directories of [CloudFormation Registry](https://aws.amazon.com/blogs/aws/cloudformation-update-cli-third-party-resource-support-registry/) [Resource Schemas](https://github.com/aws-cloudformation/aws-cloudformation-resource-schema/) |
  | -v, --version              |                      |                                                | Version of cfn-lint                                                                                                                                                                                                                                   |



  To maintain backwards compatibility `info` rules are not included by default. To include these rules you will need to include `-c I` or `--include-checks I`





  Inside the root level Metadata key you can configure cfn-lint using the supported parameters.

  ```yaml
  Metadata:
    cfn-lint:
      config:
        regions:
          - us-east-1
          - us-east-2
        ignore_checks:
          - E2530
  ```



  Inside a resources Metadata key you can configure cfn-lint to ignore checks. This will filter out failures for the resource in which the Metadata belongs. Keep in mind that [`AWS::Serverless` resources may lose metadata during the Serverless transform](https://github.com/awslabs/serverless-application-model/issues/450#issuecomment-643420308)

  ```yaml
  Resources:
    myInstance:
      Type: AWS::EC2::Instance
      Metadata:
        cfn-lint:
          config:
            ignore_checks:
              - E3030
      Properties:
        InstanceType: nt.x4superlarge
        ImageId: ami-abc1234
  ```



  cfn-lint applies configurations from several sources. The rules at lower levels are overridden by those at higher levels.

  1. cfnlintrc configurations
  2. Template Metadata configurations
  3. CLI parameters



  Certain rules support configuration properties. You can configure these rules by using `configure_rules` parameter.

  From the command line the format is `RuleId:key=value`, for example: `E3012:strict=true`.
  From the cfnlintrc or Metadata section the format is

  ```yaml
  Metadata:
    cfn-lint:
      config:
        configure_rules:
          RuleId:
            key: value
  ```

  The configurable rules have a non-empty Config entry in the table [here](docs/rules.md#rules-1).



  There are [getting started guides](/docs/getting_started) available in the documentation section to help with integrating `cfn-lint` or creating rules.



  This linter checks the AWS CloudFormation template by processing a collection of Rules, where every rule handles a specific function check or validation of the template.

  This collection of rules can be extended with custom rules using the `--append-rules` argument.

  More information describing how rules are set up and an overview of all the Rules that are applied by this linter are documented [here](docs/rules.md).



  The linter supports the creation of custom one-line rules which compare any resource with a property using pre-defined operators. These custom rules take the following format:

  ```
  <Resource Type> <Property[*]> <Operator> <Value> [Error Level] [Custom Error Message]
  ```



  A separate custom rule text file must be created.

  The example below validates `example_template.yml` does not use any EC2 instances of size `m4.16xlarge`

  _custom_rule.txt_

  ```
  AWS::EC2::Instance InstanceType NOT_EQUALS "m4.16xlarge" WARN "This is an expensive instance type, don't use it"
  ```

  _example_template.yml_

  ```yaml
  AWSTemplateFormatVersion: "2010-09-09"
  Resources:
    myInstance:
      Type: AWS::EC2::Instance
      Properties:
        InstanceType: m4.16xlarge
        ImageId: ami-asdfef
  ```

  The custom rule can be added to the [configuration file](#Config-File) or ran as a [command line argument](#Parameters)

  The linter will produce the following output, running `cfn-lint example_template.yml -z custom_rules.txt`:

  ```
  W9001  This is an expensive instance type, don't use it
  mqtemplate.yml:6:17
  ```

  More information describing how custom rules are setup and an overview of all operators available is documented [here](docs/custom_rules.md).



  The linter follows the [AWS CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html) by default. However, for your use case specific requirements might exist. For example, within your organisation it might be mandatory to use [Tagging](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/).

  The linter provides the possibility to implement these customized specifications using the `--override-spec` argument.

  More information about how this feature works is documented [here](docs/customize_specifications.md)



  If you'd like cfn-lint to be run automatically when making changes to files in your Git repository, you can install [pre-commit](https://pre-commit.com/) and add the following text to your repositories' `.pre-commit-config.yaml`:

  ```yaml
  repos:
    - repo: https://github.com/aws-cloudformation/cfn-lint
      rev: v1.14.1 # The version of cfn-lint to use
      hooks:
        - id: cfn-lint
          files: path/to/cfn/dir/.*\.(json|yml|yaml)$
  ```

  If you are using a `.cfnlintrc` and specifying the `templates` or `ignore_templates` we would recommend using the `.cfnlintrc` exlusively to determine which files should be scanned and then using:

  ```yaml
  repos:
    - repo: https://github.com/aws-cloudformation/cfn-lint
      rev: v1.14.1 # The version of cfn-lint to use
      hooks:
        - id: cfn-lint-rc
  ```

  _Note: When mixing .cfnlintrc ignore_templates and files option in your .pre-commit-config.yaml cfn-lint may return a file not found error_

  - If you exclude the `files:` line above, every json/yml/yaml file will be checked.
  - You can see available cfn-lint versions on the [releases page](https://github.com/aws-cloudformation/cfn-python-lint/releases).


pkgId: f26b7a602679032408047798e5cd49e58fa16a035aa0c775e84df78e4bd712e7
name: python-cfn-lint
arch: src
version: 1.16.0
epoch: 0
release: 1
summary: Checks CloudFormation templates for practices and behaviour that could potentially be improved
url: https://github.com/aws-cloudformation/cfn-lint
rpm_license: MIT no attribution
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfn-lint-1.16.0-1.src.rpm
checksum_type: sha256
description:
  <img alt="[cfn-lint logo]" src="https://github.com/aws-cloudformation/cfn-python-lint/blob/main/logo.png?raw=true" width="150" align="right">

  [![Testing](https://github.com/aws-cloudformation/cfn-python-lint/actions/workflows/test.yaml/badge.svg?branch=main)](https://github.com/aws-cloudformation/cfn-python-lint/actions/workflows/test.yaml)
  [![PyPI version](https://badge.fury.io/py/cfn-lint.svg)](https://badge.fury.io/py/cfn-lint)
  [![PyPI downloads](https://pepy.tech/badge/cfn-lint/week)](https://pypistats.org/packages/cfn-lint)
  [![PyPI downloads](https://pepy.tech/badge/cfn-lint/month)](https://pypistats.org/packages/cfn-lint)
  [![codecov](https://codecov.io/gh/aws-cloudformation/cfn-lint/branch/main/graph/badge.svg)](https://codecov.io/gh/aws-cloudformation/cfn-python-lint)
  [![Discord Shield](https://img.shields.io/discord/981586120448020580?logo=discord)](https://discord.gg/KENDm6DHCv)

  Validate AWS CloudFormation yaml/json templates against the [AWS CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html) and additional checks. Includes checking valid values for resource properties and best practices.



  This is an attempt to provide validation for AWS CloudFormation templates properties and
  their values. For values things can get pretty complicated (mappings, joins, splits,
  conditions, and nesting those functions inside each other) so it's a best effort to
  validate those values but the promise is to not fail if we can't understand or translate
  all the things that could be going on.



  We encourage you to contribute to `cfn-lint`! Please check out the [Contributing Guidelines](https://github.com/aws-cloudformation/cfn-lint/blob/main/CONTRIBUTING.md) for more information on how to proceed.



  Join us on Discord! Connect & interact with CloudFormation developers &
  experts, find channels to discuss and get help for cfn-lint, CloudFormation registry, StackSets,
  Guard and more:

  [![Join our Discord](https://discordapp.com/api/guilds/981586120448020580/widget.png?style=banner3)](https://discord.gg/9zpd7TTRwq)



  The Serverless Application Model (SAM) is supported by the linter. The template is
  transformed using [AWS SAM](https://github.com/awslabs/serverless-application-model) before the linter processes the template.

  _To get information about the [SAM Transformation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/transform-aws-serverless.html), run the linter with `--info`_



  Python 3.8+ is supported.



  `pip install cfn-lint`. If pip is not available, run
  `python setup.py clean --all` then `python setup.py install`.



  `cfn-lint` has optional dependencies based on certain features you may need.

  * `pip install cfn-lint[full]` for installing all the optional dependencies. This will install all the dependencies for graph, junit, and sarif.
  * `pip install cfn-lint[graph]` for installing `pydot` to draw and output template graphs
  * `pip install cfn-lint[junit]` for installing the packages to output the `junit` format
  * `pip install cfn-lint[sarif]` for installing the packages to output the `sarif` format




  `brew install cfn-lint`



  In `cfn-lint` source tree:

  ```shell
  docker build --tag cfn-lint:latest .
  ```

  In repository to be linted:

  ```shell
  docker run --rm -v `pwd`:/data cfn-lint:latest /data/template.yaml
  ```



  There are IDE plugins available to get direct linter feedback from you favorite editor:

  - [Atom](https://atom.io/packages/atom-cfn-lint)
  - [Emacs](https://www.emacswiki.org/emacs/CfnLint)
  - NeoVim 0.2.0+/Vim 8
    - [ALE](https://github.com/w0rp/ale#supported-languages)
    - [Coc](https://github.com/joenye/coc-cfn-lint)
    - [Syntastic](https://github.com/speshak/vim-cfn)
  - [Sublime](https://packagecontrol.io/packages/SublimeLinter-contrib-cloudformation)
  - [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=kddejong.vscode-cfn-lint)
  - [IntelliJ IDEA](https://plugins.jetbrains.com/plugin/10973-cfn-lint)







  - `cfn-lint template.yaml`
  - `cfn-lint -t template.yaml`

  Multiple files can be linted by either specifying multiple specific files:

  - `cfn-lint template1.yaml template2.yaml`
  - `cfn-lint -t template1.yaml template2.yaml`

  or by using wildcards (globbing):

  Lint all `yaml` files in `path`:

  - `cfn-lint path/*.yaml`

  Lint all `yaml` files in `path` and all subdirectories (recursive):

  - `cfn-lint path/**/*.yaml`

  _Note_: If using sh/bash/zsh, you must enable globbing.
  (`shopt -s globstar` for sh/bash, `setopt extended_glob` for zsh).



  `cfn-lint` will return a non zero exit if there are any issues with your template. The value is dependent on the severity of the issues found. For each level of discovered error `cfn-lint` will use bitwise OR to determine the final exit code. This will result in these possibilities.

  - 0 is no issue was found
  - 2 is an error
  - 4 is a warning
  - 6 is an error and a warning
  - 8 is an informational
  - 10 is an error and informational
  - 12 is an warning and informational
  - 14 is an error and a warning and an informational



  `cfn-lint` allows you to configure exit codes. You can provide the parameter `--non-zero-exit-code` with a value of `informational`, `warning`, `error`, or `none`. `cfn-lint` will determine the exit code based on the match severity being the value of the parameter `--non-zero-exit-code` and higher. The exit codes will remain the same as above.

  The order of severity is as follows:

  1. `informational` _default_
  1. `warning`
  1. `error`
  1. `none` _Exit code will always be 0 unless there is a syntax error_



  The template to be linted can also be passed using standard input:

  - `cat path/template.yaml | cfn-lint -`



  - `cfn-lint -r us-east-1 ap-south-1 -- template.yaml`
  - `cfn-lint -r us-east-1 ap-south-1 -t template.yaml`





  From a command prompt run `cfn-lint <path to template>` to run standard linting of the template.



  It will look for a configuration file in the following locations (by order of preference):

  - `.cfnlintrc`, `.cfnlintrc.yaml` or `.cfnlintrc.yml` in the current working directory
  - `~/.cfnlintrc` for the home directory

  In that file you can specify settings from the parameter section below.

  Example:

  ```yaml
  templates:
    - test/fixtures/templates/good/**/*.yaml
  ignore_templates:
    - codebuild.yaml
  include_checks:
    - I
  custom_rules: custom_rules.txt
  ```



  Optional parameters:

  | Command Line               | Metadata             | Options                                        | Description                                                                                                                                                                                                                                           |
  | -------------------------- | -------------------- | ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | -h, --help                 |                      |                                                | Get description of cfn-lint                                                                                                                                                                                                                           |
  | -z, --custom-rules         |                      | filename                                       | Text file containing user-defined custom rules. See [here](#Custom-Rules) for more information                                                                                                                                                        |
  | -t, --template             |                      | filename                                       | Alternative way to specify Template file path to the file that needs to be tested by cfn-lint                                                                                                                                                         |
  | -f, --format               | format               | quiet, parseable, json, junit, pretty, sarif   | Output format                                                                                                                                                                                                                                         |
  | -l, --list-rules           |                      |                                                | List all the rules                                                                                                                                                                                                                                    |
  | -r, --regions              | regions              | [REGIONS [REGIONS ...]], ALL_REGIONS           | Test the template against many regions. [Supported regions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html)                                                                                                |
  | -b, --ignore-bad-template  | ignore_bad_template  |                                                | Ignores bad template errors                                                                                                                                                                                                                           |
  | --ignore-templates         |                      | IGNORE_TEMPLATES [IGNORE_TEMPLATES ...]        | Ignore templates from being scanned                                                                                                                                                                                                                   |
  | -a, --append-rules         | append_rules         | [RULESPATH [RULESPATH ...]]                    | Specify one or more rules paths using one or more --append-rules arguments. Each path can be either a directory containing python files, or an import path to a module.                                                                               |
  | -i, --ignore-checks        | ignore_checks        | [IGNORE_CHECKS [IGNORE_CHECKS ...]]            | Only check rules whose ID do not match or prefix these values. Examples: <br />- A value of `W` will disable all warnings<br />- `W2` disables all Warnings for Parameter rules.<br />- `W2001` will disable rule `W2001`                             |
  | -e, --include-experimental | include_experimental |                                                | Whether rules that still in an experimental state should be included in the checks                                                                                                                                                                    |
  | -c, --include-checks       |                      | INCLUDE_CHECKS [INCLUDE_CHECKS ...]            | Include rules whose id match these values                                                                                                                                                                                                             |
  | -m, --mandatory-checks     |                      |                                                | Rules to check regardless of ignore configuration                                                                                                                                                                                                     |
  | --non-zero-exit-code       |                      | informational (default), warning, error, none] | Exit code will be non zero from the specified rule class and higher                                                                                                                                                                                   |
  | -x, --configure-rule       |                      | CONFIGURE_RULES [CONFIGURE_RULES ...]          | Provide configuration for a rule. Format RuleId:key=value. Example: E3012:strict=true                                                                                                                                                                 |
  | -D, --debug                |                      |                                                | Specify to enable debug logging. Debug logging outputs detailed information about rules processing, useful for debugging rules.                                                                                                                       |
  | -I, --info                 |                      |                                                | Specify to enable logging. Outputs additional information about the template processing.                                                                                                                                                              |
  | -u, --update-specs         |                      |                                                | Update the [CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html). You may need sudo to run this. You will need internet access when running this command              |
  | -o, --override-spec        |                      | filename                                       | Spec-style file containing custom definitions. Can be used to override CloudFormation specifications. More info [here](#customize-specifications)                                                                                                     |
  | -g, --build-graph          |                      |                                                | Creates a file in the same directory as the template that models the template's resources in [DOT format](<https://en.wikipedia.org/wiki/DOT_(graph_description_language)>)                                                                           |
  | -s, --registry-schemas     |                      |                                                | one or more directories of [CloudFormation Registry](https://aws.amazon.com/blogs/aws/cloudformation-update-cli-third-party-resource-support-registry/) [Resource Schemas](https://github.com/aws-cloudformation/aws-cloudformation-resource-schema/) |
  | -v, --version              |                      |                                                | Version of cfn-lint                                                                                                                                                                                                                                   |



  To maintain backwards compatibility `info` rules are not included by default. To include these rules you will need to include `-c I` or `--include-checks I`





  Inside the root level Metadata key you can configure cfn-lint using the supported parameters.

  ```yaml
  Metadata:
    cfn-lint:
      config:
        regions:
          - us-east-1
          - us-east-2
        ignore_checks:
          - E2530
  ```



  Inside a resources Metadata key you can configure cfn-lint to ignore checks. This will filter out failures for the resource in which the Metadata belongs. Keep in mind that [`AWS::Serverless` resources may lose metadata during the Serverless transform](https://github.com/awslabs/serverless-application-model/issues/450#issuecomment-643420308)

  ```yaml
  Resources:
    myInstance:
      Type: AWS::EC2::Instance
      Metadata:
        cfn-lint:
          config:
            ignore_checks:
              - E3030
      Properties:
        InstanceType: nt.x4superlarge
        ImageId: ami-abc1234
  ```



  cfn-lint applies configurations from several sources. The rules at lower levels are overridden by those at higher levels.

  1. cfnlintrc configurations
  2. Template Metadata configurations
  3. CLI parameters



  Certain rules support configuration properties. You can configure these rules by using `configure_rules` parameter.

  From the command line the format is `RuleId:key=value`, for example: `E3012:strict=true`.
  From the cfnlintrc or Metadata section the format is

  ```yaml
  Metadata:
    cfn-lint:
      config:
        configure_rules:
          RuleId:
            key: value
  ```

  The configurable rules have a non-empty Config entry in the table [here](docs/rules.md#rules-1).



  There are [getting started guides](/docs/getting_started) available in the documentation section to help with integrating `cfn-lint` or creating rules.



  This linter checks the AWS CloudFormation template by processing a collection of Rules, where every rule handles a specific function check or validation of the template.

  This collection of rules can be extended with custom rules using the `--append-rules` argument.

  More information describing how rules are set up and an overview of all the Rules that are applied by this linter are documented [here](docs/rules.md).



  The linter supports the creation of custom one-line rules which compare any resource with a property using pre-defined operators. These custom rules take the following format:

  ```
  <Resource Type> <Property[*]> <Operator> <Value> [Error Level] [Custom Error Message]
  ```



  A separate custom rule text file must be created.

  The example below validates `example_template.yml` does not use any EC2 instances of size `m4.16xlarge`

  _custom_rule.txt_

  ```
  AWS::EC2::Instance InstanceType NOT_EQUALS "m4.16xlarge" WARN "This is an expensive instance type, don't use it"
  ```

  _example_template.yml_

  ```yaml
  AWSTemplateFormatVersion: "2010-09-09"
  Resources:
    myInstance:
      Type: AWS::EC2::Instance
      Properties:
        InstanceType: m4.16xlarge
        ImageId: ami-asdfef
  ```

  The custom rule can be added to the [configuration file](#Config-File) or ran as a [command line argument](#Parameters)

  The linter will produce the following output, running `cfn-lint example_template.yml -z custom_rules.txt`:

  ```
  W9001  This is an expensive instance type, don't use it
  mqtemplate.yml:6:17
  ```

  More information describing how custom rules are setup and an overview of all operators available is documented [here](docs/custom_rules.md).



  The linter follows the [AWS CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html) by default. However, for your use case specific requirements might exist. For example, within your organisation it might be mandatory to use [Tagging](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/).

  The linter provides the possibility to implement these customized specifications using the `--override-spec` argument.

  More information about how this feature works is documented [here](docs/customize_specifications.md)



  If you'd like cfn-lint to be run automatically when making changes to files in your Git repository, you can install [pre-commit](https://pre-commit.com/) and add the following text to your repositories' `.pre-commit-config.yaml`:

  ```yaml
  repos:
    - repo: https://github.com/aws-cloudformation/cfn-lint
      rev: v1.16.0 # The version of cfn-lint to use
      hooks:
        - id: cfn-lint
          files: path/to/cfn/dir/.*\.(json|yml|yaml)$
  ```

  If you are using a `.cfnlintrc` and specifying the `templates` or `ignore_templates` we would recommend using the `.cfnlintrc` exlusively to determine which files should be scanned and then using:

  ```yaml
  repos:
    - repo: https://github.com/aws-cloudformation/cfn-lint
      rev: v1.16.0 # The version of cfn-lint to use
      hooks:
        - id: cfn-lint-rc
  ```

  _Note: When mixing .cfnlintrc ignore_templates and files option in your .pre-commit-config.yaml cfn-lint may return a file not found error_

  - If you exclude the `files:` line above, every json/yml/yaml file will be checked.
  - You can see available cfn-lint versions on the [releases page](https://github.com/aws-cloudformation/cfn-python-lint/releases).


pkgId: 60eac3f891b1f1ab3bf322d0376688e46514c59317b345ff9cdd13398e318fcc
name: python-cfn-lint
arch: src
version: 1.20.0
epoch: 0
release: 1
summary: Checks CloudFormation templates for practices and behaviour that could potentially be improved
url: https://github.com/aws-cloudformation/cfn-lint
rpm_license: MIT no attribution
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfn-lint-1.20.0-1.src.rpm
checksum_type: sha256
description:
  <img alt="[cfn-lint logo]" src="https://github.com/aws-cloudformation/cfn-python-lint/blob/main/logo.png?raw=true" width="150" align="right">

  [![Testing](https://github.com/aws-cloudformation/cfn-python-lint/actions/workflows/test.yaml/badge.svg?branch=main)](https://github.com/aws-cloudformation/cfn-python-lint/actions/workflows/test.yaml)
  [![PyPI version](https://badge.fury.io/py/cfn-lint.svg)](https://badge.fury.io/py/cfn-lint)
  [![PyPI downloads](https://pepy.tech/badge/cfn-lint/week)](https://pypistats.org/packages/cfn-lint)
  [![PyPI downloads](https://pepy.tech/badge/cfn-lint/month)](https://pypistats.org/packages/cfn-lint)
  [![codecov](https://codecov.io/gh/aws-cloudformation/cfn-lint/branch/main/graph/badge.svg)](https://codecov.io/gh/aws-cloudformation/cfn-python-lint)
  [![Discord Shield](https://img.shields.io/discord/981586120448020580?logo=discord)](https://discord.gg/KENDm6DHCv)

  Validate AWS CloudFormation yaml/json templates against the [AWS CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html) and additional checks. Includes checking valid values for resource properties and best practices.



  This is an attempt to provide validation for AWS CloudFormation templates properties and
  their values. For values things can get pretty complicated (mappings, joins, splits,
  conditions, and nesting those functions inside each other) so it's a best effort to
  validate those values but the promise is to not fail if we can't understand or translate
  all the things that could be going on.



  We encourage you to contribute to `cfn-lint`! Please check out the [Contributing Guidelines](https://github.com/aws-cloudformation/cfn-lint/blob/main/CONTRIBUTING.md) for more information on how to proceed.



  Join us on Discord! Connect & interact with CloudFormation developers &
  experts, find channels to discuss and get help for cfn-lint, CloudFormation registry, StackSets,
  Guard and more:

  [![Join our Discord](https://discordapp.com/api/guilds/981586120448020580/widget.png?style=banner3)](https://discord.gg/9zpd7TTRwq)



  The Serverless Application Model (SAM) is supported by the linter. The template is
  transformed using [AWS SAM](https://github.com/awslabs/serverless-application-model) before the linter processes the template.

  _To get information about the [SAM Transformation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/transform-aws-serverless.html), run the linter with `--info`_



  Python 3.8+ is supported.



  `pip install cfn-lint`. If pip is not available, run
  `python setup.py clean --all` then `python setup.py install`.



  `cfn-lint` has optional dependencies based on certain features you may need.

  * `pip install cfn-lint[full]` for installing all the optional dependencies. This will install all the dependencies for graph, junit, and sarif.
  * `pip install cfn-lint[graph]` for installing `pydot` to draw and output template graphs
  * `pip install cfn-lint[junit]` for installing the packages to output the `junit` format
  * `pip install cfn-lint[sarif]` for installing the packages to output the `sarif` format




  `brew install cfn-lint`



  In `cfn-lint` source tree:

  ```shell
  docker build --tag cfn-lint:latest .
  ```

  In repository to be linted:

  ```shell
  docker run --rm -v `pwd`:/data cfn-lint:latest /data/template.yaml
  ```



  There are IDE plugins available to get direct linter feedback from you favorite editor:

  - [Atom](https://atom.io/packages/atom-cfn-lint)
  - [Emacs](https://www.emacswiki.org/emacs/CfnLint)
  - NeoVim 0.2.0+/Vim 8
    - [ALE](https://github.com/w0rp/ale#supported-languages)
    - [Coc](https://github.com/joenye/coc-cfn-lint)
    - [Syntastic](https://github.com/speshak/vim-cfn)
  - [Sublime](https://packagecontrol.io/packages/SublimeLinter-contrib-cloudformation)
  - [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=kddejong.vscode-cfn-lint)
  - [IntelliJ IDEA](https://plugins.jetbrains.com/plugin/10973-cfn-lint)







  - `cfn-lint template.yaml`
  - `cfn-lint -t template.yaml`

  Multiple files can be linted by either specifying multiple specific files:

  - `cfn-lint template1.yaml template2.yaml`
  - `cfn-lint -t template1.yaml template2.yaml`

  or by using wildcards (globbing):

  Lint all `yaml` files in `path`:

  - `cfn-lint path/*.yaml`

  Lint all `yaml` files in `path` and all subdirectories (recursive):

  - `cfn-lint path/**/*.yaml`

  _Note_: If using sh/bash/zsh, you must enable globbing.
  (`shopt -s globstar` for sh/bash, `setopt extended_glob` for zsh).



  `cfn-lint` will return a non zero exit if there are any issues with your template. The value is dependent on the severity of the issues found. For each level of discovered error `cfn-lint` will use bitwise OR to determine the final exit code. This will result in these possibilities.

  - 0 is no issue was found
  - 2 is an error
  - 4 is a warning
  - 6 is an error and a warning
  - 8 is an informational
  - 10 is an error and informational
  - 12 is an warning and informational
  - 14 is an error and a warning and an informational



  `cfn-lint` allows you to configure exit codes. You can provide the parameter `--non-zero-exit-code` with a value of `informational`, `warning`, `error`, or `none`. `cfn-lint` will determine the exit code based on the match severity being the value of the parameter `--non-zero-exit-code` and higher. The exit codes will remain the same as above.

  The order of severity is as follows:

  1. `informational` _default_
  1. `warning`
  1. `error`
  1. `none` _Exit code will always be 0 unless there is a syntax error_



  The template to be linted can also be passed using standard input:

  - `cat path/template.yaml | cfn-lint -`



  - `cfn-lint -r us-east-1 ap-south-1 -- template.yaml`
  - `cfn-lint -r us-east-1 ap-south-1 -t template.yaml`





  From a command prompt run `cfn-lint <path to template>` to run standard linting of the template.



  It will look for a configuration file in the following locations (by order of preference):

  - `.cfnlintrc`, `.cfnlintrc.yaml` or `.cfnlintrc.yml` in the current working directory
  - `~/.cfnlintrc` for the home directory

  In that file you can specify settings from the parameter section below.

  Example:

  ```yaml
  templates:
    - test/fixtures/templates/good/**/*.yaml
  ignore_templates:
    - codebuild.yaml
  include_checks:
    - I
  custom_rules: custom_rules.txt
  ```



  Optional parameters:

  | Command Line               | Metadata             | Options                                        | Description                                                                                                                                                                                                                                           |
  | -------------------------- | -------------------- | ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | -h, --help                 |                      |                                                | Get description of cfn-lint                                                                                                                                                                                                                           |
  | -z, --custom-rules         |                      | filename                                       | Text file containing user-defined custom rules. See [here](#Custom-Rules) for more information                                                                                                                                                        |
  | -t, --template             |                      | filename                                       | Alternative way to specify Template file path to the file that needs to be tested by cfn-lint                                                                                                                                                         |
  | -f, --format               | format               | quiet, parseable, json, junit, pretty, sarif   | Output format                                                                                                                                                                                                                                         |
  | -l, --list-rules           |                      |                                                | List all the rules                                                                                                                                                                                                                                    |
  | -r, --regions              | regions              | [REGIONS [REGIONS ...]], ALL_REGIONS           | Test the template against many regions. [Supported regions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html)                                                                                                |
  | -b, --ignore-bad-template  | ignore_bad_template  |                                                | Ignores bad template errors                                                                                                                                                                                                                           |
  | --ignore-templates         |                      | IGNORE_TEMPLATES [IGNORE_TEMPLATES ...]        | Ignore templates from being scanned                                                                                                                                                                                                                   |
  | -a, --append-rules         | append_rules         | [RULESPATH [RULESPATH ...]]                    | Specify one or more rules paths using one or more --append-rules arguments. Each path can be either a directory containing python files, or an import path to a module.                                                                               |
  | -i, --ignore-checks        | ignore_checks        | [IGNORE_CHECKS [IGNORE_CHECKS ...]]            | Only check rules whose ID do not match or prefix these values. Examples: <br />- A value of `W` will disable all warnings<br />- `W2` disables all Warnings for Parameter rules.<br />- `W2001` will disable rule `W2001`                             |
  | -e, --include-experimental | include_experimental |                                                | Whether rules that still in an experimental state should be included in the checks                                                                                                                                                                    |
  | -c, --include-checks       |                      | INCLUDE_CHECKS [INCLUDE_CHECKS ...]            | Include rules whose id match these values                                                                                                                                                                                                             |
  | -m, --mandatory-checks     |                      |                                                | Rules to check regardless of ignore configuration                                                                                                                                                                                                     |
  | --non-zero-exit-code       |                      | informational (default), warning, error, none] | Exit code will be non zero from the specified rule class and higher                                                                                                                                                                                   |
  | -x, --configure-rule       |                      | CONFIGURE_RULES [CONFIGURE_RULES ...]          | Provide configuration for a rule. Format RuleId:key=value. Example: E3012:strict=true                                                                                                                                                                 |
  | -D, --debug                |                      |                                                | Specify to enable debug logging. Debug logging outputs detailed information about rules processing, useful for debugging rules.                                                                                                                       |
  | -I, --info                 |                      |                                                | Specify to enable logging. Outputs additional information about the template processing.                                                                                                                                                              |
  | -u, --update-specs         |                      |                                                | Update the [CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html). You may need sudo to run this. You will need internet access when running this command              |
  | -o, --override-spec        |                      | filename                                       | Spec-style file containing custom definitions. Can be used to override CloudFormation specifications. More info [here](#customize-specifications)                                                                                                     |
  | -g, --build-graph          |                      |                                                | Creates a file in the same directory as the template that models the template's resources in [DOT format](<https://en.wikipedia.org/wiki/DOT_(graph_description_language)>)                                                                           |
  | -s, --registry-schemas     |                      |                                                | one or more directories of [CloudFormation Registry](https://aws.amazon.com/blogs/aws/cloudformation-update-cli-third-party-resource-support-registry/) [Resource Schemas](https://github.com/aws-cloudformation/aws-cloudformation-resource-schema/) |
  | -v, --version              |                      |                                                | Version of cfn-lint                                                                                                                                                                                                                                   |



  To maintain backwards compatibility `info` rules are not included by default. To include these rules you will need to include `-c I` or `--include-checks I`





  Inside the root level Metadata key you can configure cfn-lint using the supported parameters.

  ```yaml
  Metadata:
    cfn-lint:
      config:
        regions:
          - us-east-1
          - us-east-2
        ignore_checks:
          - E2530
  ```



  Inside a resources Metadata key you can configure cfn-lint to ignore checks. This will filter out failures for the resource in which the Metadata belongs. Keep in mind that [`AWS::Serverless` resources may lose metadata during the Serverless transform](https://github.com/awslabs/serverless-application-model/issues/450#issuecomment-643420308)

  ```yaml
  Resources:
    myInstance:
      Type: AWS::EC2::Instance
      Metadata:
        cfn-lint:
          config:
            ignore_checks:
              - E3030
      Properties:
        InstanceType: nt.x4superlarge
        ImageId: ami-abc1234
  ```



  cfn-lint applies configurations from several sources. The rules at lower levels are overridden by those at higher levels.

  1. cfnlintrc configurations
  2. Template Metadata configurations
  3. CLI parameters



  Certain rules support configuration properties. You can configure these rules by using `configure_rules` parameter.

  From the command line the format is `RuleId:key=value`, for example: `E3012:strict=true`.
  From the cfnlintrc or Metadata section the format is

  ```yaml
  Metadata:
    cfn-lint:
      config:
        configure_rules:
          RuleId:
            key: value
  ```

  The configurable rules have a non-empty Config entry in the table [here](docs/rules.md#rules-1).



  There are [getting started guides](/docs/getting_started) available in the documentation section to help with integrating `cfn-lint` or creating rules.



  This linter checks the AWS CloudFormation template by processing a collection of Rules, where every rule handles a specific function check or validation of the template.

  This collection of rules can be extended with custom rules using the `--append-rules` argument.

  More information describing how rules are set up and an overview of all the Rules that are applied by this linter are documented [here](docs/rules.md).



  The linter supports the creation of custom one-line rules which compare any resource with a property using pre-defined operators. These custom rules take the following format:

  ```
  <Resource Type> <Property[*]> <Operator> <Value> [Error Level] [Custom Error Message]
  ```



  A separate custom rule text file must be created.

  The example below validates `example_template.yml` does not use any EC2 instances of size `m4.16xlarge`

  _custom_rule.txt_

  ```
  AWS::EC2::Instance InstanceType NOT_EQUALS "m4.16xlarge" WARN "This is an expensive instance type, don't use it"
  ```

  _example_template.yml_

  ```yaml
  AWSTemplateFormatVersion: "2010-09-09"
  Resources:
    myInstance:
      Type: AWS::EC2::Instance
      Properties:
        InstanceType: m4.16xlarge
        ImageId: ami-asdfef
  ```

  The custom rule can be added to the [configuration file](#Config-File) or ran as a [command line argument](#Parameters)

  The linter will produce the following output, running `cfn-lint example_template.yml -z custom_rules.txt`:

  ```
  W9001  This is an expensive instance type, don't use it
  mqtemplate.yml:6:17
  ```

  More information describing how custom rules are setup and an overview of all operators available is documented [here](docs/custom_rules.md).



  The linter follows the [AWS CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html) by default. However, for your use case specific requirements might exist. For example, within your organisation it might be mandatory to use [Tagging](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/).

  The linter provides the possibility to implement these customized specifications using the `--override-spec` argument.

  More information about how this feature works is documented [here](docs/customize_specifications.md)



  If you'd like cfn-lint to be run automatically when making changes to files in your Git repository, you can install [pre-commit](https://pre-commit.com/) and add the following text to your repositories' `.pre-commit-config.yaml`:

  ```yaml
  repos:
    - repo: https://github.com/aws-cloudformation/cfn-lint
      rev: v1.20.0 # The version of cfn-lint to use
      hooks:
        - id: cfn-lint
          files: path/to/cfn/dir/.*\.(json|yml|yaml)$
  ```

  If you are using a `.cfnlintrc` and specifying the `templates` or `ignore_templates` we would recommend using the `.cfnlintrc` exlusively to determine which files should be scanned and then using:

  ```yaml
  repos:
    - repo: https://github.com/aws-cloudformation/cfn-lint
      rev: v1.20.0 # The version of cfn-lint to use
      hooks:
        - id: cfn-lint-rc
  ```

  _Note: When mixing .cfnlintrc ignore_templates and files option in your .pre-commit-config.yaml cfn-lint may return a file not found error_

  - If you exclude the `files:` line above, every json/yml/yaml file will be checked.
  - You can see available cfn-lint versions on the [releases page](https://github.com/aws-cloudformation/cfn-python-lint/releases).


pkgId: 82c4a9a8e74a70edb722233057185f6138ad0e91a0258ded21245880069db00e
name: python-cfn-lint
arch: src
version: 1.20.1
epoch: 0
release: 1
summary: Checks CloudFormation templates for practices and behaviour that could potentially be improved
url: https://github.com/aws-cloudformation/cfn-lint
rpm_license: MIT no attribution
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfn-lint-1.20.1-1.src.rpm
checksum_type: sha256
description:
  <img alt="[cfn-lint logo]" src="https://github.com/aws-cloudformation/cfn-python-lint/blob/main/logo.png?raw=true" width="150" align="right">

  [![Testing](https://github.com/aws-cloudformation/cfn-python-lint/actions/workflows/test.yaml/badge.svg?branch=main)](https://github.com/aws-cloudformation/cfn-python-lint/actions/workflows/test.yaml)
  [![PyPI version](https://badge.fury.io/py/cfn-lint.svg)](https://badge.fury.io/py/cfn-lint)
  [![PyPI downloads](https://pepy.tech/badge/cfn-lint/week)](https://pypistats.org/packages/cfn-lint)
  [![PyPI downloads](https://pepy.tech/badge/cfn-lint/month)](https://pypistats.org/packages/cfn-lint)
  [![codecov](https://codecov.io/gh/aws-cloudformation/cfn-lint/branch/main/graph/badge.svg)](https://codecov.io/gh/aws-cloudformation/cfn-python-lint)
  [![Discord Shield](https://img.shields.io/discord/981586120448020580?logo=discord)](https://discord.gg/KENDm6DHCv)

  Validate AWS CloudFormation yaml/json templates against the [AWS CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html) and additional checks. Includes checking valid values for resource properties and best practices.



  This is an attempt to provide validation for AWS CloudFormation templates properties and
  their values. For values things can get pretty complicated (mappings, joins, splits,
  conditions, and nesting those functions inside each other) so it's a best effort to
  validate those values but the promise is to not fail if we can't understand or translate
  all the things that could be going on.



  We encourage you to contribute to `cfn-lint`! Please check out the [Contributing Guidelines](https://github.com/aws-cloudformation/cfn-lint/blob/main/CONTRIBUTING.md) for more information on how to proceed.



  Join us on Discord! Connect & interact with CloudFormation developers &
  experts, find channels to discuss and get help for cfn-lint, CloudFormation registry, StackSets,
  Guard and more:

  [![Join our Discord](https://discordapp.com/api/guilds/981586120448020580/widget.png?style=banner3)](https://discord.gg/9zpd7TTRwq)



  The Serverless Application Model (SAM) is supported by the linter. The template is
  transformed using [AWS SAM](https://github.com/awslabs/serverless-application-model) before the linter processes the template.

  _To get information about the [SAM Transformation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/transform-aws-serverless.html), run the linter with `--info`_



  Python 3.8+ is supported.



  `pip install cfn-lint`. If pip is not available, run
  `python setup.py clean --all` then `python setup.py install`.



  `cfn-lint` has optional dependencies based on certain features you may need.

  * `pip install cfn-lint[full]` for installing all the optional dependencies. This will install all the dependencies for graph, junit, and sarif.
  * `pip install cfn-lint[graph]` for installing `pydot` to draw and output template graphs
  * `pip install cfn-lint[junit]` for installing the packages to output the `junit` format
  * `pip install cfn-lint[sarif]` for installing the packages to output the `sarif` format




  `brew install cfn-lint`



  In `cfn-lint` source tree:

  ```shell
  docker build --tag cfn-lint:latest .
  ```

  In repository to be linted:

  ```shell
  docker run --rm -v `pwd`:/data cfn-lint:latest /data/template.yaml
  ```



  There are IDE plugins available to get direct linter feedback from you favorite editor:

  - [Atom](https://atom.io/packages/atom-cfn-lint)
  - [Emacs](https://www.emacswiki.org/emacs/CfnLint)
  - NeoVim 0.2.0+/Vim 8
    - [ALE](https://github.com/w0rp/ale#supported-languages)
    - [Coc](https://github.com/joenye/coc-cfn-lint)
    - [Syntastic](https://github.com/speshak/vim-cfn)
  - [Sublime](https://packagecontrol.io/packages/SublimeLinter-contrib-cloudformation)
  - [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=kddejong.vscode-cfn-lint)
  - [IntelliJ IDEA](https://plugins.jetbrains.com/plugin/10973-cfn-lint)







  - `cfn-lint template.yaml`
  - `cfn-lint -t template.yaml`

  Multiple files can be linted by either specifying multiple specific files:

  - `cfn-lint template1.yaml template2.yaml`
  - `cfn-lint -t template1.yaml template2.yaml`

  or by using wildcards (globbing):

  Lint all `yaml` files in `path`:

  - `cfn-lint path/*.yaml`

  Lint all `yaml` files in `path` and all subdirectories (recursive):

  - `cfn-lint path/**/*.yaml`

  _Note_: If using sh/bash/zsh, you must enable globbing.
  (`shopt -s globstar` for sh/bash, `setopt extended_glob` for zsh).



  `cfn-lint` will return a non zero exit if there are any issues with your template. The value is dependent on the severity of the issues found. For each level of discovered error `cfn-lint` will use bitwise OR to determine the final exit code. This will result in these possibilities.

  - 0 is no issue was found
  - 2 is an error
  - 4 is a warning
  - 6 is an error and a warning
  - 8 is an informational
  - 10 is an error and informational
  - 12 is an warning and informational
  - 14 is an error and a warning and an informational



  `cfn-lint` allows you to configure exit codes. You can provide the parameter `--non-zero-exit-code` with a value of `informational`, `warning`, `error`, or `none`. `cfn-lint` will determine the exit code based on the match severity being the value of the parameter `--non-zero-exit-code` and higher. The exit codes will remain the same as above.

  The order of severity is as follows:

  1. `informational` _default_
  1. `warning`
  1. `error`
  1. `none` _Exit code will always be 0 unless there is a syntax error_



  The template to be linted can also be passed using standard input:

  - `cat path/template.yaml | cfn-lint -`



  - `cfn-lint -r us-east-1 ap-south-1 -- template.yaml`
  - `cfn-lint -r us-east-1 ap-south-1 -t template.yaml`





  From a command prompt run `cfn-lint <path to template>` to run standard linting of the template.



  It will look for a configuration file in the following locations (by order of preference):

  - `.cfnlintrc`, `.cfnlintrc.yaml` or `.cfnlintrc.yml` in the current working directory
  - `~/.cfnlintrc` for the home directory

  In that file you can specify settings from the parameter section below.

  Example:

  ```yaml
  templates:
    - test/fixtures/templates/good/**/*.yaml
  ignore_templates:
    - codebuild.yaml
  include_checks:
    - I
  custom_rules: custom_rules.txt
  ```



  Optional parameters:

  | Command Line               | Metadata             | Options                                        | Description                                                                                                                                                                                                                                           |
  | -------------------------- | -------------------- | ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | -h, --help                 |                      |                                                | Get description of cfn-lint                                                                                                                                                                                                                           |
  | -z, --custom-rules         |                      | filename                                       | Text file containing user-defined custom rules. See [here](#Custom-Rules) for more information                                                                                                                                                        |
  | -t, --template             |                      | filename                                       | Alternative way to specify Template file path to the file that needs to be tested by cfn-lint                                                                                                                                                         |
  | -f, --format               | format               | quiet, parseable, json, junit, pretty, sarif   | Output format                                                                                                                                                                                                                                         |
  | -l, --list-rules           |                      |                                                | List all the rules                                                                                                                                                                                                                                    |
  | -r, --regions              | regions              | [REGIONS [REGIONS ...]], ALL_REGIONS           | Test the template against many regions. [Supported regions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html)                                                                                                |
  | -b, --ignore-bad-template  | ignore_bad_template  |                                                | Ignores bad template errors                                                                                                                                                                                                                           |
  | --ignore-templates         |                      | IGNORE_TEMPLATES [IGNORE_TEMPLATES ...]        | Ignore templates from being scanned                                                                                                                                                                                                                   |
  | -a, --append-rules         | append_rules         | [RULESPATH [RULESPATH ...]]                    | Specify one or more rules paths using one or more --append-rules arguments. Each path can be either a directory containing python files, or an import path to a module.                                                                               |
  | -i, --ignore-checks        | ignore_checks        | [IGNORE_CHECKS [IGNORE_CHECKS ...]]            | Only check rules whose ID do not match or prefix these values. Examples: <br />- A value of `W` will disable all warnings<br />- `W2` disables all Warnings for Parameter rules.<br />- `W2001` will disable rule `W2001`                             |
  | -e, --include-experimental | include_experimental |                                                | Whether rules that still in an experimental state should be included in the checks                                                                                                                                                                    |
  | -c, --include-checks       |                      | INCLUDE_CHECKS [INCLUDE_CHECKS ...]            | Include rules whose id match these values                                                                                                                                                                                                             |
  | -m, --mandatory-checks     |                      |                                                | Rules to check regardless of ignore configuration                                                                                                                                                                                                     |
  | --non-zero-exit-code       |                      | informational (default), warning, error, none] | Exit code will be non zero from the specified rule class and higher                                                                                                                                                                                   |
  | -x, --configure-rule       |                      | CONFIGURE_RULES [CONFIGURE_RULES ...]          | Provide configuration for a rule. Format RuleId:key=value. Example: E3012:strict=true                                                                                                                                                                 |
  | -D, --debug                |                      |                                                | Specify to enable debug logging. Debug logging outputs detailed information about rules processing, useful for debugging rules.                                                                                                                       |
  | -I, --info                 |                      |                                                | Specify to enable logging. Outputs additional information about the template processing.                                                                                                                                                              |
  | -u, --update-specs         |                      |                                                | Update the [CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html). You may need sudo to run this. You will need internet access when running this command              |
  | -o, --override-spec        |                      | filename                                       | Spec-style file containing custom definitions. Can be used to override CloudFormation specifications. More info [here](#customize-specifications)                                                                                                     |
  | -g, --build-graph          |                      |                                                | Creates a file in the same directory as the template that models the template's resources in [DOT format](<https://en.wikipedia.org/wiki/DOT_(graph_description_language)>)                                                                           |
  | -s, --registry-schemas     |                      |                                                | one or more directories of [CloudFormation Registry](https://aws.amazon.com/blogs/aws/cloudformation-update-cli-third-party-resource-support-registry/) [Resource Schemas](https://github.com/aws-cloudformation/aws-cloudformation-resource-schema/) |
  | -v, --version              |                      |                                                | Version of cfn-lint                                                                                                                                                                                                                                   |



  To maintain backwards compatibility `info` rules are not included by default. To include these rules you will need to include `-c I` or `--include-checks I`





  Inside the root level Metadata key you can configure cfn-lint using the supported parameters.

  ```yaml
  Metadata:
    cfn-lint:
      config:
        regions:
          - us-east-1
          - us-east-2
        ignore_checks:
          - E2530
  ```



  Inside a resources Metadata key you can configure cfn-lint to ignore checks. This will filter out failures for the resource in which the Metadata belongs. Keep in mind that [`AWS::Serverless` resources may lose metadata during the Serverless transform](https://github.com/awslabs/serverless-application-model/issues/450#issuecomment-643420308)

  ```yaml
  Resources:
    myInstance:
      Type: AWS::EC2::Instance
      Metadata:
        cfn-lint:
          config:
            ignore_checks:
              - E3030
      Properties:
        InstanceType: nt.x4superlarge
        ImageId: ami-abc1234
  ```



  cfn-lint applies configurations from several sources. The rules at lower levels are overridden by those at higher levels.

  1. cfnlintrc configurations
  2. Template Metadata configurations
  3. CLI parameters



  Certain rules support configuration properties. You can configure these rules by using `configure_rules` parameter.

  From the command line the format is `RuleId:key=value`, for example: `E3012:strict=true`.
  From the cfnlintrc or Metadata section the format is

  ```yaml
  Metadata:
    cfn-lint:
      config:
        configure_rules:
          RuleId:
            key: value
  ```

  The configurable rules have a non-empty Config entry in the table [here](docs/rules.md#rules-1).



  There are [getting started guides](/docs/getting_started) available in the documentation section to help with integrating `cfn-lint` or creating rules.



  This linter checks the AWS CloudFormation template by processing a collection of Rules, where every rule handles a specific function check or validation of the template.

  This collection of rules can be extended with custom rules using the `--append-rules` argument.

  More information describing how rules are set up and an overview of all the Rules that are applied by this linter are documented [here](docs/rules.md).



  The linter supports the creation of custom one-line rules which compare any resource with a property using pre-defined operators. These custom rules take the following format:

  ```
  <Resource Type> <Property[*]> <Operator> <Value> [Error Level] [Custom Error Message]
  ```



  A separate custom rule text file must be created.

  The example below validates `example_template.yml` does not use any EC2 instances of size `m4.16xlarge`

  _custom_rule.txt_

  ```
  AWS::EC2::Instance InstanceType NOT_EQUALS "m4.16xlarge" WARN "This is an expensive instance type, don't use it"
  ```

  _example_template.yml_

  ```yaml
  AWSTemplateFormatVersion: "2010-09-09"
  Resources:
    myInstance:
      Type: AWS::EC2::Instance
      Properties:
        InstanceType: m4.16xlarge
        ImageId: ami-asdfef
  ```

  The custom rule can be added to the [configuration file](#Config-File) or ran as a [command line argument](#Parameters)

  The linter will produce the following output, running `cfn-lint example_template.yml -z custom_rules.txt`:

  ```
  W9001  This is an expensive instance type, don't use it
  mqtemplate.yml:6:17
  ```

  More information describing how custom rules are setup and an overview of all operators available is documented [here](docs/custom_rules.md).



  The linter follows the [AWS CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html) by default. However, for your use case specific requirements might exist. For example, within your organisation it might be mandatory to use [Tagging](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/).

  The linter provides the possibility to implement these customized specifications using the `--override-spec` argument.

  More information about how this feature works is documented [here](docs/customize_specifications.md)



  If you'd like cfn-lint to be run automatically when making changes to files in your Git repository, you can install [pre-commit](https://pre-commit.com/) and add the following text to your repositories' `.pre-commit-config.yaml`:

  ```yaml
  repos:
    - repo: https://github.com/aws-cloudformation/cfn-lint
      rev: v1.20.1 # The version of cfn-lint to use
      hooks:
        - id: cfn-lint
          files: path/to/cfn/dir/.*\.(json|yml|yaml)$
  ```

  If you are using a `.cfnlintrc` and specifying the `templates` or `ignore_templates` we would recommend using the `.cfnlintrc` exlusively to determine which files should be scanned and then using:

  ```yaml
  repos:
    - repo: https://github.com/aws-cloudformation/cfn-lint
      rev: v1.20.1 # The version of cfn-lint to use
      hooks:
        - id: cfn-lint-rc
  ```

  _Note: When mixing .cfnlintrc ignore_templates and files option in your .pre-commit-config.yaml cfn-lint may return a file not found error_

  - If you exclude the `files:` line above, every json/yml/yaml file will be checked.
  - You can see available cfn-lint versions on the [releases page](https://github.com/aws-cloudformation/cfn-python-lint/releases).


pkgId: 5249a1f26d7fc2c994c69a0789e21e62f9974826669138162a8a5180e7305c5d
name: python-cfn-lint
arch: src
version: 1.20.2
epoch: 0
release: 1
summary: Checks CloudFormation templates for practices and behaviour that could potentially be improved
url: https://github.com/aws-cloudformation/cfn-lint
rpm_license: MIT no attribution
rpm_group: Unspecified
rpm_buildhost: localhost
location_href: Packages/python-cfn-lint-1.20.2-1.src.rpm
checksum_type: sha256
description:
  <img alt="[cfn-lint logo]" src="https://github.com/aws-cloudformation/cfn-python-lint/blob/main/logo.png?raw=true" width="150" align="right">

  [![Testing](https://github.com/aws-cloudformation/cfn-python-lint/actions/workflows/test.yaml/badge.svg?branch=main)](https://github.com/aws-cloudformation/cfn-python-lint/actions/workflows/test.yaml)
  [![PyPI version](https://badge.fury.io/py/cfn-lint.svg)](https://badge.fury.io/py/cfn-lint)
  [![PyPI downloads](https://pepy.tech/badge/cfn-lint/week)](https://pypistats.org/packages/cfn-lint)
  [![PyPI downloads](https://pepy.tech/badge/cfn-lint/month)](https://pypistats.org/packages/cfn-lint)
  [![codecov](https://codecov.io/gh/aws-cloudformation/cfn-lint/branch/main/graph/badge.svg)](https://codecov.io/gh/aws-cloudformation/cfn-python-lint)
  [![Discord Shield](https://img.shields.io/discord/981586120448020580?logo=discord)](https://discord.gg/KENDm6DHCv)

  Validate AWS CloudFormation yaml/json templates against the [AWS CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html) and additional checks. Includes checking valid values for resource properties and best practices.



  This is an attempt to provide validation for AWS CloudFormation templates properties and
  their values. For values things can get pretty complicated (mappings, joins, splits,
  conditions, and nesting those functions inside each other) so it's a best effort to
  validate those values but the promise is to not fail if we can't understand or translate
  all the things that could be going on.



  We encourage you to contribute to `cfn-lint`! Please check out the [Contributing Guidelines](https://github.com/aws-cloudformation/cfn-lint/blob/main/CONTRIBUTING.md) for more information on how to proceed.



  Join us on Discord! Connect & interact with CloudFormation developers &
  experts, find channels to discuss and get help for cfn-lint, CloudFormation registry, StackSets,
  Guard and more:

  [![Join our Discord](https://discordapp.com/api/guilds/981586120448020580/widget.png?style=banner3)](https://discord.gg/9zpd7TTRwq)



  The Serverless Application Model (SAM) is supported by the linter. The template is
  transformed using [AWS SAM](https://github.com/awslabs/serverless-application-model) before the linter processes the template.

  _To get information about the [SAM Transformation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/transform-aws-serverless.html), run the linter with `--info`_



  Python 3.8+ is supported.



  `pip install cfn-lint`. If pip is not available, run
  `python setup.py clean --all` then `python setup.py install`.



  `cfn-lint` has optional dependencies based on certain features you may need.

  * `pip install cfn-lint[full]` for installing all the optional dependencies. This will install all the dependencies for graph, junit, and sarif.
  * `pip install cfn-lint[graph]` for installing `pydot` to draw and output template graphs
  * `pip install cfn-lint[junit]` for installing the packages to output the `junit` format
  * `pip install cfn-lint[sarif]` for installing the packages to output the `sarif` format




  `brew install cfn-lint`



  In `cfn-lint` source tree:

  ```shell
  docker build --tag cfn-lint:latest .
  ```

  In repository to be linted:

  ```shell
  docker run --rm -v `pwd`:/data cfn-lint:latest /data/template.yaml
  ```



  There are IDE plugins available to get direct linter feedback from you favorite editor:

  - [Atom](https://atom.io/packages/atom-cfn-lint)
  - [Emacs](https://www.emacswiki.org/emacs/CfnLint)
  - NeoVim 0.2.0+/Vim 8
    - [ALE](https://github.com/w0rp/ale#supported-languages)
    - [Coc](https://github.com/joenye/coc-cfn-lint)
    - [Syntastic](https://github.com/speshak/vim-cfn)
  - [Sublime](https://packagecontrol.io/packages/SublimeLinter-contrib-cloudformation)
  - [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=kddejong.vscode-cfn-lint)
  - [IntelliJ IDEA](https://plugins.jetbrains.com/plugin/10973-cfn-lint)







  - `cfn-lint template.yaml`
  - `cfn-lint -t template.yaml`

  Multiple files can be linted by either specifying multiple specific files:

  - `cfn-lint template1.yaml template2.yaml`
  - `cfn-lint -t template1.yaml template2.yaml`

  or by using wildcards (globbing):

  Lint all `yaml` files in `path`:

  - `cfn-lint path/*.yaml`

  Lint all `yaml` files in `path` and all subdirectories (recursive):

  - `cfn-lint path/**/*.yaml`

  _Note_: If using sh/bash/zsh, you must enable globbing.
  (`shopt -s globstar` for sh/bash, `setopt extended_glob` for zsh).



  `cfn-lint` will return a non zero exit if there are any issues with your template. The value is dependent on the severity of the issues found. For each level of discovered error `cfn-lint` will use bitwise OR to determine the final exit code. This will result in these possibilities.

  - 0 is no issue was found
  - 2 is an error
  - 4 is a warning
  - 6 is an error and a warning
  - 8 is an informational
  - 10 is an error and informational
  - 12 is an warning and informational
  - 14 is an error and a warning and an informational



  `cfn-lint` allows you to configure exit codes. You can provide the parameter `--non-zero-exit-code` with a value of `informational`, `warning`, `error`, or `none`. `cfn-lint` will determine the exit code based on the match severity being the value of the parameter `--non-zero-exit-code` and higher. The exit codes will remain the same as above.

  The order of severity is as follows:

  1. `informational` _default_
  1. `warning`
  1. `error`
  1. `none` _Exit code will always be 0 unless there is a syntax error_



  The template to be linted can also be passed using standard input:

  - `cat path/template.yaml | cfn-lint -`



  - `cfn-lint -r us-east-1 ap-south-1 -- template.yaml`
  - `cfn-lint -r us-east-1 ap-south-1 -t template.yaml`





  From a command prompt run `cfn-lint <path to template>` to run standard linting of the template.



  It will look for a configuration file in the following locations (by order of preference):

  - `.cfnlintrc`, `.cfnlintrc.yaml` or `.cfnlintrc.yml` in the current working directory
  - `~/.cfnlintrc` for the home directory

  In that file you can specify settings from the parameter section below.

  Example:

  ```yaml
  templates:
    - test/fixtures/templates/good/**/*.yaml
  ignore_templates:
    - codebuild.yaml
  include_checks:
    - I
  custom_rules: custom_rules.txt
  ```



  Optional parameters:

  | Command Line               | Metadata             | Options                                        | Description                                                                                                                                                                                                                                           |
  | -------------------------- | -------------------- | ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | -h, --help                 |                      |                                                | Get description of cfn-lint                                                                                                                                                                                                                           |
  | -z, --custom-rules         |                      | filename                                       | Text file containing user-defined custom rules. See [here](#Custom-Rules) for more information                                                                                                                                                        |
  | -t, --template             |                      | filename                                       | Alternative way to specify Template file path to the file that needs to be tested by cfn-lint                                                                                                                                                         |
  | -f, --format               | format               | quiet, parseable, json, junit, pretty, sarif   | Output format                                                                                                                                                                                                                                         |
  | -l, --list-rules           |                      |                                                | List all the rules                                                                                                                                                                                                                                    |
  | -r, --regions              | regions              | [REGIONS [REGIONS ...]], ALL_REGIONS           | Test the template against many regions. [Supported regions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html)                                                                                                |
  | -b, --ignore-bad-template  | ignore_bad_template  |                                                | Ignores bad template errors                                                                                                                                                                                                                           |
  | --ignore-templates         |                      | IGNORE_TEMPLATES [IGNORE_TEMPLATES ...]        | Ignore templates from being scanned                                                                                                                                                                                                                   |
  | -a, --append-rules         | append_rules         | [RULESPATH [RULESPATH ...]]                    | Specify one or more rules paths using one or more --append-rules arguments. Each path can be either a directory containing python files, or an import path to a module.                                                                               |
  | -i, --ignore-checks        | ignore_checks        | [IGNORE_CHECKS [IGNORE_CHECKS ...]]            | Only check rules whose ID do not match or prefix these values. Examples: <br />- A value of `W` will disable all warnings<br />- `W2` disables all Warnings for Parameter rules.<br />- `W2001` will disable rule `W2001`                             |
  | -e, --include-experimental | include_experimental |                                                | Whether rules that still in an experimental state should be included in the checks                                                                                                                                                                    |
  | -c, --include-checks       |                      | INCLUDE_CHECKS [INCLUDE_CHECKS ...]            | Include rules whose id match these values                                                                                                                                                                                                             |
  | -m, --mandatory-checks     |                      |                                                | Rules to check regardless of ignore configuration                                                                                                                                                                                                     |
  | --non-zero-exit-code       |                      | informational (default), warning, error, none] | Exit code will be non zero from the specified rule class and higher                                                                                                                                                                                   |
  | -x, --configure-rule       |                      | CONFIGURE_RULES [CONFIGURE_RULES ...]          | Provide configuration for a rule. Format RuleId:key=value. Example: E3012:strict=true                                                                                                                                                                 |
  | -D, --debug                |                      |                                                | Specify to enable debug logging. Debug logging outputs detailed information about rules processing, useful for debugging rules.                                                                                                                       |
  | -I, --info                 |                      |                                                | Specify to enable logging. Outputs additional information about the template processing.                                                                                                                                                              |
  | -u, --update-specs         |                      |                                                | Update the [CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html). You may need sudo to run this. You will need internet access when running this command              |
  | -o, --override-spec        |                      | filename                                       | Spec-style file containing custom definitions. Can be used to override CloudFormation specifications. More info [here](#customize-specifications)                                                                                                     |
  | -g, --build-graph          |                      |                                                | Creates a file in the same directory as the template that models the template's resources in [DOT format](<https://en.wikipedia.org/wiki/DOT_(graph_description_language)>)                                                                           |
  | -s, --registry-schemas     |                      |                                                | one or more directories of [CloudFormation Registry](https://aws.amazon.com/blogs/aws/cloudformation-update-cli-third-party-resource-support-registry/) [Resource Schemas](https://github.com/aws-cloudformation/aws-cloudformation-resource-schema/) |
  | -v, --version              |                      |                                                | Version of cfn-lint                                                                                                                                                                                                                                   |



  To maintain backwards compatibility `info` rules are not included by default. To include these rules you will need to include `-c I` or `--include-checks I`





  Inside the root level Metadata key you can configure cfn-lint using the supported parameters.

  ```yaml
  Metadata:
    cfn-lint:
      config:
        regions:
          - us-east-1
          - us-east-2
        ignore_checks:
          - E2530
  ```



  Inside a resources Metadata key you can configure cfn-lint to ignore checks. This will filter out failures for the resource in which the Metadata belongs. Keep in mind that [`AWS::Serverless` resources may lose metadata during the Serverless transform](https://github.com/awslabs/serverless-application-model/issues/450#issuecomment-643420308)

  ```yaml
  Resources:
    myInstance:
      Type: AWS::EC2::Instance
      Metadata:
        cfn-lint:
          config:
            ignore_checks:
              - E3030
      Properties:
        InstanceType: nt.x4superlarge
        ImageId: ami-abc1234
  ```



  cfn-lint applies configurations from several sources. The rules at lower levels are overridden by those at higher levels.

  1. cfnlintrc configurations
  2. Template Metadata configurations
  3. CLI parameters



  Certain rules support configuration properties. You can configure these rules by using `configure_rules` parameter.

  From the command line the format is `RuleId:key=value`, for example: `E3012:strict=true`.
  From the cfnlintrc or Metadata section the format is

  ```yaml
  Metadata:
    cfn-lint:
      config:
        configure_rules:
          RuleId:
            key: value
  ```

  The configurable rules have a non-empty Config entry in the table [here](docs/rules.md#rules-1).



  There are [getting started guides](/docs/getting_started) available in the documentation section to help with integrating `cfn-lint` or creating rules.



  This linter checks the AWS CloudFormation template by processing a collection of Rules, where every rule handles a specific function check or validation of the template.

  This collection of rules can be extended with custom rules using the `--append-rules` argument.

  More information describing how rules are set up and an overview of all the Rules that are applied by this linter are documented [here](docs/rules.md).



  The linter supports the creation of custom one-line rules which compare any resource with a property using pre-defined operators. These custom rules take the following format:

  ```
  <Resource Type> <Property[*]> <Operator> <Value> [Error Level] [Custom Error Message]
  ```



  A separate custom rule text file must be created.

  The example below validates `example_template.yml` does not use any EC2 instances of size `m4.16xlarge`

  _custom_rule.txt_

  ```
  AWS::EC2::Instance InstanceType NOT_EQUALS "m4.16xlarge" WARN "This is an expensive instance type, don't use it"
  ```

  _example_template.yml_

  ```yaml
  AWSTemplateFormatVersion: "2010-09-09"
  Resources:
    myInstance:
      Type: AWS::EC2::Instance
      Properties:
        InstanceType: m4.16xlarge
        ImageId: ami-asdfef
  ```

  The custom rule can be added to the [configuration file](#Config-File) or ran as a [command line argument](#Parameters)

  The linter will produce the following output, running `cfn-lint example_template.yml -z custom_rules.txt`:

  ```
  W9001  This is an expensive instance type, don't use it
  mqtemplate.yml:6:17
  ```

  More information describing how custom rules are setup and an overview of all operators available is documented [here](docs/custom_rules.md).



  The linter follows the [AWS CloudFormation resource provider schemas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-type-schemas.html) by default. However, for your use case specific requirements might exist. For example, within your organisation it might be mandatory to use [Tagging](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/).

  The linter provides the possibility to implement these customized specifications using the `--override-spec` argument.

  More information about how this feature works is documented [here](docs/customize_specifications.md)



  If you'd like cfn-lint to be run automatically when making changes to files in your Git repository, you can install [pre-commit](https://pre-commit.com/) and add the following text to your repositories' `.pre-commit-config.yaml`:

  ```yaml
  repos:
    - repo: https://github.com/aws-cloudformation/cfn-lint
      rev: v1.20.2 # The version of cfn-lint to use
      hooks:
        - id: cfn-lint
          files: path/to/cfn/dir/.*\.(json|yml|yaml)$
  ```

  If you are using a `.cfnlintrc` and specifying the `templates` or `ignore_templates` we would recommend using the `.cfnlintrc` exlusively to determine which files should be scanned and then using:

  ```yaml
  repos:
    - repo: https://github.com/aws-cloudformation/cfn-lint
      rev: v1.20.2 # The version of cfn-lint to use
      hooks:
        - id: cfn-lint-rc
  ```

  _Note: When mixing .cfnlintrc ignore_templates and files option in your .pre-commit-config.yaml cfn-lint may return a file not found error_

  - If you exclude the `files:` line above, every json/yml/yaml file will be checked.
  - You can see available cfn-lint versions on the [releases page](https://github.com/aws-cloudformation/cfn-python-lint/releases).


