| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch has already been applied to 'lib/alg-sha256.c'
in commit bb1721800932268a537c804a4b7655af8c62d5e8.
|
|
|
|
All callers changed to either explicit_bzero, if an unremovable erase
is actually required in that context, or to ordinary memset, if not.
explicit_bzero is only required when the compiler could (in principle)
prove that no correct C program could depend on the erasure actually
happening. The two most common situations where this is the case are:
First, when the buffer being erased is a local variable that’s about
to go out of scope (here we’re worried about malicious code with the
ability to inspect raw memory near the stack pointer). Second, when
the buffer being erased is about to be used in an operation that
overwrites it _without_ reading it first (here we’re worried about the
operation either failing or not overwriting the _entire_ buffer).
explicit_bzero is _not_ required when the buffer being erased is about
to be passed to a function that _reads_ it. Use ordinary memset for that.
|
|
alg-yescrypt-sysendian.h provides the same set of functions that
byteorder.h does, just with different names. Have byteorder.h
provide both sets of names, and remove alg-yescrypt-sysendian.h.
Also, move the vectorized byte order conversion functions from
alg-sha{256,512}.c to byteorder.h, normalize their API, and generate
them from template macros so it’s easy to add more in the future if we
need them.
Push the warning suppression pragmas from alg-yescrypt-sysendian.h
down into the one .c file that actually needs them,
alg-yescrypt-opt.c. I am a little worried that these are papering
over actual latent bugs--we use the aggressive conversion warnings for
a reason--but that’s not today’s project.
|
|
There are enough files now that it’s getting confusing to have
everything at the top level. Create subdirectories ‘lib’, ‘doc’, and
‘test’. Move all of the code linked into libcrypt.a into ‘lib’. Move
all the manpages into ‘doc’. Move all of the test programs into ‘test’.
There is still only one Makefile at top level. Automake doesn’t make
nonrecursive makefiles as easy as it could, but everything that was
written in http://aegis.sourceforge.net/auug97.pdf back in 1997(!) is
still true.
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/03/hadrian.pdf
has an interesting counterpoint but I don’t think we’re anywhere near
the scale where those problems are relevant.
|
