[Cryptography-dev] Landing AES

[Alex Gaynor]

Sure, but the problem is triggering errors in the first place in the tests.

Alex


On Sat, Aug 31, 2013 at 4:16 AM, Vladimir Diaz <vladimir.v.diaz at gmail.com>wrote:

>
>
>
> On Sat, Aug 31, 2013 at 1:47 AM, Alex Gaynor <alex.gaynor at gmail.com>wrote:
>
>> So I gave up on trying to test the paths, until we know how they're
>> supposed to fail, I just made them asserts, this way errors do not pass
>> silently, and we have coverage (this is particularly important since we'd
>> further have untested code for figuring out what the current openssl error
>> is).
>>
>
> Might OpenSSL's ERR_get_error() and ERR_GET_REASON() help in figuring out
> what the current OpenSSL error is?
>
> http://www.openssl.org/docs/crypto/ERR_get_error.html
> http://www.openssl.org/docs/crypto/ERR_GET_LIB.html
>
>
>>
>> We still need an answer to "change the API" vs. init on first method.
>> Anyone have strong opinions?
>>
>> Alex
>>
>>
>> On Tue, Aug 27, 2013 at 5:53 AM, Donald Stufft <donald at stufft.io> wrote:
>>
>>>
>>> On Aug 27, 2013, at 8:50 AM, Hynek Schlawack <hs at ox.cx> wrote:
>>>
>>>
>>> We've slowed a bit in the last week or so. I want to get the AES patch
>>> landed so we can get the momentum back up (
>>> https://github.com/alex/cryptography/pull/28). There's a few
>>> outstanding issues we need to resolve:
>>>
>>> * How the heck do we test error conditions in OpenSSL? OpenSSL is
>>> totally negligent in how we reproduce them. Should we monkeypatching the
>>> cffi functions to return error codes so we can at least test our code paths?
>>>
>>>
>>> That sounds rather sketchy TBH but I don't know the innards of both.
>>>
>>>
>>> I agree on this sounding sketchy but it might be the best way forward.
>>>
>>>
>>> * Since the BlockCipher object doesn't know if it's in encrypt or
>>> decrypt mode until the first call it can't really initialize itself in the
>>> constructor. Is that fine?
>>>
>>>
>>> I see two options:
>>>
>>>  1. Explicit factory methods.
>>>  2. Init on first use.
>>>
>>> I tend to prefer 1., ideally with separate types. I love me some types.
>>>
>>>
>>> I prefer just init on first use, it's currently setup to switch into
>>> decrypt or encrypt modes based on if you call BlockCipher.decrypt() or
>>> BlockCipher.encrypt() first. FWIW Encrypt/Decrypt mode only makes sense for
>>> certain combinations of things, some block ciphers can use the same
>>> operation.
>>>
>>>
>>> —h
>>> _______________________________________________
>>> Cryptography-dev mailing list
>>> Cryptography-dev at python.org
>>> http://mail.python.org/mailman/listinfo/cryptography-dev
>>>
>>>
>>> FWIW there are a few outstanding issues inside the Pull Request comments
>>> as well.
>>>
>>> -----------------
>>> Donald Stufft
>>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
>>> DCFA
>>>
>>>
>>> _______________________________________________
>>> Cryptography-dev mailing list
>>> Cryptography-dev at python.org
>>> http://mail.python.org/mailman/listinfo/cryptography-dev
>>>
>>>
>>
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right
>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: 125F 5C67 DFE9 4084
>>
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> http://mail.python.org/mailman/listinfo/cryptography-dev
>>
>>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> http://mail.python.org/mailman/listinfo/cryptography-dev
>
>


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20130831/c8f79a75/attachment.html>