While combining the actions could cause duplicates (while the SA is
initiated, traffic might trigger the trap and the initiation of another
CHILD_SA), the previous commit should avoid most duplicates. If reuse_ikesa
is disabled, duplicates can't be prevented, though.
If two threads are waiting in find_entry() and remove_entry(),
respectively, and the former is woken first, the latter remains stuck
as it won't get signaled.
If there are threads waiting in find_entry() and one in remove_entry()
and the latter is woken first by a thread calling put_entry(), the
former threads would remain stuck as they get never signaled.
This ensures that e.g. ike/child-updown messages are sent that were
queued but couldn't be sent (even the job to enable to on_write() callback
requires a worker thread that's not around anymore during shutdown).
References #3602.
This way we only have one reference for each CA certificate, whether it
is loaded in an authority section, a connection or via load-certs() command.
It also avoids enumerating CA certificates multiple times if they are
loaded in different ways.
With the previous approach, CA certificates that were not re-loaded via
load-cert() (e.g. from tokens or via absolute paths) would not be available
anymore after the clear-creds() command was used. This avoids this
issue, but can cause duplicate CA certificates to get stored and enumerated,
so there might be a scaling factor.
This is the recommended location and import config as it allows running the
tests against installed versions of the package. And while the test file
itself is automatically included in the source distribution this way, the
__init__.py file is not, so we still have to update MANIFEST.in.
This avoids having to register certificates with authority/ca backends
beforehand, which is tricky for intermediate CA certificates loaded
themselves via authority/ca sections. On the other hand, the form of
these URLs can't be determined by config backends anymore (not an issue
for the two current implementations, no idea if custom implementations
ever made use of that possibility). If that became necessary, we could
perhaps pass the certificate to the CDP enumerator or add a new method
to the credential_set_t interface.
If a CHILD_SA is terminated, the updown event is triggered after the
CHILD_SA is set to state CHILD_DELETED, so no usage stats or detail
information like SPIs were reported. However, when an IKEv2 SA is
terminated, the updown event for its children is triggered without
changing the state first, that is, they usually remain in state
INSTALLED and detailed data was reported in the event. IKEv1
CHILD_SAs are always terminated individually, i.e. with state
change and no extra data so far.
With this change usage stats are also returned for individually deleted
CHILD_SAs as long as the SA has not yet expired.
Fixes#3198.
The unique names were introduced for the list-sas command in commit
04c0219e55. However, the child-updown
event wasn't updated to match. Even though the documentation suggests
that the section name of the CHILD_SAs are the same in both messages.
The original name is already being returned in the "name" attribute,
so it'll still be available.
Example:
>>> import vici, json
>>> s = vici.Session()
# First, for comparison, the list-sas command:
>>> print(json.dumps(list(s.list_sas()), sort_keys=True, indent=4, separators=(',', ': ')))
[
{
"vti0": {
"child-sas": {
"vti0-1": {
...
# A child-updown event before the change:
>>> for x in s.listen(["child-updown"]): print(json.dumps(x, sort_keys=True, indent=4, separators=(',', ': ')))
[
"child-updown",
{
"vti0": {
"child-sas": {
"vti0": { # <-- wrong: inconsistent with list-sas
...
# A child-updown event after the change:
>>> s = vici.Session()
>>> for x in s.listen(["child-updown"]): print(json.dumps(x, sort_keys=True, indent=4, separators=(',', ': ')))
[
"child-updown",
{
"vti0": {
"child-sas": {
"vti0-1": { # <-- fixed
Closesstrongswan/strongswan#153.
Tobias Brunner