Skip to content

Feature/secure mode#271

Open
CyrilVanErsche wants to merge 2 commits intoDrive-Trust-Alliance:masterfrom
CyrilVanErsche:feature/SecureMode
Open

Feature/secure mode#271
CyrilVanErsche wants to merge 2 commits intoDrive-Trust-Alliance:masterfrom
CyrilVanErsche:feature/SecureMode

Conversation

@CyrilVanErsche
Copy link

Add the secure mode (with -s option) to interactively ask all passwords with a prompt. Implemented only for linux.

hMcLauchlan pushed a commit to hMcLauchlan/sedutil that referenced this pull request Aug 17, 2022
*BASICALLY CLEANED UP VERSION OF Drive-Trust-Alliance#271

This commit does what the linked PR says, and also fixes a few bugs in
that original PR. I'm not sure what the right way to give credit is and
it was very painful to resurrect CVE's original patches and roll my own
on top, so the disclaimer here is that it's like 95% his code :).

A few notable things:
* We don't need to modify the makefiles, since we split that out in the
  prior commit.
* We fixed his original makefile, which didn't quite work: that change
  is folded naturally into prior commit.
* The generated makefiles don't need to change, because since CVE's
  original patchset, GetPassPhrase.o was introduced organically to the
  codebase, and ergo the makefiles.

The most interesting thing here is we allow hashing to be forced off by
`-n` even during secure mode.

The key issue we ran into was that if a drive is originally set with no
hashing, then hash'd invocations in the future will fail(obviously). As
implemented, CVE's original patches will silently debug output, and then
turn on hashing without telling the user.

Not a domain expert in why hashing is necessary here, but in either
case, I think we should support the case where a password was originally
set without hashing, by allowing hashing to be turned off _if_ specified
explicitly.

We also do some sneaky business by ensuring -n is evaluated after -s, so
-n will always override -s, if provided.

Signed-off-by: Howard McLauchlan <hmclauchlan@fb.com>
kushal-kumaran added a commit to kushal-kumaran/sedutil that referenced this pull request Jul 10, 2024
*BASICALLY CLEANED UP VERSION OF Drive-Trust-Alliance#271

This commit does what the linked PR says, and also fixes a few bugs in
that original PR. I'm not sure what the right way to give credit is and
it was very painful to resurrect CVE's original patches and roll my own
on top, so the disclaimer here is that it's like 95% his code :).

A few notable things:
* We don't need to modify the makefiles, since we split that out in the
  prior commit.
* We fixed his original makefile, which didn't quite work: that change
  is folded naturally into prior commit.
* The generated makefiles don't need to change, because since CVE's
  original patchset, GetPassPhrase.o was introduced organically to the
  codebase, and ergo the makefiles.

The most interesting thing here is we allow hashing to be forced off by
`-n` even during secure mode.

The key issue we ran into was that if a drive is originally set with no
hashing, then hash'd invocations in the future will fail(obviously). As
implemented, CVE's original patches will silently debug output, and then
turn on hashing without telling the user.

Not a domain expert in why hashing is necessary here, but in either
case, I think we should support the case where a password was originally
set without hashing, by allowing hashing to be turned off _if_ specified
explicitly.

We also do some sneaky business by ensuring -n is evaluated after -s, so
-n will always override -s, if provided.

Signed-off-by: Howard McLauchlan <hmclauchlan@fb.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants