Thu, May 2
Could this be imported as is, and then when the hash modules are in and exported it could be switched over?
Thu, Apr 18
I've created a hash module that has some of the sha routines. I don't have big issues connecting those.
Updated with all PR comments, save 1.
Nov 21 2023
src/sys/contrib/dev/acpica/include/actypes.h:235:41: error: redefinition of typedef 'BOOLEAN' is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef unsigned char BOOLEAN;
^
/usr/src/stand/efi/include/efidef.h:33:25: note: previous definition is here
typedef UINT8 BOOLEAN;
This broke the armv7 build...
https://ci.freebsd.org/job/FreeBSD-main-armv7-build/19710/
Please fix ASAP.
Nov 20 2023
Nov 17 2023
I'm not seeing any remaining problems here, seems to LGTM.
Nov 6 2023
Just one minor nit
looks good now. Thanks for the split.
Stripped out lua diff to submit separately
I generally like this change, one or two quibbles to work out.
I'd also split the lua and other stuff into separate commits (the old lua code will work with the new loader.efi, which I like as well).
But I can do the splitting if that's a hassle. This is otherwise fairly clean so I wouldn't mind a small amount of extra work.
Nov 3 2023
Address Warner's comment regarding legacy hints and update the man page as suggested by Kyle
I'll take a look at the rest of this later...
Aug 26 2023
Nothing too concerning, mostly some style complaints but as a general rule I'd like to keep luacheck happy for the times it does actually identify legitimate issues.
- Updated documentation
- refactored tests to make them easier to add to.
Updated diff with all comments addressed, specifically:
- hashes.lua removed and moved into crypt.lua with no reexport
- tests refactored
- tests for NIST vectors for SHA256/512 added (and verified)
- added "crypt:" prefix on password
Aug 24 2023
Aug 23 2023
Thinking about this, I can make a couple of changes that could make this more palatable:
Aug 20 2023
(Thanks for the correction in the earlier comment)
These have existed for decades and pretty much every boot loader and every link in the booting process has optional passwords in place as a check against random people interfering with the boot process. BIOS has it, openboot has it, grub has it.
Why do we even have support of loader password other than unlocking the GELI provider in the first place? Or in other words, what was the threat model it's trying to protect the user from?
Uncomfortable how? This is a very straightforward implementation of SHA256/SHA512 modeled after existing LUA SHA2 libraries. I only reimplemented because:
- existing ones were based on lua <5.4 and relied on the bit32 library which is not in LUA54
- were vastly overcomplicated and not BSD licensed (ones that worked on every version of LUA and included multiple different sub-implementations optimized for a vast number of possible LUA configurations.)
- were incapable of being used in this context (they would return hex encoded values, where the crypt(3) algorithms require the raw binary to feed into subsequent stages
To be frank, stand/lua/hashses.lua makes me a bit uncomfortable... we have sha256/sha512 in libsa if GELI is enabled, I wonder how expensive it would be to re-scope those out to libsa out of the GELI option and break those out to Lua. Less worried about the latter part being too chunky than the former...