As with the previous additions to VaMP, these latest improvements are simply a direct and prompt answer to its increased use. Growing only when and as needed, but promptly and easily so, just check the exact dates and tell me in how many cases exactly can you truly get a tool to adapt to your needs so promptly and with so little overhead, let alone without other costs of all sort?

For the concrete uses that prompted this, first there was some play with VaMP keys and messages that highlighted some specific ways in which VaMP could be more helpful when used straight from the command line for communication matters. While up to now VaMP has been in daily use for years already, such use has been either through other code mostly, where the communications part is concerned, as part of the client for Eulora 2 or otherwise focusing more on code versioning - with the result that these parts got the most feedback as well. As the actual use increases and expands in scope, there is more to inform any needed changes or additions, so these get done and then put straight to use to be further iterated if and as needed, neither more nor less, which is exactly the best way to go as far as I'm concerned.

Quite immediately following the above, even if less publicly visible, there was as well the push towards switching all of Eulora 2's client deployments to VaMP only and this added a request to better support some minimal automation for discovery and filtering of relevant patches. So I added it all to the growing list, proceeded then to implement, test, deploy and keep it all in sync across all relevant places, with the result bringing in enough changes that it makes full sense to document them here as well:

1. Added command fingerprint to calculate and display the fingerprint of a key from either its .pub file or its .priv and salt files. While VaMP always did this internally and used the fingerprint as well to name the files for newly created keys, up to now it didn't expose this for the user to call as they wish, since there was no specific case requiring it. As it turns out though, when people exchange keys, a way to check the fingerprint would be rather handy so now it's made available.
2. Added command pubkey to extract just the public part from a private key and write it to the usual .pub file format that can then be used just like any other .pub file.
3. Added command sim_go to only simulate a "go" - meaning to find and list the full set of patches that make the shortest path to bring a given directory to the final state of a given target patch, without actually applying those patches. This is quite helpful for supporting some minimal scripting or other similar automation that needs to identify and find the relevant patches and their files e.g. for deploying or updating some deployed version rather than for direct code versioning as such. For the full case where one actually wants to obtain the final state of a given target patch, the previously existing command "go" remains as it was and does it all.
4. Improved and more precise checks of the pub, priv and salt files so that the content is indeed more important than the extension at all times and when there is some obvious error or mismatch, the error message is, hopefully, more useful, too. Note here that these checks are provided to help the user figure out what is wrong whenever possible but they *cannot* be truly infallible - there are and will always be cases where the inputs *look* right enough to pass these checks but still are in fact quite different from what the user intends them to be, with the result at best an error further down the line, at worst something that looks still right but then fails to serve. There isn't really much to do about this currently and especially not while fully preserving at the same time the core desiderata of any encryption scheme. Of course, compromises of all sorts can be made at any time but at least for now, I don't think there's any need for such compromise here.
5. Fixed the issue with the way paths were handled when encrypting or decrypting files that are not in the current directory. With this fix, one can decrypt or encrypt a file in another directory and have the result written there as well, too.
6. Added a double-entry and corresponding check of the password when creating a new key, bringing in this sense VaMP closer to the more usual practice of password creation I suppose. The similar use through the graphical user interface of the client's can avoid this by enabling the user to actually see what password they entered and thus check it as and when they want but the command line doesn't quite have the same option and so it has to go with what it can do and force a double entry. Perhaps if this gets too annoying, it can get an option in the .ini file to toggle it on/off but for now at least it's simply on at all times.
7. Added a check and prompt for confirmation whenever adding a new root patch - meaning a patch which does not currently have a direct parent in the known or given set of patches¹. This is to better support users of larger code bases and patch sets, so that there is some reassurance that no accidental breakage of the tree happens without notice, even if one doesn't manually check the full tree each time they add a new patch. The cost for this is a further delay when adding a new patch, since the additional step has to search the full set of known patches for any known parent. In practice, I don't find this too much of a cost to pay and moreover, if it ever gets to be too much, one can always simply use a reduced set of patches at add time to keep the benefit while greatly reducing the cost.
8. Updated the check of the manifest file for a more flexible approach to code versioning since the various use cases that come up when having editions on top of local and shared development versions rather need this. Consequently, while the code checks the manifest files as before, a fail of such checks will prompt the user to review and confirm if they still want to proceed, rather than just forcing an abort entirely.
9. A small code-level change, mainly ditching the use of Exception_Information throughout because its implementation in GNAT is rather dubious if not buggy altogether - suffice to say that I managed to get it to overflow its stack in a different, much more complex scenario and while I am not that bothered to fully hunt or document this currently, I will still just blacklist this method entirely. The experience did prompt a closer look at the GNAT implementation of Exception_Information and such look rather supports the blacklisting: for some reason, this function needs to follow pointers through what can end up as quite convoluted links. At the same time, there are other two functions that fully provide what I need otherwise, namely Exception_Name and Exception_Message. And these two functions take a much more straightforward approach, not following any pointers and just returning what is requested. As a result, they get used and the other one gets blacklisted, that's all.
10. An internal small but overdue refactoring of the way the default paths for patches, signatures and keys are handled so that they are now in a single place in the file_io package and overwritten otherwise by values read from the .ini file if such are present.

That's all for now, let me know if you give it a spin and how it works for you. As amply documented by now, help for any productive use is still at hand when, if and as needed and asked for.

1. Note that this doesn't mean nor can it ever mean that this is or will forever be a "root patch" - there is no such thing, since it's all a matter of context. Any single patch is a root patch by definition and any root patch can become a non-root patch if and when there is another patch that produces its exact, full input state, that's all. ↩

Category: Coding, VaMP

Comments feed: RSS 2.0