[PR #578] Make clear that root password prompt is coming from sudo, not mkcert #498

New issue

Open

opened 2026-02-25 22:33:41 +03:00 by kerem · 0 comments

kerem commented

2026-02-25 22:33:41 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/FiloSottile/mkcert/pull/578
Author: @davebarkerxyz
Created: 3/30/2024
Status: 🔄 Open

Base: master ← Head: sudo-notice

📝 Commits (1)

3c990c7 Make clear that root password prompt is coming from sudo, not mkcert

📊 Changes

1 file changed (+2 additions, -1 deletions)

View changed files

📝 main.go (+2 -1)

📄 Description

Given the sensitive nature of passwords of users with sudo privileges, I propose to preserve the default behaviour (and prompt) of sudo as the user may expect, and instead print an explanatory message stating that mkcert is re-running with sudo.

Issue #178 led to commit github.com/FiloSottile/mkcert@aa4dd61066 which added the --prompt Sudo password: argument to the sudo command when re-running with elevated permissions. While a reasonable solution to the potential "which password is required?" confusion users may face, for users unfamiliar with the --prompt argument to sudo, it can cause concern that the user's password is being captured and processed by mkcert itself, and not by sudo (an insecure and unfortunately not uncommon action taken by some applications, like Zoom - see https://www.vmray.com/cyber-security-blog/zoom-macos-installer-analysis-good-apps-behaving-badly/).

This PR seeks to make it clearer to users that the password prompt is coming from sudo and not mkcert, while still explaining to users which password is being requested.

(When first trying mkcert -install and seeing the "Sudo password:" prompt, I worried that it would be capturing and saving my password for future elevation, and had to read the source to find out what was really happening - users less familiar with Go may have struggled with this).

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/FiloSottile/mkcert/pull/578 **Author:** [@davebarkerxyz](https://github.com/davebarkerxyz) **Created:** 3/30/2024 **Status:** 🔄 Open **Base:** `master` ← **Head:** `sudo-notice` --- ### 📝 Commits (1) - [`3c990c7`](https://github.com/FiloSottile/mkcert/commit/3c990c7b45ff3d0e5b4e58274427ea81d27afa18) Make clear that root password prompt is coming from sudo, not mkcert ### 📊 Changes **1 file changed** (+2 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `main.go` (+2 -1) </details> ### 📄 Description Given the sensitive nature of passwords of users with sudo privileges, I propose to preserve the default behaviour (and prompt) of sudo as the user may expect, and instead print an explanatory message stating that mkcert is re-running with sudo. Issue #178 led to commit https://github.com/FiloSottile/mkcert/commit/aa4dd610664a3b092f35cb7c996d94e3c3da6159 which added the `--prompt Sudo password:` argument to the sudo command when re-running with elevated permissions. While a reasonable solution to the potential "which password is required?" confusion users may face, for users unfamiliar with the `--prompt` argument to sudo, it can cause concern that the user's password is being captured and processed by mkcert itself, and not by sudo (an insecure and unfortunately not uncommon action taken by some applications, like Zoom - see https://www.vmray.com/cyber-security-blog/zoom-macos-installer-analysis-good-apps-behaving-badly/). This PR seeks to make it clearer to users that the password prompt is coming from sudo and not mkcert, while still explaining to users which password is being requested. (When first trying `mkcert -install` and seeing the "Sudo password:" prompt, I worried that it would be capturing and saving my password for future elevation, and had to read the source to find out what was really happening - users less familiar with Go may have struggled with this). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>