* Re: [edk2-devel] [PATCH v5 0/5] Implement SM3 measured boot
2019-07-04 0:47 [PATCH v5 0/5] Implement SM3 measured boot Imran Desai
@ 2019-07-04 8:52 ` Laszlo Ersek
0 siblings, 0 replies; 2+ messages in thread
From: Laszlo Ersek @ 2019-07-04 8:52 UTC (permalink / raw)
To: devel, imran.desai
Cc: imranodesai, Michael D Kinney, Liming Gao, Chao Zhang, Jiewen Yao,
Jian Wang, Jordan Justen, Ard Biesheuvel, Marc-André Lureau,
Stefan Berger, Leif Lindholm
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
^ permalink raw reply [flat|nested] 2+ messages in thread