{"push_id":1118558634,"size":6,"distinct_size":0,"ref":"refs/heads/jk/preapprove-helper-credentials","head":"7cf26de176ad7596d66522d4a0a1fc836a4c80ac","before":"4677d40461042d68f7f727b44f25f4323ad54258","commits":[{"sha":"f924b52a7779038cee94151f0c1ee144652bccbe","author":{"email":"fd432345609ae4d58c1aa629cb66ba96d1391622@kdbg.org","name":"Johannes Sixt"},"message":"Windows: add pthread_sigmask() that does nothing\n\nA previous change introduced a call to pthread_sigmask() in order to block\nSIGPIPE in a thread. Since there are no signal facilities on Windows that\nare similar to POSIX signals, just ignore the request to block the signal.\nIn the particular case, the effect of blocking SIGPIPE on POSIX is that\nwrite() calls return EPIPE when the reader closes the pipe. This is how\nwrite() behaves on Windows.\n\nSigned-off-by: Johannes Sixt <j6t@kdbg.org>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/f924b52a7779038cee94151f0c1ee144652bccbe"},{"sha":"ed84387a6bfe271e9c1edd277bb6fad54c6a6f0b","author":{"email":"53fb8db7833fca1e1746dd8592f61048d350f64c@gmx.de","name":"Johannes Schindelin"},"message":"Windows: only add a no-op pthread_sigmask() when needed\n\nIn f924b52 (Windows: add pthread_sigmask() that does nothing,\n2016-05-01), we introduced a no-op for Windows. However, this breaks\nbuilding Git in Git for Windows' SDK because pthread_sigmask() is\nalready a no-op there, #define'd in the pthread_signal.h header in\n/mingw64/x86_64-w64-mingw32/include/.\n\nLet's wrap the definition of pthread_sigmask() in a guard that skips\nit when compiling with MinGW-w64' headers.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/ed84387a6bfe271e9c1edd277bb6fad54c6a6f0b"},{"sha":"b153d2ae9206f752dd383c7bc30a5ab246ee5bcc","author":{"email":"a6723cc3f76163bf7adb636a73ac3b0ceb3e6b9b@pobox.com","name":"Junio C Hamano"},"message":"Merge branch 'jk/push-client-deadlock-fix'\n\nSome Windows SDK lacks pthread_sigmask() implementation and fails\nto compile the recently updated \"git push\" codepath that uses it.\n\n* jk/push-client-deadlock-fix:\n  Windows: only add a no-op pthread_sigmask() when needed\n  Windows: add pthread_sigmask() that does nothing","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/b153d2ae9206f752dd383c7bc30a5ab246ee5bcc"},{"sha":"7efc1fae77b045ac04dc037478c42d4ba2646ad0","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"credential: do not store credentials received from helpers\n\nThe typical call flow for the credential API is something\nlike:\n\n  1. Network code (like http.c) wants a credential. It calls\n     credential_fill() to get it, and one of the two happens:\n\n     a. We call out to any helpers with a \"get\" request,\n\tone of which provides the credential.\n\n     b. No helper provides us the credential, so we ask the\n        user.\n\n  2. The network code uses the credential. Let's imagine\n     that the request completes successfully.\n\n  3. The network code informs the credential subsystem of\n     success by calling credential_approve(). The credential\n     code then calls out to any helpers with a \"store\"\n     request, so they can optionally store it if they want.\n\nIn the case of (1b), this is a good thing. The credential\ncomes from the user, gets used, and then gets put into\nstorage for later use again. But in the case of (1a), we end\nup feeding the helper with a credential that came from\nitself already (or possibly from another helper).\n\nMost of the time, this is harmless and slightly inefficient.\nBut it has two user-visible impacts:\n\n  1. If you have two helpers, you end up propagating data\n     between them. For instance, imagine you have a helper\n     \"git-credential-wallet\" which pulls data from a a\n     read-only password wallet. You might configure git like\n     this:\n\n       [credential]\n\t\thelper = wallet\n\t\thelper = cache\n\n     to check the wallet first, and then fall back to asking\n     the user and caching the result. But when we do get\n     something out of the wallet, git will then ask for it\n     to be stored in the wallet (which is a no-op), and the\n     cache. So your credential migrates from the wallet into\n     the cache, which may not be what you want (e.g.,\n     because the wallet implements more strict security\n     policies than the cache).\n\n  2. If you use a time-based storage helper like\n     \"git-credential-cache\", every time you run a git\n     command which uses the credential, it will also\n     re-insert the credential after use, freshening the\n     cache timestamp. So the cache will eventually expire N\n     time units after the last _use_, not after the time the\n     user actually typed the password. This is probably not\n     what most users expect or want (and if they do, we\n     should do it explicitly by providing an option to\n     refresh the timestamp on use).\n\nWe can solve this by marking a credential that comes from a\nhelper, so we don't bother feeding it back to the helpers.\nThe credential struct already has an \"approved\" flag so\nthat we try to store it only once, rather than for each\nsuccessful http request. We can use the same flag to\n\"pre-approve\" a credential which comes from a helper, and\nenver try to store it at all.","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/7efc1fae77b045ac04dc037478c42d4ba2646ad0"},{"sha":"a00626a5970edb14f586d8da23fc91042beaf8fe","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"add credential-wrap\n\nThis lets you wrap a \"real\" helper inside a cache.","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/a00626a5970edb14f586d8da23fc91042beaf8fe"},{"sha":"7cf26de176ad7596d66522d4a0a1fc836a4c80ac","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"credential: store and relay unknown credential lines\n\nJust because git itself does not make use of a line does not\nmean that another helper might not want to see it.","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/7cf26de176ad7596d66522d4a0a1fc836a4c80ac"}]}