-
Notifications
You must be signed in to change notification settings - Fork 10
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
Improve / configure logging #12
Comments
Agreed. This is one of the TODO callouts I hadn't yet added an issue for, mainly because, at the moment, there's not much to log. A device comes in or is removed, it issues a shutdown, and that's that. It will definitely be necessary once the custom command list support is added which I'm currently working on, as it would be useful to the user to know if a command failed to execute or not. For privacy concerns, we might not want to log precisely what the command was, however. Logging will also be useful to show which device has been added/removed, and I'm making a change later today that will allow that to happen. Currently, it only works off of the ID, not the device description, but the full description will be useful for whitelisting. |
See, in USB. Kill, the shutdown of the computer also triggers a full disk encryption. So that way, we can log everything and let only the user have access to it. I know that we don't have the encryption part right now. And another thing, please change the console window's title, it changes to powershell after device enumeration. You may want to call |
USBKill does not support encryption, it encourages it, just like this tool does. As for logging WHICH commands failed, the scenario I describe is a situation in which someone is observing the logs as the software is shutting down, or is able to see them after a failed shutdown. Any leakage of information in this way is bad, and as much as possible should be hidden from inspection. Also, the windows version of deadman is not intended to be run as a console app at this time to avoid the problem with the window simply being closed. See issue #5. If and when it becomes feasible to run it in the console again, I will consider using SetConsoleTitle() |
I don't know if you can call win32 API functions in Go, but to get rid of the console window, you can use |
This seems to be solved by building with |
It is difficult to keep track of what happened when, so add logging, I have a logging framework for GO, you can use it.
The text was updated successfully, but these errors were encountered: