Chapps

Latest version: v0.5.18

Safety actively analyzes 638773 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 3 of 9

0.5.6

- Correct issues with handling unrecognized domains when checking
inbound policy option settings.

- Protect config-module debug-logging with conditionals to prevent
running during a doc-build in order to get readthedocs.io
autobuild to function properly.

- Advance the metadata Development Stage identifier to Beta. We
continue to use the software in a production environment. Feel
free to reach out and let us know about your own deployment so
we can collect more data about how it is functioning for others.

0.5.5

- Now using SQLA-based adapters throughout.

- The environment variable `CHAPPS_DB_MODULE` may be set to `mysql`
in order to cause the policy layer to use the older, previous
adapter module based on `mysqlclient`.

0.5.4

- Correcting major oversight -- until this release, the live API
lacked a route to clear the SPF option flag for domains. This
is really necessary in order for updates to options to take
effect immediately. SPF software requirements are now also
added to the API software requirements.

0.5.3

- All major features of the software have now been in use in a
large-scale production email context for a week or more. The
outbound features have been in production for a few months. The
software can no longer be considered to be in an "alpha" stage
of development.

- Some improvements are made in this release to requirements of
CREATE and UPDATE operations. Variously, attributes of models
have been made optional, and some routines which automate the
database interactions have been modified to allow for certain
attributes to be missing (defaulted or left alone) from either
CREATE or UPDATE operations. For instance, the greylisting and
SPF flag attributes on Domain objects are optional during
creation and will both default to False. For updates on Domain
or Quota objects, only the attribute(s) being adjusted need be
included, apart from the ID.

As promised in the notes for v0.5.2, this release provides a
mechanism for providing arbitrary defaults for model attributes,
in order to allow some settings to be defaulted during CREATE
operations. By default, there are no defaults. When an
attribute has no default, `Ellipsis` is used in order to signal
via FastAPI/Starlette `Field` objects that the attribute is
required. Otherwise, the default value is provided when the
closure is constructed by the `create_item` factory.

It is perhaps worth noting that the solution to the problem of
updates initially requiring all attributes to be included is not
entirely satisfactory, as it consists mainly of making all but
the `id` attribute optional on the Pydantic data model. In
practice this seems to work "okay" as the database refuses to
create objects without fields which don't have defaults, like
`name`. However, due to some as-yet-unsolved intricacy of
FastAPI and/or Starlette, the API simply locks up and eventually
times out when it receives a request with malformed data -- such
as a request to CREATE an entity with no `name` field. It would
of course be preferrable to send a code 400 with a reasonable
explanation. However, something earlier is hanging up, so that
it seems the route closure itself never gets to execute.

- API documentation has been adjusted to reflect changes since the
last time API documentation was updated, including the above.

Alpha Releases

0.5.2

- Adding in hardcoded "False" defaults for boolean values on
models during record creation. This is specifically in order to
provide backward compatibility during upgrade of CHAPPS from
versions v0.4.11-17 wherein there were no domain flags. Now
that there are flags on domains, the old domain-creation code on
clients will break utterly if the API cannot provide defaults,
which in v0.5.1 it was not doing. Now, defaults of False are provided
if the specified parameter type is Optional[bool] or any
Union[bool|...]. This is a stopgap, which provides a hint as to
how a wider change would allow for arbitrary defaults to be
provided for any specified parameter.

**TL;DR** There is a hacky kludge which fixes a
reverse-compatibility issue which will be improved into a
flexible way to provide defaults for any specified parameter to
the `create_item` and probably also `update_item` factory
functions.

0.5.1

- The recent (major) adjustment to how the config object works was not
reflected in the CLI script, and so in the last two revisions it was
broken (since v0.4.17). It is repaired in this release.

- Similarly broken were all of the outbound policy service
scripts, and the standalone greylisting service script. These
have also been corrected now.

Page 3 of 9

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.