Open dpmatthews opened 4 years ago
I'm fine with the proposal. Other command line programs work in a similar way, so +1
in production mode only print a traceback for errors not specifically handled
I personally agree with this, but the Cylc 7 pen test report (I think?) suggested users should never see tracebacks as they expose information about the program internals. On the other hand, is that a pointless distinction for a) Python programs, that b) have a --debug
option that will print tracebacks (I suppose we could remove --debug
option in releases .. but that seems counterproductive - users could then not even help us to debug on request).
in production mode only print a traceback for errors not specifically handled
I personally agree with this, but the Cylc 7 pen test report (I think?) suggested users should never see tracebacks as they expose information about the program internals.
Also it’s an open source project, so anyone with malicious intent can figure out internals.. The only “danger” is runtime settings (if not careful) and site installation/file-structure being exposed.
... unless the top-level location of the python library is considered sensitive information that shouldn't be exposed to clients (a web UI user with no local account on the back end would not have easy access to that otherwise)
(Tracebacks would require the server to run in debug mode)
We need to agree when tracebacks should be reported and then implement the agreed approach across the codebase.
Proposal:
For an example of inconsistency, create a workflow with a space after a continuation line.
cylc validate
just returns an error message butcylc run
reports a traceback as well.