When is the ability to trigger a panic a bug?

[EliahKagan]

I was originally going to ask when, if ever, it is a vulnerability for untrusted data to be able to trigger a panic, because in principle this may be a denial of service vulnerability. But I figured I’d ask the broader question as well.

I mean this in the context of gitoxide. My main motivation is to hone my mindset when reading and working on the code. But I do have a few specific concerns:

1. I think that in some common designs of graphical applications in which a user may have unsaved work on one thing while getting an unrecoverable error in another, a panic may cause lost work. I do not have examples of actual applications for which this occurs.
2. Some panics in gitoxide seem like malformed data in a repository could trigger them. The ability of an untrusted party to prepare and offer such a repository is one factor. The possibility for some applications to handle such errors meaningfully is another. This is not something I have really investigated yet, unless you count…
3. We currently panic in some situations where UTF-8 is ill-formed, and in some of these situations, that can occur in the absence of any bugs. In particular, files can be named with unpaired surrogates on Windows.

(Disclosure considerations: I originally inquired about this privately due to the security connection, but the UTF-8 situation is already publicly known, so it was decided that this can become a public discussion here.)

[Byron]

(Mostly pasting my previous private response)

Panics are considered bugs, even though some parts where it's inconvenient to handle errors properly also panic. That behaviour is really only 'allowed' on Windows in relation to illformed Unicode.

It would also be a problem if illformed unicode could be used to bring down server processes, so codepaths that are run there certainly should be handling these as errors instead.

All in all, the error handling related to illformed Unicode is a compromise which probably can be exploited and used as DoS in some shape or form.

There are probably some places where code uses a panicking version of gix_path::*() functions even though it could also use an erroring one, and avoiding this would make the API more robust.

If panics occur in other places, then they are definitely a bug that's up for immediate fixing.