Skip to content

Confidential error reporting #243

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

Open
DanielVoogsgerd opened this issue Mar 24, 2025 · 2 comments
Open

Confidential error reporting #243

DanielVoogsgerd opened this issue Mar 24, 2025 · 2 comments
Labels
C-Rework Category: Something that requires updating or replacing existing systems. E-Easy Effort: Easy

Comments

@DanielVoogsgerd
Copy link
Collaborator

In Brane, we often choose to catch our errors right before we send them back to the user and then replace them with some kind of SecretError or HTTP response containing no information and then logging our error to stderr.

This mechanism, however, is implemented in various different ways throughout the workspace. I suggest we move to a singular Error type (maybe repurpose SecretError) where we add a constructor method or some function that does this fairly standard swap.

One thing I would like to add to this mechanism once it is standardized is a unique identifier that is generated for all surfaced errors, and attach those to both the user response and the log-entry. This way, we can map the responses sent to the user directly to a full error in our logs.

@Lut99, what are your thoughts?

@DanielVoogsgerd DanielVoogsgerd added C-Rework Category: Something that requires updating or replacing existing systems. E-Easy Effort: Easy labels Mar 24, 2025
@Lut99
Copy link

Lut99 commented Mar 24, 2025

Very much agree! Good idea to standardise it.

We've had the same discussion and solution on the reasoner side, so there's precedence where multiple people came together in a room and agreed that obfuscating errors and then using unique ids was a good idea :)

Just to remark, these unique identifiers should be random or like hashes - i.e., useful to tech support to be given by the user and match them in the logs generated by Brane. Obviously, it's not very secretive if we come up with consistent identifier for every secret error and publish the mapping on public docs somewhere. Then it's not secure, it's a CTF challenge :p

@DanielVoogsgerd
Copy link
Collaborator Author

DanielVoogsgerd commented Mar 25, 2025

Haha, yeah, just some random bytes, if some information is disclosed to the user. I want to make that an explicit choice. I think I will combine this with the Axum rewrite as I think that might influence that approach quite a bit to make it ergonomic to use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-Rework Category: Something that requires updating or replacing existing systems. E-Easy Effort: Easy
Projects
None yet
Development

No branches or pull requests

2 participants