Bdbag

Latest version: v1.7.3

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

Scan your dependencies

Page 1 of 5

1.7.3

* Fix erroneous encoding of `%` char in URL field of `fetch.txt` which could break already properly encoded URLs.
This was due to a misinterpretation of the spec which states that `%` (along with `CR` and `LF`) should _only_ be URL
encoded for the `filename` field and that whitespace (` ` and `\t`) should _only_ be encoded in the URL field.
* NOTE: As a best practice, applications should always pre-encode URLs that are added to `fetch.txt` and not rely on `bdbag` to do so, since only whitespace will be encoded.
* Added a new option `strict` to the `make_bag` API function, along with a corresponding CLI argument. If `strict` is enabled,
`make_bag` will automatically validate a newly created or updated bag for structural validity and fail if the resultant bag is invalid.
This can be used to ensure that a bag is not persisted without payload file manifests. Additionally, if a created output
bag is not structurally valid, the bag will subsequently be reverted back to a normal directory. An updated bag will _not_ be reverted.
In either case, a BagValidationError exception will be thrown.

1.7.2

* Introducing support for _bag idempotentcy_, or reproducible bags. A reproducible bag is a bag that has content-equivalence (in both payload _and_ metadata, including manifests)
to another bag created at a different time, but with the same content, structure, bagging tool, and profile (if used). When this bag creation and bag archive mode is enabled,
two separately created bags (or bag archive files) with content-equivalence will _hash equally_, whether the hash is calculated on the bytes of the resultant archive file or calculated on the equivalently ordered set of individual file hashes of the bag's contents. See the [API Guide](https://github.com/fair-research/bdbag/blob/master/doc/api.md) for additional information.
* PR: [59](https://github.com/fair-research/bdbag/pull/59) Only require the external package `importlib_metadata` for Python < 3.8. This module is already included as `importlib.metadata` in Python versions 3.8 and above.
* Fix issue with HTTP fetch handler and auth header bearer-token stripping on redirects not getting restored to the cached `requests` session after redirect.
* Remove dependency on deprecated `distutils` and `distutils.util.strtobool` function.
* The `is_bag` API function will no longer attempt to instantiate a `Bag` object on non-directories.

1.7.1

Fix issue with `packaging.parse` throwing `InvalidVersion` in the `upgrade_config()` function when trying to parse the
informational version string `VERSION` set by `bdbag` when it is running in a "frozen" (e.g., with `cx_Freeze`) environment.
In such cases, `VERSION` is set to something like `1.7.1-frozen`, which is not `PEP-440` compliant.
This was not an issue in previous releases due to the fact that the implementation used `pkg_resources.parse_version` which was not as strict.

The code in `upgrade_config()` has been changed to parse the `PEP-440` compliant version returned by `distribution("bdbag").version` function from `importlib_metadata`,
rather than use the global string `VERSION`, which can still be (and is) used elsewhere for purely informational and descriptive purposes.

1.7.0

* PR: [54](https://github.com/fair-research/bdbag/pull/54): Add support for passing a local profile path for profile validation. Thanks to [Bernhard Hampel-Waffenthal](https://github.com/prettybits) for the contribution.
* [40](https://github.com/fair-research/bdbag/issues/40): Replace deprecated use of `pkg_resources` with `importlib-metadata` and `packaging`.
* Fix issue with HTTP fetch transport where bearer-token auth gets stripped from the session on a legitimate redirect but not restored for any potential new request on that same URL-bound session.
* Unpin `tzlocal` unless Python<3.
* Support for Python 3.5 and 3.6 has been dropped. Python 3.7 compatibility is deprecated but still officially supported in this release.

1.6.4

Added Google Cloud Storage fetch handler for handling `gs://` URLs in _fetch.txt_.
Note that this is a soft dependency and you must install the [gcloud CLI](https://cloud.google.com/sdk/docs/install) on the system where you will be running
`bdbag` in order for this handler to function.

Enabling "requester pays":
This handler supports the _requester pays_ usage pattern by allowing the billable `project_id` to be specified in the `auth_params` object for
a corresponding `keychain.json` entry for a matching `gs://` URI pattern.

For example, to configure (and allow) _requester pays_ for a GS bucket, you would add a `keychain.json` entry similar
to the following:

json
{
"uri": "gs://gcs-bdbag-integration-testing/",
"auth_type": "gcs-credentials",
"auth_params": {
"project_id": "bdbag-204999",
"allow_requester_pays": true
}
}

You can also explicitly disallow _requester pays_ at the client-side in the following ways:
* Set `allow_requester_pays` to `false`
* Omit the `allow_requester_pays` field.
* Omit the `project_id` field.
* Omit the `auth_params` object entirely.

Note that if you do any of the above, data retrieval requests to buckets which have _requester pays_ enabled will fail.
The use case for this configuration option is to ensure that you __don't__ pay for requests when _requester pays_
is disabled on the bucket. Per the following GCS [documentation](https://cloud.google.com/storage/docs/requester-pays):

json
Important: Buckets that have Requester Pays disabled still accept requests that include a billing project,
and charges are applied to the billing project supplied in the request.
Consider any billing implications prior to including a billing project in all of your requests.


IMPORTANT NOTE:

At the time of this writing, when using `gcloud-CLI` from `Google Cloud SDK 416.0.0` and previous, it is
possible to still be billed for bucket usage _even if_ you've disallowed _requester pays_ for a given bucket in
`keychain.json`. This is because the `gcloud init` process requires that you specify a default `project_id` and this
project id is subsequently stored in the `application_default_credentials.json` file used by the GCS APIs
(which the `bdbag` fetch handler uses) as `quota_project_id`. If this value is present it will be passed on all GCS API
calls as a fallback regardless even if explicitly not passed to the API call.
This can be worked around by removing the `quota_project_id` from `application_default_credentials.json`.

Using service account credentials:

It is also possible to specify a `service_account_credentials_file` which is a file path referencing a service account
credentials JSON file provided by Google Cloud Storage. For example:
json
{
"uri": "gs://bdbag-dev/",
"auth_type": "gcs-credentials",
"auth_params": {
"project_id": "bdbag-204400",
"service_account_credentials_file": "/home/bdbag/bdbag-204400-41babdd46e24.json"
}
}

1.6.3

* Fix bug in `bdbag_api.validate()` where underlying `BagError` exceptions were not being propagated correctly.
* Add an environment marker to `setup.py` for the `python-requests` dependency. This marker specifies that no greater
than `requests-2.25.1` be used with `Python3.5` environments, due to underlying incompatibilities with `requests` dependency
chain and `Python3.5` after `requests-2.26.0`. Reported in issue [47](https://github.com/fair-research/bdbag/issues/47).
Note that `bdbag` support for `Python3.5` is planned to be dropped in the `1.7.0` release.

Page 1 of 5

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.