This change makes minor updates to the DeriveKey payloads, fixing
error messages, comments, and local variable names to comply with
the current payload format. The corresponding unit test suite has
been updated to reflect these changes.
This change prepares the DeriveKey payloads for future updates to
support KMIP 2.0.
This change moves the KMIPProtocol class from the server module
to the services module. Because the client uses KMIPProtocol, and
KMIPProtocol lived in the server module, the client would end up
importing server libraries whenever it was used. If there are any
issues with server dependencies, this would cause the client to
fail for no good reason. This change now insulates the client from
the server code base and prevents this case from happening.
See #509
This change updates the CreateKeyPair payloads to support KMIP 2.0
features, including swapping out TemplateAttributes for the new
Attributes structure in the request payload and removing all
attribute-related encodings from the response payload. Unit tests
have been added to cover these changes.
This change updates the TemplateAttribute conversion utilities to
remove use of various TemplateAttribute subclasses. This reflects
the usage updates added for CreateKeyPair support. All related
unit tests have been updated to reflect this change.
This change updates the CreateKeyPair payloads to the current
payload format, adding properties for different payload attributes
and adding comparison and string operators. Changes are also made
to the PyKMIP clients and the surrounding testing infrastructure
to reflect the payload changes. The official unit test suite for
the CreateKeyPair payloads has been updated to also reflect these
changes.
This change prepares the CreateKeyPair payloads for future
updates to support KMIP 2.0.
This change updates the Locate payloads to support KMIP 2.0
features, including swapping out individual Attribute structures
for the new Attributes structure in the request payload. Unit
tests have been added to cover these changes.
This change updates the Locate payloads to the current payload
format, adding properties for different payload attributes and
adding comparison and string operators. Changes are also made to
the PyKMIP clients and the surrounding testing infrastructure to
reflect the payload changes. An official unit test suite for the
Locate payloads has also been included, which will eventually
replace the existing Locate message tests elsewhere in the test
suite.
This change prepares the Locate payloads for future updates to
support KMIP 2.0.
This changes adds several utilities for working with bit mask
enumerations, including functions to compute bit masks from lists
of enumeration values and vice versa. Unit tests have been added
to cover these new utilities.
This change updates the Register payloads to support KMIP 2.0
features, including swapping out TemplateAttributes for the new
Attributes structure in the request payload and removing all
attribute-related encodings from the response payload. Unit tests
have been added to cover these changes.
This change updates the Register payloads to the current payload
format, adding properties for different payload attributes and
adding comparison and string operators. Changes are also made to
the PyKMIP clients and the surrounding testing infrastructure to
reflect the payload changes. An official unit test suite for the
Register payloads has also been included, which will eventually
replace the existing Register message tests elsewhere in the test
suite.
This change prepares the Register payloads for future updates to
support KMIP 2.0.
When TLS handshake is performed while in `accept()` call, main thread
might blocked up to network timeout effectively locking out other
clients from being able to establish connection with PyKMIP server.
Easy way to reproduce the problem:
1. Start PyKMIP server
2. Establish TCP connection with `nc -v 127.0.0.1 5696`
3. Attempt to connect (concurrently):
`openssl s_client -host 127.0.0.1 -port 5696`
Without the fix, `openssl` would be blocked (won't even do initial TLS
handshake) until `nc` connection times out.
This change updates the Create payloads to support KMIP 2.0
features, including swapping out TemplateAttributes for the new
Attributes structure in the request payload and removing all
attribute-related encodings from the response payload. Unit tests
have been added to cover these changes.
This change adds several attribute-related utilities that support
converting TemplateAttribute structures to the new Attributes
structure and back. These utilities will be used in the updated
operation payloads to support seamless KMIP 2.0 encodings without
requiring broad payload internal and external usage changes.
Unit tests have been included to cover the new utility functions.
This change updates the Create payloads to the current payload
format, adding properties for different payload attributes and
adding comparison and string operators. Changes are also made to
the PyKMIP clients and the surrounding testing infrastructure to
reflect the payload changes. An official unit test suite for the
Create payloads has also been included, which will eventually
replace the existing Create message tests elsewhere in the test
suite.
This change prepares the Create payloads for future updates to
support KMIP 2.0.
This change adds a check to the read and write methods of the new
Attributes object that raises a new VersionNotSupported exception
if KMIP 2.0 is not the version used for encoding and decoding.
The Attributes object is not defined for older versions of KMIP
and therefore cannot be correctly encoded or decoded in those use
cases.
This change adds a new Enum subclass, OrderedEnum, that provides
comparison operators allowing for comparisons between enum values.
This will be used going forward with the KMIPVersion enum enabling
version checking on supported or unsupported object types.
This change adds a new Attributes object to the object hierarchy,
which replaces TemplateAttributes in KMIP 2.0. The old attribute
components, like the AttributeName and AttributeIndex, are no
longer used and are instead replaced with the KMIP TTLV tag for
the attributes in question. This brings the attribute encoding
process in line with the rest of the KMIP specification.
To support this change, additional attribute and enumeration
utility functions have been added to simply attribute building
and attribute/enumeration validity checking. New test cases
covering this new functionality are also included.
This change updates the PyKMIP object hierarchy's read/write
method signatures to support propagation of the KMIP version. The
introduction of KMIP 2.0 introduces future KMIP message encodings
that break backwards compatibility; to support this, PyKMIP must
know what KMIP version is being used when encoding or decoding an
object; the KMIP version residing in the client or server alone
is now insufficient. Prior versions of KMIP, namely 1.0 - 1.4,
have been backwards compatible, obviating the need for the KMIP
version at encode/decode time. Going forward, this is no longer
true.
The PyKMIP client and server have been updated to include the
KMIP version when making calls to read/write, as have the
associated test cases covering this functionality.
This change updates the Travis CI configuration file to output the
contents of the PyKMIP server and SLUGS log files if:
* a test failure occurred, and
* the log files exist in the test environment
This makes debugging server and service failures much easier in
Travis CI, specifically during integration and functional test
suite runs.
This change fixes a bug in the KMIPProxy client's support for the
Rekey operation. Specifically, if the operation fails and does not
return a payload, the client will still try to reference the
payload object when checking for TemplateAttribute data. This
causes an AttributeError since the payload is None. This change
fixes this and adds a unit test that covers this specific case.
Fixes#474
This change updates the PyKMIP clients, adding support for getting
and setting the KMIP version they use when making KMIP requests.
You can now do:
>>> client.kmip_version
to get the KMIP version enumeration the client is using. Use:
>>> client.kmip_version = enums.KMIPVersion.KMIP_1_1
to set the KMIP version the client uses.
The client unit tests have been updated to check and cover these
changes.
Fixes#470
This change updates the list of KMIP versions supported by the
server. While the server does not support any specific KMIP 1.3
or 1.4 features, the protocol formats are compatible across KMIP
1.0 to 1.4. Without this change, KMIP 1.3 and 1.4 requests for
older operations, like Create, Get, and Destroy, would fail.
This change also updates the server unit tests impacted by this
change.
Closes#451
This change fixes various pending deprecation warnings throughout
the library caused by recent updates to different dependencies.
While PyKMIP no longer directly triggers these warnings, some
dependencies still do when run through the test suite.
This change adds official library support for Python 3.7, including
updating the testing infrastructure for both tox and Travis CI and
updating the library package metadata in setup.py.
This change adds Ubuntu 16.04 LTS (Xenial Xerus) as a target test
platform in the Travis CI configuration file. New test builds for
all unit, integration, functional, style, security, and doc checks
should now be built for Xenial during continuous integration runs.
A recent style update to Python 3.6 adds deprecation W605, which
tightens the usage of invalid escape sequences. This patch removes
any instances of invalid escape sequences from the PyKMIP code
base, bringing the library back up to compliance with Python style.
As an application developer, you might expect to be able to turn on
debug logging at the root logger with something like
logging.basicConfig(level=logging.DEBUG)
However, if the application needed to fetch any secrets from a KMIP
server, these previously would be logged as part of the wire protocol.
Further, any passwords in configs would also get logged at DEBUG.
Applications would need to proactively silence such logging, as in
https://github.com/openstack/swift/commit/12b6d46
Now, we will default the logger level to INFO to suppress the debug
logging. However, seeing the on-wire data may still be useful, for
example when developing a new KMIP server. So, allow developers to
consciously set the logger level to DEBUG.
The old text made perfect sense when in a server context, trying to
read requests from clients, but KMIPProtocol is also used by *clients*
to read *responses*. Let's change it to something a little more
request/response agnostic.
Otherwise, you don't get much insight into why you had to settle for
your third configured host. Now, you can get information like
An error occurred while connecting to appliance foo.bar:
[Errno -5] No address associated with hostname
An error occurred while connecting to appliance localhost:
[Errno 111] Connection refused
even when we ultimately succeed in creating a client.
At that point, it's up to the caller to decide whether a stack trace is
appropriate; if the caller decides the connection error is recoverable,
us logging a traceback will only confuse things.
Also, prevent a TypeError during log interpolation by actually using the
argument we were providing.
Otherwise, you can hit errors with tracebacks like
Traceback (most recent call last):
...
File ".../kmip/pie/client.py", line 1573, in __enter__
self.open()
File ".../kmip/pie/client.py", line 135, in open
raise e
IOError: [Errno 2] No such file or directory
... which isn't terribly useful; it doesn't give you any information
about *what* file wasn't found. By using a bare `raise`, you preserve
the rest of the stack and get
Traceback (most recent call last):
...
File ".../kmip/pie/client.py", line 1573, in __enter__
self.open()
File ".../kmip/pie/client.py", line 131, in open
self.proxy.open()
File ".../kmip/services/kmip_client.py", line 221, in open
self._create_socket(sock)
File ".../kmip/services/kmip_client.py", line 246, in _create_socket
suppress_ragged_eofs=self.suppress_ragged_eofs)
File ".../eventlet/green/ssl.py", line 379, in wrap_socket
return GreenSSLSocket(sock, *a, **kw)
File ".../eventlet/green/ssl.py", line 68, in __init__
ca_certs, do_handshake_on_connect and six.PY2, *args, **kw)
File ".../ssl.py", line 558, in __init__
self._context.load_verify_locations(ca_certs)
IOError: [Errno 2] No such file or directory
... which makes it clear that it was a problem with the CA certificate
bundle.
Peter Hamilton
Andrey Smirnov
Peter Hamilton
Tim Burke