public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Dominik Csapak <d.csapak@proxmox.com>
Cc: Wolfgang Bumiller <w.bumiller@proxmox.com>
Subject: Re: [pve-devel] [PATCH access-control v2 1/3] authenticate_2nd_new: only lock tfa config for recovery keys
Date: Fri, 21 Oct 2022 13:29:42 +0200	[thread overview]
Message-ID: <04a8f643-cb3f-daf8-480b-240726cec255@proxmox.com> (raw)
In-Reply-To: <20221021083117.1239396-2-d.csapak@proxmox.com>

Can we *please* get sane commit subject for *human* consumption?!

The worst one, that really triggers me:
> authenticate_user: pass undef instead of empty $tfa_challenge to authenticate_2nd_new
Instead of a high level human overview it gives basically another almost
machine readable diff of the lower level changes. So there's close to zero
of useful higher level and/or _new_ info in there, but sure makes one stop
to parse on seeing this in some log.

Copying the method name (nor file module name!) is basically never a good
idea, especially as tag and especially for (admin) user facing changes - it
can naturally be OK for library stuff (i.e., dev-only facing changes), but
even then seldom as start `<tag>:`...

following would allow for a quicker to read, and (granted, slightly
subjective) better high level understanding of the commits, thus better
categorizing for when skimming through the log, e.g., in search of relevant
changes due to some new/questionable/.. behavior; besides that it makes
d/changelog writing easier.

* tfa: only lock config for recovery keys on authentication
* tfa: rename outdated $otp variable to $tfa_response
  (this is internal and won't ever make it in the d/changelog so only dev
  readability matters)
* auth: drop passing bogus challenge variable when checking first factor
  (also internally, dev oriented)

This should be also verified and either amened or commented on by the
maintainer (planning) pushing a commit/series - while its obviously 1) hard
and 2) a lot overhead to have a very strict rule book that's fine for a
partially subjective thing like this, it should be that hard to detect the
obvious cases, at least for user facing changes.

May look like a small thing to "rant" on, but I spend a lot of time in git
log et al. and copy pasted method/file names without simple concise tagging
and for-human info can make it much harder with no benefit for anyone.

Naturally applies to all devs/maintainers not just those in To/Cc here.




  reply	other threads:[~2022-10-21 11:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21  8:31 [pve-devel] [PATCH access-control v2 0/3] improve tfa config locking Dominik Csapak
2022-10-21  8:31 ` [pve-devel] [PATCH access-control v2 1/3] authenticate_2nd_new: only lock tfa config for recovery keys Dominik Csapak
2022-10-21 11:29   ` Thomas Lamprecht [this message]
2022-10-21 11:38     ` Dominik Csapak
2022-10-21  8:31 ` [pve-devel] [PATCH access-control v2 2/3] authenticate_2nd_new: rename $otp to $tfa_response Dominik Csapak
2022-10-21  8:31 ` [pve-devel] [PATCH access-control v2 3/3] authenticate_user: pass undef instead of empty $tfa_challenge to authenticate_2nd_new Dominik Csapak
2022-10-21  8:47 ` [pve-devel] applied-series: [PATCH access-control v2 0/3] improve tfa config locking Wolfgang Bumiller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=04a8f643-cb3f-daf8-480b-240726cec255@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=w.bumiller@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal