The issue is no crypto functions are eternal. Most of them have a finite, 10-20 year life cycle until they get broken by hidden design faults, or by increase in available computational power.
It would be nice to prepare this format for a future crypto update with a clean upgrade path by versioning the headers.
There are two cases that needs attention:
- When an old pkgar tool encounters a newer pkgar archive format.
- When a new pkgar tool encounters an older pkgar archive format.
In the first case with unversioned headers, pkgar currently returns signature validation errors on newer archive formats. This could be misleading, users might think their archives are corrupt or someone tampered with them. Instead of that, based on a header version field pkgar should notify the users that it has encountered a newer format it cannot handle yet and they should probably update the tool to a new version.
In the second case it's possible to handle multiple formats in a backwards compatible way without header versioning - by trying to decode each of the formats and checking whatever decoding fails or not. But of course this is not an optimal way to go.