Hi Giovanni! Giovanni Mascellani <[email protected]> writes: > Since the original wotsap is not maintained any more, but there are > quite a few patches that could be applied and improvements that could be > made, I decided to fork it and begin again its development here: > > https://github.com/giomasce/wotsap > > Actually, I will not have a lot of time for it, but hopefully enough to > fix the current most outstanding issues. I will also update the Debian > package after this repository.
That's great news, thank you! also means I don't need to care for the client side and can concentrate on getting the extraction part right! > I see two main alternatives: > > * The file "keys" is extended to 8 or 20 bytes record. This is the > sanest thing, but it is also backward-incompatible. The WOTVERSION > number should be bumped to 0.3, old clients could not use new files and > new clients could not use old files (unless they retain compatibility, > of course). > > * Old files are kept as they are, but another file (e.g., "longkeys") > is added, which contains 4 or 16 bytes record: each record is the part > that must be pasted before the corresponding "keys" record in order to > have the long ID. This is backward-compatible, but really ugly in itself. > > I tend to prefer the first alternative, especially if you can keep > providing 0.2 .wots for some time after the change. As wotsap can't cleanly handle the first case right now (it might when making sure the new fingerprints file is added *at*the*end*) I agree making an incompatible change is masically unavoidable. Plkease, when implementing the client consider unsing python-arpy (I started getting arpy in a shape where we can use it for that but never did anything more) so the client no longer depends on the ordering of files in the ar-archive! I think the new format should have the folloing changes + Get full fingerprints into the keys file + change compression from bzip to xz + maybe make keys a textfile (newline terminated hex-encoded strings) After encryption there should be hardly any difference in size Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer
