-
Notifications
You must be signed in to change notification settings - Fork 915
Permalink
Choose a base ref
{{ refName }}
default
Choose a head ref
{{ refName }}
default
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
base repository: golang/glog
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: v1.2.2
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
...
head repository: golang/glog
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: v1.2.4
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
- 5 commits
- 5 files changed
- 1 contributor
Commits on Nov 4, 2024
-
glog: check that stderr is valid before using it by default (#72)
Windows Services are [spawned without `stdout` and `stderr`](https://learn.microsoft.com/en-us/windows/console/getstdhandle#return-value:~:text=If%20an%20application%20does%20not%20have%20associated%20standard%20handles%2C%20such%20as%20a%20service%20running%20on%20an%20interactive%20desktop%2C%20and%20has%20not%20redirected%20them%2C%20the%20return%20value%20is%20NULL.), so any attempt to use them equates to referencing an invalid file `Handle`. `stderrSink` returns the error, which makes `logsink` trigger the termination of the process. The result is that any call to `log.Error` (or `log.Fatal`) from a Windows Service will always crash the program. This approach checks that `os.Stderr`'s embedded file descriptor (`Handle`, for Windows) is non-NULL once during `init` to determine its validity and if it fails, then never registers `stderrSink` as a logsink. Disabling based upon whether `os.Stderr` is NULL was chosen because it's precise, doesn't actually influence the result of any output and doesn't require any syscalls, but still detects the case in which `stderr` is unavailable on Windows. A rejected approach here would've been to swallow the errors from `stderrSink.Emit`, thus sparing us program termination at the hands of `logsink`. I rejected this approach because it felt like it could result in some subtle behavioral changes. For example, invoking `log.Error` after `os.Stderr.Close()` would no longer exit the program and that felt like a non-trivial change (although I can think of no reason why one would desire this behavior). cl/680817112 (google-internal)
Configuration menu - View commit details
-
Copy full SHA for 459cf3b - Browse repository at this point
Copy the full SHA 459cf3bView commit details
Commits on Nov 5, 2024
-
Configuration menu - View commit details
-
Copy full SHA for 04dbec0 - Browse repository at this point
Copy the full SHA 04dbec0View commit details
Commits on Jan 13, 2025
-
glog: Don't try to create/rotate a given syncBuffer twice in the same…
… second If you do, then you truncate the existing file. So logging too much too quickly would lose log data. cl/709080575 (google-internal)
Configuration menu - View commit details
-
Copy full SHA for dd58629 - Browse repository at this point
Copy the full SHA dd58629View commit details -
Configuration menu - View commit details
-
Copy full SHA for 7139da2 - Browse repository at this point
Copy the full SHA 7139da2View commit details -
glog: have createInDir fail if the file already exists
This prevents an attack like the one described [here](https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File#:~:text=On%20Unix%20based,with%20elevated%20permissions.). An unprivileged attacker could use symlinks to trick a privileged logging process to follow a symlink from the log dir and write logs over an arbitrary file. The components of the log names are program, host, username, tag, date, time and PID. These are all predictable. It's not at all unusual for the logdir to be writable by unprivileged users, and one of the fallback directories (/tmp) traditionally has broad write privs with the sticky bit set on Unix systems. As a concrete example, let's say I've got a glog-enabled binary running as a root cronjob. I can gauge when that cron job will run and then use a bash script to spray the log dir with glog-looking symlinks to `/etc/shadow` with predicted times and PIDs. When the cronjob runs, the `os.Create` call will follow the symlink, truncate `/etc/shadow` and then fill it with logs. This change defeats that by setting `O_EXCL`, which will cause the open call to fail if the file already exists. Fixes CVE-2024-45339 cl/712795111 (google-internal)
Configuration menu - View commit details
-
Copy full SHA for a0e3c40 - Browse repository at this point
Copy the full SHA a0e3c40View commit details
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v1.2.2...v1.2.4