use real new volume handler during rescue

With the dummy we end up with a nil object instead of a tarinfo
at the end of the volume. Reinstating the actual handler is
harmless and produces a valid info object again.

prevent tarobject iteration in disaster mode

The tarfile iterator relies on the header data to determine the
next object offset which may be wrong for corrupt files. Instead,
skip that iteration step and completely rely on the object
offsets determined during index rebuild.

implement tolerant GNU tar header parser

When skimming a file for tar objects, only consider the GNU
header magic and whether the blocks are aligned.

add restore helper handling for reconstructed indices

add iterator mode for reconstructed index

unify construction of secret values

implement tolerant gz header parser

Since they assume a stream object, we cannot rely on the original
tarfile GZ handling. Add a “tolerant” one according to the format
spec that notices malformed or unexpected (in Deltatar context)
values, but glosses over them if they do not necessarily impact
the readability of the object.

Also use the new symbolic constants in the existing GZ reader
instead of magic numbers.

ignore GCM tag mismatch in scan mode

Header info is assumed unreliable during rescue so a tag mismatch
must not result in a bad object.

convert TarInfo to index format

read tar objects at predetermined offsets for rescue index

Leverage the tarobj to read the object headers at the determined
offsets. Currently only implemented for encrypted archives whose
offsets are located with *crypto.py*.

add test skeleton for corrupt index reconstruction

Starting with an intact backup set.

draft rescue mode through all layers

The strategy is for rescue mode to reconstruct the relevant [*]
information from the index by inspecting the passed tar object,
then continue from there. On the crypto side, this boils down to
a streamlined (and silent) version of the “scan” mode. The
tarfile side is still WIP.

[*] Omitting the useless parts like inode number.

derive test skeleton for disaster rescue mode

implement dump mode for tolerant decryption

Utilize the safe dirfd based implementation from split mode to
write extracted objects to a target directory.

extend tarfile API for rescue mode

implement decryption for tolerant mode

Not possible to reuse the existing CLI decryption since we’re
operating with fds in scan mode.

attempt to process candidate objects in scan mode

print list of header candidates

implement PDTCRYPT header scanning

First phase: collect all possible header start locations.

Adds a CLI subcommand “scan” to crypto.py for analyzing files.

test corruption by tearing a hole in a volume

add test corrupting an entire volume

Zero out the first volume: None of the content can be restored.
This includes the file extending from the first into the second
volume.

use symbolic constant for errno

clarify index read failure

Instead of erroring out with an exception, make --restore emit an
error message indicating that something is wrong with the index.

do not discard valid data in buffers when in tolerant mode

Both decryption and decompression will fail on the first error
and ignore any results of earlier passes. In normal operation,
the hard failures are desirable to indicate a bad backup set.

However, in tolerant / recovery mode the error handling is closer
to the opposite extreme: we want to retrieve every last byte that
made it through the various layers and only skip over the parts
that cannot be interpreted at all.

catch bad parameter version in header

reject bad index files with a meaningful error

add brief description of disaster recovery

fail with info message if recovery is asked with source path

allow for numbers of missing and failed files to differ in recovery test

adjust the expectations about checksum mismatches with non-authenticated recover modes

use index iterator to accomodate multivol extraction

For reasons unknown, the “tar path iterator” always terminates
after the last element of the first volume. In fact, it does so
even for multi volume archives if the last object in the first
volume extends into the second volume. In this case, the object
is completely extracted but extraction terminates.

use random data in multivol tests

Brute force incompressibility to preven gzip from invalidating
our multivolume tests.

give each recovery test a multivol companion

This derives single- and multivolume versions of the tests.
Multiple volumes are generated by stretching the input file count
and size.

work around false positives in deltatar fs checks during rpmbuild

These only happen when running in rpmbuild, otherwise the tests
are fine. Of course, on RHBT the choir resoundeth “thou shalt not
run thine rpm build as root” but that’s not really an option
here.

catch incomplete trailing header in tolerant recovery

This makes decryption in recovery mode resistant against
malformed trailing data which would otherwise error out for the
entire buffered chunk on account of a decryption failure.

test recovery behavior with traling data

track successful recover of corrupted payload in tests

Gzip does CRC32, GCM has a MAC, but ordinary Tar only checksums
the header part, not the content. Thus recovery of a damaged
object will appear to succeed provided the object header is
intact. In order to detect the corruption, an external integrity
check is necessary.

add recover tests for completely damaged headers

sync tarfile stream diligently when writing new objects

Turns out all the offsets written to the index when neither
encrypting nor compressing were, well, … off. In fact they would
only be updated at tar block boundaries due to buffering. Since
“last_block_offset” record keeping blatantly violates layering
boundaries, it would only work reliably with the concat
compression and encryption modes that do the same.

Sync when adding a new object so we get the accurate offset
value. Voilà, recovery now works with uncompressed and
unencrypted archives as well

add header corruption tests

We hit them where it hurts:

    * for compressed backups, flip a bit in the magic;
    * for encrypted backups, flip a bit in the tag.

In either case, normal restore must fail, and disaster recovery
will be incomplete.

add test for corruption of encrypted files

track irrecoverable files in test_recover

prefer index iterator for recovery

properly damage gzip files for recover test

Ensure we are flipping bits in the compressed payload, not in the
mostly useless header. Requires some extra parsing to determine
the header length.

add bit flip helper for recover tests

fix misleading docstrings for index file hook

lay out skeleton for disaster recovery tests

New series of tests for corrupting backup sets and restoring them
incompletely (“tolerant” or “disaster recovery” mode).

draft disaster recovery mode for deltatar

The first stage recovery assumes the index is intact and all
objects are at their expected position. In this scenario, an
attempt is made to extract each object, keeping track of those
that weren’t readable and why.

return valid decrypted data on decryption failure

force tarfile reopen after bad read in deltatar

Closing the tarfile after an unreadable object was encountered
causes the stream to be reopened for the next read. Otherwise,
the corrupt object is already buffered and tarfile would continue
to seek inside the bad data.

distinguish invalid files from parse errors in restore

Especially with index files, the parse error is misleading.
Indicate the prevalent cause of the problem, i. e. that the
file is compressed but compression was not requested during
restore.

update help usage strings wrt. crypto in backup.py

extend crypto.py exception descriptions

actually default to i2n mode with crypto.py scrypt

And adapt the relevant unit test to explicitly request the full
parameters output.

add crypto.py option to output cnf-compatible scrypt object

support PDT encrypted archives with rescue_tar.py

adapt file_crypt.py for revised crypto

kill off old crypto implementation

The old aescrypto.py was only kept for reference but since
downstream integration is more or less complete wrt. encryption
we don’t need it any longer.

Good riddance.

allow passing salt to crypto.py on the command line

Nifty shortcut for hashing without a corresponding pdtcrypt file.

properly align usage message of crypto.py

improve bad CLI argument handling of crypto.py

include header version info in scrypt handler

accept crypto format version in deltatar ctor

add unit test for CLI scrypt hashing

allow passing keys directly to CLI crypto.py

Keys may now be passed as command line argument or environment
variable.

The only valid format is 16 bytes in hexadecimal.

grab password from envp if not supplied on CLI

In order to avoid the password showing up in full in the process
table, pass it in the environment instead. Uses the environment
variable PDTCRYPT_PASSWORD with both crypto.py and backup.py.

default to index mode of deltatar object when choosing extension

For external use.

handle bad randomness during IV creation

Since IVs must be unique we rely on /dev/urandom to yield a
different sequence of bytes when requesting a new fixed part.
In the unlikely event that a new fixed part has already been
used earlier, repeat it for number of times.

Abort if no unique IV could be generated this way since it
most likely indicates a faulty RNG.

extend crypto.py documentation

distinguish auxiliary file errors

Auxiliary files that grow larger than the maximum defined
encrypted file size cause an irrecoverable error because their
fixed IV is being reused. Add a new exception to distinguish this
specific case. Encrypted auxiliary files thus never consist of
more than one object, no on-the-fly continuation is permitted
like with ordinary files.

adapt unit tests for crypto.py subcommands

export scrypt hashing functionality

add SCRYPT hashing mode to crypto.py

Add a subcommand “scrypt” to crypto.py in CLI mode. Example:

    $ python3 ./deltatar/crypto.py scrypt foo -i - -o pwd   \
        <backup_dir/bfull-2017-05-11-0919-001.tar.pdtcrypt
    {"scrypt_params": {"p": 1, "N": 65536, "dkLen": 16, "r": 8},
     "salt": "b'fbdbaa9890ae243eb16391199c9243f6'", "hash":
     "b'1e7d7a78b9300d461779e9c80e4a15ac'"}

The output “hash” is calculated from the salt in the first
header found in the given archive and the password specified.

graciously handle GCM data length limit

unit test crypto file counter wraparound

After the file counter reaches UINT_MAX, it wraps around and a
new fixed part must be created.

The file counter is 32 bit unsigned integer so it needs to be
lowered to make bounds testing feasible.

extend strict iv tracking to encryption

This is just an extra soundness check to prevent accidental reuse
if IVs when handled incorrectly (same initial counters passed
twice to the same context). In normal usage this case cannot
happen.

expand crypto api to accept precomputed key

reduce noise in test_multivol_compression_sizes.py

improve iv diagnostics when decrypting

test that seeking backwards is disallowed by _Stream

Re-extracting an already decrypted file will fail on account of
IV reuse. Currently, tarfile._Stream is not capable of performing
backward seeks, so we’re good. Should this limitation be removed
in a future version, this unit test will fail.

remove pytest dependency from test_crypto.py

add unit test for IV reuse

adapt crypto unit tests to run in main suite

remove IV validation step from RestoreHelper

Since the same decryption context is carried over between the Tar
volumes of one backup set, the built-in IV uniqueness checks
suffice. Between multiple backup sets, the salt and IV fixed
parts change, so there is no occasion for conflict. The IVs of
auxiliary files are unique anyways.

adjust acceptable size window for compressed unit test data

A low bound of 330 causes the test to fail with version 1.2.3 of
zlib.

Earlier this did not occur because in concat mode, tarfile would
always write an empty zlib compressed chunk right at the
beginning of the archive and then immediately create a new one as
soon as actual input arrived. For this reason, the resulting
archive size remained within the bounds chosen in
test_multivol.py. Due to the removal of the redundancy, this is
no longer the case. The problem is masked on newer versions of
zlib (tested: 1.2.8 of fc25) which create larger compressed files
in general for the same inputs.

For the “test_compress_single” unit test, the input consists of a
an archive 61440 bytes. Compress with level 9, window bits 31,
and a memlevel of 9, the output length is:

    version     size (B)
    1.2.3       308
    1.2.8       324

Add to that the file name in our custom header and the latter
passes 330 B whereas the former doesn’t.

A lower bound of 315 is justified.

reuse existing crypto context for subsequent volumes

validate exceptions being thrown from invalid tarfile.open() params

move final IV checks out of crypto context

Collect IVs while decrypting but postpone the final check for
duplicates. Reused IVs still trigger an exception during
decryption but since multiple different contexts may be active
(e. g. when handling a diff backup), the IVs they retrieved from
the headers must be compared afterwards. This test has its place
in a new function “validate” of the ``RestoreHelper`` and must be
called when decryption has been completed.

write auxiliary files whilst processing the backup

Introduce a fixed value for the index file counter to allow
encryption on the fly.

use independent decryption contexts for backup files

When restoring individual files from a diff backup, Deltatar will
traverse both tarballs simultaneously. This leads to access
patterns where reads are interleaved between the two sources,
possibly corrupting the decryption state. Thus when restoring
from multiple “index files” (in practice only two are relevant),
use a separate decryptor context for each of them.

clean up multi-index handling

WIP

properly handle encryption and compression of empty archives

The old implementation always initialized in the ctor regardless
of whether contents would be written to the archive. For empty
archives this now has to be done in ``.close()`` if no data has
been added yet.

adapt test_multivol_compression_sizes.py to revised crypto

remove redundant test

The first part of the condition always evaluates to True since
it’s the precondition to entering that branch.

encode operation modes

Introduce the “arcmode” to comprehensively switch modes to
supplant the pervasive ad-hoc string parsing and attribute
queries. Encodes the triple encryption, compression, concat.

cleanly perform block transition in non-concat mode

clarify exception-driven control flow

Distinguish the actual EOF when hit at the beginning from other
IO errors in _init_read_gz() and only catch this one where it’s
expected. Well formed archives do not end inside a header.

remove unused state variable

“internal_pos” which is only written to and never read was
introduced with this commit:

    commit 85737f48c38a432f2429e9e3e4b81fed164c4b9a
    Author: Eduardo Robles Elvira <edulix@wadobo.com>
    Date:   Fri Jul 5 11:50:43 2013 +0200

        extracting files in r#gz mode now works too, includes unit tests

and lacks a raison d’être ever since.

use append mode in symlink unit test

These tests currently fail despite using the original Gzipfile
compression path. The archives appear to overwrite instead the
passed archive instead of writing new objects.

fix multivol compression handling