Your SlideShare is downloading. ×
Kiwipycon command line
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Kiwipycon command line


Published on

My talk at KiwiPyCon 2011 about securely giving your website a command line API

My talk at KiwiPyCon 2011 about securely giving your website a command line API

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Giving your website a command line interface
    Michael Hudson-Doyle
  • 2. Linaro and its mission
    Linaro aims to make Linux work better on ARM processors
  • 3. The Problem
    The ARM ecosystem is very fragmented, and the kernel has a lot of copy and paste code
    "Gaah. Guys, this whole ARM thing is a f*cking pain in the ass."
    — Linus Torvalds, 17 Mar 2011
  • 4. Enter Linaro!
    "Linaro is a not-for-profit software engineering company investing in core Linux software and tools for ARM SoCs."
    Also about educating the members in how to do open source development...
  • 5. LAVA - Linaro Automated Validation
    A bit part of Linaro is about automated validation:
    • Find regressions earlier
    • 6. Also benchmark toolchain improvements
    • 7. Maybe even power management changes too...
  • LAVA
    We have a bunch of hardware
  • 8. LAVA
    Some scripts and tricks that can boot a board with a new kernel and run some tests.
    Quick Demo
    (ever the optimist)
  • 9. LAVA
    And a website that lets you see whats going on
  • 10. The Problem (finally!)
    We want to do things like trigger test runs when a kernel build finishes.
    This basically means some kind of Remote Procedure Call (RPC).
  • 11. Paranoia
    For a bunch of reasons, we need some kind of security in our system:
    • The boards in our lab are a limited resource
    • 12. Some risk of mischief
    • 13. Eventually may have test results from unreleased hardware or benchmarks with licenses that forbid publication of results
  • Protocol Choices
    • We use XML-RPC
    • 14. We didn't think about this very hard but it is well supported in most languages
    • 15. Will probably add JSON-RPC support at some point for easier browser access
  • First idea: OAuth
    An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.
  • 16. The great thing about standards...
    <bob2> kennethreitz: oauth
    is a font of villany
    and dispair
    -- #python, Jun 09 11:55:08
  • 17. Also doesn't solve our problem
    OAuth specifies that various aspects of the request are signed, but not, crucially for us, the body of the request – an important detail, because in XML-RPC the body of the request is where all the important stuff is.
  • 18. Transport Layer Security, here we come
    If you're going as far as to cryptographically sign something, it's not much further to go to actually just encrypt it!
  • 19. And what does everyone know about encryption?
    Don't implement it yourself
    (i.e. use HTTPS)
  • 20. Back to Basic
    And if you're operating over HTTPS, you might as well just just good old RFC 2617 Basic Authentication...
    ... but with tokens rather than passwords
  • 21. Tokens > Passwords
    Because we expect the RPC to be invoked from build systems and so on, there is a moderate chance of the token being leaked – so it should not let you take over the owning user's account.
    In the future, a token might only let you access some APIs.
  • 22. Also, we use SSO...
    In addition we use Launchpad's SSO service for authentication, so most users don't have a LAVA password!
  • 23. Show me the code!
    On the server side, we've built a library that lets you add a authenticating XML-RPC to a Django project:
    It includes views and models (and very very simple templates) for creating and managing tokens.
  • 24. Server side code
    from linaro_django_xmlrpc.models import ExposedAPI
    from linaro_django_xmlrpc.globals import mapper
    class ExampleAPI(ExposedAPI):
    def whoami(self):
    if self.user:
    return self.user.username
    return None
    in your urlconf:
    url(r'', include('linaro_django_xmlrpc.urls')),
  • 25. Client side library
    This isn't properly factored yet really (it's it all mashed up with our toolkit for doing command line tools), but the code is in "lava-tool":
    It uses python-keyring for token management.
  • 26. Client-side code
    from lava_tool.authtoken import
    AuthenticatingServerProxy, KeyringAuthBackend
    auth_backend = KeyringAuthBackend()
    "user", "http://server/RPC2/", token)
    sp = AuthenticatingServerProxy(
    print server.whoami()
  • 27. Demo
    (assuming the first one wasn't a disaster)
  • 28. Conclusion
    The lesson:
    Don't try to be clever – just use HTTPS and Basic auth.
    The code:
  • 29. Thanks for listening!
    Any Questions?