| Some questions about the spec: 1. How does age disambiguate between filenames and other key formats for the -r argument? (Those formats are also valid filenames) 2. Does the header use normal Base64 (i.e. +/) or url-safe Base64 (i.e. -_). The specification sounds like normal Base64, but some lines of the example contain -_ others contain +. 3. What characters are allowed in the header? ASCII only?
(the current key-formats are ASCII only, but an implementation is supposed to skip unknown formats) 4. Are any characters forbidden in recipient types, arguments and additional lines? 5. Which strings at the beginning of a header line have special meaning and thus are illegal for additional lines? Only `-> ` and `--- `? I assume the space is mandatory in those strings despite the spec not mentioning that for `->`? 6. CRLF normalization of the header is only mentioned in the section about ascii-armored files. I assume it also applies to non ASCII armored files? 7. Is keeping the public key secret to achieve symmetric authenticated encryption an officially supported/recommended use-case? (If the public key is public, the MACs block decryption oracles. However they don't provide any authentication, because the message isn't bound to any sender and thus an attacker can just encrypt their own message to your public key. If the receiver's public key is secret, this isn't possible and thus the current implementation provides symmetric sender authentication) 8. How does the command line tool signal failure/truncation/corruption? |
1. rage tests arguments for validity as filepaths, and uses the file preferentially over treating the argument itself as a recipient format.
2. The header uses normal Base64. This was changed recently, and the examples likely need updating.
3. rage currently rejects unknown formats; I haven't implemented this part of the spec yet.
4. Based on the current contents of the age specification, it looks like limiting to standard Base64 characters is consistent.
5. Additional lines all need to be standard Base64 characters (i.e. consistent with the format of current recipient lines) if implementations are going to be able to skip unknown formats.
(Recipient lines are currently under-specified in the spec. I opened https://github.com/FiloSottile/age/issues/9 a while back for addressing this.)
6. The normalization notes are an artifact of an earlier ASCII armoring format. Now that the armor is (a strict subset of) PEM, there is no need for CRLF normalization, as the age format solely uses LF, and PEM (which can tolerate either) is only a wrapper around the age format and thus does not affect the header.
8. rage signals this via an I/O error in the library that will bubble up through std::io::copy; this amounts to truncation on a chunk boundary and a non-zero exit value.