[Cryptography] how reliably do audits spot backdoors?

ianG iang at iang.org
Sun Dec 29 16:07:22 EST 2013


On 28/12/13 22:21 PM, Jerry Leichter wrote:
> On Dec 28, 2013, at 5:04 AM, James A. Donald wrote:
>> Modern C++ has some tools that substantially automate memory management and  type management, but you still have to think about memory management, while Java does it all for you.
> It really depends on what you're doing.  Java only *appears* to do it all for you; while you can't get the traditional memory leak (memory to which no accessible pointers exist), you can easily build up piles of guck that's pointed to by hash table entries you forgot to clean up, for example.

OK, knew that one...

> And the GC doesn't help you with non-memory resources.  This is where destructors, if used carefully, can really pay off in C++:  You can guarantee ....

> You can't do that in Java - you're left telling users they *must* call close() before they stop using function, which they forget to do - unless they remember to use a try/finally, which has an annoying scope definition requiring yet more restructuring of the code.


Blech.  This thread has been the bane of my last 36 hours.  On reading 
that above revelation, I scanned my code for close() calls ... and found 
pathetic results.  Hmmm...

> The new "try-with-resources" syntax *finally* improved the story here - it's new to Java 7 - but it still has its limitations.)

Worse, it's not worth fixing it all until Java 7 is available across all 
platforms.  Sigh.

Does C# have this problem?

And, what actually happens if the close() isn't called?

And, why didn't I know this before?  What other secrets?  And and and...


iang, blurrr...


More information about the cryptography mailing list