Remote clusters should only send their own CAs. #1108
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
klizhentas
reviewed
Jun 27, 2017
|
|
||
| // create a request to validate a trusted cluster (token and local certificate authorities) | ||
| validateRequest := ValidateTrustedClusterRequest{ | ||
| Token: trustedCluster.GetToken(), | ||
| CAs: localCertAuthorities, | ||
| } | ||
|
|
||
| // log the local certificate authorities that we are sending |
There was a problem hiding this comment.
seems like a lot of repetition of the same logic, can you factor this into separate function, e.g.
type CertAuthorities []CertAuthority
func (s CertAuthorities) String() string {
... formatting logic
}
so later you can do this:
log.Debugf("[TRUSTED CLUSTER %v", CertAuthority(validateRequest.CAs))
klizhentas
reviewed
Jun 27, 2017
kontsevoy
approved these changes
Jun 27, 2017
russjones
force-pushed
the
rjones/send-correct-ca
branch
from
b25bef3 to
2286c65
Compare
|
@klizhentas Made the changes you suggested, can you take another look? |
klizhentas
approved these changes
Jun 27, 2017
hatched
pushed a commit
that referenced
this pull request
Feb 1, 2023
Calling `electron-builder install-app-deps` during `yarn build-and-package-term` is unnecessary as `electron-builder build` already does that. The only time where you'd need to run `electron-builder install-app-deps` is when you just cloned the repo and would like to run the dev version of the app without building the prod version.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose
At the moment, when doing a Trusted Cluster exchange, the remote cluster sends all the CAs that it has to the main cluster which then adds these CAs to it's own backend. Then the main CA sends it's CAs to the Trusted Cluster which adds them to it's own backend.
This exchange works correctly the first time it occurs. However if you try and add an existing Trusted Cluster twice, since the Trusted Cluster sends all of the CAs it has, it sends back the CA for the main cluster as well, but it sends it back without signing keys. The main cluster adds it to it's backend which then causes an error similar to the following to occur when trying to add a node (because the CA legitimately no longer has it's signing keys).
To fix this problem, the Trusted Cluster should only send it's own CAs to the main cluster.
Implementation
Related Issues
Fixes #1050