Changes made:

[sokorototo]

• Originally since the loader checked if signatures existed from the flags in the Header, you could only toggle signatures globally. This was also the reason why Flags::SIGNED_FLAG did not appear in the RegEntry flags, this bug, since it existed in the Header. Now since the signed flag belongs in the RegistryEntry, it can be toggled locally when building the .vach file, ie it is now scoped ( with Leaf::sign(false) ). Also, that's why RegistryEntry::from_handle(---) now takes one argument instead of two, as it reads the signatures internally instead of taking a bool from Header::flags.contains(Flags::SIGNED_FLAG).
• Now you can't construct a Flags instance directly: with Flags { bits: 0 }, as bits is now private, and can only be accessed with Flags::bits().
• Also Header formatting was changed to include less information, for extra information use dbg!() as fmt::Debug gives more info.

[zeskeertwee]

Shouldn't this be 4-15, since we start counting at 0?

[zeskeertwee]

We want this in the 0.2.0 release, @sokorototo, right?

[sokorototo]

Yes, it all comes with the 0.2.0 release

[sokorototo]

@zeskeertwee probably merge this PR because the next PR switches from chacha20poly to AES for encryption, with support for hardware acceleration. In short the next PR will be fully focused on the encryption side. And after that a better error handling framework

[zeskeertwee]

Yeah this PR is almost ready to merge, its just the documentation that has one small mistake in it. Could you fix that @sokorototo ?

[sokorototo]

What issue @zeskeertwee?

[zeskeertwee]

I left a review comment, but basically the spec says bytes go from 0-16 and it should be 0-15 @sokorototo

[sokorototo]

@zeskeertwee The spec.txt has been fixed. I have also migrated encryption from chacha20_polyfill to aes-gcm-siv. This allows for hardware-accelerated, OpenSSL-less ( issue on windows, as windows, does not come with OpenSSL) de|en-cryption. Remind me to write in the docs how one should configure hardware-accelerated AES with RUSTFLAGS

[zeskeertwee]

By the way, did you consider the encryption algorithm's speed? I saw this table comparing different algorithms, and the one we use definitely isn't close to the fastest @sokorototo . RustCrypto/AEADs#243 (comment)

[sokorototo]

Good point, we should probably shift to the much faster version

[sokorototo]

It's even better that I isolated the encryption logic. So we can easily swap out algorithms

[sokorototo]

My take on encryption

I figured that encryption is not about speed, but rather for safety. I still did some benchmarks, and crypto2 requires cargo nightly, so it was evicted from the start. I do not want to touch hazmat crates, lest I jeopardize the safety of vach archives (I am not a security researcher after all). I also wanted to avoid crates that had bindings to OpenSSL, as that would require installing OpenSSL on windows. And since vach is meant to be embedded into games, it was best to use a native solution: ie AES or chacha20PolyFill (?). And turns out, either I was so severely io bound and my benchmarks were microseconds apart, or that they performed very close to each other on my computer. So I just decided to go with AES as with the right compiler flags, it out-performed chacha20. Also, for a much more modern CPU (I am rocking an i5-4590) and faster storage, I think the performance is acceptable. Besides, if you want to load data fast, store it raw or only compress it. Encryption adds a lot of steps on top of loading the data, so only use it if you actually need it. @zeskeertwee

[zeskeertwee]

Allright, that makes sense!

[sokorototo]

• Awesome! Anyway, is version 0.2.0 ready to be published? It has a new error type, which is in need of some streamlining.
• I also plan to separate the benchmarks from the crate source. Why? Because cargo has to download and compile criterion, which comes with 50+ dependencies and adds a lot of download bloat during development. The only issue is that this will void small incremental performance updates, as the benchmark source and the crate source will now be separate. @zeskeertwee
• Which means, a new workspace member: vach-benchmarks

[sokorototo]

Windows build successful.