glog is used on a variety of systems, and we must assume that some of
them still use vulnerable mailers that have bugs or "interesting
features" such as https://nvd.nist.gov/vuln/detail/CVE-2004-2771.
Let's protect users against accidental shell injection by validating
the email addresses against a slightly stricter version of the regex
used by HTML5 to validate addresses[1].
This should prevent triggering any unexpected behavior in these tools.
Also add some basic unit tests for the SendEmail method.
[1] https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address
https://github.com/google/glog/issues/837 has caused a couple of
disappointments for PR authors, so I'm hoping this comment can save them
some time, or even help them towards finding a complete solution for the
problem.
Since #846, `HAVE_UNWIND_H` is not really in use. Instead we should use `HAVE__UNWIND_BACKTRACE` and `HAVE__UNWIND_GETIP` (added in #846). To prevent that from happening again, also added Bazel tests that confirm stacktrace are still working.
1. Initializing std::ostringstream with a string makes no sense, as the
string becomes an initial value of an underlying buffer; seek-to-end
is not performed, so the initial value gets completely overwritten by
subsequent writing.
2. Flag `log_year_in_prefix` should be considered, as if formatting a
regular logging message.
3. Writing a buffer to std::ostream is better expressed with write(s,n).
As specified in the doc comment for SetLogger, "the logger becomes the
property of the logging module and should not be deleted by the caller".
Not only should the LogDestination delete a custom logger in its
destructor, but it should also delete a previous logger when another
logger is passed to SetLogger().
Co-authored-by: Sergiu Deitsch <sergiud@users.noreply.github.com>
Log lines can be customized for parsing by an external tool.
To simplify such customization and parsing, there should be an option to
customize the file header, or at least to disable adding it.
Calling FormatMessage without a FORMAT_MESSAGE_IGNORE_INSERTS flag could
cause trouble, as explained in an article by Raymond Chen:
* The importance of the FORMAT_MESSAGE_IGNORE_INSERTS flag
https://devblogs.microsoft.com/oldnewthing/20071128-00/?p=24353
The previous approach used
--incompatible_enable_cc_toolchain_resolution, which is recommended by
the docs, but a Bazel developer told me it's obsolete. The new, old
approach is simpler and should stop the warning from being user-visible.
