Alignment issue with sha1 code from gnulib

[David Shaw]

Hello,

Peter Palfrader reported a bug against the sha1 code in paperkey, but
that code actually comes from gnulib, so I'm referring it to you.

The issue comes up (as noted in the comment) if resbuf is not 32-bit
aligned.  Rather than requiring all programs that use the gnulib sha1
code to align their result buffer, Peter's patch seems to make more
sense in that it "just works" on any platform.

David

----- Forwarded message from Peter Palfrader <address@hidden> -----

This seems to fix the issue:

--- paperkey-0.7.orig/gl/sha1.c
+++ paperkey-0.7/gl/sha1.c
@@ -67,19 +67,28 @@
   ctx->buflen = 0;
 }
 
+/* Copy the 4 byte value in v into the memory location pointed to by *cp,
+   If your architecture allows unaligend access this should be equivalent
+   to *cp = v */
+void
+set_uint32(char *cp, uint32_t v)
+{
+  memcpy(cp,&v,4);
+}
+
 /* Put result from CTX in first 20 bytes following RESBUF.  The result
    must be in little endian byte order.
 
    IMPORTANT: On some systems it is required that RESBUF is correctly
    aligned for a 32-bit value.  */
 void *
-sha1_read_ctx (const struct sha1_ctx *ctx, void *resbuf)
+sha1_read_ctx (const struct sha1_ctx *ctx, char *resbuf)
 {
-  ((uint32_t *) resbuf)[0] = SWAP (ctx->A);
-  ((uint32_t *) resbuf)[1] = SWAP (ctx->B);
-  ((uint32_t *) resbuf)[2] = SWAP (ctx->C);
-  ((uint32_t *) resbuf)[3] = SWAP (ctx->D);
-  ((uint32_t *) resbuf)[4] = SWAP (ctx->E);
+  set_uint32(&resbuf[0*4], SWAP (ctx->A));
+  set_uint32(&resbuf[1*4], SWAP (ctx->B));
+  set_uint32(&resbuf[2*4], SWAP (ctx->C));
+  set_uint32(&resbuf[3*4], SWAP (ctx->D));
+  set_uint32(&resbuf[4*4], SWAP (ctx->E));
 
   return resbuf;
 }

----- End forwarded message -----