LunaPack 0.1.4

LunaPack 0.1.4

The encryption of the entries.

The mechanism is the one of the reference implementation this package
follows: a key is established with the recipient, HKDF-SHA512 turns it
into the key of the package, and every entry is sealed on its own with
ChaCha20-Poly1305 under a key and a nonce that are derived for it. The
additional data of an entry holds its place in the package and its name,
so that neither the order nor the name of an entry can be changed
without the seal breaking. A check in the manifest tells a wrong key
from a damaged package.

The key exchange is the one part that is different. The reference uses the
sntrup761 KEM, which the toolchain has no counterpart of, so this package
uses X25519, the curve that the reference itself carries as a part of its
own sntrup761x25519-sha512 method.

Every primitive is implemented here, because the toolchain ships none of
them: SHA-512, HMAC, HKDF, PBKDF2, ChaCha20, Poly1305 and X25519. Each
one is checked against the vector that its standard publishes, and the
derivation is checked against the reference implementation itself.

There are two methods. The x25519 method seals a package to the owner of
a public key; the passphrase method seals it with a passphrase. A secret
key that a passphrase protects is the better form.

The self-extracting bundle finds its key next to itself: the file
.key for a public key, the file .pass for a passphrase.

The manifest format version goes to 5, because an entry may now be
sealed. A package written by an older version still unpacks.

70/70 tests pass on the native and the wasm backend.

LunaPack 0.1.3

LunaPack 0.1.3

LZ4, and a packing that is much faster.

The toolchain ships no LZ4, so the block format and the frame format of the
reference implementation are written here in pure MoonBit, together with
the xxHash32 that the frame header needs. What is produced is a standard
.lz4 frame: the lz4 tool decompresses it, and this package decompresses
what that tool produces. Both directions are covered by the test suite.

The codec is chosen with --compression-method, which takes none, gzip, lz4
or auto. Measured on an application of 392 files and 332 MB:

packing gzip 39 s lz4 16 s
unpacking gzip 21 s lz4 19 s
size gzip 139 MB lz4 175 MB

LZ4 does no entropy coding at all, so it is much faster while producing a
larger result. The gzip codec moves to moonbitlang/core/compress/gzip,
which is faster in both directions and produces a smaller result than the
stream implementation did; the two read each other.

Three things that made the packing slower than it had to be are gone: the
unpack read every extracted file back twice, the fingerprint of the
produced file was computed by reading the whole file back, and a path at
the root of a drive failed.

The manifest format version goes to 4, because an entry may now name the
lz4 codec. A package written by an older version still unpacks.

42/42 tests pass on the native and the wasm backend.

LunaPack 0.1.2

LunaPack 0.1.2

The package now builds on moonbitlang/core/async, which the MoonBit
developers have confirmed the stable releases will use. The wrapper
package moonbitlang/async was already built on the core one, so this
removes a layer instead of adding a risk.

The package has no dependencies at all now: moon.mod declares none,
nothing is vendored, nothing has to be resolved when the published
module is fetched, and the CI no longer contacts the registry.

The packages are unchanged. The archive built by the old and the new
implementation is byte-identical apart from the creation time in the
manifest, the gzip streams included, and every entry agrees on its size,
mode, checksum and fingerprint.

The API differences were mechanical:

• fs.read_file(p).binary() -> fs.read_binary(p)
• fs.write_file(p, bytes) -> fs.write_binary(p), write_text(p, s)
• the io traits are BinaryReader and BinaryWriter now
• the gzip decoder returns the bytes directly

30/30 tests pass on the native and the wasm backend.

LunaPack 0.1.1

LunaPack 0.1.1

The MD5 fingerprints:

• every file is scanned before it goes into the package, and the list of
  fingerprints is printed;
• the fingerprint of the produced file is reported as well;
• after unpacking, every extracted file is read back from the disk and
  checked against the fingerprint it had in the package;
• the self-extracting bundle checks the files it writes as it extracts them;
• 'lunapack verify --extracted ' audits the files that are
  already on the disk.

MD5 is a convenience fingerprint that can be compared with what the platform
tooling shows; the integrity of the package rests on the SHA-256 checksum of
every entry.

The manifest format version goes to 3 because the entry now carries the
fingerprint. A package written by an older version still unpacks, because the
fingerprint is optional.

LunaPack 0.1.0

LunaPack 0.1.0

The first release of LunaPack:

• pack an application and its resources into a single self-extracting file
• SHA-256 checksums for every entry
• gzip compression per entry
• pre_install / post_install scripts with a target platform
• the icon of the application is copied to the bundle on Windows

The binaries are attached to the GitHub release; the same version is
published to the Mooncakes registry.