Re: [edk2-devel] [PATCH v5 0/5] Implement SM3 measured boot

["Laszlo Ersek" <lersek@redhat.com>]

On 07/04/19 02:47, Imran Desai wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1781
>
> EDK2 Support for SM3 digest algorithm is needed to enable TPM with SM3 PCR
> banks. This digest algorithm is part of the China Crypto algorithm suite.
> This integration has dependency on the openssl_1_1_1b integration into
> edk2.
>
> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Chao Zhang <chao.b.zhang@intel.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Jian Wang <jian.j.wang@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
> Cc: Stefan Berger <stefanb@linux.ibm.com>
>
> Imran Desai (5):
>   MdePkg/Protocol/Hash: introduce GUID for SM3 digest algorithm
>   SecurityPkg: introduce the SM3 digest algorithm
>   SecurityPkg/HashLibBaseCryptoRouter: recognize the SM3 digest
>     algorithm
>   SecurityPkg: set SM3 bit in TPM 2.0 hash mask by default
>   OvmfPkg: link SM3 support into Tcg2Pei and Tcg2Dxe

This posting is still not correct, process-wise.

Please refer to
<https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05>,
in particular

  git config sendemail.chainreplyto false
  git config sendemail.thread       true

Quoting git-send-email(1),

       --[no-]thread
           If this is set, the In-Reply-To and References headers will
           be added to each email sent. Whether each mail refers to
           the previous email (deep threading per git format-patch
           wording) or to the first email (shallow threading) is
           governed by "--[no-]chain-reply-to".

           [...]

       --[no-]chain-reply-to
           If this is set, each email will be sent as a reply to the
           previous email sent. If disabled with
           "--no-chain-reply-to", all emails after the first will be
           sent as replies to the first email sent. When using this,
           it is recommended that the first file given be an overview
           of the entire patch series. Disabled by default, but the
           sendemail.chainReplyTo configuration variable can be used
           to enable it.

If you don't set these knobs appropriately, the patches constituting the
series will fly apart on the list. The emails in the patch series should
form a shallow thread, where the cover letter is not sent in reply to
anything, and the actual patches are all sent in reply to the cover
letter directly. This way the cover letter will function as an anchor
point for the entire patch set and review discussion, without needlessly
nesting patch#(n+1) under patch#n.

But, again: please do not post a new version until the previous range of
patches:

     1  49c1e683c452 MdePkg/Protocol/Hash: introduce GUID for SM3
     2  06dd5863b66e SecurityPkg: introduce the SM3 digest algorithm
     3  542d04e2a4fe SecurityPkg/HashLibBaseCryptoRouter: recognize the SM3 digest algorithm
     4  d5af8fc5a975 SecurityPkg: set SM3 bit in TPM 2.0 hash mask by default
     5  a7c7d21ffa9a OvmfPkg: link SM3 support into Tcg2Pei and Tcg2Dxe

has been reverted (in reverse order of original commit order)

--*--

Let me point out some other process mistakes:

- TianoCore#1781 was not closed (and the commit range was not captured
  in a TianoCore#1781 bug comment) when the series was pushed. (In
  retrospect, that's actually helpful, because now I don't have to
  reopen that bug, for to the revert + repost.)

- Mailing list postings (various patch set versions) have not been
  referenced in TianoCore#1781 (with URLs into the list archive). I
  tried to show how to do that, for v1 at least, in
  <https://bugzilla.tianocore.org/show_bug.cgi?id=1781#c6>, but the
  example has not been followed, with further versions.

--*--

Now you could say that many of these measures are automated away in
development workflows that use the GitHub.com PR feature. That's
possible, yes; the mailing-list based approach is not *perfect*.
However, the problems that GitHub.com PRs have, are more serious:

  http://mid.mail-archive.com/793375cd-f55a-fa22-97c2-d6fd04da7d8b@linux.intel.com
  http://mid.mail-archive.com/0b2ce1b0-93ab-aef2-d192-23fd84024b70@redhat.com

(Alternative links:

  https://lists.01.org/pipermail/edk2-devel/2019-February/036428.html
  https://lists.01.org/pipermail/edk2-devel/2018-December/033509.html
)

Thanks
Laszlo