Daiki Ueno <ueno@gnu.org> writes:

> Łukasz Stelmach <stlman@poczta.fm> writes:
>
>>>> +	    (string-match
>>>> +	     "^\\(0x\\)?[[:xdigit:]]\\{8\\}\\([[:xdigit:]]\\{8\\}\\)?$"
>>>> +	     recipient))
>>>
>>> I think this can be simplified to:
>>>
>>> (not (string-match "\\`<" recipient))
>>>
>>> since all the mml2015-epg-* functions normalize recipient addresses in
>>> the form of "<foo@bar>", so they only match email addresses.
>>
>> Indeed, however I still think we should check this the hard way: return
>> t if and *only* if it is a key-id. The simpler check *might* result in
>> information disclosure if a message is encrypted to a revoked uid.
>
> Sorry, I don't quite understand here.  What's the senario you are
> thinking of?  I think the only case RECIPIENT doesn't start with "<" is,
> a user sets mml2015-signers manually.  How does it cause information
> disclosure?

It should not be a problem in case of mml2015-signers (I have analysed
this case thoroughly). However, I don't like mml2015-signers work now,
an have some ideas (and even some code) to improve it. What I mean, here
is a rather hypothetical case when someone writes some code forgetting
about your assumption of normalisation. We can say: "let the guy shoot
his own foot", but I think we shouldn't. We should rather follow the
logic: assume key-id is a correct uid. In such case we should check the
input for *being* the key-id rather than not being an e-mail address.

I am not a security expert but this seems more security-wise correct and
future proof to me.

-- 
Miłego dnia,
Łukasz Stelmach