Skip to content

fix: verify TLS certificates by default in the library - #26

Merged
cigamit merged 1 commit into
ctrliq:mainfrom
blaipr:fix/verify-tls-by-default
Sep 13, 2026
Merged

fix: verify TLS certificates by default in the library#26
cigamit merged 1 commit into
ctrliq:mainfrom
blaipr:fix/verify-tls-by-default

Conversation

@blaipr

@blaipr blaipr commented Sep 12, 2026

Copy link
Copy Markdown
Contributor

Using this package as a library meant unverified TLS, silently.

Connection.__init__ took verify=False, and the value that actually governs the normal path, config.assume_untrusted, defaulted to True. So Page(...) built a connection with verification off, and the constructor then called disable_warnings() so nothing said as much. A library that talks to an Ascender over HTTPS was not checking who answered.

Two defaults flip:

  • Connection(server, verify=True).
  • config.assume_untrusted now defaults to False, and reads ASCENDERKIT_ASSUME_UNTRUSTED for the opt-out, following the same pattern as ASCENDERKIT_SESSIONS and ASCENDERKIT_PREVENT_TEARDOWN. There was no environment variable for it before, only the config dictionary.

This is a behaviour change for library consumers and is in the changelog as one. Anyone pointed at an Ascender with a self-signed certificate sets the variable, or passes verify=False explicitly, and is back where they were.

The CLI is unaffected. CLI.connect() already sets config.assume_untrusted = False and only sets it True for -k / --conf.insecure, so it has always verified by default. This brings the library in line with the CLI rather than changing the CLI.

Out of scope, and worth its own change: ascenderkit/cli/__init__.py:16 calls urllib3.disable_warnings(InsecureRequestWarning) unconditionally at import, so even a verifying connection has the warning suppressed. And ws.py hardcodes ssl.CERT_NONE regardless of any of this, which #27 covers.

Note for whoever merges: #25 also touches this constructor, so whichever lands second needs a rebase.

Verified with black --check, flake8 and the unit suite, 355 passing.

Using this package as a library meant unverified TLS, silently.

`Connection.__init__` took `verify=False`, and the value that actually governs
the normal path, `config.assume_untrusted`, defaulted to `True`. So
`Page(...)` built a connection with verification off, and the constructor then
called `disable_warnings()` so nothing said as much. A library that talks to
an Ascender over HTTPS was not checking who answered.

Two defaults flip:

- `Connection(server, verify=True)`.
- `config.assume_untrusted` now defaults to `False`, and reads
  `ASCENDERKIT_ASSUME_UNTRUSTED` for the opt-out, following the same pattern as
  `ASCENDERKIT_SESSIONS` and `ASCENDERKIT_PREVENT_TEARDOWN`. There was no
  environment variable for it before, only the config dictionary.

This is a behaviour change for library consumers and is in the changelog as one.
Anyone pointed at an Ascender with a self-signed certificate sets the variable,
or passes `verify=False` explicitly, and is back where they were.

**The CLI is unaffected.** `CLI.connect()` already sets
`config.assume_untrusted = False` and only sets it `True` for
`-k` / `--conf.insecure`, so it has always verified by default. This brings the
library in line with the CLI rather than changing the CLI.

Out of scope, and worth its own change: `ascenderkit/cli/__init__.py:16` calls
`urllib3.disable_warnings(InsecureRequestWarning)` unconditionally at import, so
even a verifying connection has the warning suppressed. And `ws.py` hardcodes
`ssl.CERT_NONE` regardless of any of this, which ctrliq#27 covers.

Note for whoever merges: ctrliq#25 also touches this constructor, so whichever lands
second needs a rebase.

Verified with `black --check`, `flake8` and the unit suite, 355 passing.
@ciq-it-service-account

Copy link
Copy Markdown

Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
Code Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@cigamit cigamit self-assigned this Sep 13, 2026
@cigamit cigamit added the enhancement New feature or request label Sep 13, 2026
@cigamit
cigamit merged commit ada811c into ctrliq:main Sep 13, 2026
1 check passed
blaipr added a commit to blaipr/ascender-kit that referenced this pull request Sep 13, 2026
Two places reach a submodule through its parent package without importing it:

```python
import requests
...
class Token_Auth(requests.auth.AuthBase):
```

```python
import yaml
...
raise yaml.constructor.ConstructorError
```

Both work today, and only because `requests` and `yaml` happen to import those submodules themselves as part of their own initialisation. Nothing in the language guarantees that: `import requests` binds the package, not its children, and a release that stops importing `auth` eagerly turns this into an `AttributeError` at class definition time, which is to say at import of `ascenderkit`.

Imported by name instead, which is what the code means and what a reader would expect:

```python
from requests.auth import AuthBase
from yaml.constructor import ConstructorError
```

This also clears the two `possibly-missing-submodule` warnings the type checker reports, which is how it surfaced.

Note for whoever merges: ctrliq#25 and ctrliq#26 also edit `api/client.py`, so whichever lands after them needs a rebase.

Verified with `black --check`, `flake8` and the unit suite, 355 passing.
cigamit pushed a commit that referenced this pull request Sep 13, 2026
Two places reach a submodule through its parent package without importing it:

```python
import requests
...
class Token_Auth(requests.auth.AuthBase):
```

```python
import yaml
...
raise yaml.constructor.ConstructorError
```

Both work today, and only because `requests` and `yaml` happen to import those submodules themselves as part of their own initialisation. Nothing in the language guarantees that: `import requests` binds the package, not its children, and a release that stops importing `auth` eagerly turns this into an `AttributeError` at class definition time, which is to say at import of `ascenderkit`.

Imported by name instead, which is what the code means and what a reader would expect:

```python
from requests.auth import AuthBase
from yaml.constructor import ConstructorError
```

This also clears the two `possibly-missing-submodule` warnings the type checker reports, which is how it surfaced.

Note for whoever merges: #25 and #26 also edit `api/client.py`, so whichever lands after them needs a rebase.

Verified with `black --check`, `flake8` and the unit suite, 355 passing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Development

Successfully merging this pull request may close these issues.

3 participants