Hi Simon,
On 5/10/21 9:19 PM, Simon Glass wrote:
> On Mon, 10 May 2021 at 11:05, Steffen Jaeckel
> <jaeckel-fl...@eyet-services.de> wrote:
>> On 5/10/21 6:27 PM, Simon Glass wrote:
>>> On Mon, 10 May 2021 at 00:19, Steffen Jaeckel
>>> <jaeckel-fl...@eyet-services.de> wrote:
>>>>
>>>> Hook into the autoboot flow as an alternative to the existing
>>>> mechanisms.
>>>>
>>>> Signed-off-by: Steffen Jaeckel <jaeckel-fl...@eyet-services.de>
>>>> ---
>>>>
>>>> (no changes since v1)
>>>>
>>>> common/Kconfig.boot | 37 ++++++++++++++++++---
>>>> common/autoboot.c | 80 ++++++++++++++++++++++++++++++++++++++++-----
>>>> 2 files changed, 103 insertions(+), 14 deletions(-)
>>>
>>> Reviewed-by: Simon Glass <s...@chromium.org>
>>>
>>> But I think you'll need to allow both to be enabled.
>>
>> Sorry, but what exactly do you mean?
>
> I mean the ability to enable both crypt and the sha options rather
> than just one at a time.
You have a point there. Even though this approach should IMO become the
recommended way to store passwords, one could imagine that support for
both approaches in parallel could be needed, e.g. in a transition period.
The biggest problem I see is that the passwd_abort_{crypt,sha256}()
functions consume the serial input. I fear that an implementation that
supports both would need to have a painful amount of special case
handling in order to not break the expected behavior of the existing
sha256 implementation.
Supporting both in a backwards compatible way would make the
implementation a lot more complex and therefor I'd prefer to leave it as is.
Cheers
Steffen
