nthmost.comnthmost » About

naomi theora most Home About The Resume Community Projects and Promotions Above Portfolio DocPop dot org Ephemerisle dot org RadioValencia dot fm My Performance Reviews Subscribe Posts Comment ClinVar / Genetic Testing Registry Data Exploration Tags: data , genetics , python Tweet A few months back I decided to do a basic data investigation of how two genomic health related NIH databases — ClinVar (the Clinical Variation Database) and GTR (the Genetic Testing Registry) — relate to each other. The basic question I wanted to explore was the following: Of the genetic variants submitted to ClinVar, how well represented in GTR are these gene regions (indicated by gene Symbol in both databases)? In other words: does the number of industry and research tests known in GTR for a particular gene relate at all to the number of variants that have been submitted by researchers as belonging to that particular gene region? You can check out the results, process, and code on my blog devoted to ClinVar / GTR data exploration . Share and Enjoy 03 February 2016 | | hacking , science | No Comment | Read More The Great Noisebridge Reboot of 2014 Tags: noisebridge Tweet Noisebridge is an open-access hackerspace — a priceless community organization and physical space that provides access to free education, tools, equipment, and a great community to boot. A few months ago, we were faced with an electrical safety noticed tinged with the possibility that the city would fine us or even shut us down. We had to act quickly. I have been with Noisebridge since early 2009, having become a full Member in August 2009. I owe this crazy hackerspace a great deal for what I have going in my life right now — from regaining confidence in my technical skills after a long hiatus, to helping me with the near-impossible task of finding an apartment in San Francisco — and now I am giving Noisebridge my ALL to keep the dream alive. Countless visitors and members of the space have benefited from Noisebridge, so we are investing incredible amounts of time and money right now to lay down a solid foundation for its future. Real estate prices in San Francisco have soared well above the already-high rates when we moved into our current space in 2009. In the current economic climate, building a new Noisebridge from scratch would be extremely difficult, if not impossible. We recruited the help of two C-10 certified electricians who happen to be Noisebridge fans, Tim and Neil from Electric City SF, who expertly evaluated our space (factoring in that we are hackers and want to do a lot of stuff ourselves!) and gave us a Master Plan For Not Failing Our Inspections [pdf]. But we’re not just going to stop at electrical refits — why waste an opportunity? The sign in front of Noisebridge this month Instead we are turning the crisis of potential city scrutiny into an opportunity to Upgrade the space and Reboot Noisebridge into a better, safer, more robust and versatile hackerspace. After all: when Life gives you Inspections, Make Inspectionade. After we reopen at the end of this month, we have two major events queued up: * August 9th-15th: Class-A-Thon! All kinds of workshops and teaching events all week long (and we still need teachers to sign up — contact me at naomi at dot net if interested) * August 15th: Grand Reopening REBOOT PARTY featuring art, music, performance, and more. Visit the front page of Noisebridge.net for schedule updates, and if you can help us at the space, contact me (Naomi at dot net), and if you can donate money, donate HERE on our IndieGoGo campaign. Stay Excellent! A healthy dose of hackerspace irony. Share and Enjoy 23 July 2014 | | announcement , events , hacking | 1 Comment | Read More using secureconfig with multiple config files Tags: deployment , python , secureconfig , security , systems Tweet I thought perhaps I’d start sharing some of the idioms I’ve developed whilst working with secureconfig — particularly the SecureConfigParser library. Because of ConfigParser’s handy aggregation of `sections` from several config files, one way of making config file management easier is to split off all of the “credentials” and other sensitive data — passwords, api tokens, etc — into a separate config file. Then I encrypt those credentials and (usually) don’t ever have to touch them. But, splitting sensitive data away from other variables may not make organizational sense. You may have different details for “development” and “production” sets of configurations. For my projects, I have standardized to using the “.insecure” extension to indicate an ini config that hasn’t had its sensitive data encrypted yet. This practice helps me avoid accidentally committing credentials to the source repo simply by adding a line like the following to my .hgignore or .gitignore file: *.insecure Having done that, I can use an iPython shell or a short python script to encrypt those variables I want encrypted, and then write it back to the config file: from secureconfig import SecureConfigParser # upon first run, my key doesn't actually exist yet -- I let # SecureConfigParser generate one for me. scfg = SecureConfigParser.from_file('.keys/demo.key') scfg.read('demo.ini.insecure') pwd = scfg.read('credentials', 'password') token = scfg.read('api', 'token') scfg.set('credentials', 'password', pwd, encrypt=True) scfg.set('token', 'token', token, encrypt=True) scfg.write(open('demo.ini', 'w')) But I’m lazy, and I like using Fabric for automated deployment . I want all variables matching certain names — particular “password” and “token” — to be encrypted every time I make a change to any .ini.insecure file. Here’s a function I call via fab protect that does the following — although you can just as easily strip away the Fabric specific stuff for another deployment library: gets a list of all config files with the “insecure” extension reads each config in separately and iterates through every option compares each option against a manually entered list of variable names that should be encrypted uses .set method with encrypt=True to set the specified variables back into the config, encrypted writes config files back into the same directory but without the .insecure extension. from __future__ import print_function import os from fabric.decorators import task from secureconfig import SecureConfigParser KEYPATH_LOCAL = '.keys/super_secret_key' CONFIG_DIR_LOCAL = 'etc/configs' INSECURE_CONFIG_FILES = [x for x in os.listdir(CONFIG_DIR_LOCAL) if x.endswith('insecure')] VARS_TO_PROTECT = ['token', 'password'] @task def protect(keypath=KEYPATH_LOCAL): 'generate safe *.ini files from *.ini.insecure files' for cfgfile in INSECURE_CONFIG_FILES: configpath = os.path.join(CONFIG_DIR_LOCAL, cfgfile) scfg = SecureConfigParser.from_file(keypath) scfg.read(configpath) #'amqp.ini.insecure') for sec in scfg.sections(): for opt in scfg.options(sec): if opt in VARS_TO_PROTECT: val = scfg.get(sec, opt) scfg.set(sec, opt, val, encrypt=True) outpath = configpath.rstrip('insecure')[:-1] print("Writing %s (don't forget to commit changes to the repo!)" % outpath) scfg.write(open(outpath, 'w')) Post here if you have any trouble using this! Share and Enjoy 14 May 2014 | | hacking | 2 Comments | Read More pip install secureconfig Tags: cryptography , idiom , module , python , security , usability Tweet Back in January at Invitae, in response to an internal security audit, I took on the task of coming up with a set of Best Practices For Not Getting Instantly Pwned When Someone Leaves Their Laptop On A Plane Or Something . What I found, in addition to lots of other things, was that the Python world lacked a sturdy, well-constructed module that allowed developers to keep the configuration management idioms many have baked into their code (e.g. ConfigParser and JSON) while keeping sensitive stuff out TL;DR — I found a huge security-usability hole in the Python world, so I patched it, and you can RTFM and try it out here: pip install secureconfig The i...