{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":249207961,"defaultBranch":"master","name":"puma","ownerLogin":"stanhu","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2020-03-22T15:03:57.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/963826?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1704927684.0","currentOid":""},"activityList":{"items":[{"before":"883b6303afa8a9f55cfef8c85259f443ebb25609","after":"d4ac708814ce71da8718b985c3b8473b9c56b5a8","ref":"refs/heads/sh-fix-pid1-wait","pushedAt":"2024-01-26T17:59:16.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Add integration test for Puma worker reaping\n\nThis test ensures that Puma handles the `Process.detach` bug described\nin https://bugs.ruby-lang.org/issues/19837.","shortMessageHtmlLink":"Add integration test for Puma worker reaping"}},{"before":"b20415f0c562deeeb59642321ceb0d12a662de35","after":"883b6303afa8a9f55cfef8c85259f443ebb25609","ref":"refs/heads/sh-fix-pid1-wait","pushedAt":"2024-01-16T16:51:00.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Add integration test for Puma worker reaping\n\nThis test ensures that Puma handles the `Process.detach` bug described\nin https://bugs.ruby-lang.org/issues/19837.","shortMessageHtmlLink":"Add integration test for Puma worker reaping"}},{"before":"bd08e8a8ee8b62cccd7eb23b30c8bcdf997be64e","after":"b20415f0c562deeeb59642321ceb0d12a662de35","ref":"refs/heads/sh-fix-pid1-wait","pushedAt":"2024-01-12T20:17:58.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Add integration test for Puma worker reaping\n\nThis test ensures that Puma handles the `Process.detach` bug described\nin https://bugs.ruby-lang.org/issues/20181.","shortMessageHtmlLink":"Add integration test for Puma worker reaping"}},{"before":"83f53bdc4f0998f12019a96e20bae4c47f6a62b4","after":"bd08e8a8ee8b62cccd7eb23b30c8bcdf997be64e","ref":"refs/heads/sh-fix-pid1-wait","pushedAt":"2024-01-11T17:04:05.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Fix child processes not being reaped with PID 1\n\nStarting with Puma v6.4.1, we observed that killed Puma cluster\nworkers were never being restarted when the parent was run as PID\n1. For example, I issued a `kill 44` and PID 44 remained in the\n`defunct` state:\n\n```\ngit@gitlab-webservice-default-78664bb757-2nxvh:/var/log/gitlab$ ps -ef\nUID          PID    PPID  C STIME TTY          TIME CMD\ngit            1       0  0 Jan09 ?        00:01:39 puma 6.4.1 (tcp://0.0.0.0:8080) [gitlab-puma-worker]\ngit           23       1  0 Jan09 ?        00:05:46 /usr/local/bin/gitlab-logger /var/log/gitlab\ngit           41       1  0 Jan09 ?        00:01:55 ruby /srv/gitlab/bin/metrics-server\ngit           44       1  0 Jan09 ?        00:02:41 [ruby] <defunct>\ngit           46       1  0 Jan09 ?        00:02:38 puma: cluster worker 1: 1 [gitlab-puma-worker]\ngit           48       1  0 Jan09 ?        00:02:42 puma: cluster worker 2: 1 [gitlab-puma-worker]\ngit           49       1  0 Jan09 ?        00:02:41 puma: cluster worker 3: 1 [gitlab-puma-worker]\ngit         5205       0  0 21:57 pts/0    00:00:00 bash\ngit         5331    5205  0 22:00 pts/0    00:00:00 ps -ef\n```\n\nFurther investigation showed that the introduction of\n`Process.wait2(-1, Process::WNOHANG)` in #3255 never appears to return\nanything when:\n\n1. The parent PID is 1.\n2. `Process.detach(some PID != 1)` is run after a `Process.spawn`.\nThis bug appears to be present in Ruby 3.1 and 3.2, but it seems to\nhave been fixed in Ruby 3.3.\n\nPreviously `Process.wait(w.pid, Process::WNOHANG)` was called on each\nknown worker PID. #3255 changed this behavior to do this only if the\n`fork_worker` config parameter were enabled, but it seems that we\nshould always do this.\n\nCloses #3313","shortMessageHtmlLink":"Fix child processes not being reaped with PID 1"}},{"before":"02096b55e9d315e46418ac113d4b6c2ea74ce548","after":"83f53bdc4f0998f12019a96e20bae4c47f6a62b4","ref":"refs/heads/sh-fix-pid1-wait","pushedAt":"2024-01-10T23:24:57.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Fix child processes not being reaped with PID 1\n\nStarting with Puma v6.4.1, we observed that killed Puma cluster\nworkers were never being restarted when the parent was run as PID\n1. For example, I issued a `kill 44` and PID 44 remained in the\n`defunct` state:\n\n```\ngit@gitlab-webservice-default-78664bb757-2nxvh:/var/log/gitlab$ ps -ef\nUID          PID    PPID  C STIME TTY          TIME CMD\ngit            1       0  0 Jan09 ?        00:01:39 puma 6.4.1 (tcp://0.0.0.0:8080) [gitlab-puma-worker]\ngit           23       1  0 Jan09 ?        00:05:46 /usr/local/bin/gitlab-logger /var/log/gitlab\ngit           41       1  0 Jan09 ?        00:01:55 ruby /srv/gitlab/bin/metrics-server\ngit           44       1  0 Jan09 ?        00:02:41 [ruby] <defunct>\ngit           46       1  0 Jan09 ?        00:02:38 puma: cluster worker 1: 1 [gitlab-puma-worker]\ngit           48       1  0 Jan09 ?        00:02:42 puma: cluster worker 2: 1 [gitlab-puma-worker]\ngit           49       1  0 Jan09 ?        00:02:41 puma: cluster worker 3: 1 [gitlab-puma-worker]\ngit         5205       0  0 21:57 pts/0    00:00:00 bash\ngit         5331    5205  0 22:00 pts/0    00:00:00 ps -ef\n```\n\nFurther investigation showed that the introduction of\n`Process.wait2(-1, Process::WNOHANG)` in #3255 never appears to return\nanything inside Google Kubernetes Engine running as PID 1.\n\nPreviously `Process.wait(w.pid, Process::WNOHANG)` was called on each\nknown worker PID. #3255 changed this behavior to do this only if the\n`fork_worker` config parameter were enabled, but it seems that we\nshould always do this.\n\nCloses #3313","shortMessageHtmlLink":"Fix child processes not being reaped with PID 1"}},{"before":"cbb25edd4e50a350f574f4750a89e91e08c11317","after":"02096b55e9d315e46418ac113d4b6c2ea74ce548","ref":"refs/heads/sh-fix-pid1-wait","pushedAt":"2024-01-10T23:13:50.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Fix child processes not being reaped with PID 1\n\nStarting with Puma v6.4.1, we observed that killed Puma cluster\nworkers were never being restarted when the parent was run as PID\n1. For example, I issued a `kill 44` and PID 44 remained in the\n`defunct` state:\n\n```\ngit@gitlab-webservice-default-78664bb757-2nxvh:/var/log/gitlab$ ps -ef\nUID          PID    PPID  C STIME TTY          TIME CMD\ngit            1       0  0 Jan09 ?        00:01:39 puma 6.4.1 (tcp://0.0.0.0:8080) [gitlab-puma-worker]\ngit           23       1  0 Jan09 ?        00:05:46 /usr/local/bin/gitlab-logger /var/log/gitlab\ngit           41       1  0 Jan09 ?        00:01:55 ruby /srv/gitlab/bin/metrics-server\ngit           44       1  0 Jan09 ?        00:02:41 [ruby] <defunct>\ngit           46       1  0 Jan09 ?        00:02:38 puma: cluster worker 1: 1 [gitlab-puma-worker]\ngit           48       1  0 Jan09 ?        00:02:42 puma: cluster worker 2: 1 [gitlab-puma-worker]\ngit           49       1  0 Jan09 ?        00:02:41 puma: cluster worker 3: 1 [gitlab-puma-worker]\ngit         5205       0  0 21:57 pts/0    00:00:00 bash\ngit         5331    5205  0 22:00 pts/0    00:00:00 ps -ef\n```\n\nFurther investigation showed that the introduction of\n`Process.wait2(-1, Process::WNOHANG)` in #3255 never appears to return\nanything inside Google Kubernetes Engine running as PID 1.\n\nPreviously `Process.wait(w.pid, process::WNOHANG)` was called on each\nknown worker PID. #3255 changed this behavior to do this only if the\n`fork_worker` config parameter were enabled, but it seems that we\nshould always do this.\n\nCloses #3313","shortMessageHtmlLink":"Fix child processes not being reaped with PID 1"}},{"before":"1c10a00a251edb76ff9fc6fddfb2f220f78861c3","after":"cbb25edd4e50a350f574f4750a89e91e08c11317","ref":"refs/heads/sh-fix-pid1-wait","pushedAt":"2024-01-10T23:13:03.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Fix child processes not being reaped with PID 1\n\nStarting with Puma v6.4.1, we observed that killed Puma cluster\nworkers were never being restarted when the parent was run as PID\n1. For example, I issued a `kill 44` and PID 44 remained in the\n`defunct` state:\n\n```\ngit@gitlab-webservice-default-78664bb757-2nxvh:/var/log/gitlab$ ps -ef\nUID          PID    PPID  C STIME TTY          TIME CMD\ngit            1       0  0 Jan09 ?        00:01:39 puma 6.4.1 (tcp://0.0.0.0:8080) [gitlab-puma-worker]\ngit           23       1  0 Jan09 ?        00:05:46 /usr/local/bin/gitlab-logger /var/log/gitlab\ngit           41       1  0 Jan09 ?        00:01:55 ruby /srv/gitlab/bin/metrics-server\ngit           44       1  0 Jan09 ?        00:02:41 [ruby] <defunct>\ngit           46       1  0 Jan09 ?        00:02:38 puma: cluster worker 1: 1 [gitlab-puma-worker]\ngit           48       1  0 Jan09 ?        00:02:42 puma: cluster worker 2: 1 [gitlab-puma-worker]\ngit           49       1  0 Jan09 ?        00:02:41 puma: cluster worker 3: 1 [gitlab-puma-worker]\ngit         5205       0  0 21:57 pts/0    00:00:00 bash\ngit         5331    5205  0 22:00 pts/0    00:00:00 ps -ef\n```\n\nFurther investigation showed that the introduction of\n`Process.wait2(-1, Process::WNOHANG)` in #3255 never appears to return\nanything inside Google Kubernetes Engine running as PID 1.\n\nPreviously `Process.wait(w.pid, process::WNOHANG)` was called on each\nknown worker PID. #3255 changed this behavior to do this only if the\n`fork_worker` config parameter were enabled, but it seems that we\nshould always do this.\n\nCloses #3313","shortMessageHtmlLink":"Fix child processes not being reaped with PID 1"}},{"before":"65c7246db0504e0916d805859b84b0977d95e7aa","after":"1c10a00a251edb76ff9fc6fddfb2f220f78861c3","ref":"refs/heads/sh-fix-pid1-wait","pushedAt":"2024-01-10T23:05:48.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Fix child processes not being reaped with PID 1\n\nStarting with Puma v6.4.1, we observed that killed Puma cluster\nworkers were never being restarted when run as PID 1. Note that PID 44\nremained in the `defunct` state after a `kill 44` was issued:\n\n```\ngit@gitlab-webservice-default-78664bb757-2nxvh:/var/log/gitlab$ ps -ef\nUID          PID    PPID  C STIME TTY          TIME CMD\ngit            1       0  0 Jan09 ?        00:01:39 puma 6.4.1 (tcp://0.0.0.0:8080) [gitlab-puma-worker]\ngit           23       1  0 Jan09 ?        00:05:46 /usr/local/bin/gitlab-logger /var/log/gitlab\ngit           41       1  0 Jan09 ?        00:01:55 ruby /srv/gitlab/bin/metrics-server\ngit           44       1  0 Jan09 ?        00:02:41 [ruby] <defunct>\ngit           46       1  0 Jan09 ?        00:02:38 puma: cluster worker 1: 1 [gitlab-puma-worker]\ngit           48       1  0 Jan09 ?        00:02:42 puma: cluster worker 2: 1 [gitlab-puma-worker]\ngit           49       1  0 Jan09 ?        00:02:41 puma: cluster worker 3: 1 [gitlab-puma-worker]\ngit         5205       0  0 21:57 pts/0    00:00:00 bash\ngit         5331    5205  0 22:00 pts/0    00:00:00 ps -ef\n```\n\nFurther investigation showed that the introduction of\n`Process.wait2(-1, Process::WNOHANG)` in #3255 never appears to return\nanything inside Google Kubernetes Engine running as PID 1.\n\nPreviously `Process.wait(w.pid, process::WNOHANG)` was called on each\nknown worker PID. #3255 changed this behavior to do this only if the\n`fork_worker` config parameter were enabled, but it seems that we\nshould always do this.\n\nCloses #3313","shortMessageHtmlLink":"Fix child processes not being reaped with PID 1"}},{"before":"4eef2506b6b0cd189cd27328c11ce6365d5b9eb4","after":"65c7246db0504e0916d805859b84b0977d95e7aa","ref":"refs/heads/sh-fix-pid1-wait","pushedAt":"2024-01-10T23:03:00.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Fix child processes not being reaped with PID 1\n\nStarting with Puma v6.4.1, we observed that killed Puma cluster\nworkers were never being restarted when run as PID 1. Note that PID 44\nremained in the `defunct` state after a `kill 44` was issued:\n\n```\ngit@gitlab-webservice-default-78664bb757-2nxvh:/var/log/gitlab$ ps -ef\nUID          PID    PPID  C STIME TTY          TIME CMD\ngit            1       0  0 Jan09 ?        00:01:39 puma 6.4.1 (tcp://0.0.0.0:8080) [gitlab-puma-worker]\ngit           23       1  0 Jan09 ?        00:05:46 /usr/local/bin/gitlab-logger /var/log/gitlab\ngit           41       1  0 Jan09 ?        00:01:55 ruby /srv/gitlab/bin/metrics-server\ngit           44       1  0 Jan09 ?        00:02:41 [ruby] <defunct>\ngit           46       1  0 Jan09 ?        00:02:38 puma: cluster worker 1: 1 [gitlab-puma-worker]\ngit           48       1  0 Jan09 ?        00:02:42 puma: cluster worker 2: 1 [gitlab-puma-worker]\ngit           49       1  0 Jan09 ?        00:02:41 puma: cluster worker 3: 1 [gitlab-puma-worker]\ngit         5205       0  0 21:57 pts/0    00:00:00 bash\ngit         5331    5205  0 22:00 pts/0    00:00:00 ps -ef\n```\n\nFurther investigation showed that the introduction of\n`Process.wait2(-1, Process::WNOHANG)` in #3255 never appears to return\nanything inside Google Kubernetes Engine running as PID 1.\n\nPreviously `Process.wait(w.pid, process::WNOHANG)` was called on each\nknown worker PID. #3255 changed this behavior to do this only if the\n`fork_worker` config parameter were enabled, but it seems that we\nshould always do this.\n\nCloses #3313","shortMessageHtmlLink":"Fix child processes not being reaped with PID 1"}},{"before":"310f35ea0af2507bf986d2a5222193fde29a127b","after":"4eef2506b6b0cd189cd27328c11ce6365d5b9eb4","ref":"refs/heads/sh-fix-pid1-wait","pushedAt":"2024-01-10T23:02:07.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Fix child processes not being reaped with PID 1\n\nStarting with Puma v6.4.1, we observed that killed Puma cluster\nworkers were never being restarted when run as PID 1. Note that PID 44\nremained in the `defunct` state after a `kill 44` was issued:\n\n```\ngit@gitlab-webservice-default-78664bb757-2nxvh:/var/log/gitlab$ ps -ef\nUID          PID    PPID  C STIME TTY          TIME CMD\ngit            1       0  0 Jan09 ?        00:01:39 puma 6.4.1 (tcp://0.0.0.0:8080) [gitlab-puma-worker]\ngit           23       1  0 Jan09 ?        00:05:46 /usr/local/bin/gitlab-logger /var/log/gitlab\ngit           41       1  0 Jan09 ?        00:01:55 ruby /srv/gitlab/bin/metrics-server\ngit           44       1  0 Jan09 ?        00:02:41 [ruby] <defunct>\ngit           46       1  0 Jan09 ?        00:02:38 puma: cluster worker 1: 1 [gitlab-puma-worker]\ngit           48       1  0 Jan09 ?        00:02:42 puma: cluster worker 2: 1 [gitlab-puma-worker]\ngit           49       1  0 Jan09 ?        00:02:41 puma: cluster worker 3: 1 [gitlab-puma-worker]\ngit         5205       0  0 21:57 pts/0    00:00:00 bash\ngit         5331    5205  0 22:00 pts/0    00:00:00 ps -ef\n```\n\nFurther investigation showed that the introduction of\n`Process.wait2(-1, Process::WNOHANG)` in #3255 never appears to return\nanything inside Google Kubernetes Engine running as PID 1.\n\nPreviously `Process.wait(w.pid, process::WNOHANG)` was called on each\nknown worker PID. #3255 changed this behavior to do this only if the\n`fork_worker` config parameter were enabled, but it seems that we\nshould always do this.","shortMessageHtmlLink":"Fix child processes not being reaped with PID 1"}},{"before":null,"after":"310f35ea0af2507bf986d2a5222193fde29a127b","ref":"refs/heads/sh-fix-pid1-wait","pushedAt":"2024-01-10T23:01:24.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Fix child processes not being reaped with PID 1\n\nStarting with Puma v6.4.1, we observed that killed Puma cluster\nworkers were never being restarted when run as PID 1. Note that PID 44\nremained in the `defunct` state after a `kill 44` was issued:\n\n```\ngit@gitlab-webservice-default-78664bb757-2nxvh:/var/log/gitlab$ ps -ef\nUID          PID    PPID  C STIME TTY          TIME CMD\ngit            1       0  0 Jan09 ?        00:01:39 puma 6.4.1 (tcp://0.0.0.0:8080) [gitlab-puma-worker]\ngit           23       1  0 Jan09 ?        00:05:46 /usr/local/bin/gitlab-logger /var/log/gitlab\ngit           41       1  0 Jan09 ?        00:01:55 ruby /srv/gitlab/bin/metrics-server\ngit           44       1  0 Jan09 ?        00:02:41 [ruby] <defunct>\ngit           46       1  0 Jan09 ?        00:02:38 puma: cluster worker 1: 1 [gitlab-puma-worker]\ngit           48       1  0 Jan09 ?        00:02:42 puma: cluster worker 2: 1 [gitlab-puma-worker]\ngit           49       1  0 Jan09 ?        00:02:41 puma: cluster worker 3: 1 [gitlab-puma-worker]\ngit         5205       0  0 21:57 pts/0    00:00:00 bash\ngit         5331    5205  0 22:00 pts/0    00:00:00 ps -ef\n```\n\nFurther investigation showed that the introduction of\n`Process.wait2(-1, Process::WNOHANG)` in #3255 never appears to return\nanything inside Google Kubernetes Engine running as PID 1.\n\nPreviously `Process.wait(w.pid, process::WNOHANG)` was called on each\nknown worker PID. #3255 changed this behavior to do this only if the\n`fork_worker` config parameter were enabled, but it seems that we\nshould always do this.","shortMessageHtmlLink":"Fix child processes not being reaped with PID 1"}},{"before":"e381976dd44f51eace5a5ea043398ecf407e1270","after":"571f7e6bcb0052a45d11420827dcf5f4931ef844","ref":"refs/heads/sh-support-openssl-decrypt-key","pushedAt":"2023-04-29T17:20:22.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Add documentation for `key_password_command`","shortMessageHtmlLink":"Add documentation for <code>key_password_command</code>"}},{"before":"80d9c024c0f3db8bad4442806afb0364a5b2500a","after":"e381976dd44f51eace5a5ea043398ecf407e1270","ref":"refs/heads/sh-support-openssl-decrypt-key","pushedAt":"2023-04-29T17:11:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Allow tests to run on Windows","shortMessageHtmlLink":"Allow tests to run on Windows"}},{"before":"8cf9ce25cf4ca2921217fd3cbd758057f5755ba8","after":"80d9c024c0f3db8bad4442806afb0364a5b2500a","ref":"refs/heads/sh-support-openssl-decrypt-key","pushedAt":"2023-04-29T05:36:04.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Exclude Windows from encrypted SSL key tests\n\nshell scripts can't be executed in Windows, so let's\nnot bother.","shortMessageHtmlLink":"Exclude Windows from encrypted SSL key tests"}},{"before":"0e32efc962ac3051854d025d627c698dda9a55e9","after":"8cf9ce25cf4ca2921217fd3cbd758057f5755ba8","ref":"refs/heads/sh-support-openssl-decrypt-key","pushedAt":"2023-04-29T05:21:10.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Support decryption of SSL key\n\nThis commit makes it possible to store an encrypted SSL key on disk\nand have Puma decrypt it at runtime by supplying a\n`key_password_command`. Supplying a `key_password_command` will cause\nPuma to:\n\n1. Execute the external program.\n2. Read the password from stdout and remove the trailing newline.\n2. Configure the OpenSSL callbacks to use the password.\n\nOther Web servers, such as NGINX and Apache, have a similar feature.\nNGINX only allows supplying a password file via the `ssl_password`\nparameter (https://www.nginx.com/blog/secure-distribution-ssl-private-keys-nginx/),\nwhile Apache has a `SSLPassPhraseDialog` option (https://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslpassphrasedialog)\nthat allows an admin to execute an external program.\n\nCloses #3132","shortMessageHtmlLink":"Support decryption of SSL key"}},{"before":"f313f4f1266256f7216016fa514adcbc752badce","after":"0e32efc962ac3051854d025d627c698dda9a55e9","ref":"refs/heads/sh-support-openssl-decrypt-key","pushedAt":"2023-04-29T05:15:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Support decryption of SSL key\n\nThis commit makes it possible to store an encrypted SSL key on disk\nand have Puma decrypt it at runtime by supplying a\n`key_password_command`. Supplying a `key_password_command` will cause\nPuma to:\n\n1. Execute the external program.\n2. Read the password from stdout and remove the trailing newline.\n2. Configure the OpenSSL callbacks to use the password.\n\nOther Web servers, such as NGINX and Apache, have a similar feature.\nNGINX only allows supplying a password file via the `ssl_password`\nparameter (https://www.nginx.com/blog/secure-distribution-ssl-private-keys-nginx/),\nwhile Apache has a `SSLPassPhraseDialog` option (https://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslpassphrasedialog)\nthat allows an admin to execute an external program.\n\nCloses #3132","shortMessageHtmlLink":"Support decryption of SSL key"}},{"before":"95a8856100ba374f5c7d24d8e741fb5c63c2ad61","after":"f313f4f1266256f7216016fa514adcbc752badce","ref":"refs/heads/sh-support-openssl-decrypt-key","pushedAt":"2023-04-29T05:14:09.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Support decryption of SSL key\n\nThis commit makes it possible to store an encrypted SSL key on disk\nand have Puma decrypt it at runtime by supplying a\n`key_password_command` that prints the decryption password to stdout.\nSupplying a `key_password_command` will cause Puma to:\n\n1. Execute the external program.\n2. Read the password from stdout and remove the trailing newline.\n2. Configure the OpenSSL callbacks to use the password.\n\nOther Web servers, such as NGINX and Apache, have a similar feature.\nNGINX only allows supplying a password file via the `ssl_password`\nparameter (https://www.nginx.com/blog/secure-distribution-ssl-private-keys-nginx/),\nwhile Apache has a `SSLPassPhraseDialog` option (https://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslpassphrasedialog)\nthat allows an admin to execute an external program.\n\nCloses #3132","shortMessageHtmlLink":"Support decryption of SSL key"}},{"before":"2d360fd2d9b0f8d10d197d97a15cae6a6bfd2096","after":"95a8856100ba374f5c7d24d8e741fb5c63c2ad61","ref":"refs/heads/sh-support-openssl-decrypt-key","pushedAt":"2023-04-29T05:07:34.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Add tests, rename to key_password_command, and fix PEM decryption","shortMessageHtmlLink":"Add tests, rename to key_password_command, and fix PEM decryption"}},{"before":"a471932d56493efcbe74e55eed4520a725242d30","after":"2d360fd2d9b0f8d10d197d97a15cae6a6bfd2096","ref":"refs/heads/sh-support-openssl-decrypt-key","pushedAt":"2023-04-26T19:49:36.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Allow key_decrypt_command to be used with `key_pem` as well","shortMessageHtmlLink":"Allow key_decrypt_command to be used with <code>key_pem</code> as well"}},{"before":null,"after":"a471932d56493efcbe74e55eed4520a725242d30","ref":"refs/heads/sh-support-openssl-decrypt-key","pushedAt":"2023-04-26T19:29:10.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"stanhu","name":"Stan Hu","path":"/stanhu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/963826?s=80&v=4"},"commit":{"message":"Support decryption of SSL key\n\nThis commit makes it possible to store an encrypted SSL key on disk\nand enables Puma to decrypt it via a `key_decrypt_command`. This\ncommand is executed when OpenSSL needs to decrypt a encrypted key.\n\nCloses #3132","shortMessageHtmlLink":"Support decryption of SSL key"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAD6hxLSQA","startCursor":null,"endCursor":null}},"title":"Activity · stanhu/puma"}