1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2017-05-20T17:53:29Z"
content="""
So the problem comes from the hash
"cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e",
-- if that's intended to be a `Maybe Hash` that's the hash of a `ByteString`,
we can't tell if it was produced by hashing `Nothing`, or hashing
`Just (mempty :: ByteString)`
Double hashing would avoid this ambiguity, but it does also break backwards
compatability of the debug-me protocol and logs. It's still early enough to
perhaps do that without a great deal of bother, but it's not desirable.
debug-me does not appear to be actually affected by this currently. The only
`Maybe Hash` in debug-me is used for a hash of values of type `Activity`
and `Entered`, not the hash of a `ByteString`. So, as far as the debug-me
protocol goes, the above hash value is unambiguously the hash of `Nothing`;
there's no `Activity` or `Entered` that hashes to that value.
(Barring of course, a cryptographic hash collision which would need SHA2
to be broken to be exploited.)
So, I'd like to clean this up, to avoid any problems creeping in if
a `Maybe Hash` got used for the hash of a `ByteString`. But, I don't feel
it's worth breaking backwards compatibility for.
(I tried adding a phantom type to Hash, so the instance could be only
for `Maybe (Hash Activity)`, but quickly ran into several complications.)
What I've done is fixed the instance to work like you suggested,
but kept the old function as `hashOfMaybeUnsafe` and used it where
necessary. This way, anything new will use the fixed instance and we don't
break back-compat.
"""]]
|
