...and a question (SHA1 UUIDs)

[Ken Murchison]

My gut is to use the 'replace' patch.  I'm not comfortable with the 21 
byte scenario.  If we need a UUID schema version, we can always use a 
new MINOR_VERSION.


David Carter wrote:
> All from:
> 
>   http://www-uxsup.csx.cam.ac.uk/~dpc22/cyrus/patches/2.3.8/
> 
> 3 _incompatible_ spins on SHA1 UUID support
> ============================================
> 
> Each of the following requires an index upgrade and a new MINOR_VERSION.
> Serious business, needs discussion.
> 
> sha1_uuid_add.patch:
> --------------------
> 
> Extend UUIDs to 20 bytes: 1 byte version (schema) plus 19 bytes payload.
> 
> uuid_mode:
>   none
>   prealloc  (schema 1)  Current 2.3.8 behaviour with fix to master applied
>   shortmd5  (schema 2)  First 11 bytes of message MD5, as per Fastmail.
>        md5  (schema 3)  Full 16 bytes of message MD5
>   shortsha1 (schema 4)  First 19 bytes of message SHA1
> 
> Existing schema 1 UUIDs are filled to 20 bytes
> 
> sha1_uuid_replace.patch
> -----------------------
> 
> Throw away the existing UUID apparatus (in particular the environment
> value CYRUS_UUID_PREFIX used to pass state from master to imapd and
> lmtpd). Replace it with simple 20 byte UUIDs which are the message SHA1.
> 
> Any existing UUIDs are reset to NIL. I suppose that it would be possible
> to pad the existing 12 byte UUIDs to 20 bytes: the chance of a collision
> is remote.
> 
> sha1_uuid_full.patch
> --------------------
> 
> Extend UUIDs to 21 bytes: 1 byte version (schema) plus 20 payload.
> 
> uuid_mode:
>   none
>   prealloc  (schema 1)  Current 2.3.8 behaviour with fix to master applied
>   shortmd5  (schema 2)  First 11 bytes of message MD5, as per Fastmail.
>        md5  (schema 3)  Full 16 bytes of message MD5
>        sha1 (schema 4)  Full 20 bytes of message SHA1
> 
> Existing schema 1 UUIDs are filled to 21 bytes.
> 
> sha1.patch :: required by all of the above.
> ==========
> 
> SHA1 library that I found with Google, released under LGPL. If the
> licensing is a problem, then any alternative which provides:
> 
>   void sha1( unsigned char *input, int ilen,
>              unsigned char *output );
> 
> will do just fine. I imagine that it appears in a lot of crypto libraries.
> 
> Discussion
> ==========
> 
> sha1_uuid_full.patch is the most flexible of the three versions, and 
> allows us to add further schemas (another 252) in the future.
> 
> 12 to 21 bytes is an awkward change. I have done this by shrinking the 
> preceding item in the index (cache_version) from 4 to 3 bytes and 
> punting modseq and modseq64 up by 8 bytes. This did involve some work on 
> mailbox_upgrade_index_work(), which wasn't expecting things in the 
> middle of the index record to expand (and in both directions at once!).
> 
> Thoughts? I appreciate that it will take some time for these patches to 
> be reviewed properly, but a ruling on which of the three potential index 
> formats are preferred would allow early adopters (I imagine Fastmail and 
> myself) to get on without worrying that we have an unsupported database.
> 


-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University