Context managers in python --verbose

Context manager is a piece of code that wraps around another block of code, creating a local run time context for that block. A context type is an object with two methods .__entry__() and .__exit__(exc_type, exc_val, exc_tb). Basically these two methods define the setup and tear down of the state. This state is insulated from outer scopes and context managers are used to execute code inside this 'sandbox' environment to prevent any changes to outer namespaces. Context managers are also useful when refactoring code. If you have code that follows a similar pattern where you need to preform some form of setup and tear down each time, then you can abstract that into a context manager.
Context manager types are often used with the 'with' statement to wrap code. The with statement executes .__exit__() callable of the context type and assigns the return value to the 'as' target (if any). When the wrapped code finishes execution, the .__exit__(exc_type, exc_value, exc_tb) is called. This code performs clean up and handles any exceptions that were raised. To be more precise, the return type of this callable is a boolean, true to signal that all exceptions raised will be suppressed (either during the execution of the block statement or the execution of the __exit__()) or False to indicate that exceptions should propagate further.

Python Decorators

A word about decorators in Python. A 'decorators' is a piece of code that modifies other code (often refered to as metaprogramming). There are two types of decorators: a function and a class decorators, modifying functions and classes respectively. Decorators take in a callable type and return a callable type. Lets restrict our attention to the following subset of callable types: user defined functions, builtin function and generator functions. Functions, like everything else in Python, is an object. The most simple decorator may take a user defined function as input and add an extra attribute to this function, returning this new version. In this case, the action of the underlying callable object does not change, we simply use the decorator to attach more information to it. A more complicated example of a decorator is one that changes the action of the 'decorated' callable, returning a new modified callable with different behaviour. An example of a decorator is the property builtin that was introduced in class. This function 'decorates' variables allowing to modify/restrict access, change doc strings etc. Note that variables are also objects, instances of more 'fundamental' classes such as int, float etc and these themselves are instances of a factory object 'type'. Factory as in a sense that this object assembles/creates 'fundamental' classes.

Adobe data leak

Several days ago major news organizations picked up the story of the adobe data leak. Adobe released a security notice on Oct 3 notifying its customers that their data has been stolen. According to the security notice, 2.9 customers were affected; however, 38 million users were notified and it is believed that as much as 150 million passwords were stolen. Stolen data consisted of emails, encrypted passwords and plaintext hints (user hints to remind themselves of their password in case they forget it). Adobe claimed that all confidential data that was lost was encrypted. Recent analysis by Paul Ducklin seems to indicate that stolen data was not salted or hashed. Worse, it appears that the passwords were encrypted using a single key. In other words, if someone gets the secret key then they would have be able to decrypt every single password. The discussion around this story comes down to how badly Adobe mismanaged user passwords (using block cypher instead of hash and salt combination) and the sheer scale of this breach. I would like to mention my take on this story. If a significant amount of passwords are recovered than this event has the potential to have the scale and magnitude of 2009 rockyou.com leak. In other words, this could be a giant data sample that could be used to refine and improve password crackers. Password crackers don't simply brute force passwords, but they exploit the common features of passwords (ie substituting numbers for letters, appending number to words). In other words, crackers look for common patterns in passwords and write algorithms that exploit those patterns, significantly reducing the time needed to break/crack passwords. This leak could be a potential gold mine for passwords. Sure most of these (even all) have been changed but understanding common themes in how people chose passwords may be a lot more valuable then the initial breach.