Skip to content
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

Fix proxy hash #1157

Merged
merged 6 commits into from
Nov 28, 2024
Merged

Fix proxy hash #1157

merged 6 commits into from
Nov 28, 2024

Conversation

njvrzm
Copy link
Contributor

@njvrzm njvrzm commented Nov 25, 2024

What this PR does / why we need it:
The proxy hash added to the datasource instance cache key in #1133 ends up always being ---\n, because the contents of the proxy client key are PEM-encoded. This PR fixes that by PEM-decoding the contents, which gives a key in []bytes, then base64-encoding the final three bytes, giving a four-character hash.

Since this is a bit more complex than the previous approach, I added a benchmark, which times this to about 250ns on my laptop, compared to the 1-2 microseconds for the original version discussed in #1133. Seems acceptable to me, but if need be we can do a hackier approach and just extract some characters directly from the key contents.

Which issue(s) this PR fixes:
https://github.com/grafana/app-platform-wg/issues/174, again.

@njvrzm njvrzm self-assigned this Nov 25, 2024
@njvrzm njvrzm requested a review from a team as a code owner November 25, 2024 14:15
@njvrzm njvrzm requested review from wbrowne, andresmgot and oshirohugo and removed request for a team November 25, 2024 14:15
Copy link
Member

@wbrowne wbrowne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few initial comments

backend/config.go Show resolved Hide resolved
start := max(len(key)-4, 0)
return key[start:]
contents := c.config[proxy.PluginSecureSocksProxyClientKeyContents]
block, _ := pem.Decode([]byte(contents))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we actually need to add any more logic here or can we simplify by using the client key in its entirety?

Copy link
Contributor Author

@njvrzm njvrzm Nov 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose we could! It's 120 bytes long currently, or 64 if we extract only the encoded part. Potentially longer later. Granted there shouldn't be ever be more than few hundred of them at a time tops, but it seems wasteful, and the key would be hashed internally for every map access; the longer key adds a small but nonzero latency to lookups, although that would be more than made up for by not doing the PEM decode and base64 decode.

I guess one concern is that the key is a bit more likely to leak out in an error message this way, but without the other values the key is probably not dangerous.

I dunno - it feels odd to me, but if you think it's the best approach I can change it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's go with how it is now and see how we get on 😄

Copy link
Member

@wbrowne wbrowne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

backend/config.go Outdated Show resolved Hide resolved
@njvrzm njvrzm merged commit 316ae3b into main Nov 28, 2024
3 checks passed
@njvrzm njvrzm deleted the njvrzm/fix-proxy-hash branch November 28, 2024 12:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants