I think that the comments on this post do a good job of answering the question it asks – “where are the women in Python.” Turns out we’re out there, you just need to keep your eyes open and ask in the right places :)

Comments 2 Comments »

These are the notes and some links for a brief talk I gave a few weeks ago to my classmates in the summer CS project class I’m taking at U of T.  We’re working on the Basie and Markus projects.  Both are web apps; Basie is a software project management app built on Django, and Markus is a CS-specific marking / grading app built on Rails.

The debate over full disclosure goes back hundreds of years in the locksmithing world.  Locksmiths were historically very secretive about weaknesses in their products; interestingly, they still are – here’s an interesting note on the subject from a few years ago.

There’s nuance and detail to the recent history of disclosure practices which Wikipedia does a good treatment of, but it’s fair to say that today there are three broad categories of practices:

  • silent patching (no disclosure) – this is a bad idea for fairly obvious reasons, except (some argue) in edge cases like the Linux kernel (the “every kernel bug is a security bug” argument) (one discussion of this, another)
  • partial disclosure, where one issues the patch before explaining full details of the vulnerability
  • full disclosure, where vulnerability details (and sometimes exploit code) are released at the same time as the patch is issued

Aside from how much is being disclosed, there’s the question of  responsible disclosure on the part of security researchers, which is in a nutshell the idea of giving software vendors a set amount of time to respond to security issues before going public with them.

How to Screw Up Disclosure

  • don’t give credit in your vulnerability advisories
  • don’t even bother publishing advisories (silent patching)
  • be unresponsive
  • demand excessive, unreasonable timeframes for patching (this is of course subjective)
  • make people sign NDAs (!)
  • threaten to sue people

The last two aren’t generally screwups committed by Open Source projects, of course :)
How to do it right – best practices

  • have a clear security contact on your site, no more than a click away from the homepage, and easily googlable with the string “$projectname security”
  • have a gpg key posted, with a good web of trust, for that contact
  • have email to that contact go to an email list with a clear process for dealing with it so that you don’t drop the ball, or have it filed into the bugtracker automagically (in a private bug!!11)
  • have an announce-only security mailing list for your users, and post issues to it ASAP when they come out!  An RSS feed works too.  Do both!
  • ensure that someone in your project monitors lists such as full-disclosure and bugtraq for issues in both your project, upstream frameworks, and your infrastructure.  For just monitoring your project, a Google Alert works well too. “project name + bug or vulnerability or security”.  People sometimes announce vulns without disclosing at all; you want to catch these.
  • if the project ends up getting abandoned at some point in the future, at the very least post a warning that it’s deprecated and unmaintained even for security issues, and possibly take down the code.

Specific Issues for web apps

  • you may have a widely deployed base of users.  An auto-update system such as WordPress’s is awesome for getting them to $%^$&&* patch!
  • the framework you’re building on may have (security) bugs too.
  • your code may be customized by users, which makes them lazy about patching – a good plugin architecture can help mitigate this.

Comments 1 Comment »

I promised the girls in my workshop sessions today that I would post some links to various resources on the Arduino microcontroller and some of the awesome projects I showed off. Here goes!

Places to get Arduinos and other electronic components in Toronto:

  • Creatron has good prices on the Lilypad and regular Arduino, as well as a very friendly and helpful proprietor.  It’s on College just East of Spadina.
  • Honson is just West of Spadina; they have a wider selection of things like LEDs, but don’t stock Arduinos.
  • Active Surplus on Queen West is also worth a look, though their selection of components varies.

Project inspiration, resources, and other links:

I hope everyone has fun learning more about electronics and microcontrollers than what little I talked about in the workshops, and please feel free to email me if you have any questions – my address is leigh (at) hypatia.ca .

-Leigh

Comments No Comments »

U of T has off-campus access to research papers and other resources. This is obviously super useful. There are a couple of ways of logging into their web-based proxy service, and they are all annoying. So I made a bookmarklet:

UTL Proxy

Drag this link to your bookmarks bar, then go to a restricted URL like the one I’m currently reading and click it – you’ll be directed to U of T’s central web login page if you’re not cookied already from something like UTORmail.

Once you’re cookied you’ll be able to do this until your session goes idle.

The javascript is pretty basic, but due credit is owed to the University of Manitoba.

Comments 1 Comment »

Today at the meshU conference I gave a talk about secure programming, with a focus on the web.  There were 2 token slides for the C and C++ devs out there, which ended up working perfectly because there were only two people in the room who wrote C/C++ :)

I mostly touched on stuff from OWASP’s vast collection of resources,specifically their top ten principles of secure programming, and their top ten web application vulnerabilities.  Slides are after the jump, but I wanted to include some related links to things which came up during the talk:

Enjoy the slides!  Slideshare messed up the formatting of the additional notes, so for full effect I’d download them from here.

Read the rest of this entry »

Comments 1 Comment »