Go back to the original counter-intuitive definition of is_me, which is used in
many places which apparently depend on its behaviour. Only leave a comment
explaining the dangers of it.
This change is likely to weaken the fix for
#170 . Preventing
the user from calling encrypt_message with a non-own From is a burden on
applications, which I dislike. I made p-m-t very defensive in this sense
because I knew the problem, but other application writers may be lax and
therefore fall into #170. The current checks based on the counter-intuitive
is_me might not cover every possible case.
timegm_with_gmtoff: do not read again from the struct that timegm has just
overwritten: since we worked on a copy we still have the original to read from.
I have some difficulty understanding why timegm modifies the struct it receives
in the first place; however who wrote the original code in timegm_with_gmtoff
clearly knew or noticed, since the code first copies the struct, then passes
a pointer to the copy. However, by mistake, the copy is read again after the
Easy fix, resolving a quite enigmatic bug:
...even if that semantics is very ugly and error-prone. In practice we want
is_me to return true when the identity is *known* to be own, false when it it
*not known* to be own, while also accepting very incomplete identities; for
example with a user id but no address.
A lot of existing code in the Engine seems to be relying on this lax behaviour,
therefore I am restoring it, and documenting it in a comment.