From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id CFB8D1FF135 for ; Sun, 08 Feb 2026 14:26:14 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 04CC51D260; Sun, 8 Feb 2026 14:26:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forestier.app; s=protonmail2; t=1770557167; x=1770816367; bh=CBCFP3P5csidkhkKJuu9XVq285WZQgzcVEcAlctcH08=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=dwjQeCn4fFekd1jb6qm86XpLRgBUBdTzaMjObndVGKNL1yelAZwkmb7xQjRGmaT6U sby009D+2gOUAr9Ndb6ARMFxMYtwtcr/P9YjqD2hwxHO/BMSJnWG/nHStvCRtLiaoI v62Om8+cC35xhpDjTb+OjX2urriqKzgzZuXv0311R/lkRCm2gve4xnrAqsXY3a4Pn0 S72B++8Ho1rGxuyf9aUp76daz/o9BwzjSC3AfC/sxASVgYyxuzScwrAquor5fwE0pp FuRUZtvJD97l/+Agt8t2u/M8ADeZWQ6wFXZnMiq46Qif1hN1keTIISULrn9zueiSiw B5LJ2S9+GASCg== Date: Sun, 08 Feb 2026 13:26:02 +0000 To: Stoiko Ivanov From: Samuel FORESTIER Subject: Re: [pmg-devel] [PATCH pmg-api 0/1] user config: password: allows (gost-)yescrypt, hashes Message-ID: <2b4c5404-bb61-4a91-8eb2-681b8f20e406@forestier.app> In-Reply-To: <20260206115328.74115c4a@rosa.proxmox.com> References: <576e113b-a610-47d6-99fa-c980e8c96e57@forestier.app> <20260206115328.74115c4a@rosa.proxmox.com> Feedback-ID: 90315422:user:proton X-Pm-Message-ID: 57bb06c25554e2cef70b2f1a428e7f9c8abb1499 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.002 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy RCVD_IN_DNSWL_LOW -0.7 Sender listed at https://www.dnswl.org/, low trust RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_PASS -0.001 SPF: HELO matches SPF record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: GN3MWK5ITRARGF2JW5AJKFMKOHPLA3FT X-Message-ID-Hash: GN3MWK5ITRARGF2JW5AJKFMKOHPLA3FT X-MailFrom: samuel+dev@forestier.app X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pmg-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Mail Gateway development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi Stoiko ! Thanks for your feedback, my responses inline. BR Stoiko Ivanov wrote: > It is possible to create a user in the PAM realm (just like in our other > products) - then you can simply login with the user - and their password > should be checked by PAM. This has the advantage that you do not duplicat= e > the password information and it stays consistent. >=20 > Currently creating users with realm PAM in the GUI is disabled (afair > simply because we haven't seen reports where people would want to have > many system-users as users in their PMG), but this could potentially be > allowed - if there is a use-case which benefits from this. > see: https://bugzilla.proxmox.com/show_bug.cgi?id=3D6488 for the request = to > hide the realm (expecting it not to be needed) Indeed it would have been possible to do so, but as you pointed out, PMG=20 currently doesn't honor system users through the PAM realm (bar root=20 itself, mainly for node bootstrapping and to limit the number of=20 passwords, I guess). > What is your use-case - how do you create the users on the system, and > would there be any upside for you to keep 2 copies of the password > (compared to having the user@pam directly ask PAM)? In my use case, PMG users are provisioned through a system configuration=20 manager, which doesn't know password clear texts (yescrypt hashes are=20 directly passed to shadow). These users are then synchronized from PAM=20 to PMG realm, by still using their hashed passwords. As of PMG 9.0, this patch is the only quick win I've come up with so far. > Regarding the patch itself allowing other password-hashes (and maybe > changing the default to yescrypt - as currently recommended by mkpasswd) > might be ok. Awesome ! No strong opinion about improving consistency across other=20 Proxmox' products or _simply_ applying this patch to PMG, to extend=20 UserConfig compatibility with more CRYPT(5) supported hash types. From a security point of view, I second your idea of defaulting to=20 yescrypt in the future, maybe in the next major PMG release (according=20 to your roadmap and "important" changes policy regarding semantic=20 versioning).