Function read_key_material 

pub fn read_key_material<R: BufRead, W: Write>(
    input: &mut R,
    output: &mut W,
    input_is_a_terminal: bool,
) -> Result<Zeroizing<String>>

Reads the text of a key file from input, prompting on output.

This is what unlock --key uses. It exists for the two shapes a path cannot serve: a key pasted by hand, and a key arriving over a pipe from whatever holds secrets — cat key | git-xcrypt unlock --key. The text goes through keyfile::decode_portable exactly like a file’s, so the header still verifies the material behind it.

Entry ends at a blank line, or at end of input. The blank line is what makes the interactive form usable: an export is two lines, and pressing Enter once more is easier to reach for than the end-of-file key, which is Ctrl+Z on Windows and Ctrl+D everywhere else. Leading blank lines are skipped rather than treated as the end, because a key travelling through a password manager or an email body picks them up — the same tolerance keyfile::significant_lines already grants a file. The recorded limit of that: a # comment counts as content here, so a comment followed by a blank line ends the entry before the key arrives. It fails closed — the parser says this is not a key file — and the one shape this command is pointed at, what export-key writes, has no comment in it.

The terminal answer is an argument, not a question asked here, for the reason export_key::to_writer splits the same way: a test cannot portably arrange a terminal, and both arms have to be reachable on all three platforms. It decides two things and neither is the parsing — whether to print a prompt at all, which would be noise in a CI log, and whether the key was echoed and is therefore sitting in the scrollback.

Errors

Error::Io when the prompt cannot be shown or the input cannot be read, including input that is not UTF-8 — a key file is text, and the file route refuses the same shape.