Skip to content

Safer error messages #104

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

Merged
merged 1 commit into from
May 22, 2023
Merged

Conversation

ImogenBits
Copy link
Collaborator

There is a potential attack vector where an error such as

EncodingError(f"Vertex {v} is invalid")

can be abused by students to leak information. For example, a solver could encode the generator's instance into a single (very large) int, and then use it in a proposed solution. This would obviously raise an error, which contains this int. When viewing the logs the error would then expose the other team's instance.

To prevent this I've adopted a two tier error messaging system, each exception we raise has a plain and a detailed error message, with the intention being that the plain error contains static info about the general class of problem that occurred and the detailed containing specifics about this particular situation. The idea then is that we can display the plain error messages in public logs without exposing any information about other team's code, and people can view detailed error messages in logs from test runs on their local machine to get detailed debugging info.

Python has a nice system where you can help with stuff like this by using the LiteralString type which accepts any string that is statically known, so "abc" + "def" is accepted by type checkers, but f"{runtime_var}" is not. This doesn't change runtime behaviour, but makes it easier to catch potential information leaks with linters.

@Benezivas Benezivas merged commit f67edf2 into Algorithmic-Battle:4.0.0-rc May 22, 2023
@ImogenBits ImogenBits deleted the safe_error branch May 22, 2023 12:31
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