19

When our in-house developed application (C#, ASP.NET) is throwing an exception, it displays a stack trace that contains path information like C:\users\DEVELOPER_FULL_NAME\path\some-module.cs. So it shows the full name of the developer who compiled it.

The developers are telling me, this is unavoidable. I find this hard to believe. I am no professional C# programmer, but working in IT, I have been programming (from Pascal to Assembler to C), so I think that my understanding should be fair enough.

So, how do you hide developer related personal information from the stack trace? Compile with a anonymous user on a dedicated machine? Is there a possibility to strip this information using a compile time switch or anything like that?

Jennifer S
  • 733
  • 1
  • 6
  • 14
ChristianH
  • 331
  • 2
  • 4
  • 3
    Are you compiling in Debug or Release mode? Are you including the PDB file with the release? – Robert Harvey Dec 19 '19 at 22:56
  • 18
    Do you mean your production software releases are actually being created on developers' own machines rather than being created in a dedicated build environment? If so, then I'd think that's a much larger risk/problem. – Ben Cottrell Dec 19 '19 at 23:01
  • 1
    To reverse one (as I cannot do better) _downvote_ with no feedback, I hereby **upvote** this question, which, in my opinion, does not deserve the downvotes. The question is clear and concise, and, while some additional research might have resolved **part of it**, it gives a very good starting point for some [indispensable advice](https://softwareengineering.stackexchange.com/a/402751/340885). So, it is good that it ended up on this site! – Vector Zita Dec 20 '19 at 16:40
  • 1
    `The developers are telling me, this is unavoidable.` This is **always** hard to believe. Developers are weird creatures, their usually tell you something along the lines of: `almost anything is doable, as long as you can think of it`. A group of developers unanimously deducing that something is `unavoidable` is rather rare. – Vector Zita Dec 20 '19 at 16:47
  • 1
    @VectorZita many things are unavoidable if the developers are being forced to do things certain ways. The correct response to this claim isn't "you're wrong". It's "why?". – candied_orange Dec 20 '19 at 17:21
  • @candied_orange Yes, I agree. It's the part where the developers did not explain to the OP the "why" (otherwise they wouldn't be motivated to ask here) that I was worrying about. But then again, maybe this is just a simple question, we do not know anything regarding the relation of the OP with the developer team. – Vector Zita Dec 20 '19 at 22:40
  • I did a quick google search, and it seems that indeed having just the relative path (relative to the directory where the complete code resides) instead of having the full path (which includes the name of my hard drive) is difficult in some developent environments. Difficult meaning: No solution on stackoverflow. – gnasher729 Dec 28 '19 at 09:51
  • On the other hand, a stack trace is just text. For my own code, the app knows the path to the source directory and replaces that with src/ wherever relevant so all developers get identical log files. – gnasher729 Jan 28 '21 at 18:35

5 Answers5

21

Couple of pointers.

You should never expose stacktrace to users. Thats a security risk. You should also never expose exception messages to users, only for custom exceptions that you know can not contain sensitive information is ok to expose.

You should never build your release candidate on a developer machine. You should use a build agent for this. The best solution is to look at using build agents, for example Azure devops support this and is a pollished and well working continuous integration suit. edit: There is also another reason for not building on your machine. On your machine you can have stuff in the GAC that makes the project build just fine on your machine but will not run on the target host.

Finally you should build the release candidate in release mode. Both for performance reasons and security.

Anders
  • 671
  • 1
  • 4
  • 11
  • 1
    Thank you for your comments and pointers, in fact this is what I would have expected: compiling on a dedicate machine makes sense to me. Showing the full exception stacktrace to users maybe triggers a false perception of software quality for end users, so I personally would store that information in logs rather than exposing it to the user. – ChristianH Dec 20 '19 at 09:07
  • 3
    I will use your pointers and start a discussion with the developers based on that. Again, thank you for your insights! – ChristianH Dec 20 '19 at 09:13
  • 1
    @ChristianH And if you *do* have builds (test or debug or whatever) that are for some reason built on the devs' machines, just don't put the source in the dev's user directory. Put it in some generic location like c:\path\some-module.cs. – Eric King Dec 20 '19 at 14:39
  • 2
    Showing exceptions to users is only a security risk for remote applications like a web app. For desktop applications, there isn't any security risks in exposing them to the user. There may be concerns about the perceptions of the software that spews out garbages that the user don't understand, but that's not a security risk. – Lie Ryan Dec 27 '19 at 00:07
  • @ChristianH Counterpoint: if I can see the stack trace as a user, I have at least a small chance of guessing what went wrong and not doing that thing again. – user253751 Jan 29 '21 at 23:26
  • Added a new point why you should build on a agent – Anders Feb 28 '21 at 11:03
7

From this blog:

<PropertyGroup>
  <PathMap>$([System.IO.Path]::GetFullPath('$(MSBuildThisFileDirectory)'))=./</PathMap>
</PropertyGroup>

So instead of this:

Unhandled exception. System.Exception:
at MyProject.Program.Main(String[] args) in /home/username/dev/MyProject/Program.cs

It will show this:

Unhandled exception. System.Exception:
at MyProject.Program.Main(String[] args) in ./MyProject/Program.cs

lonix
  • 211
  • 2
  • 5
6

The build property or rather msbuild parameter is /pathmap or <PathMap>. It will rewrite all traces to your source locations.

Unfortunately i wasnt able to find the perfect documentation for this, but you can find a couple of blog posts using it.

e.G.: https://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html

Also: you can avoid the whole problem by using a build server, as suggested in the other comments. The "whole" solutions is probably to do both.

Chris
  • 238
  • 1
  • 2
  • Using a build server would expose paths on the build server, which isn't really progress. – gnasher729 Dec 28 '19 at 09:52
  • It will solve the problem of showing the developers name in the path. But the pathmap is the better solution to do this. – Chris Dec 29 '19 at 10:20
1

One simple solution is to clone (check out) the project to a folder outside of C:\users, provided the developers have access to such folders. For example, instead of:

C:\users\DEVELOPER_FULL_NAME\path

simply create a new folder (C:\dev) and clone here:

C:\dev\path

Of course, as others have pointed out, you're still exposing exception messages and stack traces to users, but at least developers' names are no longer being exposed.

Graham
  • 11
  • 3
0

When our in-house developed application (C#, ASP.NET) is throwing an exception, it displays a stack trace ...

And therein lies your fundamental problem - poor programming in the client application that does not correctly catch Exceptions and display Error Messages. Note the difference.

Exceptions contain a lot of information and they are not, generally, intended for User consumption. Indeed, to a User, they're downright scary! Exceptions are meant to tell Developers where their code [got] broke. They don't [often] include [the far more useful] why the code [got] broke, but at least "where" offers a place to start diagnosis.

Error Messages, on the other hand, are crafted for Users.
It tells them that something went wrong and, if possible, what they can do to put it right.
Users do not care that the Discombobulator's Frognosticate method threw a WeShouldNeverGetToThisLineException. They care that by changing something on the screen and clicking "OK" again, the application will do what they want! Don't scare them by throwing a screen-load of unintelligible junk at them.

Now there is a School of Thought that says that Exceptions can do both jobs.
Exceptions have a Message property and, some would argue, that this Message can be [safely] shown to the User. The important bit is that only the Message should be shown to the User, which brings me back to that improper handling of Exceptions - showing the whole thing, stack trace and all, is just plain wrong.

Phill W.
  • 11,891
  • 4
  • 21
  • 36
  • That is not the fundamental problem. If you run into a completely unexpected situation never seen before this might be the proper way to do it, to ensure the necessary information is as visible as possible. The fundamental problem is that builds are not created in a controlled and reproducible environment. – Thorbjørn Ravn Andersen Jan 30 '21 at 11:32
  • 1
    @ThorbjørnRavnAndersen: I disagree. The point of Exceptions is that they are /exceptional/, not unexpected. At any Process Boundary, you have - and should take advantage of - the opportunity to "sanitise" the Exception to make it "suitable" for the client - in this case, the end User. Yes, ensuring "necessary information" is visible is important, but emphasis on the "necessary". Do you log the whole Exception somewhere for later diagnosis (because Users /never/ remember "errors" correctly?) If so, it's visible /there/ - putting the whole thing on screen is redundant and confusing. – Phill W. Feb 01 '21 at 08:36