Not only did I get to work all day while the upgrade was downloading, only having to reboot at the very end, but everything worked as I expected when I rebooted – which is to say that the only thing which didn’t work was VMWare, which I expected to not work as with every kernel upgrade.  I might even take this as an opportunity to give Virtualbox a proper try (it was less than amazing last time I did).

Let me make that really clear – I only had about twenty minutes of downtime for the entire upgrade, and it would have been less if the installer had left upgrading Firefox until the end, as that was the only thing which broke (and even then, only partly – no new urls, but clicking through links was fine) while the upgrade was going on.  Try that with Windows :)

Things feel just a little snappier, just a little shinier.  I’m really impressed so far.  The new theme and icon set is lovely.

If you’ve been putting off trying out Ubuntu or Linux in general, now’s a great time to start!

English Bread Sauce

Ingredients

• 10-15 cloves
• 1 medium onion
• 3 cups milk
• 1 tsp salt
• 1-2 cups bread crumbs (the ones you can get pre-made at the grocery store work, but bakery ones are better :) )
• butter

Directions

• Stick the cloves in the onion.
• Add onion to milk in a saucepan.
• Simmer for about one hour on low heat, so that milk is infused with the onion-clove flavour. Do not boil.
• Remove onion and discard.
• Add salt and about 1 cup bread crumbs, and simmer over low heat.  Again, do not  boil.
• The crumbs will swell up, and the sauce should have a thick consistency. If it is too runny after simmering for a few minutes, add some more bread crumbs.

Serve with turkey, ideally with more bread crumbs, these ones fried in butter.  About a half cup should be enough – use whatever you have left.

-!- zfe [n=Gianluca@88.252.29.47] has joined #ubuntu-women
<zfe> is this the kitchen?
<zfe> who would make me a sammich?
<redacted> zfe: No this is not the kitchen
<zfe> aren’t you women?
<redacted> zfe: you are welcome to go into your own kitchen and make yourself a sandwich.
<redacted> zfe: please read the channel guidelines in the topic
-!- mode/#ubuntu-women [+o hypa7ia] by ChanServ
<zfe> ok i will while you make me a sammich
-!- mode/#ubuntu-women [+b *!*=Gianluca@88.252.29.*] by hypa7ia
-!- zfe was kicked from #ubuntu-women by hypa7ia [http://xkcd.com/322]

Nicknames redacted to protect the innocent.

3D printing is so amazing. This is the MITS Altair of a DIY revolution whose shape I’m not at all certain of. I couldn’t be more exited to see what the hacklabbers make and how we improve the machine, too.

In alphabetical order, the donors were:

3ric Johanson
Alex Leitch
Byron Sonne
Chad Mounteny
Cheryl Mok
Chris Pilkington
Dale Babiy
Dan Kaminsky
Eric from NYC Resistor
Kate Raynes-Goldie
Sergio Martns
Seth Hardy

Welcome to the future, folks.

-Leigh

-Leigh

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.

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:

• The Arduino homepage is probably a good place to start.
• LadyAda has awesome projects.
• MakeZine posts new things all the time.
• The High-Low Tech group at MIT, where Leah Buechley (creator of the Lilypad) is a professor, has really inspirational work.
• My bookmarks for Gr8 Girls have some more random projects.

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

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.

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:

• SANS says to have good, visible security contact info
• Some more web app hacking learning resources from RSnake

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