-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-register first-party endpoints when the private gateway's certificate changes #175
Labels
Comments
gnarea
changed the title
Re-register with private gateway to get new certificate
Re-register endpoints when the private gateway's certificate changes
Jan 5, 2022
gnarea
changed the title
Re-register endpoints when the private gateway's certificate changes
Re-register first-party endpoints when the private gateway's certificate changes
Jan 6, 2022
|
kodiakhq bot
pushed a commit
that referenced
this issue
Apr 14, 2022
…enewed (#212) Fixes #185. It's also worth highlighting the following: - It introduces the instance method `FirstPartyEndpoint.authorizeIndefinitely()`, which is like `FirstPartyEndpoint.issueAuthorization()`, except that it tracks which 3rd party endpoints are authorised in order to renew their PDAs automatically. - For example, Awala Ping will continue to use `FirstPartyEndpoint.issueAuthorization()` but Letro will use `FirstPartyEndpoint.authorizeIndefinitely()`. - To stop renewing an _indefinite PDA_, it's enough to delete the respective 1st or 3rd party endpoint. - This PR introduces the concept of "channel" (e.g., `ChannelManager`), which exists in the Awala protocol suite and refers to an established communication channel between two endpoints (which is end-to-end encrypted and where both are mutually authorised to send messages to each other). - Because #175 isn't implemented yet, I haven't actually integrated the function to reissue+send PDAs (`FirstPartyEndpoint.reissuePDAs()`). This should be done as part of #175. - This PR integrates `CertificationPath` from the core Awala lib, which effectively duplicates the existing `AuthorizationBundle` data class. Once this PR is merged, I'll create a separate PR to replace the remaining uses of `AuthorizationBundle`. # Review notes Of things that I'm likely to have got wrong here, I'd rank highly the use of `SharedPreferences` and coroutines (esp. where I have to specify a context explicitly), so please pay special attention to those.
This was referenced Apr 14, 2022
🎉 This issue has been resolved in version 1.10.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What to do with old certificates
Old certificates should continue to be used in all calls to
parcel.validate()
. The old (yet valid) certificates should be passed astrustedCertificates
, along with the new certificate.Old certificates should only be deleted after they expire (e,g., once a day, when the app starts). However, expired certificates must not be included in the
trustedCertificates
above.What to do with the new certificate
The new certificate should be used in all calls to
parcel.serialize()
andissueDeliveryAuthorization()
. This shouldn't require code any further code changes, but I'm documenting this requirement to make sure we don't change the code inadvertently.Related issues
The text was updated successfully, but these errors were encountered: