So, storing the signature of catalog parts or update logs inside the
serialized data structure of those files itself isn't really a practical
option.
In other words, this is what was currently suggested for catalog parts /
update logs:
{
'__SIGNATURE': {
sha-1: 4beda7834728ebfc78sa9d9aa7f,
},
'publisher': {
...fmri data...
}
}
However, that requires that I serialize the entire catalog part/update
log twice. Once to get the signature, and then once again to write out
the result with the signature. That is fine for small files such as
catalog.attrs, but is impractical from a performance standpoint for the
catalog parts/update logs (doubled write times, which could mean a full
minute on SPARC systems as opposed to 20-30 seconds).
As I mentioned before, JSON is not a container format, that is I cannot
simply append multiple data structure serialisations together. I'd have
to use MIME or my own custom container.
So that leaves me with the following options that I can think of at the
moment:
1) store the serialized signature data in the same file as the catalog
part / update log, but wrap the contents in a container format using
something like MIME
* advantage: allows signature to be stored with data the signature is for
* disadvantage: while not as bad from a performance standpoint as double
writes, possibly not nearly as fast as just loading straight-up JSON
2) Given that the catalog.attrs file also contains a copy of the
signatures for each catalog part/updatelogs, just rely on the signature
data there since that file is 'self-signed'.
3) Store signature data in a separate file.
What's the preferred direction?
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
