We'll see | Matt Zimmerman

a potpourri of mirth and madness

Posts Tagged ‘Technology

Decoding a .mobileconfig file containing a Cisco IPsec VPN configuration

When someone wants to give you access to a Cisco VPN, they might give you a .mobileconfig file. This is apparently used by MacOS and iOS to encapsulate the configuration parameters needed to connect to a VPN. You should be able to connect to it with open source software (such as NetworkManager and vpnc) as long as you have the right configuration. Some helpful soul has tried to give you that configuration, but it’s wrapped up in an Apple-specific container. Here’s how you rip it open and get the goodies.

File format

A .mobileconfig appears to contain:

  1. Some binary garbage which is safe to ignore
  2. An XML document containing the good bits, i.e.:
    1. The “local identifier” (i.e. IPsec group name)
    2. The “remote address” (i.e. IPsec gateway host)
    3. The shared secret (base64 encoded)
  3. Some more binary garbage which is safe to ignore

…and it looks like this:

<plist version="1.0">
<dict>
  <key>PayloadContent</key>
  <array>
    <dict>
      <key>IPSec</key>
      <dict>
        <key>AuthenticationMethod</key>
        <string>SharedSecret</string>
        <key>LocalIdentifier</key>
        <string>LOCAL_IDENTIFIER_HERE</string>
        <key>LocalIdentifierType</key>
        <string>KeyID</string>
        <key>RemoteAddress</key>
        <string>REMOTE_ADDRESS_HERE</string>
        <key>SharedSecret</key>
        <data>
        BASE64_ENCODED_SHARED_SECRET_HERE
        </data>
      </dict>
      <key>IPv4</key>
      <dict>
        <key>OverridePrimary</key>
        <integer>0</integer>
      </dict>
      <key>PayloadDescription</key>
      <string>...</string>
      <key>PayloadDisplayName</key>
      <string>...</string>
      <key>PayloadIdentifier</key>
      <string>...</string>
      <key>PayloadOrganization</key>
      <string>...</string>
      <key>PayloadType</key>
      <string>com.apple.vpn.managed</string>
      <key>PayloadUUID</key>
      <string>...</string>
      <key>PayloadVersion</key>
      <integer>1</integer>
      <key>Proxies</key>
      <dict>
        <key>HTTPEnable</key>
        <integer>0</integer>
        <key>HTTPSEnable</key>
        <integer>0</integer>
        <key>ProxyAutoConfigEnable</key>
        <integer>0</integer>
        <key>ProxyAutoDiscoveryEnable</key>
        <integer>0</integer>
      </dict>
      <key>UserDefinedName</key>
      <string>...</string>
      <key>VPNType</key>
      <string>IPSec</string>
    </dict>
  </array>
  <key>PayloadDescription</key>
  <string>...</string>
  <key>PayloadDisplayName</key>
  <string>...</string>
  <key>PayloadIdentifier</key>
  <string>...</string>
  <key>PayloadOrganization</key>
  <string>...</string>
  <key>PayloadRemovalDisallowed</key>
  <false/>
  <key>PayloadType</key>
  <string>Configuration</string>
  <key>PayloadUUID</key>
  <string>...</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
</dict>
</plist>

The shared secret is base64-encoded, so you can decode it with:

$ echo -n 'BASE64_ENCODED_SECRET_HERE' | base64 -d

Network Manager configuration

  1. Make sure you have network-manager-vpnc installed
  2. Click the Network Manager icon, select “VPN Connections”, “Configure VPN…”
  3. Create a “Cisco-compatible (vpnc)” connection

    Create a “Cisco-compatible (vpnc)” VPN connection

  4. Configure the connection settings as follows:

    Configure the connection settings

    • Enter the “remote address” in the “Gateway” field
    • Enter the “local identifier” in the “Group name” field
    • Enter the shared secret in the “Group password” field
  5. To connect, click the Network Manager icon, select “VPN Connections”, and select the connection you just configured

Good luck and enjoy!

Advertisements

Written by Matt Zimmerman

November 15, 2012 at 18:29

Building a personal data locker

If you were building a digital container to store your personal data, what would it look like?

Personal data being information associated with you: your contacts, your photos, the web pages you’ve visited, the places you’ve been, the messages you’ve sent and received, and so on. In short, your stuff.

Here’s my personal wish list of technical requirements:

  • It has to be made of free software, of course
  • It must keep my data secure, while allowing me to share it when and how I want to
  • It needs to handle a range of different data types natively, and be extensible to new types, from photos to real-time sensor data
  • It should be able to collect my data from many different places where it is being created and stored
  • It should have a rich API, so that I can create applications which access my data
  • If I want to, I should be able to host it myself, on my own hardware, without compromising my ability to access and share it

Of course, this isn’t merely an academic exercise, as my new day job at Singly is about building exactly this type of system. With a technical team including Jeremie Miller of Jabber and XMPP fame, our goal is to develop a personal data platform which meets these criteria and more.

There’s a lot of work to do, but today, you can check out the code and run a locker of your own, which can sync in data from Facebook, Twitter, Google, Foursquare, Github and dozens of other services. It’s a bit of a bear to set up, particularly if you don’t already have API keys for these services, but that’s fairly normal at this early stage of development.

If you try it, or have thoughts about what we’re doing, please let me know in the comments.

Written by Matt Zimmerman

August 15, 2011 at 16:00

Where’s your data center?

Thanks to the tremendous growth of “social” applications over the past five years, we have our pick of services for collecting, saving and sharing our experiences online. We each have collections of photos, contacts, messages and more, spread across multiple popular services like Twitter, Facebook, LinkedIn, as well as many less popular services which address particular needs or preferences. We’re also producing a wealth of “exhaust data” through our browsing history, mobile sensors, transactions and other activity streams that we rarely if ever examine directly.

This ecosystem is becoming so complex that it’s easy to lose track of what you’ve created, shared or seen. We need new tools to manage this complexity, to make the most of the wealth of information and connections available to us through various services. John Battelle calls these “metaservices”, and points to growth in the number of connections between the services we use.

I expect that this next age of information tools will center around data rather than services. Data is a common denominator for these online experiences, a bridge across disparate services, technologies, social graphs, and life cycles. Personal data, in particular, has this property: the only thing that links together your photos on Flickr, Facebook, Picasa and Twitpic is…you.

So where’s your “data center”? I don’t anticipate the emergence of a single service where you do everything. There will continue to be innovation in the form of new and specialized services which meet a particular need very well. There won’t be a single service which is everything to everybody.

Instead, I foresee us wanting to track, save, use and control all of our “stuff” across the web. That’s why my new colleagues and I are working to make that possible.

There’s open source code available on github, a vibrant IRC channel (#lockerproject on Freeenode), and lots more I’d like to write about it. But it’s time to get back to work for now…

Written by Matt Zimmerman

August 9, 2011 at 15:53

DEX finishes first batch of derivative patches for Debian

It’s been a few months since Zack and I announced the DEX project, which aims to improve the Debian ecosystem by working jointly with derivative distributions.

Our first milestone

The goal of our first project, nicknamed ancient-patches, was to clear out an old batch of a few hundred Ubuntu patches whose status was unclear. We couldn’t tell which ones had been merged into Debian, which were waiting in the BTS, and which had yet to be submitted to Debian. All of them were several years old.

I’m pleased to announce that this project is now complete. Thanks to help from David Paleino, Colin Watson, Nathan Handler and Steve Langasek, we were able to clear over 95% of the patches in a matter of days. These were the easy ones: patches which were obsolete, or had already been applied. We discussed the remainder, and resolved all of the patches whose status was still unclear. This left the harder ones: patches stalled in the BTS, and patches where there was no consensus about what to do with them.

One of the stalled patches was merged into Debian via an NMU, eliminating the delta between Debian and Ubuntu. Another had been submitted to Debian by a third party, but was no longer shipping in Ubuntu, so we considered it obsolete for purposes of this project.

This has left only two patches out of the original list of 277. Both of them are filed in the BTS and have been discussed with the relevant maintainer team. One of them is expected to be obsoleted when a new upstream version is packaged, which implements similar functionality. The other is being discussed with the upstream developers, but there is no conclusion yet about whether it can be merged upstream or in Debian.

Conclusions

Although we weren’t quite able to clear the whole list, we still consider the project to be a success because:

  • We ensured that all of the patches received due consideration for inclusion in Debian
  • We proved the concept of DEX, with developers from Debian and derivatives cooperating on a common goal and sharing tools
  • Most importantly, we learned from the experience

What’s next

In the most recent DEX update on debian-derivatives, I highlighted a few important events for DEX:

  • Our second major project, nicknamed “big-merges”, will begin soon. Our goal is to identify the few packages which are most diverged between Debian and Ubuntu, and work to get them as close to identical as possible. If you have suggestions for packages to focus on, let us know!
  • Allison Randal is beginning a DEX project to implement the Python 2.7 transition across Debian and Ubuntu
  • Nathan Handler is working on a Summer of Code project to develop specialized tools to help with this kind of cross-distribution teamwork
  • Zack is organizing a derivatives BoF at DebConf 11

We’re looking forward to seeing DEX develop further. If you’d like to get involved, come and join us on the debian-derivatives mailing list or IRC (#debian-derivatives on freenodeOFTC).

Matt Zimmerman and Stefano Zacchiroli

Written by Matt Zimmerman

June 8, 2011 at 14:21

Why I’m excited about joining Singly

This summer, I’ll be taking a bit of time off, moving back to San Francisco and starting a new job. I can’t wait to get back to work. Here’s why.

Me and my data


I have a singular relationship with my data. I have a copy of every email I’ve sent since I first got an Internet email address in 1994 (82,000 messages and counting). I have even older files downloaded from BBSes, and passed between friends on floppy disks. Chat logs, text messages, voicemail…I hold onto them all. Anything which is relevant to me personally, I tend to save.

This must seem banal to people who are first getting online today. In the age of Gmail and Flickr, it’s easy to assume that all of your data will be preserved indefinitely, with little or no effort on your part. But for me, it has been hard work over the years, because I’ve done it myself. I’ve carried my data with me to countless new computers, operating systems, storage technologies, file formats and cities over the years. Everywhere I’ve lived, I’ve brought it with me. Physically.

Really?

Why do I do this? Why have I gone to such trouble for a collection of bits? Especially now, why is most of my data still at home?

One pragmatic answer is that I can simply do more with my data when I have a copy. I can work with it using any software I want, including software that I write myself. I don’t have to worry about whether I can transfer it from one web service to another. I’m never stuck using yesterday’s services because my data is never trapped in them. My personal data is always available to me me, always raw, ready and waiting for the next wave of software to come along. When it does, I can load my data into it and keep going. The fact that Facebook and Google disagree over sharing their users’ data doesn’t bother me in the least.

Another reason is that I want to be in control of it. I decide who to share my data with, and when. Some of it, I prefer not to share at all, with any person or company, and I have that choice. Even if a powerful government wants to access my data, I am afforded certain protection under the law, at least in the countries where I’ve lived. If I turned over my data to service providers, my choices and protection would likely be much more limited.

I have a deeper emotional attachment to my data as well. Enfolded within that vast pattern of bits is some part of my self. By sharing my personal data with other people, I show them something of who I am. Increasingly, my personal data is part of my identity. This is more than just a state of mind: it’s been shown that even our “non-identifying” personal data can reveal who we are.

In other words, it’s not just “my data”—it’s me data”.

Singly

I’m joining Singly because I want to take this concept much further, and combine people, data and software into a different shape with people at the center.

Today, we are creating vastly greater amounts of personal data, and it’s stored in many more places. We leave our trail on the Internet in the form of activity streams, messages and content, spread across different web sites, each with their own inscrutable terms of service and (if we’re lucky) their own API. These disconnected silos prevent us from using all of this information effectively.

Meanwhile, we want—and need—to connect with each other in more ways than ever before. We need applications which can connect us, through our personal data, to the services we need.

Singly is building the technology to make this possible. It will be designed with the deepest respect for the relationship that we have with our personal data, and with a vision for truly personal computing.

Singly is…

  • A team of passionate people, dedicated to a vision for personal data
  • Building an open source data locker, which aggregates and stores your personal data from around the web and ensures that it’s always available to you
  • Enabling developers to create powerful distributed applications based on this data, without having to deal with the complexity of multiple web services APIs
  • Providing secure hosting services for personal data lockers
  • Hiring! We’re looking for people with deep experience in security and cryptography, cloud infrastructure and user experience, as well as software engineering generalists

This opportunity is a great fit for my interests and experience. Singly aims to be the commercial part of a vibrant open source community, and I’m looking forward to building on what I’ve learned in Debian, Canonical and Ubuntu to help make it a success.

I’ll have lots more to say about it as time goes on. Meanwhile, if you’re interested in following what we’re doing, here’s where:

Written by Matt Zimmerman

May 27, 2011 at 17:13

DEX: Debian and its derivatives, getting things done together

Since I resumed active status in Debian, I’ve been thinking about how to bridge the gap between Debian and its derivatives*. I’ve spoken at length with Zack, the attendees of the Derivatives BoF at DebConf 10, and the fine folks at the Derivatives Front Desk about the technical and social issues affecting derivative projects, and could probably write a very thorough series of blog posts on the subject.

Instead, Zack and I decided to try doing something about it: we have begun a project to test out a new approach to the problem.

Introducing DEX

DEX is all about action: merging patches, fixing bugs, crunching data, whatever is necessary to get changes from derivatives into Debian proper. DEX doesn’t try to change the way any existing project works, but adds a “fast path” for getting code from one place to another.

DEX is a joint task force where developers from Debian and its derivatives work together on this common goal. As a pilot project, we’ve established an Ubuntu DEX Team focused on merging code from Ubuntu into Debian. With members from both projects, we hope to be able to resolve blockage anywhere in the pipeline. Whatever needs to get done in order to merge an Ubuntu patch, someone in the Ubuntu DEX team will know what to do. If we get good results with Ubuntu, we hope that other derivatives will follow. With thanks to David Paleino, we’re excited that the Utnubu project is merging into DEX as it aligns well with their goals. I’m very grateful to have Colin Watson and James Westby signed up to contribute as well.

Our first project is simple: turn this list green. This is an archive of quite old patches from Ubuntu, most of which have probably been merged already or made obsolete, but they pre-date any kind of tracking system so they need to be verified. Once that’s done, we’ll move on to a new project with a new todo list.

If you want to see Debian benefit from technical work done in derivatives, DEX is a chance for you to act together to make it happen. If you work on a derivative and want to carry a smaller delta, come and join us. I’m sure we’ll learn a lot from this experience.

* There are many instances of great cooperation between Debian and derivative distributions, including joint package maintenance teams, and some derivatives are even part of the Debian project. Nonetheless, there are areas were most people I’ve spoken to agree that we need to do better. This is what I’ve referred to as the “gap”.

Written by Matt Zimmerman

March 16, 2011 at 21:30

Listening to users

In the software community, people hold strong opinions on the subject of listening to users. Some feel that users are an essential source of information for making successful products, as evidenced in the customer development methodology, and seek to involve users deeply in product development. Others believe that users don’t know what they want, invoking the quote attributed to Henry Ford, “If I’d asked customers what they wanted, they would have said ‘a faster horse'”. Some say that user needs are unknowable except through the lens of a marketplace, where people choose in aggregate which products suit them best, and customers “vote with their wallets” (anything else is “anecdata”).

Regular readers will not be surprised that I believe they are all right, but only in certain contexts. The right strategy for involving users in product decisions will depend on factors related to the product itself, the market, and the product development method being used.

One of the most important is the life cycle stage of the product: is it a new and rapidly evolving concept, or a mature commodity, or somewhere in between? Simon Wardley explains this well over on his blog, so I won’t rehash his points here, but will add a few of my own.

If what we’re looking for is inspiration for a new product, it’s here that Henry Ford was right: users generally won’t hand you a complete product vision on a silver platter. They’ll frame their input in terms of what they know, and the choices already available to them. However, this doesn’t mean that users don’t have a role to play in this instance: watching users can be a great source of inspiration. It’s the combination of domain knowledge and passionate imagination which triggers the creative spark. Henry Ford applied his engineer’s interests to a problem which was evident all around him.

If our goal is to test whether a new product is a good fit for its users, there is no substitute for user feedback. We can guess at whether there is a fit, and our intuition may be good, but users are the ultimate judges, and we don’t know if we’re right or wrong until users evaluate it. So ask them! By engaging in dialogue with individual users, we can learn unexpected things which will help to refine the idea. If we don’t find what they think until our new product is released, we risk making something that no one wants. Why wait until it’s too late? It can be challenging to extract useful feedback for a product which doesn’t yet exist, but this effort is well worth it to avoid wasting much more effort in software engineering.

When our objective is to incrementally improve an existing product, individual anecdotes can mislead us. A given change may be an improvement for one user, but a disaster for another. What we want to know is whether the new version is better for the population as a whole, and in this case, we do well to rely on data. There are pitfalls here as well, of course. We need to choose our questions carefully, and realize that users will often resist any change: not because they’re stodgy by nature, but because they have to invest effort in adapting to the change. I think of incremental improvement as a joint investment made between product developers and their users, to improve the whole system of people and technology for the better.

By choosing the right tool for the job, we can make better decisions, improve faster, and ultimately solve the right problem for our users.

Written by Matt Zimmerman

March 7, 2011 at 12:56