I think that what we should do is look at the errors it can raise when we
add support for this library.   Errors we understand and can give good
feedback on, we should do so.   For things that we aren't expecting, we can
raise something generic.

So, if we expect they may enter the wrong password, we should do something
sane in this case.   Same for an invalid key.


On Tue, Oct 1, 2013 at 9:33 AM, Vladimir Diaz <notifications@github.com>wrote:

> In tuf/repo/keystore.py:
>
> > @@ -583,7 +609,11 @@ def _encrypt(key_data, derived_key_information):
> >    # repetitions are performed by AES, 14 cycles for 256-bit keys.
> >    try:
> >      ciphertext = aes_cipher.encrypt(key_data)
> > -  except:
> > +
> > +  # Raise generic exception message to avoid revealing sensitive information,
> > +  # such as invalid passwords, encryption keys, etc., that an attacker can use
> > +  # to his advantage.
> > +  except Exception, e:
>
> Should I propagate exceptions from PyCrypto, nacl, etc. so the error
> messages are more detailed or add the detail to my generic message?
>
> I want to suppress exceptions from any libraries we use that I cannot
> predict. I can just let them through if it doesn't matter too much here.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/theupdateframework/tuf/pull/124/files#r6686011>
> .
>