Going forward, persist profiles encrypted to the CloudKit container.
Conversely, read from the encrypted field if any, falling back to the
plain JSON field.
WARNING: the change is NOT backward compatible, as it would defeat the
purpose. That is, once the profile is stored encrypted, the old plain
profile is erased and its content won't be readable by older versions of
the app.
There may be a mismatch between profiles and profile headers. For
example, some profiles may appear in the main list, but the same ones
may not appear in the existing profile names when adding a new profile
(and vice versa). That's because they are being fetched from different
sources. Unify that.
In #333, the non-optional field `disconnectsIfNotMatching` was removed
completely. Therefore, downgrading from 2.2.0 may lose profiles due to
the missing required field.
Mitigate the issue by restoring the field as optional, even if it's
unused, for the sake of not breaking profile serialization until the
2.2.0 release. Remove the deprecated field after that.
Extend the feature by also providing a complementary "include" policy,
i.e. activate the VPN _only_ on the specified networks. "Trusted
networks" was only providing the "exclude" counterpart, i.e. _except_
the specified networks.
Closes#119
The VPNConfiguration parameter is opaque and tightly coupled to
TunnelKit. Connecting to a Profile makes infinitely more sense, beyond
simplifying the VPNManager class. Configuration building is fully
delegated to the strategy (as it has to be).
- VPNManager takes Profile and produces VPNConfigurationParameters
- VPNManagerStrategy takes VPNConfigurationParameters (abstract)
- TunnelKitVPNManagerStrategy takes VPNConfigurationParameters and
produces TunnelKitVPNConfiguration internally
* Make specific message levels a default extension
* Define Loggable protocol
* Keep track of message originator metadata
* Fix tracing of Core Data logs
* Log query on entity not found
Davide De Rosa