HPACK(1)HPACK(1)NAMEhpack — Multi-System Archiver
SYNOPSIShpack command [-options] archive [file|@scriptfile]...
DESCRIPTION
The hpack Multi-System Archiver is an archiver that was written to
allow the transfer of archived data to different systems. In the past
archivers have traditionally been available for single systems only,
for example PKZIP™ and LHARC for the IBM PC, Larc for the Amiga,
StuffIt™ and Compactor for the Macintosh, and tar and compress for UNIX
systems (while these archivers are available on other systems, their
use is not widespread). It is intended to make hpack a more universal
archiver by offering versions for the following environments:
· Apple IIgs (planned)
· Archimedes
· Atari ST
· Commodore Amiga
· Microsoft Windows
· Macintosh
· MSDOS
· OS/2 (16 and 32-bit versions)
· OS/2 Presentation Manager (currently in development)
· Primos (planned)
· UNIX
· VMS (currently in development)
· Any other system which people offer to port it to
Currently Bavarian, Dutch, English, German, Italian, Polish, Spanish,
and Swiss German versions of hpack using the ASCII, IBM PC, IBM Code‐
page 850, IBM Codepage 869, ISO 8859-1 (Latin 1), ISO 8859-2 (Latin 2),
ISO 8859-3 (Latin 3), ISO 8859-4 (Latin 4), Macintosh, Mazovia, and
NeXTSTEP character sets exist. Anyone wishing to take advantage of
these features should read the section HPACK Internationalization
below.
Note: This documentation is intended mainly as an alternative to the
proper documentation which is in Postscript format. If possible the
proper documentation should be used.
INVOCATIONhpack is run with the following command:
hpack command [-options] archive [file|@scriptfile]...
The allowed values of command are:
a Add files to an archive.
x Extract files from an archive.
v Display a directory of files inside an archive.
p View files within an archive.
t Test the integrity of an archive.
d Delete files from an archive.
f Freshen files to an archive.
r Replace files in an archive.
u Update files to an archive.
The allowed options are:
-0 Store files without attempting any compression.
-a Store file attributes.
-b pathname
Specify a base pathname for all files.
-c options
Encryption options (conventional and public-key encryption).
-d options
Directory options (Mkdir, Rmdir, Mvdir, path options etc).
-e Add (or use) error recovery information.
-f Force file move into or out of an archive.
-i Interactive mode (prompt for all actions).
-k Overwrite existing archive.
-l Security options (data authentication)
-m Create a multipart archive.
-o options
Overwrite on extraction options (All, None, Prompt, Smart).
-r Recurse through subdirectories.
-s Run in stealth mode.
-t Touch files on extraction.
-u Unified compression mode.
-v options
View files options (Files, Directories, All).
-w Treat files as archive comments.
-x options
Text file translate options (see below).
+options
Extended options (usually system-specific, see below).
Commands, options, extended options, and archive and file names may be
given in upper or lower case (they are given in lowercase in the exam‐
ples which follow merely for consistency). Options may be lumped
together or may be given separately preceded by the ``-'' delimiter.
The option ``--'' may be used to indicate that no more options are
present on the command line, following the standard UNIX convention.
Extended options must be given separately followed by the ``+'' delim‐
iter.
The default archive extension is ``.hpk''. hpack will always add this
extension (provided the underlying filesystem supports it), changing
any other given extension if necessary. Note that some quantum physics
theories suggest that when the user is not directly observing the hpack
archive, it may cease to exist or will exist only in a vague and inde‐
terminate state; in this case the existence of the ``.hpk'' extension
cannot be guaranteed.
The filenames field may consist of zero or more filenames, defaulting
to all files if no filenames are given (in other words archive all
files in the current directory, or dearchive and view all files in the
archive). hpack uses UNIX-style wildcards (which are described in more
detail in the section HPACK Wildcards below), as well as UNIX-style
pathnames in place of the usual ones used by the systems' command
interpreter, so that for example the path:
/temp/work/files
is used instead of the MSDOS equivalent:
\TEMP\WORK\FILES
or the VMS equivalent:
[TEMP.WORK]FILES
or the Archimedes equivalent:
$.temp.work.files
If any additional components are needed, such as drives, network nodes,
or devices, these can be specified in the manner usual to the host com‐
mand interpreter. For example if the path in the above example were on
drive a: under MSDOS the pathname would be:
a:/temp/work/files
If the path in the above example were on the ``HOME'' node, on device
``DISK1'' under VMS, the pathname would be:
home::disk1:/temp/work/files
The scriptfiles are names of files preceded with an ``@'' character.
When hpack encounters one of these it will treat the filename as a file
containing a list of files to process. Script files and normal file‐
names may be freely mixed on the command line. See the section HPACK
Script Files below for more information.
HPACK Wildcards
When hpack scans any filename that has been given to it, it will check
for the presence in the filename of any of the special characters:
* ? [ ] \
If one of these is detected, then the string of characters making up
the filename will be treated as being a pattern for a filename, rather
than the name of a specific file. These special characters have the
following meanings when used in a filename string:
* Matches zero or more characters
? Matches any one character
[...] Matches any of the enclosed range of characters ``...'' in
turn. If two characters appearing in the pattern in alpha‐
betical order are separated by a dash ``-'', then any charac‐
ter in the alphabetic range between these two characters will
be matched. This is a more selective version of the ``?''
form.
[^...] As above, but this time matches anything not in the enclosed
range of characters ``...''.
\ Treat the next character as a normal character rather than
one of the special characters. This can be used to override
the usual meaning of the ``*'', ``?'', ``[]'', and ``\''
characters. Note that the Atari ST, MSDOS, and OS/2 versions
of hpack uses ``#'' instead of ``\'' since the command inter‐
preter uses ``\'' in its pathnames.
The case-sensitivity when handling filenames depends on the operating
system hpack is being run under. On the Atari ST and under MSDOS and
VMS, filenames are converted to uppercase, but are not case-sensitive;
on the Amiga, Archimedes, Macintosh and under OS/2, filenames are left
as is, but are also not case sensitive (so that ``FileName'' will match
``Filename'', ``FILENAME'', and ``filename''); and under UNIX, file‐
names are left as is, and are case sensitive, so that ``makefile'' and
``Makefile'' are treated as separate names.
These wildcards can be combined to create quite powerful expressions.
For example, to match any filename not beginning with an ``a'', ``b'',
``c'', or ``f'', and containing at least two characters, the required
expression would be:
[^a-cf]?*
where the ``[^a-cf]'' would match anything but ``a'', ``b'', ``c'', or
``f''; the ``?'' would match the second character required, and the
``*'' would match any remaining characters.
For example, if we have an archive whose contents are:
file1.txt file2.txt file3.txt file4.txt file5.txt file6.txt
file7.txt file8.txt file9.txt Index.txt
we could perform the following file matches on it:
Expression Matches files
-----------------------------------------------------------------------
* file1.txt file2.txt file3.txt file4.txt file5.txt
file6.txt file7.txt file8.txt file9.txt Index.txt
f* file1.txt file2.txt file3.txt file4.txt file5.txt
file6.txt file7.txt file8.txt file9.txt
*4* file4.txt
file?.txt file1.txt file2.txt file3.txt file4.txt file5.txt
file6.txt file7.txt file8.txt file9.txt
file[1-4].txt file1.txt file2.txt file3.txt file4.txt
file[^1-4].txt file5.txt file6.txt file7.txt file8.txt file9.txt
file[1-46].txt file1.txt file2.txt file3.txt file4.txt file6.txt
file[^13-5].txt file2.txt file6.txt file7.txt file8.txt file9.txt
-----------------------------------------------------------------------
Finally, note that these wildcards may not perform quite like the stan‐
dard wildcards used by the system's command interpreter. For example
under GemDOS, MSDOS, and OS/2, to specify all files in a directory or
archive, it is not necessary to use the usual sequence of ``*.*''.
Instead simply typing ``*'' will match all the files in the archive
(the DOS-like wildcards are in fact a bit of a hack — for example
``*abc.*'' will (incorrectly) match ``*.*''). The extended wildcards
act as true wildcards, so that ``FILE.*'' will not match ``FILE'' as
it would under DOS, since there is a spurious ``.'' in the DOS wild‐
card matching.
These extended wildcards can be useful when extracting files whose
names cannot normally be handled by the command interpreter. For exam‐
ple, to extract the file ``Filename with spaces in it'' from the ar‐
chive archive.hpk, you would type:
hpack x archive Filename?with?spaces?in?it
where the ``?'' wildcard will match the spaces. Alternatively you can
just type:
hpack x archive Filename*
which will usually do the same thing with a lot less typing involved.
Another point is that these wildcards cannot be used to represent full
regular expressions (the idea behind hpack was to create an archiver,
not a regular expression parser), so that, for example, ``*?'' will
not work as an expression, and that they can only be used inside path‐
names when the path is inside the archive (since the extended wildcards
are built on top of the usual operating system ones (if they exist) the
resulting system would run very slowly if they had to be simulated on
an external filesystem).
Using wildcards for pathnames inside archives is perfectly legal. When
matching wildcards to pathnames, hpack follows the standard convention
of matching the directory contents if the directory name is given, or
matching the directory itself when a wildcard matching it is given.
Consider an archive with a subdirectory dir, with both the archive root
directory and the subdirectory containing files. Then the following
wildcard matches could occur:
* Match all files and directories in the root directory
d?r Match the directory dir (and possibly other files) in the root
directory.
dir Match the contents of directory dir (equivalent to ``dir/*'')
*/* Match all files and directories (equivalent to using ``*'' with
the [-r]ecurse option).
Unlike most filesystems, hpack has no notion of a ``current directory''
within an archive, so all pathnames must be given relative to the ar‐
chive root directory.
Finally, UNIX users may have to either set the shell variable
``noglob'' (csh) or quote the wildcard characters used to prevent them
being expanded by the shell if it is required that hpack handle wild‐
card expansion. One case in which this is necessary is when recur‐
sively adding files in subdirectories which match a certain filespec to
an archive. The command
hpack a -r test *.h
exposes the ``*.h'' filespec to shell wildcard expansion. The shell
will try to match all the files in the current directory whose names
end in ``.h'', and it will not try to match any files in subdirecto‐
ries. In contrast:
hpack a -d test '*.h'
will cause hpack to perform the wildcard expansion, and will correctly
add files in subdirectories. Some shells provide other ways to turn
off their wildcard expansion. For instance, csh user can do the fol‐
lowing:
set noglob
hpack a -d test *.h
unset noglob
and ksh users can do the following:
set -o noglob
hpack a -d test *.h
set +o noglob
HPACK Commands
a Add files to an archive. The archive given in the command-line
is opened, or created if it doesn't already exist, and is given
the extension ``.hpk'' if this is not explicitly specified.
Then all files given in the list of filenames are added to to
it.
Example: To add all files in the current directory to the ar‐
chive archive.hpk in the current directory:
hpack a archive
x Extract files from an archive. All files are extracted from the
archive given in the command line to the current directory. If
the file already exists and no overwrite options are given
(these are explained in the section HPACK Options below), you
will be asked if you wish to overwrite it:
File already exists - overwrite [y/n/a]
The answer ``y'' will replace the file with the file from the
archive, ``n'' will skip the extraction of this file, and ``a''
will process all files from this point as if a ``y'' answer was
given for each file. In some cases the name of the file
extracted will need to be translated to allow for the naming
conventions of different operating systems. In these cases the
original name will be printed, followed by the name it will be
extracted under.
On Apple systems data is divided into two sections in a file, a
``data fork'' and a ``resource fork''. Under non-Apple operat‐
ing systems only the data fork will be extracted from an ar‐
chive: the resource fork (which only Apple systems can make any
use of) will be skipped.
Example: To extract all files in archive.hpk not beginning with
an ``a'' to the current directory:
hpack x archive [^a]*
v Display a directory of files inside an archive. If no view
options are given (these are explained in the section HPACK
Options below), a listing in the following format is produced:
HPACK - The multi-system archiver Version 0.79a0 (shareware version)
For Amiga, Archimedes, Atari ST, Macintosh, MSDOS, OS/2, and UNIX
Copyright (c) Peter Gutmann 1989 - 1993. Release date: 1 May 1993
Archive is 'ARCHIVE.HPK'System Length Size Ratio Date Time Name------ ------ ------ ----- -------- -------- -------------------------
MSDOS 18537 6217 66% 04/05/90 11:32:48 README.TXT
Atari 8301 3169 74% 27/12/90 21:02:39 LZSS.EXE
UNIX 30061 9127 70% 24/11/89 16:52:57 compr.method.txt
OS/2 8481 3282 61% 22/12/90 08:58:52 Comp.test
Mac 0 0 0% 01/07/91 18:20:20 Fast LZ Decoder using B..
------ ------ ------ ----- -------------------------
65380 21795 67% Total of 5 files
Done
The archive used is displayed, followed by a list of all the
files within the archive. The fields for each file inside the
archive are as follows:
System The system the file was archived under.
Length The length of the file when unarchived.
Size The size of the compressed file within the archive.
Ratio The ratio of the compressed file to the uncompressed
file.
Date The creation date of the file within the archive.
Time The creation time of the file within the archive.
Name The name of the file within the archive. If the name
is too long to fit on the screen then a ``..'' is
appended to indicate this. In addition files may have
a single character prepended to them: an asterisk
``*'' before the name indicates that this file has
been encrypted, a dash ``-'' indicates that it
includes authentication information, and a hash ``#''
indicates that it is both encrypted and includes
authentication information.
Note that the name within the archive may not be the
same as the name given to the unarchived file since
translation may be necessary to allow for the naming
conventions of different operating systems.
Note also that in the example above the file originat‐
ing on the Macintosh has a length of zero bytes. This
does not necessarily mean the total data size is zero
bytes, since files originating on Apple systems have a
second block of data called a resource fork which con‐
tains code and other program resources. These
resources are only useful on Apple systems and are not
shown as part of the total file size on other systems.
Finally the total length of all files within the archive, uncom‐
pressed and compressed, the overall compression ratio for the
archive, and the number of files within the archive, is given.
If any filespecs are given, only files which match those file‐
specs will be displayed. This is useful when you only want to
extract certain files and would like to see how much space they
will use.
If more than one archive is viewed, a grand total of the size
and number of files in all the archives viewed is printed. The
type of information printed may be controlled by using the view
options (which are explained in the section HPACK Options
below). The default is to print all files and directories in
the root directory of an archive. If the root directory con‐
tains no files or directories matching the given filenames
and/or wildcards, the error message ``No matching files in ar‐
chive'' will be printed. To recursively display the contents of
all subdirectories, either the [-r]ecurse subdirectories option
or the wildcard string ``*/*'' should be used.
Example: To view the contents of any archives in the current
directory
hpack v *
p View files within an archive. This option will output the con‐
tents of one or more files within an archive, with a prompt for
more between files. The output can be redirected in the stan‐
dard manner, for example:
hpack p data contents.doc | lpr
will send the file contents.doc from within the archive data.hpk
to the printer, and:
hpack p data description.doc | more
will display the file description.doc with page breaks on your
screen. Note that trying to display non-text files in this man‐
ner can be interesting, if not terribly productive.
Example: To display the file readme.txt from within the archive
archive.hpk:
hpack p archive readme.txt
t Test the integrity of an archive. hpack will display the usual
messages about extracting data as it unpacks and tests the data,
and if it thinks the data has been corrupted it will issue the
following warning message:
Warning: File may be corrupted
Otherwise hpack will display:
File tested OK
If, when all files have been tested, there were corrupted files,
hpack will print the total number of corrupted files:
Warning: n files were corrupt
where n is the number of corrupted files.
Note that this test is also performed automatically on extract‐
ing a file from an archive.
Example: To test the integrity of all MSDOS executable files in
the archive archive.hpk:
hpack t archive *.com *.exe
d Delete files from an archive. All files given in the command-
line are deleted from the given archive.
If all files are deleted from an archive (leaving an empty ar‐
chive), hpack will delete the archive as well.
Example: To delete all Pascal program files (a commendable move)
from the archive archive.hpk:
hpack d archive *pas
f Freshen files in an archive. The dates of all specified files
in the archive are compared with the dates of the same files on
disk. If the version on disk is more recent than the stored
version, the stored version is replaced by the version on disk.
If all files in the archive are uptodate, hpack will display the
message:
Archive is uptodate
and exit.
Example: To freshen all files in the archive archive.hpk:
hpack f archive.hpk
r Replace files in an archive. All given files in the archive are
replaced by their counterparts on disk.
Example: To replace all the files which begin with the letters
a-g in the archive archive.hpk with their couterparts on disk:
hpack r archive [a-g]*
u Update files to an archive. All specified files not already in
the archive are added to the archive, and all files already in
the archive are replaced if the version on disk is more recent
than the version already in the archive.
Example: To update the archive archive.hpk with all files from
the directory b:/data/junk:
hpack u archive b:/data/junk
Note that the last four options need to create temporary work
files on disk. Thus it is necessary to have at least twice as
much free disk space to work with as the total length of the ar‐
chive. All other options use only the archive file, so it is
possible to use them with minimal free disk space.
HPACK Options-0 Store files without attempting any compression. This option can
be used to quickly add incompressible files to an archive or
when breaking up a large file to move to another system via a
multidisk archive when space isn't at a premium.
-a Store file attributes. Many operating systems support two lev‐
els of files, those classed as ``normal'', and those classed as
``hidden'', ``invisible'', ``system files'', and so on (for
example the Macintosh, MSDOS, and the Atari ST all have these
file types). By default hpack will only add normal files to an
archive. However using the [-a]ttributes flag allows archiving
of files with special attributes as well as full restoration of
attributes when archives are extracted. The [-a]ttributes flag
is also necessary under some operating systems to store extra
information pertaining to a file, for example access control
information, file and directory type information, icons, and so
on.
hpack will attempt to translate the attributes of files from
different systems into equivalent file attributes for the local
system. This has varying degrees of effectiveness: Many of the
Apple IIgs, Atari ST, Macintosh, MSDOS, and OS/2 attributes are
equivalent so a direct translation is possible, and the Amiga,
the Apple IIgs, the Archimedes, UNIX, and VMS also have some of
the read/write attributes in common, and have a rough equivalent
of a read-only file attribute in these attributes.
If directories were stored within the archive, hpack will also
store directory attributes, and set the directory attributes to
the stored values when creating the directories on extraction.
Example: To extract all files in the root directory of the ar‐
chive archive.hpk, restoring all possible attribute information:
hpack x -a archive
-b Specify a base pathname for all files. This option is followed
by the pathname which hpack will use as a base path for all
files to be added to or extracted from an archive. This option
is very convenient when adding a number of files in the same
directory to an archive or when extracting an archive to a
directory which is not the same as the current directory. It is
also useful for handling archives which contain subdirectories.
To add files to a subdirectory within hpack, the base pathname
is used to specify the path to the subdirectory, with the actual
file pathname given being the path inside hpack in which the
file will be stored. In this case the argument given with the
[-b]ase path option is the part of the pathname outside the ar‐
chive, and the file pathname is the part of the pathname inside
the archive.
Example: To extract all files in the archive archive.hpk to the
directory d:/output/data:
hpack x -bd:/output/data archive
Example: To add the files file1, file2, text, and program.exe,
all in the directory d:/junk/data, to the archive archive.hpk:
hpack a -bd:/junk/data archive file[1-2] text program.exe
Example: To add the files in c:/junk/data/files to the archive
archive.hpk inside the archive directory data/files:
hpack a -bc:/junk archive data/files/*
-c Encryption options (conventional and public-key encryption).
Encrypt/decrypt archive data using a selection of public- and
conventional-key encryption algorithms. Using this option with
conventional-key encryption will prompt for a passphrase before
any files are added, followed by a request to retype the
passphrase for security if the data is being encrypted. This
passphrase, which is not echoed to the screen, should be a mini‐
mum of eight and a maximum of eighty characters long, and may
contain any combination of upper and lowercase letters, numbers,
spaces, punctuation symbols, and control characters. If public-
key encryption is used, the userID of the recipient of the data
is specified as part of the encryption command. Although hpack
itself will support non-ASCII text strings, the userIDs for pub‐
lic keys must be in ASCII format for compatibility with other
programs. Be warned that forgetting or losing a conventional or
public-key encryption key will present you with a fairly sub‐
stantial exercise in cryptography.
By default hpack will encrypt entire archives (rather than just
the files in them), meaning that not even the archive directory
can be read by someone who does not have the decryption pass‐
word.
The encryption options are divided into two classes, those
employing conventional-key encryption and those employing pub‐
lic-key encryption:
-c Use conventional-key encryption to encrypt the entire ar‐
chive, the same as [-c]rypt [a]ll.
-ci Encrypt individual files using conventional-key encryp‐
tion. The use of this option is not generally recom‐
mended as it is not quite as secure as the standard
[-c]rypt [a]ll option. It is however useful when only a
few files need to be encrypted, the rest being subject to
constant change which makes encrypting them impractical.
-ca Encrypt entire archive. This will encrypt not only the
files themselves but all additional data associated with
them (attributes, icons, and so on), as well as the ar‐
chive directory information. The only remaining accessi‐
ble data is a small amount of archive identification
information needed to allow hpack to process the archive.
-cs Prompt for second password to access archive data. This
allows the archive directory to be encrypted with one
password, and files to be encrypted with another pass‐
word. This option is useful if it is desirable to give a
group of users access to the archive directory but not to
the files themselves, since the contents of the archive
can be made available with the first password, but a sec‐
ond password is required to access the files themselves.
-cpi<userID>
Encrypt individual files using the public key which
matches the given userID. The public-key-encryption
equivalent of the [-c]rypt option. This option is not
recommended if more than a small number of files are
present in an archive due to the amount of time needed to
perform each public-key decryption calculation.
-cpa<userID>
Encrypt the entire archive using the public key which
matches the given userID. The public-key-encryption
equivalent of the [-c]rypt [a]ll option.
-cps<userID>
Encrypt the archive with a secondary public key which
matches the given userID. The public-key-encryption
equivalent of the [-c]rypt [s]econdary option.
When processing an encrypted archive, all that is necessary is
to tell hpack to handle encrypted data by specifying the
[-c]rypt option. hpack will determine the encryption type and
prompt for passwords as necessary as it processes the archive.
If the archive is public-key encrypted and the recipients secret
key is protected by encryption, hpack will prompt:
Please enter password for secret key (8..80 characters)
If an incorrect password is given, hpack will warn:
Password is incorrect.
and allow the password to be reentered. Up to three attempts at
the password are allowed before hpack gives up.
When searching for the key corresponding to a given userID,
hpack will perform a case-insensitive match of the given userID
against any part of the keys userID. This means that only a
partial userID need be given on the command line, and hpack will
use the first key for which the partial userID matches. This
makes specifying the userID easier since the entire userID need
not be given, but also means care should be taken if there are
several similar userIDs (all of which may match a certain userID
fragment) in a collection of keys. In all cases these userIDs
act exactly like they do in PGP.
If there is a chance that the userID is ambiguous, the key can
also be specified by its keyID using the standard C programming
language format for hexadecimal values, namely a prefix of
``0x'' and then the value itself. The keyID is the 6-digit
hexadecimal value displayed for the key. As with userIDs, hpack
will perform a case-insensitive match against any part of the
full keyID.
hpack will also allow the public-key encryption of data for mul‐
tiple recipients, meaning that a single encrypted archive can be
sent to an arbitrarily large number of recipients. This allows
archives to be distributed to working groups or via mailing
lists without necessitating a separate encrypted archive for
each recipient. Note that there is a slightly increased risk
involved in this process since the chain of intended recipients
is only as strong as its weakest link — only one of the private
keys needs to be compromised to render the encrypted data inse‐
cure.
The use of encryption for multiple recipients is specified by
enclosing a comma-seperated list of recipient userIDs or keyIDs
inside a key-or construct:
or(user1,user2,...userN)
On decryption, the data can be decrypted by user1 or user2 or
... userN. Future versions of HPACK will also allow key-and
(where all of a given list of keys must be used to decrypt data)
and key-quorum (where a certain proportion of a given number of
keys must be used to decrypt data).
In addition there are moves afoot to add a mailing-list capabil‐
ity to the public keyring format which will be fully supported
by hpack if it eventuates.
Example: To encrypt the entire archive archive.hpk, leaving only
a small amount of identification information readable:
hpack a -c archive
Example: To encrypt all files to be added to the archive ar‐
chive.hpk:
hpack a -ci archive
Example: To encrypt the entire archive archive.hpk with the ar‐
chive directory readable by ``TheMunsters'' but the archive data
itself only readable by ``UncleFester'':
hpack a -cpaTheMunsters -cpsUncleFester archive
Example: To encrypt the file baseball.bat in the archive ar‐
chive.hpk with the key corresponding to the hexadecimal keyID
A72F3B, taking advantage of the fact that hpack will match any
fragment of the keyID:
hpack a -cpi0x2f3 archive baseball.bat
Example: To encrypt the entire archive archive.hpk making it
readable by either ``Boris'', ``Igor'', or ``Ivan'':
hpack a -cpaor(Boris,Igor,Ivan) archive
Note that the public-key decryption process can take a long
time, especially when it must be performed multiple times (for
example when the [-c]rypt [p]ublic-key [i]ndividual files option
is used). hpack will display the message:
One moment...
whenever it performs the calculations involved in public-key
decryption. This process can often take significantly longer
than one moment — on slower machines hpack may appear to have
ground to a halt as it performs the public-key decryption opera‐
tion. Unless there is a special need for it, the use of conven‐
tional-key encryption is recommended.
One advantage of public-key encryption is that the key manage‐
ment is automatic — there is no need to enter passwords to per‐
form the encryption and decryption operations. When passwords
must be entered manually for conventional-key encryption, there
is a chance that an incorrect password will be entered by mis‐
take. If this happens for archive directories, hpack will warn:
Warning: Archive directory corrupted, probably due to
incorrect password. Continue (y/n)
Since the password was incorrect, the archive directory informa‐
tion has been decrypted incorrectly. The ``n'' option should be
selected and the password reentered.
If this happens for archived files, the files will not be
extracted properly:
Warning: File may be corrupted
Again, the password should be reentered when hpack is re-run.
-d Directory options. This hideously complicated command has a
large number of suboptions. Normally hpack will store any
directories it finds files in inside an archive, in effect
allowing you to archive entire directory trees. These directory
options allow more precise control over the storing of directo‐
ries inside the archive.
hpack will add directories traversed only if there are files
contained in them. To add all directories regardless of whether
they contain files or not, use the [-d]irectories [a]ll option
(see below).
The extended directory options are are as follows: (Note: Some
of these aren't implemented yet: Feedback on whether this way of
doing things is a good idea or not would be appreciated.)
-da Store or extract all directories scanned, even if they
contain no files. This option is useful for storing
entire filesystems inside archives and restoring entire
directory trees from archives.
-dc Create only immediate containing directory for a group of
files, not the entire directory path. This is mainly for
use by GUI versions of hpack to allow extraction of indi‐
vidual directories, folders, or drawers (depending on
what the host operating system calls them) of files.
-df Flatten directories. This option can be used to prevent
hpack from storing directories, so that all files added
or extracted are placed in the same directory, in effect
flattening the directory structure.
-dm Mkdir: Create the given directories. (Not yet imple‐
mented — if necessary this can be faked by using ``hpack
a -da<path> <non-matching filespec>'' where path is the
new directory to add and the non-matching filespec
ensures that only the new directory, but none of the
files in it, are added.)
-dn Do not create the directory inside the archive if it
doesn't already exist. If an attempt is made to add a
file to a nonexistent directory, hpack will exit with the
error message:
Path not found
-dr Rmdir: Delete the given directories. (Not yet imple‐
mented)
-dv Mvdir: Move the given directory into the second given
directory.
Warning: Through injudicious use of this command it is
possible to create circular directory references, or to
cut off entire directory trees. Do not try to move
directories into subdirectories of themselves! (Or
should hpack check for this?) (Not yet implemented)
Example: To delete the directory data/junk inside the archive
archive.hpk:
hpack a -dr archive data/junk
Note the use of the [a]dd command as a dummy command: In this
case the main command is ignored and only the directory option
is used (ICK!).
Example: To move all files and directories in and below
data/junk in the archive archive.hpk into the directory stuff:
hpack a -dv archive data/junk stuff
Example: To add all files and directories (even empty ones) in
and below the current directory to the archive archive.hpk:
hpack a -rda archive
-e Add (or use) error recovery information. This option allows the
adding of error recovery information to the archive when adding
files, or makes use of error recovery information present in an
archive. hpack will write extra information with the file data
which may be used to recover the data if the main archive direc‐
tory is seriously damaged. This recovery information will
increase the amount of data stored for each file by about 20-25
bytes. Note that although hpack will add this extra informa‐
tion, the current version will not make use of it.
Example: To add all text files in the directory a:/data to ar‐
chive archive.hpk, adding error recovery information for each
file:
hpack-e archive a:/data/*.txt
Example: To extract the same files from the archive, making use
of the error recovery information:
hpack x -e archive *.txt
-i Interactive mode — prompt for all actions. This option works
for all commands except [v]iew files (for which it would be
pointless). Before the file is processed, hpack will ask
whether you wish to process this file; answering ``y'' will han‐
dle the file, ``n'' will skip the file, and ``a'' will process
all files from this point (in other words it will assume a ``y''
answer for each file from this point).
Example: To add all files in the current directory to the ar‐
chive archive.hpk, prompting for each file before adding it:
hpack a -i archive *
-f Force file move into or out of an archive. This option can be
used with the [a]dd, [f]reshen, [r]eplace, [u]pdate, and
[x]tract commands to move the files instead of merely copying
the data into or out of an archive. Note that when the move
option is used in conjunction with encryption, hpack will go to
extreme lengths to destroy any traces of the file which is being
moved. Caution is recommended when using move with encryption
as forgetting the password or using the wrong public key will
lead to the permanent loss of the encrypted data.
If all files are moved out of an archive (leaving an empty ar‐
chive), hpack will delete the archive as well.
Example: To move all text files from the archive archive.hpk
into the current directory:
hpack x -f archive *.txt
-k Overwrite existing archive. This only works with the [a]dd com‐
mand. Normally, using the [a]dd command will add any new files
to the end of an existing archive. Using the [-k]ill switch
will erase the old archive and create a new one.
Example: To create the archive archive.hpk on drive a:, over‐
writing it if it already exists, and add all files in the cur‐
rent directory to it:
hpack a -k a:archive
-l Security options (data authentication). This option allows the
encapsulation of either entire archives or individual files
inside a secure envelope which it is computationally infeasible
to break. This option allows anyone to later determine that the
data has been both untampered with, and genuinely came from the
source (corresponding to the userID) from which it claims to
have originated.
When searching for the key corresponding to a given userID,
hpack will perform a case-insensitive match of the given userID
against any part of the keys userID. This means that only a
partial userID need be given on the command line, and hpack will
use the first key for which the partial userID matches. This
makes specifying the userID easier since the entire userID need
not be given, but also means care should be taken if there are
several similar userIDs (all of which may match a certain userID
fragment) in a collection of keys. In all cases these userIDs
act exactly like they do in PGP.
If there is a chance that the userID is ambiguous, the key can
also be specified by its keyID using the standard C programming
language format for hexadecimal values namely a prefix of ``0x''
and then the value itself. The keyID is the 6-digit hexadecimal
value displayed for the key. As with userIDs, hpack will per‐
form a case-insensitive match against any part of the full
keyID.
If the secret key is protected by encryption, hpack will prompt:
Please enter password for secret key (8..80 characters)
If an incorrect password is given, hpack will warn:
Password is incorrect.
and allow the password to be reentered. Up to three attempts at
the password are allowed before hpack gives up.
The security options are as follows:
-l<userID>
Secure the entire archive with security information from
a given userID.
-li<userID>
Secure individual files rather than the archive as a
whole, with security information for a given userID. The
use of this option is not generally recommended since the
generation of the security information for each file can
consume a considerable amount of time, and since only the
files themselves are secured it leaves the file
attributes and directory information open to modifica‐
tion. It is however useful when only a few files need to
be secured, the rest being subject to constant change
which makes securing them impractical.
Example: To create the archive archive.hpk, add all files in the
current directory to it, and secure it on behalf of your cat:
hpack a -lthecat archive
-m Create a multipart archive. Normally when hpack runs out of
disk space it will exit with an error message. When this option
is used hpack will instead prompt for another disk and continue
the archive on the new disk. In this manner it is possible to
spread an archive which would be too large for a single disk
over several disks. Due to their rather special nature, multi‐
part archives do not support the [d]elete, [f]reshen, [r]eplace,
or [u]pdate commands (since, for example, deleting a file from
the middle of an archive which stretches over 15 disks would be
quite time-consuming). All other operations are supported how‐
ever.
Example: To fully back up hard drive c: onto drive a:
hpack a -kmarda a:archive c:/*
This will create the archive archive.hpk on one or more disks in
drive a: containing the complete contents of the drive c: (the
options used are [-k]ill existing archive, [-m]ultipart archive,
store file and directory [-a]ttributes, [-r]ecurse through all
subdirectories, for [-d]irectories store [a]ll of them, even
empty ones). Once each disk has been completely filled, hpack
will prompt:
Please insert the next disk and press a key
followed by the message:
Continuing...
as it continues the archive on the next disk inserted. Note the
use of the [-k]ill existing archive option to overwrite any
existing archive of the same name which may already exist on the
disk — if hpack finds an archive of the given name already on
the disk and the [-k]ill option is not specified, it will not,
by default, overwrite it but will exit with an error message.
Multipart archives have a minimum size of around 500 bytes
(roughly the size of a disk sector for many disk formats — stor‐
ing archive parts of less than 500-odd bytes would be point‐
less). If a section of a multi-part archive is less than
approximately 500 bytes hpack will skip it and move it to the
next (hopefully less full) disk after printing the following
warning:
Warning: Archive section too short, skipping...
If a multipart archive is small enough to fit onto a single
disk, hpack will store the archive as a standard archive instead
of a multipart one.
Example: To view the files in the previously created multipart
archive:
hpack v a:archive
hpack will automatically determine whether the archive is a mul‐
tipart archive or not so the [-m]ultipart command is only neces‐
sary when creating the archive. Since hpack stores its direc‐
tory information at the end of the archive, only the last disk
or disks of the archive must be read to obtain the archive
directory. Initially hpack will prompt:
Please insert the disk containing the last part of this archive
and press a key.
If the wrong disk is inserted, hpack will prompt:
This is part n of a multipart archive.
Please insert the disk containing the last part of this archive
and press a key.
where n is the part number of this section of the archive.
Example: To extract the single file letter.txt from the previ‐
ously created archive:
hpack x a:archive letter.txt
hpack will then prompt for the disk which contains the file let‐
ter.txt:
Please insert the disk containing part n of this archive
and press a key.
where n is the part number of the archive section which contains
letter.txt.
Example: To fully restore the contents of a hard drive from the
previously created archive:
hpack x -arda a:archive
hpack will prompt for the last part of the archive as usual and
then for each disk in turn as it extracts the files from the ar‐
chive.
-o Overwrite on extraction options. Normally when hpack tries to
extract a file which already exists, it will prompt for whether
the existing file should be overwritten or not. With this
switch it is possible to specify a default action to be taken.
There are four possibilities:
-oa Automatically overwrite [a]ll existing files on extrac‐
tion.
-on Automatically overwrite [n]one of the existing files on
extraction.
-os [s]mart overwrite. hpack will change the extension of
the file to be extracted to ``000'', and try to extract
this file. If a file of this name already exists, the
extension will be changed to ``001'' and so on until it
is possible to extract the file. This option is very
useful for files that have been archived on a system
which allows filenames which are longer or more complex
than those allowed by the local system and which due to
the filename being truncated or translated end up with
identical names. Note that the term ``extension'' can
mean different things to different operating systems —
hpack will do its best to use the local equivalent.
-op [p]rompt for new filename. hpack will ask for a new
filename and try to use that name, repeating until a non-
conflicting filename is given.
Example: To extract all files from the archive archive.hpk to
the current directory, skipping any files that already exist:
hpack x -on archive
-r Recurse through subdirectories. hpack will step through all
sub-directories of the current directory, and add all files with
names matching those given on the command line.
Example: To add all files in all directories in and below the
current directory to the archive archive.hpk:
hpack a -r archive *
-s Run in stealth mode. All messages except warnings and error
messages are suppressed. hpack will automatically turn on
stealth mode if it detects it is running in the background on
operating systems which support background operation.
Example: To add all files in the current directory to all ar‐
chives in the current directory, without printing the usual
progress reports to the screen:
hpack a -s *
-t Touch files on extraction. Normally hpack will give all files
and directories extracted the original date they had when they
were archived. Using the [-t]ouch option will give files and
directories the current date.
Example: To extract all files from the archive archive.hpk, giv‐
ing them todays datestamp:
hpack x -t archive
-u Unified compression mode. In this mode hpack will attempt to
achieve increased compression by using unified compression
across all files to be added. This is especially effective when
many generally similar files or many small files are being added
to an archive. The disadvantage of unified compression is that
the archive cannot be updated or changed later, and that when
extracting individual files there is a slight speed penalty as
intervening files are skipped. Unified compression is ideal for
storing data like Usenet news articles, collections of icons,
and program source code, in which cases significant compression
gains are usually seen.
Example: To all all files in /usr/spool/news/comp/compression to
the archive compress.hpk using the unified compression mode:
hpack a -u compress /usr/spool/news/comp/compression/*
-v View options. Normally when the [v]iew command is used, hpack
will print information on all the directories and files in an
archive. With these options it is possible to specify which
parts of the archive directory are to be viewed. There are
three possible options:
-vf Display information only on matching files.
-vd Display information only on matching directories. This
option is sexually transmitted.
Example: To print all the files, but not any directories or sub‐
directories, in the archive archive.hpk:
hpack v -vf archive.hpk
-w Treat files as archive comments. This makes the [a]dd,
[d]elete, [f]reshen, [r]eplace, and [u]pdate commands work for
archive comments instead of normal files. Archive comments are
files which are displayed when the [v]iew archive command is
used, and may contain text describing the contents of the ar‐
chive, ANSI extended characters, graphics, digitised sound, even
full motion video with 16-bit stereo sound if desired. Most CLI
versions of hpack will currently only handle the displaying of
plain text, although some will handle ANSI-text type archive
comments as well. Comments can be added, deleted, replaced, and
so on just like normal files. Subdirectories can contain their
own comments, and each directory can contain multiple comment
files. In addition comment filenames are not treated as normal
archive filenames, so a directory can contain a comment file and
a normal archived file of the same name. Possible archive com‐
ment types are:
-w Plain text comment. This can be entered in free-form
since hpack will automatically word wrap the text to fit
the screen size. Plain text comments may also contain
formatting commands which control the way the text is
displayed. For more information on formatting the text
comments, see the extended documentation file hpack‐
ext.doc.
-wa ANSI text comment. This type of comment can contain the
extended 8-bit character set used by IBM PC's, as well as
ANSI escape codes. No reformatting of any type is done
on ANSI comments. Note that the plain text comment type
is preferred, since many systems cannot display the
extended ANSI character set or interpret ANSI escape
codes. Also note that if an ANSI comment is stored as
plain text hpack will quietly delete all extended charac‐
ters and ANSI escape codes when it displays the comment,
to make it conform to the 7-bit ASCII character set.
-wg GIF format graphics comment. Display of this comment
format is generally only suported on systems running
graphics-based user interfaces.
Example: To view all comment-type files in the archive ar‐
chive.hpk as files instead of displaying them as comments:
hpack v -w archive.hpk
-x Text file translate options. Different systems store text files
in different formats, for example on the Amiga, the Archimedes,
and under UNIX, these are stored in ASCII format with a linefeed
at the end of each line; on the Atari ST and under MSDOS and
OS/2, there are carriage return/linefeed pairs at the end of
each line; and on the Macintosh, there are carriage returns at
the end of each line. Some systems store text in a non-ASCII
format altogether, for example IBM systems which use the EBCDIC
character set, and Prime systems which use their own bizarre
text encoding technique. Using this option it is possible to
specify translation of different character systems and end-of-
line markers to the one used by the local system. In most cases
the [-x]late option will suffice, however it is possible to
override the translation using the following options:
-x Smart translate. hpack will attempt to translate all
files it recognises as text files from the textfile for‐
mat used on the system the file was archived on to the
textfile format used on the system the file is being
extracted on. In most cases this option will be the only
one necessary.
-xr Treat carriage return (ASCII 13) as end-of-line marker.
The Macintosh stores text this way.
-xl Treat linefeed (ASCII 10) as end-of-line marker. Text on
the Amiga, the Archimedes, and UNIX systems is stored in
this manner.
-xc Treat carriage return/linefeed pairs as end-of-line
marker. The Atari ST, MSDOS and OS/2 store text files
like this.
-xxnn Treat the one- or two-character hexadecimal value n or nn
as the character to use as the end-of-line delimiter.
For example when moving textfiles from a QNX 2.x/3.x sys‐
tem (which uses the RS character, ASCII 30 or 1E hexadec‐
imal), the option would be -xx1e.
-xe Translate the character set from EBCDIC to ASCII. Text
on IBM systems is stored this way.
-xp Translate the character encoding from that used on Prime
systems to ASCII.
-xa Translate from ASCII to ASCII.
The textfile translation works by first translating entire char‐
acter sets (either ASCII, Prime ASCII or EBCDIC) if necessary,
and then translating the end-of-line characters, depending on
the options specified.
The end-of-line translation options are only available where
they would make sense (for example the ability to translate
linefeed to linefeed isn't particularly useful). The possible
translation options are shown below, with LF being the linefeed
character, CR being carriage return, and CRLF being carriage
return/linefeed pairs:
To → | Atari ST Amiga Macintosh
| MSDOS Archimedes
From | OS/2 UNIX
------------------------------------------------
Atari ST | -xc-xc
MSDOS | --- CRLF→LF CRLF→CR
OS/2 |
|
Amiga | -xl-xl
Archimedes | LF→CRLF --- LF→CR
UNIX |
|
Macintosh | -xr-xr
| CR→CRLF CR→LF ---
Example: To extract all files with the extension .txt from the
archive archive.hpk, translating linefeed characters into what‐
ever end-of-line character the local system uses:
hpack x -xl archive *.txt
Example: To extract all files with the extension .txt from the
archive archive.hpk, translating the files from EBCDIC to ASCII,
and translating all carriage return characters to the end-of-
line character used by the local system:
hpack x -xexr archive *.txt
HPACK Extended Options
The extended options supported by hpack are usually somewhat system-
specific and in general will only be present on one particular version
of hpack. They either support the storing or extraction of system-spe‐
cific information in archives, or the special handling of data which
has been archived on another system. The recognised options are:
+devcheck
MSDOS version only. Check all files for [s]afe extrac‐
tion. MSDOS has a serious problem in that when a file
with the same name as a device driver is extracted (for
example ``CON'', ``COM1'', or ``LPT1'') it will force the
contents of that file into the device driver. The damage
can be minor for devices like ``CLOCK$'' (it will at a
minimum mangle the system date and time, perhaps scramble
the CMOS ram, or cause the system to hang — even the
changing of system dates can cause problems on a system
running a computer bulletin board which relies on correct
timestamps), all the way through to very serious for
devices like ``SMARTAAR'' (it will corrupt the disk cache
and therefore corrupt the drives being cached).
The +devcheck option will check each file before extract‐
ing it, and if it corresponds to a device driver will
print the warning:
File corresponds to device driver - skipping
and move on to the next file. The only way in which
hpack will allow a file of this type to be extracted is
by using the [-o]verwrite [p]rompt option, in which you
will be prompted for a new filename to extract under.
Even [-o]verwrite [s]mart is unsafe since the peculiar
handling of device drivers by DOS makes the automatic
substitution of a new filename very difficult.
Filenames which can cause these problems are virtually
unheard-of — they would have to be created deliberately
by a malicious user, in which case there are few limits
on the potential damage they can cause.
+invert
Archimedes version only. ADFS doesn't support extensions
to filenames since dots are used as directory delimiters,
which can lead to problems when moving, for example,
source code files ending with the traditional ``.c'' and
``.h'' to the Archimedes. Many programs allow a work‐
around where the file ``foo.c'' is accessed as ``c.foo''.
This option allows this form of inversion of the filename
and directory structure so that ``*.c'' and ``*.h'' would
be extracted as ``c.*'' and ``h.*''. This command usu‐
ally invokes an intense sense of disbelief in non-
Archimedes owners.
Incidentally, non-Archimedes owners may wonder what the
Archimedes uses in place of a ``.'' in filenames. It
uses a ``/'', of course.
+lower Amiga, Archimedes, OS/2, Macintosh, and UNIX versions
only. Force all file and directory names to lowercase.
Some systems store file and directory names in uppercase
only. Using this option all names will be converted to
lowercase before any operations (such as [v]iew archive,
[x]tract from archive, and so on), are performed on them.
When processing Atari ST, MSDOS, and some OS/2 archives,
the use of the +lower option is recommended.
+noext By default HPACK will force an extension of ``.hpk''
(where the operating system allows it) to be added to the
archive name, with any existing extension being replaced
by ``.hpk''. This option allows the default behaviour to
be overridden so that no extension is added or changed.
However this lack of an extension will force hpack to
work much harder in deciding what is and isn't an hpack
archive, and will disable certain features such as its
ability to automatically pick out hpack archives when
simply told to process all files in a directory. This
option is mainly for use with automated mail-processing
software such as Fidonet mail unpackers which depend on
the extension for information on the packet contents.
+noumask
UNIX version only. Normally the setting of the umask
environment variable affects the attribute bits of any
files and directories hpack creates. This option over‐
rides the umask setting and uses the attributes stored
within the archive. Since these attributes can be set to
allow outsiders read/write access to files and directo‐
ries which would normally be off-limits to them, this
option should be used with care.
+rsx VMS version only. Normally VMS files can have 39 charac‐
ters of filename and 39 characters of extension, or type.
This can lead to strange-looking filenames when they are
truncated from operating systems which allow longer or
more flexible names. Using this option truncates file‐
names to an RSX-11 compatible format, which results in
more traditional-looking names with 9 characters of file‐
name and three characters of file type, and directory
names with 9 characters of filename.
+select <select-statement>
Apply an SQL select command. This option is explained in
more detail in the section HPACK SQL Commands in the
extended documentation.
+type<type-association>
Archimedes, Apple IIgs, and Macintosh versions only.
Some operating systems store file type information for
each file. hpack will, when extracting files, try to
determine the type information for each file and set it
correctly. However in some cases no type information can
be determined, or the determined information may be
incorrect. This option can be used to set type informa‐
tion for a file, or to override hpack's internal type-
determining rules.
Type information is given as a type-association, associ‐
ating a file extension with whatever type information the
OS requires, and is given in the form:
.<extension>=<type info>{,<type info>}
For example to associate the Macintosh ThinkC source file
type with the extension ``.c'', the type argument would
be ``TEXT,KAHL'', corresponding to the ThinkC file type
and creator type.
Example: To associate the ``.c'' extension on the Macin‐
tosh with the ThinkC source file type:
+type.c=TEXT,KAHL
Example: To associate the ``.gif'' extension on the
Archimedes with the GIF file type:
+type.gif=693
The types given above are actually already part of
hpack's default rule set for type associations, but can
be overridden with the use of the +type option if
desired.
HPACK Archive Integrityhpack checks the integrity of files stored within an archive by encod‐
ing a continuous checksum as part of each file when it is archived, and
decoding it as the file is extracted. As soon as an error is encoun‐
tered, hpack will skip over the rest of the file and move on to the
next one. If the file checksums differ then it may be reasonably
assumed that there is an error in the extracted data. This is impor‐
tant: The entire physical universe, including hpack itself, may one day
collapse back into an infinitely small space. Should another universe
subsequently re-emerge, the integrity of hpack archives in that uni‐
verse cannot be guaranteed.
hpack also checksums the archive directory. If an error is found in
the directory information, the message:
Warning: Archive directory corrupted. Continue (y/n)
will be displayed. Hitting ``n'' at this point will abort any attempts
to process the archive, hitting ``y'' will process the (damaged) ar‐
chive. hpack will attempt some error recovery in this case (for exam‐
ple files and directories which seem to be in impossible directories
will be moved into the root directory), and some files may be able to
be recovered. If error recovery information (specified with the
[-e]rror recovery option (see the section HPACK Options above)) is
present, chances of recovering data from an archive with a corrupted
directory are greatly enhanced.
HPACK Archive/Data Authentication
Data authentication facilities in an archiver should provide the fol‐
lowing features:
1. Sender authenticity. The data could only have come from the
source which it is supposed to have come from.
2. Data integrity measures. Any attempt to tamper with the data
should be recognised and reported by the authentication system.
3. Non-repudiation of origin. The originator of the data cannot
later disclaim responsibility for it.
hpack includes provisions for authenticating archived data by adding a
unique digital signature to either entire archives or individual files
within an archive. This works exactly like a normal signature on a
piece of paper, proving that the sender was the true originator of the
file or archive. Forgery of a digital signature of this sort is compu‐
tationally infeasible, and once the data has been signed the sender
cannot later disavow his or her signature. In addition a cryptographic
checksum of the data or archive is made and included as part of the
signature to allow detection of any attempts to tamper with the data.
Like forging a signature, defeating the checksum is computationally
infeasible.
When the data in an archive with authentication information present is
extracted or tested, an authentication check is performed for the
entire archive before it is processed. Similarly, an authentication
check is performed on files before they are extracted if there is
authentication information present.
In order for the authenticity information generation and checking to be
possible, two key files are required. To secure archives, the files
secring.pgp or ripemprv, which contain the secret key of the person
securing the archive, are required. To check secured archives, the
files pubring.pgp or rpubkeys, which contain the public key of the per‐
son or organization who signed the file or archive are needed. These
key files are generated and managed by either version 2.0 or higher of
Philip Zimmermanns excellent pgp encryption package (for the PGP keys),
or various implementations of pem, among them Mark Riordan's equally
good ripem encryption package. If you don't have a copy of pgp or
ripem, it is recommended you obtain one. pgp is freely available on
many archive sites, computer bulletin boards and other systems. ripem
may only be available within the United States. pgp is also required
to handle any key management, and for authentication of the keys them‐
selves. ripem currently doesn't support much key management or key
authentication. The pgp documentation and portions of the extended
hpack documentation hpackext.doc are recommended reading for those
wanting more information on the background of pgp and the security
techniques used by pgp and hpack.
If PEM (Privacy-Enhanced Mail) ever becomes a reality, hpack will sup‐
port PEM/PKCS format keys as well as pgp ones. This will allow data to
be encrypted and decrypted inside the US with PEM keys and outside the
US with pgp keys, allowing, for the first time, the easy transfer of
public-key encrypted data to and from the US.
Before hpack can use it, the secret keyring secring.pgp must have a
small amount of extta information added to it. Details on this are
given in the section Using PGP Secret Keyrings below.
hpack will search for the key files in the directories given in the
environment variables PGPPATH and PEMPATH. These variables should con‐
tain the paths to any pubring.pgp, secring.pgp, ripemprv, and rpubkeys
files which are needed, with more than one path being possible. In
order to eliminate the possibility of spoofing via a bogus keyring
placed in the current directory, hpack will, like all well-designed OS
shells, not search the current directory unless this is explicitly
specified in the PGPPATH or PEMPATH variables with the use of the ``.''
option indicating the path to the current directory.
For example if the search path for pgp keyrings included the directo‐
ries $HOME/bin/pgp, /usr/bin/pgp, and /usr/local/pgp then PGPPATH
should be set with:
set PGPPATH=/bin/pgp (Atari ST, MSDOS, OS/2)
set PGPPATH filesys::drive.$.bin.pgp
set PGPPATH <PGPPATH>,filesys::drive.$.usr.bin.pgp
set PGPPATH <PGPPATH>,filesys::drive.$.usr.local.pgp
(Archimedes)
setenv PGPPATH $HOME/bin/pgp:/usr/bin/pgp:/usr/local/pgp
(UNIX csh)
export PGPPATH # export before set is OK
PGPPATH=$HOME/bin/pgp:/usr/bin/pgp:/usr/local/pgp
(UNIX sh)
The directories for pgp and pem keyrings are always searched in the
order given in the PGPPATH and PEMPATH variables. Note that in the
above example the single-user Amiga, Atari ST, MSDOS and OS/2 systems
only have a single path for keyrings, whereas the multiuser UNIX envi‐
ronments have multiple search paths corresponding to custom user
keyrings followed by system-wide master keyrings.
If the data in the archive, or the archive itself, is to be checked,
the authentication check will be performed using the key found in pub‐
ring.pgp or rpubkeys. If the authentication check succeeds, the mes‐
sage:
Good signature from name.
Signature made on date.
will be displayed, with name being the name of the person or organiza‐
tion who made the signature, and date being the date the signature was
made (on some systems the signature time may be off by a few hours if
the system doesn't adjust for different time zones properly). If the
check fails, the message:
Warning: Bad signature, doesn't match file contents.
Bad signature from name.
Signature made on date.
will be printed. If the archive is a multipart archive (for which the
authentication check can take some time since an archive stretching
over several disks needs to be processed), the message:
Verify multipart archive authenticity [y/n]
is displayed. The answer ``y'' will check the authenticity of the ar‐
chive, ``n'' will skip the authenticity check and continue with pro‐
cessing the archive.
If the data in the archive, or the archive itself, is to be secured,
the authentication information will be generated using the key found in
secring.pgp or rpempriv.
The signature scheme used is the RSA public key cryptosystem (for more
information on this and the pgp encryption package see the extended
documentation hpackext.doc). This scheme involves the manipulation of
very large numbers, which can be quite time-consuming on slow systems,
where the signature generation and checking can take several minutes
(for this reason the use of authentication for entire archives rather
than individual files in an archive is recommended).
Unlike encryption software, authentication code is not export-
restricted from the US. The U.S. Code of Federal Regulations, Title 22
which includes sub-chapter M, ``International Traffic in Arms Regula‐
tions'' (ITAR), makes an exception for software that can only be used
for authentication purposes and cannot not be used for general-purpose
encipherment and decipherment, as is the case for the data authentica‐
tion code in hpack.
HPACK Internationalizationhpack is available in Bavarian, Dutch, English, German, Italian, Pol‐
ish, Spanish, and Swiss German versions using the ASCII, IBM PC (Code‐
page 437), IBM Codepage 850, IBM Codepage 869, ISO 8859-1 (Latin 1),
ISO 8859-2 (Latin 2), ISO 8859-3 (Latin 3), ISO 8859-4 (Latin 4), Mac‐
intosh, Mazovia, and NeXTSTEP character sets. The exact language and
character set used by hpack is controlled by the environment variables
CHARSET and LANGUAGE. By default hpack interacts with users in English
using the ASCII/ISO646 character set. By setting these two variables,
another language and/or character set can be selected. Note that not
all combinations of languages and character sets will provide a useful
result.
Possible options for LANGUAGE are bavarian, dutch, english, german,
italian, polish, spanish, and swiss.
Possible options for CHARSET are ascii, cp850, cp869, ibmpc, iso8859-1,
iso8859-2, iso8859-3, iso8859-4, macintosh, mazovia, and nextstep.
For example to set hpack to interact with the user in Italian using the
ISO 8859-1 (Latin 1) character set, the environment variables should be
set as follows:
set LANGUAGE=italian
set CHARSET=iso8859-1 (MSDOS, OS/2)
setenv LANGUAGE=italian
setenv CHARSET=iso8859-1 (UNIX csh)
export LANGUAGE; LANGUAGE=italian
export CHARSET; CHARSET=iso8859-1 (UNIX sh)
Obtaining Public Keys
There are currently several key servers which can be used to obtain pgp
public keys through the Internet and UUCP email systems. These are a
convenient way of obtaining keys for people you wish to communicate
with. The servers do not attempt to guarantee that a key is a valid
key — the signators on the key should be used for that kind of secu‐
rity. These services can be discontinued at any time without prior
notification.
Operating key servers as of 1 April 1993 are:
Server: pgp-public-keys@pgp.iastate.edu
Administrator: Michael Graff <explorer@iastate.edu>
Site: Iowa State University
FTP: tbird.cc.iastate.edu:/usr/explorer/public-keys.pgp
Server: pgp-public-keys@toxicwaste.mit.edu
Administrator: Derek Atkins <warlord@MIT.EDU>
Site: MIT/Athena
FTP: toxicwaste.mit.edu:/pub/keys/public-keys.pgp
Server: pgp-public-keys@phil.utmb.edu
Administrator: John Perry <perry@phil.utmb.edu>
Site: University of Texas
FTP: phil.utmb.edu:/pub/pgp/public-keys.pgp
Server: pgp-public-keys@cs.tamu.edu
Administrator: Gary Ratterree <garyr@cs.tamu.edu>
Site: Texas A&M University
Server: pgp-public-keys@demon.co.uk
Administrator: Mark Turner <mark@demon.co.uk>
Site: Demon Internet Services, UK
FTP: ftp.demon.co.uk:/pub/pgp/pubring.pgp
Server: pgp-public-keys@chao.sw.oz.au
Administrator: Jeremy Fitzhardinge <jeremy@sw.oz.au>
Server: pgp-public-keys@kiae.su
Administrator: Victor Borisov <blaster@rd.relcom.msk.su>
Site: Relcom Corporation, Moscow
Server (UUCP): pgp-public-keys@jpunix.com
(uunet!jpunix!pgp-public-keys)
Administrator: John Perry <perry@jpunix.com>
Site: J. P. and Associates
Server (UUCP): pgp-public-keys@proxima.alt.za
Administrator: Lucio de Re <lucio@proxima.Alt.ZA>
Updates to this list are posted to the Usenet alt.security.pgp news‐
groups.
Each keyserver processes requests in the form of mail messages. The
commands for the server are entered on the ``Subject:'' line of the
message, for example:
To: pgp-public-keys@junkbox.cc.iastate.edu
Subject: help
In the above example the server will return an informational message on
how to use it. Other possible commands are:
Command Message body contains
ADD Your PGP public key to add to server.
INDEX Returned list of all PGP keys the server knows
about (the same as the output from PGP's -kv
command).
VERBOSE INDEX Returned list of all PGP keys in verbose format
(the same as the output from PGP's -kvv com‐
mand).
GET Returned complete public key ring from the
server.
GET userID Returned public key for the given userID.
MGET regexp Returned set of keys for which the userID
matches the given regexp.
To have your key added to the collection maintained by the key servers,
save your public key to a file in ASCII-armoured format and simply mail
it to one of the pgp key servers using add as the message subject line.
For example with most command-line oriented mailers the command would
be:
mail -s add <server address> < file.asc
To get the key for the userID ``pgut1'' (my own public key), the com‐
mand would be:
mail -s "get pgut1" <server address>
To get multiple keys using the mget command, possible options are:
mget michael Gets all keys whose userIDs contain
``michael''.
mget F605A5|3A738B Gets the two keys with the given keyIDs.
In addition to this service, there is a large collection of public
keys available for anonymous FTP at:
ftp.informatik.uni-hamburg.de:/pub/virus/misc/pubkring.pgp
To have your key added to the collection send it to Vesselin Bontchev,
bontchev@fbihh.informatik.uni-hamburg.de.
HPACK Archive/Data Encryption
hpack allows data stored in an archive to be encrypted with a variety
of public or conventional-key encryption algorithms. Encryption of
either entire archives or individual files is possible, as well as the
use of multiple keys to encrypt different sections of an archive
(though the use of public-key encryption is preferred for this since
its inherent automatic key management greatly simplifies handling the
encrypted data).
When chosing an encryption key for a conventional-key algorithm, the
following guidelines should be observed:
· hpack allows keys of up to 80 characters in length. These keys
can contain letters, numbers, spaces, and punctuation. This
fact should be made use of to the fullest, with preferred pass‐
words being entire phrases rather than individual words. There
exist programs designed to allow high-speed password cracking of
conventional-key encryption algorithms which can, in a matter of
hours (sometimes minutes, even seconds in the case of very weak
algorithms), attempt to use the contents of an average large
dictionary as sample passwords. Most passwords composed of sin‐
gle words can be broken with ease in this manner, even in the
case of algorithms like the MDC one which is used by hpack,
which has been specially designed to be resistant to this form
of attack (doing a brute-force search of all 8-letter passwords
(the minimum length allowed by hpack) assuming a worst-case sit‐
uation in which the password contains lowercase letters only,
can be accomplished in 662 years on a fast CPU (Sparcstation
IPX) if the attacker knows the contents of the encrypted file(s)
in advance — or about 8 months on a network of 1000 of these
machines. Using an intelligent dictionary-based cracking pro‐
gram will reduce this time significantly). This is especially
apparent if the encryption algorithm used is very weak — the
Pkzip encryption, for example, can be broken in this manner in a
few seconds on a cheap personal computer using the standard Unix
/usr/dict wordlist).
· Simple modifications to passwords should not be trusted. Capi‐
talizing some letters, spelling the word backwards, adding one
or two digits to the end, and so on, only present a slightly
more difficult challenge to the average password-cracker than
plain unadorned passwords.
· Probably the most difficult passwords to crack in this manner
are ones comprising phrases or sentences, since instead of
searching a small body of text like the contents of a dictio‐
nary, the cracker must search a much larger corpus of data,
namely all possible phrases in the language being used. Need‐
less to say, the use of common phrases should be avoided, since
these will be an obvious target for crackers.
As is the case when using public-key encryption for data and archive
authentication, the secret keyring secring.pgp will need to have a
small quantity of extra information added to it, for which details are
given in the section Using PGP Secret Keyrings below.
Using PGP Secret Keyrings
Like pgp and pem implementations, hpack can store its secret keys in an
encrypted format to protect them from prying eyes. However the encryp‐
tion algorithm hpack uses is somewhat different to the one used in pgp
due to patent restrictions and in pem due to export restrictions. This
means that encrypted pgp keyrings need to have a small amount of extra
information added to them before hpack can use them. The hpack distri‐
bution includes a utility called keycvt which performs this task. key‐
cvt is run as follows:
keycvt <PGP secret keyring> [<output keyfile>]
Normally keycvt will append the extra information to the existing
keyring. However if an optional output keyfile name is given, the
extra information will be written to the output file instead of being
added to the keyring.
The source keyring may contain one or more secret keys. For each key
in the file, keycvt will display its key information and ask:
Add information for this key so HPACK can use it (y/n)
An ``n'' response will cause keycvt to print:
Skipping key...
and move on to the next key. A ``y'' response will cause keycvt to try
to add the extra information needed by hpack. If the key is encrypted,
keycvt will ask for the decryption password:
Please enter password for this private key.
Warning: Password will be echoed to screen!
Password:
If the incorrect password is entered, keycvt will warn:
Incorrect checksum, possibly due to incorrect password
and allow it to be reentered. Up to three attempts at the password are
allowed before keycvt gives up. When the key has been read in, keycvt
will add the extra information encrypted with the same password as was
used for the decryption. This is the password which hpack, like pgp
and pem implementations, will use to decrypt the secret key.
Please note that, unlike hpack, keycvt will echo the password entered
to the screen. Since keycvt is a one-use only application and since
obtaining keyboard input without echo is quite difficult on many sys‐
tems, keycvt uses a standard input routine to obtain its password. In
addition, the password used for keycvt should follow the same rules as
hpack, namely the key should be 8 characters or more long (see the sec‐
tion HPACK Archive/Data Encryption below for more details).
Finally, when keycvt has finished processing the key file, it will ask:
Finished processing keys. Add new key information to output keyring (y/n)
A ``y'' response will add the new key information to the output key
file. If no keys were converted or an ``n'' response is given, keycvt
will display:
No keys converted, output file left unchanged.
In addition, keycvt will create the seed file needed by hpack in the
same directory as the pgp seed file if it doesn't already exist. If
the seed file already exists, keycvt will display:
Existing HPACK seed file left unchanged.
and exit. If the file doesn't exist, hpack will create it and display:
HPACK seed file created
before exiting.
This seed file can also be created manually by copying the pgp seed
file randseed.bin to a new file hpakseed.bin.
Authentication of HPACK Executables
There have been several occasions in the past when fake versions of new
archivers have been distributed. Sometimes these fake release are even
wrapped up in a nice-looking ``security envelope'' guaranteeing their
authenticity. Since the source code is freely available, it's all too
easy for anyone to create a fake version of hpack in which the encryp‐
tion or authentication code has been compromised. In order to avoid
any problems in this respect, the distributed hpack executables are
accompanied by a digital signature (see the section HPACK Archive/Data
Authentication above) which can be used to verify that it is indeed an
official version. Unlike the schemes used by other archivers, it is
computationally infeasible to compromise this method of authentication.
In order to check the authenticity of the particular version of hpack,
you will need the pgp encryption package (see the section HPACK Ar‐
chive/Data Authentication above), and my public key, which is included
in the standard pgp distribution and also in the hpack distribution.
My key is signed by Philip Zimmermann, the original author of pgp, and
several members of the pgp development team. First, you should check
my key for authenticity:
pgp -kc 'Peter Gutmann'
When it performs the key check, pgp should display the following signa‐
tures:
Type bits/keyID Date User ID
pub 1024/997D47 1992/08/02 Peter Gutmann <pgut1@cs.aukuni.ac.nz>
sig! E722D9 1992/11/26 Branko Lankester <lankeste@fwi.uva.nl>
sig! 997D47 1992/10/11 Peter Gutmann <pgut1@cs.aukuni.ac.nz>
sig! 7C02F9 1992/09/07 Felipe Rodriquez <nonsenso@utopia.hacktic.nl>
sig! 1336F5 1992/09/05 Harry Bush <Harry@castle.riga.lv>
sig! 67F70B 1992/09/02 Philip R. Zimmermann <prz@sage.cgd.ucar.edu>
Version 2.1 and up of pgp can, in addition, calculate a key fingerprint
for a key. This can be calculated with:
pgp -kvc 'Peter Gutmann'
pgp should display the following:
pub 1024/997D47 1992/08/02 Peter Gutmann <pgut1@cs.aukuni.ac.nz>
Key fingerprint = 7C 6D 81 DF F2 62 0F 4A 67 0E 86 50 99 7E A6 B1
If the keyID or key fingerprint for my key differs from the one shown
above or the signatures don't check out, then the key is a probably a
fake and shouldn't be trusted. Assuming the key is in order, the
authenticity of the program itself and the internationalization infor‐
mation can be checked with:
pgp <program name> hpack.sig
pgp <internationalization file name> language.sig
where hpack.sig and language.sig are the digital signatures included
with the program as distributed. For example to check the authenticity
of the Amiga hpack executable type:
pgp hpack hpack.sig
pgp language.dat language.sig
When it performs the check, pgp should display:
Good signature from user Peter Gutmann <pgut1@cs.aukuni.ac.nz>.
Signature made <date of signature>
If pgp reports a bad signature then the executable shouldn't be
trusted. A new, hopefully untouched, version can be obtained from any
archive site, BBS, or system which carries the standard hpack distribu‐
tion, or you can arrange to get it directly from the author.
Using HPACK Encryption in the US
The following section is only of interested to hpack users residing in
the US — non-US hpack users can skip it.
The RSA public-key encryption algorithm is covered by US Patent
4,405,829, and also by US Patent 4,218,582. The exclusive licensing
rights to both patents are held by Public Key Partners (PKP) of Sunny‐
vale, California. The US version of hpack uses a special set of rou‐
tines called RSAREF which are available from RSA Laboratories, which is
the research and development division of RSA Data Security, Inc., the
company founded by the inventors of the RSA public-key cryptosystem.
RSA Laboratories reviews, designs and implements secure and efficient
cryptosystems of all kinds. Its clients include government agencies,
telecommunications companies, computer manufacturers, software develop‐
ers, cable TV broadcasters, interactive video manufacturers, and satel‐
lite broadcast companies, among others.
RSA Laboratories have granted users of hpack permission to make a small
number of changes to the RSAREF code in order to integrate it into
hpack. More details on this integration are contained in the
``readme'' file included in the hpack distribution. This applies only
for noncommercial use of hpack. Anyone intending to use hpack commer‐
cially should contact RSA Laboratories at the address given below.
Everyone who wishes to compile hpack themselves must obtain their own
copy of RSAREF. Free licenses to redistribute RSAREF are available.
For information, please send electronic mail to <rsaref-administra‐
tor@rsa.com>.
RSAREF is available to citizens and permanent residents of the US. It
can't be sent outside the United States, or given to anyone who is not
a United States citizen and doesn't have a ``green card''. These are
US State and Commerce Department requirements, because the code in
RSAREF is export-controlled technology. (Incidentally, the fastest
implementation I've ever seen of the conventional cipher used in RSAREF
was written in Moscow, but that's another story).
Any questions on the RSAREF software, licenses, export restrictions, or
other RSA Laboratories offerings should be addressed to:
RSA Laboratories RSA Data Security, Inc.
10 Twin Dolphin Drive 100 Marine Parkway
Redwood City, CA 94065 Redwood City, CA 94065
USA USA
(415) 595-7703 (415) 595-8782
(415) 595-4126 (fax) (415) 595-1873 (fax)
or via email to <rsaref-administrator@rsa.com>.
CREDITS
Many people have helped to get hpack where it is today, among them (in
no particular order):
Ports to different operating systems:
Stuart Woolford did the UNIX port.
John Burnell did the OS/2 port.
Jason Williams and Edouard Poor helped with the Archimedes port.
Nick Little and Joerg Plate helped with the Amiga port.
Martin Braschler did the Atari ST/TT port.
Translations:
Peter Sowa and Martin Braschler did the German translation.
Peter de Vocht did the Dutch translation.
Arrigo Triulzi did the Italian translation.
Rafal Mazkowski did the Polish translation.
Eduardo Jacob did the Spanish translation.
Martin Braschler did the Swiss German translation.
Peter Gutmann had a go at the Klingon translation.
Documentation:
DaviD W. Sanderson (dws@ssec.wisc.edu) did major formatting work
on the man page.
CONTACTING THE AUTHOR
You can contact me in any of the following ways:
· By calling me on +64 9 426-5097 within reasonable hours
(10am-12pm NZT).
· By Usenet email to either pgut1@cs.aukuni.ac.nz (preferred), or
p_gutmann@cs.aukuni.ac.nz, peterg@kcbbs.gen.nz, or peter@nac‐
jack.gen.nz (in rough order of preference).
· By Fidonet email to Peter Gutmann at 3:772/90.0. However this
is probably about as reliable a link as using carrier mackerel
across the Sahara.
· By snail mail to 24 Durness Pl, Orewa, Auckland, New Zealand
· By throwing a bottle in the ocean (slightly less reliable than
the Fidonet link).
· By implanting subliminal messages in the music I listen to.
HPACK Error Messages
The error messages given by hpack are the following:
No matching files on disk
The command you have given resulted in no changes being made to
the archive(s) specified, due to the files you specified not
being found on the disk.
No matching files in archive
The command you have given resulted in no changes being made to
the archive(s) specified. There can be several reasons for
this, among them being that there were no matching files in the
archive to replace/update, or that there were no matching files
in the root directory of the archive (hpack will not, by
default, check subdirectories: To handle subdirectories you must
either give the full path within the archive, or use the
[-r]ecurse subdirectories option).
No matching archives found
The command you have given resulted in no changes being made to
the archive(s) specified, as they could not be found on the
disk.
Out of disk space
There is not enough room on the current disk to finish archiv‐
ing/unarchiving a file.
Unknown command
You have given hpack a command which it doesn't understand.
Check the section HPACK Commands for valid hpack commands.
Unknown option
You have given hpack an option which it doesn't understand.
Check the section HPACK Options for valid hpack options.
Unknown overwrite option
You have specified an unknown option for the [-o]verwrite
switch. This error may also be caused by forgetting to specify
an option for the switch, in which case hpack will treat the
character following the -o as the option.
Unknown view option
You have specified an unknown option for the [-v]iew options
switch. This error may also be caused by forgetting to specify
an option for the switch, in which case hpack will treat the
character following the -v as the option.
Unknown directory option
You have specified an unknown option for the [-d]irectory
options switch. This error may also be caused by forgetting to
specify an option for the switch, in which case hpack will treat
the character following the -d as the option.
Bad wildcard format
You have used an incorrect format when using wildcards in file‐
names.
Wildcard expression too complex
You have used a very complex wildcard sequence, and hpack
doesn't have enough room to process it fully. Try simplifying
the expression, or break it up into separate simpler expres‐
sions.
Cannot use wildcards in external pathname
You have used wildcards in a pathname outside the archive.
Since hpack's extended wildcards are built on top of the usual
operating system ones (if they exist) the resulting system would
run very slowly if they had to be simulated on an external
filesystem.
Not an HPACK archive
The supposed archive file does not appear to be an archive cre‐
ated by hpack.
Cannot open archive file
hpack cannot open the archive file.
Cannot open data file - skipping
hpack cannot open the data file to dearchive data to, and is
skipping to the next file to be processed.
Cannot open temp file
hpack cannot open the temporary work file it needs for the
[d]elete, [f]reshen, [r]eplace, or [u]pdate commands.
Cannot open script file - skipping
hpack cannot open the script file containing the list of files
to process and hpack control commands, and is skipping to the
next file to be processed.
Cannot access base directory
The base directory you have specified does not exist.
Cannot create directory
hpack cannot create a directory to unarchive files into.
Cannot override base path
This error message arises when using the [-b]ase path option and
either a drive specifier is given in the pathname of one of the
files to process or the base path includes an actual path and
the file pathname is specified as being off the root directory.
Since the base path is prepended to the pathname of the file,
the pathname cannot contain a drive specifier or absolute direc‐
tory reference in it.
Unknown archiving method - skipping
The version of hpack you are using is unfamiliar with the ar‐
chiving method used for this file, and is skipping to the next
file to be processed.
Data is encrypted - skipping
The data in this file is encrypted, and no means of decryption
has been supplied by the user; therefore hpack cannot process it
and will move on to the next file to be processed.
Cannot process encrypted archive
The entire archive (rather than just the data in it) is
encrypted, and hpack cannot decrypt it to read it. This is
either because no decryption password has been supplied, or
because the archive is encrypted with an encryption method for
which no decryption information is available.
Cannot change deleted archive
You have used the [-k]ill original archive option along with the
[r]eplace, [f]reshen, or [u]pdate options.
Cannot change multipart archive
You have asked hpack to [f]reshen, [u]pdate, [r]eplace, or
[d]elete files in a multipart archive, which would involve
rewriting an archive spread across multiple disks.
Cannot change unit-compressed archive
If an archive is compressed as one unit, it cannot later be
changed in any way. Unit-compressed archives trade off com‐
pressed size for flexibility in updating them.
Cannot change encrypted archive
You have asked hpack to [a]dd, [f]reshen, [u]pdate, [r]eplace,
[d]elete, or [x]tract with move, files in an encrypted archive.
Files or data in an encrypted archive cannot be changed without
decrypting and re-encrypting the entire archive.
Cannot change unencrypted archive
You have asked hpack to make changes to an unencrypted archive,
using block-encryption. hpack will not retroactively encrypt
the archive, however the files can be individually encrypted as
they are added to the archive.
Cannot use both conventional and public-key encryption
You have specified that data be both conventional and public-key
encrypted. Data can be encrypted with one of the two methods,
but not with both at once.
Passwords not the same
When encrypting data, hpack will ask you to retype the password
for security. If the second password doesn't match the first
password, this error message is issued.
Password must be between 8 and 80 characters long
The passphrase you have entered is either less than eight char‐
acters (making it dangerously short), or more than 80 characters
(making it excessively long).
Bad keyfile
The keyfile containing the keys used for decrypting and authen‐
ticating data is corrupted.
Missing userID for encryption/authentication
You have forgotten to specify a userID when adding authentica‐
tion information to an archive, or when using public-key encryp‐
tion, or haven't given a primary userID for public-key encryp‐
tion when using a secondary userID.
Cannot find secret key for userID
The secret key needed to add authentication information to data
for the given userID cannot be found, and the authentication
information cannot be added.
Cannot find public key for userID
The public key needed to encrypt data for the given userID can‐
not be found, and the encryption can't be carried out.
Cannot find secret key - cannot decrypt data
The secret key needed to decrypt the data cannot be found, and
the data cannot be decrypted. This message will also occur if
the secret key exists but hasn't been processed with the keycvt
utility, which adds a small amount of extra information needed
by hpack to use the key. See the section Using PGP Secret
Keyrings above for more details.
Cannot find public key - cannot perform authentication check
The public key for the authentication information attached to
the data or archive can't be found, and thus the data authenti‐
cation check can't be carried out.
Authentication data corrupted - cannot perform authentication check
The information used for authenticating the data in an archive
has been corrupted.
Cannot read random seed file
The random seed file needed for public-key encryption cannot be
read. If it doesn't exist or has been accidentally destroyed, a
new one should be created either using the keycvt utility or
manually. See the section Using PGP Secret Keyrings above for
more details.
Archive directory corrupted
The archive directory information has been corrupted. Depending
on how bad the corruption is, hpack will either exit or prompt
the user for whether it should try to continue, attempting to
fix any errors in the directory as it processes it.
Out of memory
There is not enough memory available for hpack to continue.
Path too long
You have used more than the maximum allowable number of charac‐
ters (the limit set by the host OS) in a pathname.
Path not found
You have asked hpack to add a file to a nonexistent directory
inside an archive.
Bad character in filename
Input lines in script files are given a basic check for being
valid filenames. If blatantly incorrect characters are discov‐
ered in a line of input this warning will be printed.
Errors detected in script file
Errors (either illegal characters or too-long pathnames) have
been detected in the script file.
Maximum level of errors detected in script file
More than 10 errors have been detected in the script file. This
error message generally results from erroneously specifying a
non-script file as a script file.
Too many levels of directory nesting
You have tried to go down through more than 15 levels of subdi‐
rectories using the [-r]ecurse subdirectories option.
Stopped at user request
The user or some other program interrupted hpack during the ar‐
chiving process (for example by pressing the ``Break'' key or by
sending it a termination signal).
Truncated EOF padding
In some implementations of the Xmodem and Ymodem transfer proto‐
cols, CP/M end-of-file characters (Ctrl-Z's) are appended to the
end of the transmitted file. When hpack detects these spurious
characters on the end of an archive, it will truncate the ar‐
chive to its correct size and issue this warning message.
Archive section too short, skipping...
If part of a multipart archive is less than approximately 500
bytes long, hpack will not attempt to create the archive but
will move the data to the next, hopefully less full, disk.
File error
A miscellaneous type of file error occurred during the archiving
process (for example some sort of network error). The message
itself will if possible contain more detail about the precise
type of error.
Internal error
Some form of internal error occurred in hpack. Contact the
author with details on how the error was brought about.
Long argument format not supported in this version
Some CLI versions of hpack, notably the Amiga, Archimedes, Mac-
CLI, MSDOS, OS/2, UNIX, and VMS ones, support a long argument
format signalled by the -z switch, which is used to handle OS-
specific options. The version you are using doesn't support
this option.
DISCLAIMER
This program is guaranteed to perform as claimed, excluding any delays
caused or enhanced by war, civil commotion, or rioting, whether
declared, spontaneous, reprehensible, or justified; undue pressure to
perform, from whatsoever source; mal de mer, mal de pays, mal de
siecle, mal de code, mal de machine, or any force majeure not pretofore
invoked.
The program warranty is void in case of nuclear war, whether caused by
the program or not.
TRADEMARKS
Amiga is a trademark of Commodore Business Machines.
Archimedes is a trademark of Acorn Computers.
GIF is a trademark of Compuserve Inc.
IBM is a trademark of International Business Machines Corp.
Macintosh is a trademark of Apple Computer Inc.
MSDOS is a trademark of Microsoft Inc.
OS/2 is a trademark of International Business Machines Corp.
PKZIP is a trademark of PKWare Inc.
Prime and Primos are a trademark's of Prime Computer Corp.
QNX is a trademark of someone.
Rolemaster is a trademark of Iron Crown Enterprises Inc.
StuffIt is a trademark of Raymond Lau and Aladdin Systems.
ThinkC is a trademark of Symantec Corporation.
UNIX is both a trademark and a footnote of AT&T.
Windoze is not a trademark of Microsoft Corp.
Windows is, but it's a somewhat less accurate description of its per‐
formance.
These trademark lists are a trademark of too many lawyers and too few
people with common sense being involved.
``Good compression isn't a matter of life and death — it's far more
important than that''
Ver:0.79a0, 1 May 1993 HPACK(1)
