Still eagerly awaiting a response to my #pyzipper pull request. Waiting is so hard!

In the meantime, I've added zip and unzip commands to #passcrow, to facilitate creating #AES encrypted #ZIP archives with recoverable passwords.

I haven't pushed my changes, because they depend on the pyzipper updates.

Hacking on #pyzipper made me want to hack on #passcrow again.

Filed a pull request to see if #pyzipper wants my fancy new features: https://github.com/danifus/pyzipper/pull/34

Fingers crossed!

Incidentally, if I decide to do a talk about crash tolerant code, it will be a discussion about this change: https://github.com/danifus/pyzipper/pull/34/commits/ffc101d57e1fad4773c3ed6f4d2614697378e12d

Not sure I can squeeze that into a lightning talk, TBH. But it might be fun to try?

Spent a bit more time on my #pyzipper enhancements.

One of the interesting challenges to writing code like this, is: what happens if something crashes or the code is interrupted? Does data get corrupted? Can I reduce the chances of that?

Rewriting in place is good for reclaiming space, because it works even if a drive is full - exactly when you need to reclaim space! But it's risky, because if you crash part-way things may be in an odd state.

Crash-tolerant code is interesting.

Talk-worthy?

Oh no, I got confused and wrote some useful code now instead of later!

Ah well. I've now got an updated #pyzipper (itself an updated #python zipfile) which supports deleting files from a #ZIP archive - and thus also supports writing updated versions of files to a ZIP archive.

It's feels weird that I had to write this myself!

I guess I should probably figure out how to contribute my code as far back upstream as I can?

@HerraBRE@floss.social My local #moggie now knows how to export search results as a .ZIP archive of AES-encrypted messages!

I've also enhanced #pyzipper so I can add unencrypted files to an otherwise encrypted archive, which means embedding #passcrow recovery support (and instructions) directly in the .ZIP is now feasible.

This is starting to tick all the security / portability / recoverability boxes.

I am very pleased!

I spent yesterday afternoon looking into whether I could port #pyzipper to use the #Python cryptography module instead of #Cryptodome.

After diving into the sources of both libraries and finding myself reading #openssl 's aes.c, I discovered this is most definitely not possible without awful perf killing hacks: https://stackoverflow.com/questions/69144760/aes-ctr-decryption-cryptography-and-cryptodome-give-different-results/69145945

Why? Because OpenSSL's AES CTR hard-codes a big-endian counter. #WinZip compatible AES encryption requires a little-endion counter.

I'm not even mad.