diff options
| author | Stef Walter <stefw@redhat.com> | 2014-11-04 11:31:31 +0100 |
|---|---|---|
| committer | Stef Walter <stefw@redhat.com> | 2014-11-04 13:55:32 +0100 |
| commit | 0968f903fe66f9bb8957b8d01e35f3743c74404b (patch) | |
| tree | 5928fbcdf458575c77cbfe8edac12afc7d71b768 | |
| parent | 054fed351b16d608f6ae4b8fd3cf3a38434117bd (diff) | |
Brought old blog over
57 files changed, 1635 insertions, 0 deletions
diff --git a/content/cockpit/cockpit-does-docker.md b/content/cockpit/cockpit-does-docker.md new file mode 100644 index 0000000..ae111a1 --- /dev/null +++ b/content/cockpit/cockpit-does-docker.md @@ -0,0 +1,15 @@ +Title: Cockpit does Docker +Date: 2014-04-25 19:39 +Tags: cockpit, technical +Slug: cockpit-does-docker + +Here's a short video showing how Cockpit manages Docker containers. +Cockpit is in RHEL branding here, but it's basically the same thing as +you get from [cockpit-project.org][] + +<iframe src="//www.youtube.com/embed/5dM4CqIp2s4" allowfullscreen="" frameborder="0" height="480" width="853"></iframe> + +This UI is going to be refined somewhat, but it's nice to see things +coming together. + + [cockpit-project.org]: http://cockpit-project.org/ diff --git a/content/cockpit/cockpit-has-a-terminal.md b/content/cockpit/cockpit-has-a-terminal.md new file mode 100644 index 0000000..6db3d1e --- /dev/null +++ b/content/cockpit/cockpit-has-a-terminal.md @@ -0,0 +1,12 @@ +Title: Cockpit has a terminal +Date: 2014-04-22 16:06 +Tags: cockpit, technical +Slug: cockpit-has-terminal + +[Cockpit][] 0.5 now has a nice terminal in a web browser. AKA +[term.js][] is awesome. + + + + [Cockpit]: http://cockpit-project.org/ + [term.js]: https://github.com/chjj/term.js/ diff --git a/content/cockpit/dbus-powerful-ipc.md b/content/cockpit/dbus-powerful-ipc.md new file mode 100644 index 0000000..17e4285 --- /dev/null +++ b/content/cockpit/dbus-powerful-ipc.md @@ -0,0 +1,36 @@ +Title: DBus is powerful IPC +Date: 2014-11-04 +Category: Linux +Tags: dbus, linux +Slug: d-bus-is-powerful-ipc + +D-Bus is powerful IPC Cockpit is heavily built around DBus. We send DBus over our +[WebSocket transport](https://github.com/cockpit-project/cockpit/blob/master/doc/protocol.md), +and marshal them in JSON. + +DBus is powerful, with lots of capabilities. Not all projects use all of these, but so many of +these capabilities are what allow Cockpit to implement its UI. + + * Method Call Transactions + * Object Oriented + * Efficient Signalling + * Properties and notifications + * Race free watching of entire Object trees for changes + * Broadcasting + * Discovery + * Introspection + * Policy + * Activation + * Synchronization + * Type-safe Marshalling + * Caller Credentials + * Security + * Debug Monitoring + * File Descriptor Passing + * Language agnostic + * Network transparency + * No trust required + * High-level error concept + * Adhoc type definitions + +Lennart goes into these further [in a kdbus talk](http://youtu.be/HPbQzm_iz_k?t=2m6s), as well as some of the weaknesses of DBus. diff --git a/content/cockpit/feature-docker-pull.md b/content/cockpit/feature-docker-pull.md new file mode 100644 index 0000000..923913c --- /dev/null +++ b/content/cockpit/feature-docker-pull.md @@ -0,0 +1,12 @@ +Title: Cockpit has Docker pull support +Date: 2014-06-24 +Category: Cockpit +Tags: cockpit, docker + +Cockpit 0.12 now has support for pulling Docker images from the +[Docker registry](https://registry.hub.docker.com/). + + + +Unfortunately Docker doesn't have support for cancelling the pull of an image. So that +sort of hampers the UI a bit. At least for now. diff --git a/content/cockpit/feature-simple-network.md b/content/cockpit/feature-simple-network.md new file mode 100644 index 0000000..d0f4b45 --- /dev/null +++ b/content/cockpit/feature-simple-network.md @@ -0,0 +1,9 @@ +Title: Cockpit Simple Networking Configuration +Date: 2014-06-20 +Category: Cockpit +Tags: cockpit, network-manager, linux + + Cockpit 0.11 now has an all new simple Networking UI. Still some work to do, but it's +coming together. You can see it here: + + diff --git a/content/cockpit/introducing-cockpit.md b/content/cockpit/introducing-cockpit.md new file mode 100644 index 0000000..6ac7691 --- /dev/null +++ b/content/cockpit/introducing-cockpit.md @@ -0,0 +1,29 @@ +Title: Introducing Cockpit +Date: 2014-02-13 12:46 +Tags: technical +Slug: introducing-cockpit + +Gave a [talk at DevConf][] in Brno about the project a bunch of us have +been working on: [Cockpit][]. It's a UI for Linux Servers. Currently in +the prototype stage... + + + +Hopefully there'll be a video of the talk available soon. You can try +out the Cockpit prototype in Fedora like so: + + :::text + # yum install --enablerepo=updates-testing cockpit + # setenforce 0 # issue 200 + # systemctl enable cockpit-ws.socket + $ xdg-open http://localhost:21064 + + +**Don't run this on a system you care about (yet).** Sorry about the +certificate warning. Groan ... I know ... working on that. + +Needless to say I'm excited about where this is going... + + + [talk at DevConf]: http://thewalter.net/stef/misc/cockpit-devconf-2014-talk.pdf + [Cockpit]: http://cockpit-project.org/ diff --git a/content/images/1-add-account.png b/content/images/1-add-account.png Binary files differnew file mode 100644 index 0000000..b96520b --- /dev/null +++ b/content/images/1-add-account.png diff --git a/content/images/2-enterprise-login.png b/content/images/2-enterprise-login.png Binary files differnew file mode 100644 index 0000000..78322e3 --- /dev/null +++ b/content/images/2-enterprise-login.png diff --git a/content/images/3-validate-domain.png b/content/images/3-validate-domain.png Binary files differnew file mode 100644 index 0000000..e391863 --- /dev/null +++ b/content/images/3-validate-domain.png diff --git a/content/images/4-validate-login.png b/content/images/4-validate-login.png Binary files differnew file mode 100644 index 0000000..1b87422 --- /dev/null +++ b/content/images/4-validate-login.png diff --git a/content/images/5-validate-password.png b/content/images/5-validate-password.png Binary files differnew file mode 100644 index 0000000..7ad29fd --- /dev/null +++ b/content/images/5-validate-password.png diff --git a/content/images/6-administrator.png b/content/images/6-administrator.png Binary files differnew file mode 100644 index 0000000..87ed9b6 --- /dev/null +++ b/content/images/6-administrator.png diff --git a/content/images/7-added-accounts.png b/content/images/7-added-accounts.png Binary files differnew file mode 100644 index 0000000..63f12e1 --- /dev/null +++ b/content/images/7-added-accounts.png diff --git a/content/images/IMG_7385.JPG b/content/images/IMG_7385.JPG Binary files differnew file mode 100644 index 0000000..cf753ea --- /dev/null +++ b/content/images/IMG_7385.JPG diff --git a/content/images/certificate-1.png b/content/images/certificate-1.png Binary files differnew file mode 100644 index 0000000..13ab2ac --- /dev/null +++ b/content/images/certificate-1.png diff --git a/content/images/certificate-2.png b/content/images/certificate-2.png Binary files differnew file mode 100644 index 0000000..2ad2583 --- /dev/null +++ b/content/images/certificate-2.png diff --git a/content/images/certificate-viewer-1.png b/content/images/certificate-viewer-1.png Binary files differnew file mode 100644 index 0000000..3434285 --- /dev/null +++ b/content/images/certificate-viewer-1.png diff --git a/content/images/certificate-viewer-2.png b/content/images/certificate-viewer-2.png Binary files differnew file mode 100644 index 0000000..cbbdc19 --- /dev/null +++ b/content/images/certificate-viewer-2.png diff --git a/content/images/certificate-viewer.png b/content/images/certificate-viewer.png Binary files differnew file mode 100644 index 0000000..0bd64f5 --- /dev/null +++ b/content/images/certificate-viewer.png diff --git a/content/images/cockpit-docker-pull.png b/content/images/cockpit-docker-pull.png Binary files differnew file mode 100644 index 0000000..080cf5e --- /dev/null +++ b/content/images/cockpit-docker-pull.png diff --git a/content/images/cockpit-simple-network.png b/content/images/cockpit-simple-network.png Binary files differnew file mode 100644 index 0000000..2e265c3 --- /dev/null +++ b/content/images/cockpit-simple-network.png diff --git a/content/images/cockpit-terminal.png b/content/images/cockpit-terminal.png Binary files differnew file mode 100644 index 0000000..0466e07 --- /dev/null +++ b/content/images/cockpit-terminal.png diff --git a/content/images/cockpit1.png b/content/images/cockpit1.png Binary files differnew file mode 100644 index 0000000..70df926 --- /dev/null +++ b/content/images/cockpit1.png diff --git a/content/images/gcr-smart-card.png b/content/images/gcr-smart-card.png Binary files differnew file mode 100644 index 0000000..06676b3 --- /dev/null +++ b/content/images/gcr-smart-card.png diff --git a/content/images/git-coverage-shot.png b/content/images/git-coverage-shot.png Binary files differnew file mode 100644 index 0000000..fb33aac --- /dev/null +++ b/content/images/git-coverage-shot.png diff --git a/content/images/p11-glue.jpg b/content/images/p11-glue.jpg Binary files differnew file mode 100644 index 0000000..7c71a55 --- /dev/null +++ b/content/images/p11-glue.jpg diff --git a/content/images/reset-computer.png b/content/images/reset-computer.png Binary files differnew file mode 100644 index 0000000..17f0b15 --- /dev/null +++ b/content/images/reset-computer.png diff --git a/content/images/screenshot-with-places2.png b/content/images/screenshot-with-places2.png Binary files differnew file mode 100644 index 0000000..3698245 --- /dev/null +++ b/content/images/screenshot-with-places2.png diff --git a/content/images/seahorse-combined-view.png b/content/images/seahorse-combined-view.png Binary files differnew file mode 100644 index 0000000..5fc2637 --- /dev/null +++ b/content/images/seahorse-combined-view.png diff --git a/content/images/seahorse-importer.png b/content/images/seahorse-importer.png Binary files differnew file mode 100644 index 0000000..7abf05a --- /dev/null +++ b/content/images/seahorse-importer.png diff --git a/content/personal/at-guadec.md b/content/personal/at-guadec.md new file mode 100644 index 0000000..2af01b5 --- /dev/null +++ b/content/personal/at-guadec.md @@ -0,0 +1,22 @@ +Title: At GUADEC +Date: 2010-07-06 +Tags: technical, security, gnome +Slug: at-guadec + +Yesterday was the first day of my first GUADEC. It was great meeting +many people I've only been in touch with remotely. + +We had our Desktop Crypto BOF as well. I imagined it going differently, +and probably should have prepared for it differently. There were topics +that would have been great to discuss but I forgot to bring up: + + * libgcr: the certificate and other crypto widgets and where they'll +live. Should we +split that out in a separate library. + * What to keep/drop from libcryptui. + * Our common gsettings schemas for non app specific settings. + * Gnome Keyring to do list: [http://live.gnome.org/GnomeKeyring/ToDo](http://live.gnome.org/GnomeKeyring/ToDo) + +But I think there was some solid progress made and really good ideas +came up. Especially the discussion toward the end about how to build the +web of trust more simply. diff --git a/content/personal/berlin-and-desktop-summit-talk.md b/content/personal/berlin-and-desktop-summit-talk.md new file mode 100644 index 0000000..a1c162f --- /dev/null +++ b/content/personal/berlin-and-desktop-summit-talk.md @@ -0,0 +1,27 @@ +Title: Berlin and Desktop Summit Talk +Date: 2011-08-12 +Tags: technical, security, gnome +Slug: berlin-and-desktop-summit-talk + +Really enjoyed the Desktop Summit, and meeting everyone there. The only +bummer part was the network connectivity. My +employer [Collabora][] sponsored my trip and work. + +My talk went well ([slides][]), and we had a great time discussing +things afterwards. [LWN wrote an article][] about the talk (the article +will be available for non-subscribers on the 18th of August). + +During the BoFs I worked on gnome-keyring integration into the +gnome-shell, as well as fixing bugs in gobject-introspection and +integrating it into gnome-keyring. + +Berlin really surprised me. Classier and more alive than I expected. +Classy thunderstorms too. I took a couple hours to ride around on a bike +between rain showers. + + + + + [Collabora]: http://www.collabora.com/ + [slides]: http://thewalter.net/stef/misc/desktop-summit-2011-stef-walter-desktop-crypto.pdf + [LWN wrote an article]: http://lwn.net/Articles/454307/ diff --git a/content/personal/going-to-the-desktop-summit.md b/content/personal/going-to-the-desktop-summit.md new file mode 100644 index 0000000..e7c77ee --- /dev/null +++ b/content/personal/going-to-the-desktop-summit.md @@ -0,0 +1,17 @@ +Title: Going to the Desktop Summit +Date: 2011-08-04 +Tags: technical, security, gnome +Slug: going-to-desktop-summit + + + + +I'm off the the Desktop Summit shortly. Going to be giving a talk +about [gluing together desktop crypto][] (Oh boy, there's a life size +picture of me at that link. I wonder why it ended up so big? Hrmmmm....) + +My first time in Berlin, and it sounds like it'll be fun. Also looking +forward to getting to meet some KDE developers :) + + [gluing together desktop crypto]: https://www.desktopsummit.org/program/sessions/gluing-together-usable-desktop-crypto + []: https://www.desktopsummit.org/sites/www.desktopsummit.org/files/DS2011banner.png diff --git a/content/personal/looking-for-open-source-work.md b/content/personal/looking-for-open-source-work.md new file mode 100644 index 0000000..6b2cf0f --- /dev/null +++ b/content/personal/looking-for-open-source-work.md @@ -0,0 +1,27 @@ +Title: Looking for open source work +Date: 2010-10-22 +Tags: technical, security +Slug: looking-for-work + +Well, all good things must come to an end. My [job at The Family +International][] is changing significantly, and I'm looking for other +work. It's been a great organization to work for, I've been able to work +on real interesting and varied projects, and at the same time working to +[support a really worthy cause][]. + +They've been supportive of my open source work, and have allowed me to +release several internal projects as open source. I managed +singlehandedly to get them on the [short list of top organizations][] +that contributed to GNOME. + +But I'm excited about this change. I've applied for positions at a +number of open source companies. I think it'd be awesome working further +with the great folks in the open source community. I've had [over 10 +years of extensive experience][job at The Family International] to bring +to the table. + +My wife, son and I are likely going to move to Germany. + + [job at The Family International]: http://thewalter.net/stef/resume/ + [support a really worthy cause]: http://www.thefamily.org/en/ + [short list of top organizations]: http://blogs.gnome.org/bolsh/2010/07/28/gnome-census/ diff --git a/content/technical/about-trust-assertions.md b/content/technical/about-trust-assertions.md new file mode 100644 index 0000000..41e2428 --- /dev/null +++ b/content/technical/about-trust-assertions.md @@ -0,0 +1,130 @@ +Title: About Trust Assertions +Date: 2010-10-13 +Tags: technical, security, gnome +Slug: about-trust-assertions + +I've been working on some specifications for storage of 'trust'. This a +sufficiently vague and abstract concept to require a hoity toity name: +*Trust Assertions* + +Trust assertions are used to assign an explicit level of trust to a +public key or certificate. I'll just refer to certificates below because +that's the easiest to grasp, but the concept is sufficiently abstract to +allow trust assertions for other types of keys. + +Examples of trust assertions include: + +- Certificate Authority root certificates +- Certificate Revocation Lists +- Certificates you decide to trust manually (for your favorite self + signed certificate) +- Certificates marked bad explicitly + +Trust assertions are not about the process of deciding whether you'll +eventually trust a certificate. Ultimately an application needs to +determine trust a certificate for a given connection, email or instant +message. It does this by checking if it's valid, who it's signed by, and +an obscene amount of other rules. It usually does this with the help of +a crypto library. + +Only the application has all the information necessary to make a trust +decision. A simple example of this is how web browsers check that the +common name (ie: `CN`) of the certificate matches the domain name of the +`https://` website you've browsed to. + +Trust assertions are about storing basic facts that applications use in +their trust decision process. + + **The Concept** + +A trust assertion describes a level of trust in a certificate for a +given usage or purpose. Conceptually each trust assertion is a triple +containing: + +- Certificate Reference +- Usage (aka purpose) +- Level of Trust + +We examine each of these parts of the triple in further detail below. + +**The Level of Trust** + +A trust assertion ultimately denotes a level of trust. These are: + +- Untrusted: The certificate is explicitly untrusted. +- Unknown: The trust is not known and should be determined + elsewhere. +- Trusted: The certificate itself is explicitly trusted. +- Trusted Delegator: The certificate is trusted as a certificate + authority trust root. Trust is conferred to certificates that + this certificate has signed, or that signed certificates have + signed, and so on. + +**The Usage** + +A trust assertion always refers to a specific purpose or usage. A +certificate may be trusted for purposes like: email, code signing, +authenticating a server. + +It turns out that carte blanche trust not a super useful concept. You +(should) always trust someone for some purpose. You trust your bank +with your money, not your children; you trust your school with your +children, and so on. + +**The Certificate Reference** + +And finally we have the certificate that the trust assertion refers +to. + + +Pretty boring stuff actually. But it does get exciting. By comoditizing +trust storage, we can use these well defined concepts for new methods of +trust decision making. + +The way certificate authorities work in your web browser scares a lot of +people. By changing to a more general trust storage model, we have the +possibilities for applications to try out new trust paradigms. One +example is the have-I-seen-this-key-at-this-site-before trust model, +used by OpenSSH. But I'm certain that more methods will emerge as more +energy is brought to bear on the problem. + +Okay enough hand waving, and back to earth. + +The [specification I'm working on][] defines how to store trust +assertions as PKCS\#11 objects. This isn't a new concept, and has been +[implemented in Mozilla's NSS][] for a long time. However as far as I +can tell it hasn't yet been documented. + + +<div +style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"> + +After some prodding (thanks Nikos) I figured I'd do some work to +document it properly. + +</div> + +<div> + +</div> + + +GNOME Keyring is completing its implementation of trust assertions. For +a long time now, we've had simple read-only trust assertions that +exposed everything in <span class="Apple-style-span" +style="font-family: 'Courier New', Courier, monospace;">/etc/ssl/certs</span> as +a trusted delegator (ie: a certificate authority). + +But now we're working on rounding out the support on the [trust-store +branch of gnome-keyring][]. + +[Cosimo][] is working on XTLS to encrypt jabber chats in empathy, and so +the trust-store work will help store certificate exceptions in +gnome-keyring. + +</p> + + [specification I'm working on]: http://thewalter.net/git/cgit.cgi/pkcs11-trust-assertions/tree/draft-pkcs11-trust-assertions.xml + [implemented in Mozilla's NSS]: http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/util/pkcs11n.h + [trust-store branch of gnome-keyring]: http://git.gnome.org/browse/gnome-keyring/tree/?h=trust-store + [Cosimo]: http://blogs.gnome.org/cosimoc/ diff --git a/content/technical/certificate-and-key-widgets.md b/content/technical/certificate-and-key-widgets.md new file mode 100644 index 0000000..00f9fa0 --- /dev/null +++ b/content/technical/certificate-and-key-widgets.md @@ -0,0 +1,31 @@ +Title: Certificate and Key Widgets +Date: 2010-10-08 +Tags: technical, security, gnome +Slug: certificate-and-key-widgets + +The new certificate and key view widgets are now merged into +gnome-keyring master. They live in [libgcr][]: a library for crypto UI +widgets and crypto helpers. + +The goal of the widgets are to have a simple mode, where only the +information needed for a user to uniquely identify a certificate is +displayed. The widget can be expanded to show all the details about the +certificate. + + + +Simple mode, with a dialog border. + + + + + + +Details expanded. + +At GUADEC [Matthew Paul Thomas][] helped us design a nice certificate +selector, and I'm working on implementing that. + + + [libgcr]: http://git.gnome.org/browse/gnome-keyring/tree/gcr + [Matthew Paul Thomas]: http://mpt.net.nz/ diff --git a/content/technical/ditching-certificate-authorities-with-convergence.md b/content/technical/ditching-certificate-authorities-with-convergence.md new file mode 100644 index 0000000..69c8ce8 --- /dev/null +++ b/content/technical/ditching-certificate-authorities-with-convergence.md @@ -0,0 +1,88 @@ +Title: Ditching Certificate Authorities with Convergence +Date: 2011-09-06 19:49 +Tags: security, gnome +Slug: listened-to-moxies-talk-about-trust + +Listened to [Moxie's][] [talk about Trust Agility and 'Convergence'][]. +Sounds like a viable candidate for ditching the Certificate Authority +mess, or at least part of a solution. Go [watch the video][talk about +Trust Agility and 'Convergence'] if you haven't already. + +I was thinking about how we could implement support for +[Convergence][] in GNOME. The local cache of discovered valid +certificates would work far better across an entire desktop, rather than +each application (browser or otherwise) including code, configuration, +and storage to do it on their own. + +In fact it fits in nicely with the Trust Assertion stuff I've been +playing with. It'd be relatively straightforward to build a [PKCS#11 Trust Assertion module][] which used Convergence to seed Trust +Assertions. That would plug in easily to [GLib][], [GCR][], NSS etc. +(modulo a few patches not yet merged). + +But a few things popped into my mind while watching the video. Stuff +that it seems would need to be solved before this can be implemented as +general purpose solution. This is just off the top of my head, and +perhaps I'm woefully mistaken about something: + + +1. **Protocols and Options:** Since I work for Collabora and we have a + thing for XMPP, the first thing that stood out to me, is that the + protocol is limited to HTTP, and more specifically SSL. Nearly every + other protocol uses TLS for security. + + So for starters this means that when the Notary wants to retrieve + the certificate it'll need to know how to speak a given protocol. I + guess different notaries could know speak different protocols when + fetching the certificate from the target server? + + Then the Convergence protocol would need to be changed to allow the + caller to specify a well known protocol. Perhaps the protocol would + also need some sort of capabilities support so that clients can know + which Notaries can do what? + +2. **TLS Options, Extensions:** Taking this a step further, the Notary + would need to provide the same TLS options and extensions that are + used in the handshake. Most obviously: [SNI][] + +3. **Hash Algorithm:** The protocol currently hardcodes things like + SHA-1, which isn't aging very well. And as we've learned, [it's often better to pass the entire certificate around][]. Or at least, + have it extensible where you can specify a hash algorithm to use. + +4. Obviously Convergence doesn't (and probably can't) work if the + server is requiring client certificates. I guess it's not meant to + solve this use case though. + +5. The installing of Notaries by downloading them as files from + websites (including the certificate) smells sort of wrong, at first + whiff. But if you figure that several Notaries would be distributed + with a distribution (and could later be updated as necessary) and + the certificates of websites hosting additional .notary files could + be checked using the initial set of Notaries, then I guess it sort + of makes sense. + +6. **Protocol Specification:** Last but not least, the protocol needs to + be documented and reviewed. + +About usability: Obviously most users will never care about checking +which Notaries they use. I have a hard time expecting most people to +care. But they don't have to. + +The Trust Agility comes with the fact that a distributor like GNOME +could easily ship a default set of Notaries, and then update them as +needed without affecting functionality. As Moxie points out the browser +vendors can't even disable [screwballs like Comodo][] because it would +disable a quarter of the web. So that's where this is different. You can +replace screwed up Notaries without affecting functionality. + +And no more self-signed certificate warnings. Seriously, that dialog +(wherever it's implemented) is the worst security cop-out ever. + + [Moxie's]: http://thoughtcrime.org/about.html + [talk about Trust Agility and 'Convergence']: http://www.youtube.com/watch?v=Z7Wl2FW2TcA + [Convergence]: http://convergence.io/ + [PKCS#11 Trust Assertion module]: http://p11-glue.freedesktop.org/trust-assertions.html + [GLib]: https://bugzilla.gnome.org/show_bug.cgi?id=656361 + [GCR]: http://developer.gnome.org/gcr/unstable/gcr-Trust-Storage-and-Lookups.html + [SNI]: http://en.wikipedia.org/wiki/Server_Name_Indication + [it's often better to pass the entire certificate around]: http://p11-glue.freedesktop.org/doc/pkcs11-trust-assertions/#justification-why-no-hash + [screwballs like Comodo]: http://www.livehacking.com/2011/03/31/comodo-saga-continues-two-more/ diff --git a/content/technical/git-coverage-useful-code-coverage.md b/content/technical/git-coverage-useful-code-coverage.md new file mode 100644 index 0000000..ca114a4 --- /dev/null +++ b/content/technical/git-coverage-useful-code-coverage.md @@ -0,0 +1,107 @@ +Title: git-coverage: Useful code coverage +Date: 2012-12-18 10:55 +Tags: technical, gnome +Slug: git-coverage-useful-code-coverage + +I've sorta dabbled in using code coverage off and on, but it never +really grabbed me as super useful and fit well within my workflow. + +When hacking on open source I want to try out patches, run tests against +them, whether automatic unit tests or manually diddling things during +testing. What I'm really interested is whether I tested out all the bits +of the patch. + +Traditional coverage tools tell you about the coverage of the whole +project, which you then have to update and dig through to see if your +changes were covered. I really don't care about the code coverage of +entire projects. This is especially true if I'm just a contributor of a +few patches. I want to see the coverage of the stuff I just changed. + + + +Anyhooo ... after much ongoing grumpiness ... I put together +[git-coverage][] which is a git plugin which you can use to look at a +patch and see which code paths have been run. Basically you use it +exactly like you would `git diff` but it highlights the code in the diff +that didn't have coverage. Works with Python, C and C++ code so far. + +<div class="separator" style="clear: both; text-align: center;"> + + + +</div> + +To use with C or C++ code, you need to build the project using gcc's +`--coverage` info. Something like this: + + :::text + $ CFLAGS='--coverage' ./configure ... + $ make clean all + + +Next you make some modifications to the code, rebuild, and run the tests +or code. Now the following command will tell you which of your changes +were covered. + + :::text + $ git coverage + + +Any lines that start with an exclam have no coverage. They're +highlighted in red if you have git coloring enabled. If there's no +output from the above command, then all lines have coverage. Similar to +how if nothing has changed, diff will output nothing. + +If you've already checked in your code then you would use the following +command to test the coverage of the last commit, similar to how you +might use git diff to show the last commit. + + + :::text + $ git coverage HEAD~1 + + +Or you can test coverage of the last N patches by doing stuff like: + + + :::text + $ git coverage HEAD~3.. + + +Normally `git-coverage` tries to check the coverage of lines surrounding +the changes. If you want to suppress this, you just pass in diff options +to narrow the diff down: + + + :::text + $ git coverage --unified=0 + + +To install `git-coverage` put it somewhere in your path. You might use: + + :::text + $ git clone git://thewalter.net/git-coverage + $ cd git-coverage + $ ln -s $PWD/git-coverage ~/.local/bin + +To use with Python code, install the `python-coverage` package, and run +your code or tests like this: + + + :::text + $ # Yup, python-coverage has a rather bold command name. + $ coverage run /path/to/python-code args ... + $ git coverage + +Anyway, maybe this'll help someone. It's an itch I've had for some +time. + +BTW, [Phillip][] put some [code into gnome-common][] which you can use +to [add --enable-code-coverage to your configure script][], and +optionally get full coverage reports for the project. Obviously also +works with git-coverage. + + [git-coverage]: http://thewalter.net/git/cgit.cgi/git-coverage/ + [Phillip]: http://tecnocode.co.uk/ + [code into gnome-common]: http://git.gnome.org/browse/gnome-common/tree/macros2/gnome-code-coverage.m4 + [add --enable-code-coverage to your configure script]: http://git.gnome.org/browse/gcr/commit/?id=a185f4f20f20776f6b0dcccb4f3eeba30941022a diff --git a/content/technical/goals-of-the-keyring-and-seahorse-projects.md b/content/technical/goals-of-the-keyring-and-seahorse-projects.md new file mode 100644 index 0000000..efef235 --- /dev/null +++ b/content/technical/goals-of-the-keyring-and-seahorse-projects.md @@ -0,0 +1,29 @@ +Title: Goals of the Keyring and Seahorse Projects +Date: 2010-10-17 +Tags: technical, security, gnome +Slug: goals-of-keyring-and-seahorse-projects + +<span class="Apple-style-span" style="font-family: inherit;">In an +effort to get better organized, I've put together [a page listing the +goals][] of the [gnome-keyring][] and [seahorse][] projects. </span>It's +all broken down into tasks, plans, and what's already done. + +The basic jist of it is to make crypto and security a usable experience +on the desktop. This means laying down a foundation for integrating +crypto into applications easily. We have tons of technically excellent +crypto libraries and security components, but there hasn't been the glue +to tie them together and make them usable in apps. + +<span class="Apple-style-span" style="font-family: inherit;">It's sort +of like what PackageKit or NetworkManager did for their respective +areas. Linux (and other open source OS's are) really great at +networking, but NetworkManager pulled together all the various bits, and +completed missing parts to make it to be usable.</span> + +[<span class="Apple-style-span" +style="font-family: inherit;">http://live.gnome.org/GnomeKeyring/Goals</span>][a +page listing the goals] + + [a page listing the goals]: http://live.gnome.org/GnomeKeyring/Goals + [gnome-keyring]: http://live.gnome.org/GnomeKeyring + [seahorse]: http://projects.gnome.org/seahorse/ diff --git a/content/technical/how-to-build-telepathy-qt4-with-alternate-prefix.md b/content/technical/how-to-build-telepathy-qt4-with-alternate-prefix.md new file mode 100644 index 0000000..09d1cd2 --- /dev/null +++ b/content/technical/how-to-build-telepathy-qt4-with-alternate-prefix.md @@ -0,0 +1,19 @@ +Title: How to build telepathy-qt4 with alternate prefix +Date: 2011-08-11 +Tags: technical +Slug: how-to-build-telepathy-qt4-with + +Just figured out how to build telepathy-qt4 in an alternate prefix and +also look for dependencies in that prefix as well. Since I don't use +cmake much these days, figured I'd post this so I could go and look back +at it later. Depends on [this fix][]. + + :::sh + PKG_CONFIG_PATH=~/the/prefix cmake -DCMAKE_INSTALL_PREFIX=~/the/prefix .make install + +Or if on a 64-bit system: + + :::sh + PKG_CONFIG_PATH=~/the/prefix cmake -DCMAKE_INSTALL_PREFIX=/data/build/telepathy -DLIB_SUFFIX=64 .make install + + [this fix]: https://bugs.freedesktop.org/show_bug.cgi?id=40008 diff --git a/content/technical/how-to-create-an-active-directory-domain-to-test-against.md b/content/technical/how-to-create-an-active-directory-domain-to-test-against.md new file mode 100644 index 0000000..db1e330 --- /dev/null +++ b/content/technical/how-to-create-an-active-directory-domain-to-test-against.md @@ -0,0 +1,229 @@ +Title: How to create an Active Directory domain to test against +Date: 2012-08-03 +Tags: technical, security +Slug: how-to-create-active-directory-domain + +Many interested people want to help test the Active Directory work and +bug fixes we've been doing. But sadly there's no public Active Directory +servers that I know of. So here's how to setup a virtual machine with +your own Active Directory. It's not that hard. + + +### 1. Preparation + +- Each Active Directory has a unique domain name. Choose one. You can + choose a subdomain of a domain you own, or one that's completely + made up. I chose `borg.thewalter.lan` +- Download the evaluation edition of [Windows 2008 R2 Enterprise server][]. Click the *Get Started *button at that link to download + it. The evaluation edition is valid for 180 days. You should end up + with an ISO file named something + like: `7601.17514.101119-1850_x64fre_server_eval_en-us-GRMSXEVAL_EN_DVD.iso` +- We'll be using virt-manager in this tutorial, so install + `virt-manager`, `libvirtd, qemu` and all their dependencies. + +### 2. Create a virtual network + +- The Active Directory server will need a static IP address. The + `default` virtual network configured by libvirtd does not have any + space for a static IP address, so we need to create a new virtual + network. +- Start `virt-manager` and make sure you're connected to the + *localhost (QEMU)* connection. +- Click on *localhost (QEMU)* and choose *Edit* \> *Connection + Details* from the menu. +- Choose the *Virtual Networks* tab in the dialog that pops up and + click the add button. +- Use settings like: + *Network Name*: ad + *Network*: `192.168.12.0/24` + *Enable DHCP*: checked + *Start*: `192.168.12.128` + *End*: `192.168.12.254` +- Notice that we left some space between the start of the netblock and + the first DHCP allocated address. Actually virt-manager does this by + default for added virtual networks like this one. +- You probably want to *Forward* (via *NAT*) to your physical network. + That makes it easier to activate windows later and get updates. +- Complete the wizard and you're done. + +### 3. Create a new virtual machine + +- In the main virt-manager window, click the create button in the + toolbar to create a new virtual machine. +- Type the domain name you chose above as the virtual machine *Name*. +- Choose *Local install media* and when prompted select the *ISO + image* you downloaded above as the *install media*. +- Set *OS type* to *Windows*, and *Version* to *Microsoft Windows + Server 2008.* +- 512 MB of memory is enough, 1 CPU is enough. Feel free to set these + higher if you like. +- Create a new virtual disk with at least 10 GB of disk space. +- On the last page of the *Create a new virtual machine* dialog, + expand the *Advanced options* section and choose the network you + created above. +- Complete the dialog and the virtual machine should be created. Then + the Windows install should begin. + +### 4. Windows Server install + +- Choose whatever keyboard and language you want on the first dialog + of the install. +- On the next page choose *Install now*. +- A list of types of Windows Server installs should show up. Choose + *Windows Server 2008 R2 Standard (Full Installation)*and go to the + next page. +- Read and accept the license. +- Choose *Custom (advanced)* when prompted how to install Windows. +- Select the disk to install Windows on. There should only be one + choice which is the virtual disk you configured when you created the + virtual machine. +- Windows Server will proceed to install, and will reboot a couple + times in the process. +- Once the system is ready, you will be prompted to change the + *Administrator* password. This is actually setting the password for + the first time. This is the password for the *Administrator* account + on the server itself, not the administrator of the Active Directory + domain, which you'll set later. You can use the same password for + both, since this is a test install. +- If all goes well you should be logged into your new server at this + point. A bunch of helpful windows will pop up, but you don't need to + do anything with them. + +### 5. Set the IP address + +- An Active Directory server acts as an LDAP and DNS server, and needs + a static IP address. +- Click *Start* \> *Network,*and then click the *Change adapter + settings* link in the window that comes up. Another window should + appear. +- Right click on the *Local Area Connection* item and choose + *Properties* in the menu. +- Click on the *Internet Protocol Version 4 (TCP/IPv4)* item and then + click the *Properties* button. A dialog for setting the addresses + comes up. +- Choose *Use the following IP address.*Then set the relevant fields. + The settings here are based on the virtual network you created + above, if you used a different netblock then modify as appropriate: + *IP Address*: `192.168.12.10` + *Subnet mask*: `255.255.255.0` + *Default gateway*: `192.168.12.1` + *Preferred DNS Server*: `192.168.12.1` +- Click OK or Close in the various dialogs to complete things. + +### 6. Set the machine name + +- An Active Directory server should have a well known DNS name, you + don't need to set it in DNS, but just name the server appropriately + and then Active Directory will do the rest. +- Click *Start* \> *Computer*, and a window should come up. +- In the left pane of the window, there's an item called + *Computer.*Right click on it and choose *Properties* from the menu. + Another window should show up. +- Click *Change Settings*, and a dialog will come up. +- In the *Computer Name* tab click the *Change...* button, which + displays another dialog. +- Set `DC` as the *Computer name* or another name of your choice. + Don't worry about the *Member of Domain or Workgroup* stuff yet. +- Click OK and/or Close to complete the changes. You'll be prompted to + restart, so go ahead and do that. + +### 7. Setting up Active Directory + +- Click *Start \>* *Run* and type `DCPROMO` in the dialog that comes + up. +- A progress window will come up which explains about installing some + components. This takes a while. +- A wizard will eventually show up. Click through the introduction and + warnings. +- Choose *Create a new domain in a new forest*. +- On the next page enter the domain you chose earlier, like + `borg.thewalter.lan` +- Choose the *Forest functional level*. You can choose whichever one + you like. Choosing *2008 R2* is a decent choice. You can test + against various Active Directory servers with different levels to + simulate different domains you might encounter in the wild. +- Make sure *DNS Server* is chosen on the next page. +- Once you complete that, a dialog will come up warning you about how + the DNS delegation cannot be created. We'll do that manually below, + so this is nothing to worry about. Choose *Yes*. +- Leave the default paths for database and log files. +- Choose a domain *Administrator* password. Logically this is + different from the local server *Administrator* account you set the + password for above. But you can use the same password to keep things + simple. +- Review the selections if you're interested, and then click *Next* to + complete things. +- Wait for a while for installation and configuration, *Finish. * +- You'll need to *Restart Now*. +- The reboot after installing Active Directory will take a while as it + does a bunch of stuff on the first boot. + +### 8. Setup DNS to work with Active Directory + +- Back on your linux box you'll want to be able to connect to Active + Directory. To do this you need to setup DNS. Active Directory comes + with its own DNS server, you just need to tell your local host where + it is. To do this we'll install a local caching name server. +- Install bind. If you're on Fedora you can use a command + like: `# yum install caching-nameserver` +- After the install completes, edit `/etc/named.conf` and add the + following line to your main *options* section: + + :::text + forwarders { 8.8.8.8; /* ... or the address of your ISP DNS server */ }; + +- And add this to the end of `/etc/named.conf`. Modify for your domain + name or server static IP address assigned above: + + :::text + zone "borg.thewalter.lan" { type stub; masters { 192.168.12.10; }; }; + +- Restart the named service with: `# systemctl restart named.service` +- Before configuring your host to use the local caching nameserver, + test it with commands like: + + :::text + # host borg.thewalter.lan 127.0.0.1 + # host dc.borg.thewalter.lan 127.0.0.1 + # host google.com 127.0.0.1 + +- Once you know it's working, use `nm-connection-editor` to edit your + connection. Choose your connection, and on the *IPv4 Settings* tab, + choose *Automatic (DHCP) addresses only.*Now set `127.0.0.1` as the + *DNS servers*. +- You should now be able to test you local server with commands like: + + :::text + # host borg.thewalter.lan + # host dc.borg.thewalter.lan + # host google.com + +### 9. Test the Active Directory domain works + +- On your host linux box you should now be able to get a kerberos + ticket. +- If you have a custom configured `/etc/krb5.conf`, you may need to + remove or move it. There is no real need for this file with a modern + kerberos domain like Active Directory. +- Run this command. Make sure the domain is upper case here: + + :::text + $ kinit Administrator@BORG.THEWALTER.LAN + +- You'll be prompted for the domain *Administrator* password. The one + you typed in the *Setting up Active Directory* step above. +- If successful `kinit` will show no output. You can use the `klist` + command to see your ticket. + +That's it. You're done. + +You can add additional Active Directory users via the *Active Directory +Users and Computers* tool in the *Administrative Tools* section of the +*Start* menu in the Windows Server virtual machine. + +You may be prompted to Activate your Windows install. You won't need any +special information or keys or anything. Just go ahead with it. The +install you have is valid for 180 days, and will say in the lower left +corner how long you have left. + + [Windows 2008 R2 Enterprise server]: http://technet.microsoft.com/en-us/evalcenter/dd459137.aspx diff --git a/content/technical/how-to-join-active-directory-domains-with-a-one-time-password.md b/content/technical/how-to-join-active-directory-domains-with-a-one-time-password.md new file mode 100644 index 0000000..28f5b92 --- /dev/null +++ b/content/technical/how-to-join-active-directory-domains-with-a-one-time-password.md @@ -0,0 +1,65 @@ +Title: How to join Active Directory domains with a One Time Password +Date: 2014-05-06 14:23 +Tags: active-directory +Slug: how-to-join-active-directory-domains + +[realmd][] and [adcli][] allow you to join a domain with a one time +password. + +That is: a domain administrator can prepare a one time password, and +that one time password can later be used (usually by someone else) to +join a specific computer to the domain. + +[FreeIPA][] supports this natively. But adcli also accomplishes this for +Active Directory domains. People have been asking how that happens. + +Each computer in an Active Directory domain has a computer account. Each +computer account has a computer password. Normally this password is +[randomly generated][] while joining the domain. + +When you choose the *Reset Password* option in the Active Directory UI, +this password is set to a predictable string, which is just the computer +account name in lower case (ie: `samAccountName` without the dollar +sign). + + + + + +Since computer accounts can (by default) change their own account +passwords, reseting a computer account allows anyone to claim the +computer account, by changing its password from this known password to a +generated one. + +realmd takes advantage of the above, and will automatically join a +domain if the relevant computer account has been reset. + +In addition adcli has a `preset-computer` mode which allows an +administrator to generate a new computer account, and set its paswsord +to a one time use password. + + + :::text + $ adcli preset-computer --domain=ad.example.com --one-time-password=ThisIsthe1xPass computer1.example.com + Password for Administrator@AD.EXAMPLE.COM: + computer-name: COMPUTER1 + + +This one time password can later be used with realmd to have it join the +computer account, like so: + + :::text + $ hostname + computer1.example.com + $ realm join --one-time-password=ThisIsthe1xPass ad.example.com + + +Or you can use this one time password with kickstart, as shown here: + + +<iframe allowfullscreen="" src="//www.youtube.com/embed/1Tm1jZ8fpW4" frameborder="0" height="720" width="960"></iframe> + + [realmd]: http://www.freedesktop.org/software/realmd/docs/ + [adcli]: http://www.freedesktop.org/software/realmd/adcli/adcli.html + [FreeIPA]: http://www.freeipa.org/page/Main_Page + [randomly generated]: http://cgit.freedesktop.org/realmd/adcli/tree/library/adenroll.c#n185 diff --git a/content/technical/implemented-trust-assertions-and-certificate-chains.md b/content/technical/implemented-trust-assertions-and-certificate-chains.md new file mode 100644 index 0000000..5c34ddc --- /dev/null +++ b/content/technical/implemented-trust-assertions-and-certificate-chains.md @@ -0,0 +1,47 @@ +Title: Implemented trust assertions and certificate chains +Date: 2010-12-11 +Tags: technical, security, gnome +Slug: implemented-trust-assertions-and + + +Trust assertions are bits of trust information used by applications to +make trust decisions about certificates. For example, trust assertions +can represent certificate authority anchors, pinned certificate +exceptions, or revocation lists. Trust assertions do not represent the +trust decision itself, but they're used in a trust decision. + +By using trust assertions applications (and libraries) can make +consistent trust decisions and not confuse the poor user with different +security in each app when making TLS connections. + +For example all the applications on the user's desktop would use the +same set of certificate authorities when making TLS connections. And the +user can then easily manage that set of certificates. It's also easy to +store per-host pinned certificate exceptions for self-signed +certificates, and have all applications use them consistently. + +I've put together a [spec for storing and looking up trust assertions +via PKCS\#11][] which allows a loose coupling between applications and +the storage of these trust assertions. I've also implemented support for +storing trust assertions in Gnome Keyring, and [client side support in +libgcr][]. + +To make it all very easy to use, I've added a [GcrCertificateChain][] +class which builds up a certificate chain, based on trust assertions and +gets it ready for verification by your favorite crypto library. + +All this goodness is available in the [trust-store branch][] of +gnome-keyring, and it looks like [empathy will be the first][] app to +make use of it. I'm gonna try and see how we can fit this into the nice +new [GTlsConnection][] support in glib. + +I'm looking forward to the [security devroom at FOSDEM][] and hope to +talk about some of this stuff. + + [spec for storing and looking up trust assertions via PKCS\#11]: http://people.collabora.co.uk/~stefw/trust-assertions.html + [client side support in libgcr]: http://people.collabora.co.uk/~stefw/gcr-docs/ + [GcrCertificateChain]: http://people.collabora.co.uk/~stefw/gcr-docs/GcrCertificateChain.html + [trust-store branch]: http://git.gnome.org/browse/gnome-keyring/log/?h=trust-store + [empathy will be the first]: https://bugzilla.gnome.org/show_bug.cgi?id=636258 + [GTlsConnection]: https://bugzilla.gnome.org/show_bug.cgi?id=588189 + [security devroom at FOSDEM]: http://opensc-project.org/opensc/wiki/FOSDEM2011 diff --git a/content/technical/importing-certificates-and-keys.md b/content/technical/importing-certificates-and-keys.md new file mode 100644 index 0000000..0610dd2 --- /dev/null +++ b/content/technical/importing-certificates-and-keys.md @@ -0,0 +1,49 @@ +Title: Importing certificates and keys +Date: 2011-10-05 +Tags: technical, security, gnome +Slug: importing-certificates-and-keys + +I've been working on an importer for keys and certificates that can work +with PKCS#11 key storage, such as smart cards, NSS or gnome-keyring. + +Here's a demo of it in action. If you want to try this out yourself, +you'll need: + +- latest gcr library from [gnome-keyring git master][] +- [p11-kit 0.7][] or later +- [OpenSC configured][] to show up in p11-kit +- [NSS configured][] to show up in p11-kit +- an [OpenSC patch][] for mlock issue +- an Entersafe based smart card, like the [Feitan 310 or 301][]. +- the smart card [needs to be initialized][] + +It's possible that this works with other smart cards too, but I haven't +tested it. By the way, if you want to help work on smart cards support, +[Gooze gives away free smart cards][] for open source developers working +on this stuff. + +On to the demo... + +<iframe allowfullscreen="" src="http://player.vimeo.com/video/30069077?title=0&byline=0&portrait=0" webkitallowfullscreen="" frameborder="0" height="477" width="720"></iframe> + +[View the Importer demo][] from [Stef Walter][] on [Vimeo][]. + +The importer and all the widgets are available for use by other apps in +the gcr library. So Seahorse has the same interface: + + + +As you might note, I've been reworking the Seahorse user interface, more +about that coming soon... + + [gnome-keyring git master]: http://git.gnome.org/browse/gnome-keyring/ + [p11-kit 0.7]: http://p11-glue.freedesktop.org/releases/ + [OpenSC configured]: http://www.opensc-project.org/opensc/ticket/390 + [NSS configured]: https://live.gnome.org/CryptoGlue/Integration#NSS_libsoftokn3 + [OpenSC patch]: http://www.opensc-project.org/opensc/ticket/389 + [Feitan 310 or 301]: http://www.gooze.eu/ + [needs to be initialized]: http://www.gooze.eu/howto/smartcard-quickstarter-guide/smart-card-initialization + [Gooze gives away free smart cards]: http://www.gooze.eu/feitian-pki-free-software-developer-card + [View the Importer demo]: http://www.blogger.com/30069077 + [Stef Walter]: http://www.blogger.com/user6330669 + [Vimeo]: http://www.blogger.com/ diff --git a/content/technical/introducing-libgck-a-pkcs11-gobject-wrapper.md b/content/technical/introducing-libgck-a-pkcs11-gobject-wrapper.md new file mode 100644 index 0000000..8901cc4 --- /dev/null +++ b/content/technical/introducing-libgck-a-pkcs11-gobject-wrapper.md @@ -0,0 +1,31 @@ +Title: Introducing libgck: A PKCS#11 GObject wrapper +Date: 2010-10-04 +Tags: technical, security, gnome +Slug: introducing-libgck-pkcs11-gobject + +In gnome-keyring we use [PKCS#11][] for the storage of keys and +certificates. PKCS#11 is standard sort of a plugin API that allows +drivers or software to provide key storage and crypto algorithms to an +application. +libgck is a GObject wrapper of PKCS#11. Still pretty low level but +makes PKCS#11 easier to use from GNOME or GTK+ apps. libgck is used +extensively in gnome-keyring and seahorse. + +- GCK stands for "**G**object **C**rypto**K**i". +- Currently lives in the gnome-keyring git module, but could be split + into its own module in the future. +- Replaces libgp11 with many lessons learned and a cleaner API. + +Besides the mundane expected key and certificate storage functionality +and crypto mechanisms. There's support for stuff like [PKCS#11 URIs][] +used to identify keys or certificates residing in a certain key storage +or smart card. Also enumeration and loading of modules from a [common +system location][]. + +All this goodness is in gnome-keyring master or 2.91.0 + +</p> + + [PKCS#11]: http://www.rsa.com/rsalabs/node.asp?id=2133 + [PKCS#11 URIs]: http://tools.ietf.org/html/draft-pechanec-pkcs11uri-02 + [common system location]: http://wiki.cacert.org/Pkcs11TaskForce diff --git a/content/technical/introspecting-certificates.md b/content/technical/introspecting-certificates.md new file mode 100644 index 0000000..501a40f --- /dev/null +++ b/content/technical/introspecting-certificates.md @@ -0,0 +1,53 @@ +Title: Introspecting Certificates +Date: 2011-09-29 +Tags: technical, security, gnome +Slug: introspecting-certificates + +Today I merged in a contribution from Evan Nemerson for GObject +introspection support into the Gcr and Gck libraries. I ended up +tweaking thousands of lines of comments and code, +[filed][] [some][] [bugs][] and so forth. + +But the end result is you use PKCS\#11 and stuff like the [Gcr +certificate widgets][], from languages like python and javascript +(although not your browser). For example this: + + + :::javascript + const Gck = imports.gi.Gck; + const Gcr = imports.gi.Gcr; + const Gtk = imports.gi.Gtk; + + /* TODO: From pkcs11.h */ + const CKA_CLASS = 0; + const CKO_CERTIFICATE = 1; + const CKA_VALUE = 17; + const URI = "pkcs11:object-type=cert"; + + Gtk.init(null, null); + var dialog = new Gtk.Dialog(); + + var viewer = new Gcr.ViewerWidget(); + dialog.get_content_area().pack_start(viewer, true, true, 0); + + var modules = Gck.modules_initialize_registered(null); + var objects = Gck.modules_objects_for_uri(modules, URI, Gck.SessionOptions.READ_ONLY); + + objects.forEach(function(object) { + viewer.load_data(null, object.get_data(CKA_VALUE, null)); + }); + + viewer.show(); + dialog.run(); + + +... will pop up a window show up with every certificate on every smart +card and key storage [you have configured][]. All of this goodness is in +[gnome-keyring git master][]. + + [filed]: https://bugzilla.gnome.org/show_bug.cgi?id=660436 + [some]: https://bugzilla.gnome.org/show_bug.cgi?id=581525 + [bugs]: https://bugzilla.gnome.org/show_bug.cgi?id=660352 + [Gcr certificate widgets]: http://developer.gnome.org/gcr/unstable/gcr-GcrCertificateWidget.html + [you have configured]: http://p11-glue.freedesktop.org/doc/p11-kit/config-example.html + [gnome-keyring git master]: http://git.gnome.org/browse/gnome-keyring/?h=master diff --git a/content/technical/kerberos-and-active-directory-logins.md b/content/technical/kerberos-and-active-directory-logins.md new file mode 100644 index 0000000..faad741 --- /dev/null +++ b/content/technical/kerberos-and-active-directory-logins.md @@ -0,0 +1,134 @@ +Title: Kerberos and Active Directory Logins +Date: 2012-06-15 +Tags: technical, security, gnome +Slug: kerberos-and-active-directory-logins + +Ray and I and some others have been working on making it easy to use +Kerberos single sign on with GNOME 3.6. The feature itself isn't super +revolutionary. You sign in with your realm login (eg: your Active +Directory user name and password) and then you can go on and use other +services with that same kerberos sign in. + +You could already do this, but setting it up was hard ... and setting it +up so it couldn't be trivially hacked was even harder. If you just use +pam_krb5 without 'enrolling' your machine an attacker can log in as +anyone (woooooo). ... and keeping it running without breaking down on +you was even harder than that, especially for mobile environments. + +So I've been working a lot on making this easy to setup; auto +discovering the domain/realm, its settings and as much information as +possible. Last week [some user visible][] changes [landed into +gnome-control-center][] so here are some screenies. + +You'll notice the new *Enterprise Login* mode of the *Add account* +dialog: + + + +It lets you add users from an Active Directory domain or [FreeIPA][] +(soon) realm, and perhaps others in the future. Any domains we already +know about are in the drop down. If this is the first time you're using +the feature, we try and automatically discover the domain from your DHCP +DNS domain name. We automatically discover what kind of realm/domain +we're dealing with, all the other settings, and whether it's valid or +not. + +Login details for the user are typed in, and then we bonk the *Add* +button: + + + +We try to be intelligent about validation and give good feedback: + + + + + + + +If the domain requires administrative credentials to enroll the local +machine, then we prompt for those. Active Directory on Windows 2003 and +later [don't require admin creds by default][]. FreeIPA does. + + + +And voila, the user is added. Only the users specifically added should +be able to log in; there's actually a bit of work to do on that, but +that's the plan. If an admin wants to enable any domain user to log in +on the machine, then they can enroll the machine using the command line +or admin tools. Both are supported, just not both in +gnome-control-center. + +Here I added two users, Fry and Leela. Not sure why one of them showed +up with their full name and the other not. Something to fix... + + + +Under the hood a the enrollment in realms is managed by a small DBus +on-demand system service called [realmd][]. realmd can also be driven +using command line tools, which expose additional options. + +It was important to me to make sure that the diagnostics are clear. So +many of these tools throw up cryptic error messages without anywhere to +go to figure out 'Why?'. So we try hard to have user visible error +messages, and then very clear diagnostic output on the console when +performing these operations, that looks like: + + :::text + * Looking up our DHCP domain + * Searching for kerberos SRV records for domain: _kerberos._udp.ad.thewalter.lan + * Searching for sub zone on domain: _msdcs.ad.thewalter.lan + * dc.ad.thewalter.lan:88 + * Found AD style DNS records on domain + * Successfully discovered realm: AD.THEWALTER.LAN + +Hmmm, what else ... Ray's been working on other parts of this: fixing +the user accounts panel so it makes sense for non-local users. And +making sure that the Kerberos tickets we get at login are correctly +renewed and reauthenticated. + +### SSSD + +These guys. Props to the SSSD guys. They've been working hard to make +that daemon the perfect client for Kerberos/IPA/AD. It's a modern clean +implementation, and makes stuff like using your domain login when not +attached to the domain really reliable and easy. + +### No mo' NTP Time Syncing + +I've been running around the kerberos stack trying to fix issues that +cause configuration problems, fragility or just plain nastiness. For +example: + +For decades now kerberos implementations have pretty much required you +to sync your time up with the kerberos server. It makes you roll your +eyes that a security protocol relies so much on time for security, when +the syncing of that time is almost always insecure. But oh well. + +Anyway, for the good news. 15 years ago [these guys figured out][] how +to do kerberos without time syncing. And bit by bit their ideas have +made it into kerberos implementations, but nobody new about it because +the there were tons of fiddly bits that made assumptions about time +syncing. I did a few last patches to sort out some issues, which have +been accepted by MIT Kerberos. + +Anyway, that was long enough, there's lots more, but it's starting to +get boring ... + +Lots of patches are being merged as we speak, but if you want to test +this stuff out right now, ping me on IRC \#gnome-os on gimpnet, and I'll +help you get started. + + [some user visible]: https://live.gnome.org/Design/Proposals/UserIdentities?action=AttachFile&do=get&target=user-accounts-add.png + [landed into gnome-control-center]: https://bugzilla.gnome.org/show_bug.cgi?id=677548 + []: http://2.bp.blogspot.com/-YAnYRd1vlMI/T9sdGxrDUiI/AAAAAAAABXI/yh4uS9doQ5k/s1600/1-add-account.png + [FreeIPA]: http://freeipa.org/page/Main_Page + [1]: http://1.bp.blogspot.com/-q0FBQlA8If8/T9sdfi5NqYI/AAAAAAAABYA/psQ0es2-Z-Q/s1600/2-enterprise-login.png + [2]: http://2.bp.blogspot.com/-dcn3wCsPd-A/T9sdIijrqzI/AAAAAAAABXU/ch5I1l9JnRg/s1600/3-validate-domain.png + [3]: http://2.bp.blogspot.com/-H91ZbCQ0WME/T9sdJDRfk7I/AAAAAAAABXc/cZwm-oCXMso/s1600/4-validate-login.png + [4]: http://3.bp.blogspot.com/-D56zzIljSFY/T9sdJqkuxVI/AAAAAAAABXo/oY8D0VE-8AI/s1600/5-validate-password.png + [don't require admin creds by default]: http://technet.microsoft.com/en-us/library/cc780195%28WS.10%29.aspx + [5]: http://2.bp.blogspot.com/-D1mEGikSSaY/T9sdLbl0vXI/AAAAAAAABXw/g5h5AVD9cXo/s1600/6-administrator.png + [6]: http://1.bp.blogspot.com/-48xy1QCK5i4/T9sdMemzYWI/AAAAAAAABX0/VReT8j4eqgk/s1600/7-added-accounts.png + [realmd]: http://cgit.freedesktop.org/~stefw/realmd/ + [these guys figured out]: http://static.usenix.org/publications/compsystems/1996/win_davis.pdf diff --git a/content/technical/more-secure-with-less-security.md b/content/technical/more-secure-with-less-security.md new file mode 100644 index 0000000..fee65f9 --- /dev/null +++ b/content/technical/more-secure-with-less-security.md @@ -0,0 +1,11 @@ +Title: More secure with less "security" +Date: 2013-08-16 16:23 +Tags: technical, security, gnome +Slug: more-secure-with-less-security + +At GUADEC in Brno, I gave a talk about usability and security prompts. + +The [video and slides is now online][]. I'm really impressed with how +fast the videos became available this time around. + + [video and slides is now online]: http://www.superlectures.com/guadec2013/more-secure-with-less-security diff --git a/content/technical/my-talk-usable-crypto-on-gnome.md b/content/technical/my-talk-usable-crypto-on-gnome.md new file mode 100644 index 0000000..739e93b --- /dev/null +++ b/content/technical/my-talk-usable-crypto-on-gnome.md @@ -0,0 +1,19 @@ +Title: My Talk: Usable Crypto on GNOME +Date: 2010-07-30 +Tags: technical, security, gnome +Slug: my-talk-usable-crypto-on-gnome + +I gave a talk on Wednesday about using a common certificate and key +store across the desktop and using common widgets for crypto bits. + + +Sadly the talk was at the same time as a big release team +announcement/talk. Notwithstanding more people came than I expected. + + +The [slides are here][]. + +Discussing this topic with people has resulted in lots of cool +developments and ideas. More to come. + + [slides are here]: http://memberwebs.com/stef/misc/guadec-usable-crypto.pdf diff --git a/content/technical/part-of-postgresql-90.md b/content/technical/part-of-postgresql-90.md new file mode 100644 index 0000000..b7bae8c --- /dev/null +++ b/content/technical/part-of-postgresql-90.md @@ -0,0 +1,28 @@ +Title: Part of Postgresql 9.0... +Date: 2010-05-07 +Tags: technical +Slug: part-of-postgresql-90 + +I've +contributed to another open source project, Postgresql. My first +contribution [made it into version 9.0][].</span> + +I +worked on the ```samenet``` and +```samehost``` +host +based access control feature, which lets you grant database access to +hosts on the physical subnets that the postgresql server is attached +to. + +Previously many postgresql +deployments for clients used to have +```0.0.0.0/0``` +in +the +pg_hba.conf +file, +because more limited access controls were too brittle and would +inevitably fall over when the client renumbered their network. + + [made it into version 9.0]: http://developer.postgresql.org/pgdocs/postgres/release-9-0.html diff --git a/content/technical/redesigning-the-seahorse-experience.md b/content/technical/redesigning-the-seahorse-experience.md new file mode 100644 index 0000000..0cfb5c6 --- /dev/null +++ b/content/technical/redesigning-the-seahorse-experience.md @@ -0,0 +1,103 @@ +Title: Redesigning the Seahorse Experience +Date: 2011-10-17 +Tags: technical, security, gnome +Slug: redesigning-seahorse-experience + +As part of the work on getting smart cards into Seahorse, there's some +design work that needs to be done to make the new functionality usable. +In particular, the overarching design goal is that Seahorse isn't a tool +we expect users to "learn". Actions should follow mostly from the +passwords and keys that have been accumulated. + +So I've been working on the experience a bit. Some concepts: + + +- When most user's arrive, they should see their personal passwords, + and keys or certificates if they have any listed. In this mode we + combine items from all the various places these things are stored. +- The user sees a certificate regardless of it's on a smart card, + Gnome Keyring, or in NSS's store. +- Each item should have an icon, and text describing what it is. +- By default only 'personal' passwords and keys are shown. Those + belonging to the user. So things like Trusted Root CA's don't litter + the combined listing. This is easily changed on the 'View' menu. +- The list is easily filterable by typing in the box. +- We make sure to unlock the default password keyring when seahorse is + started. Normally it's unlocked already, but just in case. + +A screenshot (the toolbar needs some work): + + + +So the experience starts off really straight forward, no need to clutter +things with where these items are coming from. If the user has a smart +card inserted, the certificates and keys on the smart card will also +show up there. + +In order to see and manage stuff related to where the keys come from, +the user chooses 'View | Places' from the menu. A sidebar appears, which +supports the following concepts: + + +- Click on a place to view items from a that 'place'. +- See which keyrings exist, delete, change master passwords etc. +- See smart cards that are inserted. + + +A screenshot (the places need some tweaking): + + + + +Something I've also been playing with is an easy to use multiple +selection. For example I'd like the user to be able to select multiple +places (let's say all the password keyrings), and see their items +together. + +I wanted to do something where check boxes are shown to the right of +each 'place' when the Alt-key is depressed. The user then would click +those checkboxes to select multiple places, and show their items +together. Once one box is checked, all check boxes remain visible. This +fits in with the concept of showing keyboard mnemonics when Alt is +pressed, and also GNOME seems to be using a +show-advanced-shortcuts-on-Alt-key concept here and there, and I thought +this would fit nicely. However, sadly the window manager grabs the mouse +when Alt is held down, for the purpose of full window drags, so I had to +think of something else. + +What I came up with was that a check box is shown next to a place when +that place is selected and focused. If the user clicks that check box, +then all the check boxes next to the other places become visible, and +more than one can be selected. As long as one is checked, all the check +boxes are visible. Works well enough, and should work with touch devices +as a bonus. But I'm not as satisfied as I would have been with the Alt +concept. + +Of course this is an advanced feature, and not necessarily something +that needs to be super 'beautiful' but none the less it was interesting +to try out these alternatives. + +There's lots more [design][] [work][] that needs to be done. For +example, I'd also like to integrate the new control center style +'Unlock' button in a way that makes sense. It gets complicated because +there's more than one thing to unlock (ie: smart cards, password +keyrings, etc.) + +Most of this is done in such a way that the pieces can be reused +elsewhere in other apps as well. Available right now in the seahorse +[refactor branch][] and depends on an up to date [build of the Gcr +library][]. Hopefully I'll be merging this into seahorse master soon. + +Oh, and thanks to [NLnet][] for sponsoring [Collabora][] to work on the +Seahorse smart card support. + +</p> + + []: http://3.bp.blogspot.com/-utsxZuycKuQ/TpxZ9iNZ5oI/AAAAAAAAAjI/wM5Fxxv0FQ0/s1600/seahorse-combined-view.png + [1]: http://1.bp.blogspot.com/-zY7nRuOwnx0/TpxbaKD0MKI/AAAAAAAAAjY/nwlTKih3DYw/s1600/screenshot-with-places2.png + [design]: https://bugzilla.gnome.org/show_bug.cgi?id=656956 + [work]: https://bugzilla.gnome.org/show_bug.cgi?id=644214 + [refactor branch]: http://git.gnome.org/browse/seahorse/log/?h=refactor + [build of the Gcr library]: http://git.gnome.org/browse/gcr/log/ + [NLnet]: http://nlnet.nl/ + [Collabora]: http://www.collabora.com/ diff --git a/content/technical/smart-card-icons.md b/content/technical/smart-card-icons.md new file mode 100644 index 0000000..d573b2a --- /dev/null +++ b/content/technical/smart-card-icons.md @@ -0,0 +1,30 @@ +Title: Smart card icons +Date: 2011-09-23 +Tags: technical, security, gnome +Slug: smart-card-icons + +I've been working on smart card integration into Seahorse, and as part +of that [we need icons for smart cards][]. I had fun putting together +something today: + + + +Obviously not perfect, but I'm happy with the result. The tools and info +in gnome-icon-theme are really nice. + +At some point when the illustrious icon designers get a chance, it'd be +cool to have a smart card icon in gnome-icon-theme. I imagine they'd +want to fix it up or replace it. But for now this will live in the gcr +library. + +[NLnet][] is sponsoring my employer [Collabora][] to work on basic smart +card viewing and simple management in Seahorse. Shortly I'll be posting +more goodies coming related to this, including stuff that fixes up +Seahorse for casual users as well. + +</p> + + [we need icons for smart cards]: https://bugzilla.gnome.org/show_bug.cgi?id=659951 + []: http://4.bp.blogspot.com/-M8yIP2e-oxM/TnylJDVu0oI/AAAAAAAAAgc/5CeHEvK5Xys/s1600/gcr-smart-card.png + [NLnet]: http://nlnet.nl/ + [Collabora]: http://www.collabora.com/ diff --git a/content/technical/talk-at-guadec-on-integration-of-certificate-and-key-storage.md b/content/technical/talk-at-guadec-on-integration-of-certificate-and-key-storage.md new file mode 100644 index 0000000..9d27cc6 --- /dev/null +++ b/content/technical/talk-at-guadec-on-integration-of-certificate-and-key-storage.md @@ -0,0 +1,87 @@ +Title: Talk at GUADEC on Integration of Certificate and Key Storage +Date: 2010-05-14 +Tags: technical, security, gnome +Slug: talk-at-guadec-on-integration-on + +I'll be attending GUADEC for the first time. Not only that but I'll be +giving a talk. I'm a bit nervous, but excited! + +The talk is about integrating various +applications using keys and certificates to use a common key +storage. + + + + + + + + + + + + +Currently each application puts their +certificates and private keys in distinct locations, which make it hard +for the user, but also for application developers, since new +applications integrating crypto need to work out a whole raft of things +such as secure key storage. + + + + + +- Currently when you need to use a + certificate with network-manager and a wireless connection, you have + to specify three files in a fragile formats. +- When using certificates with + evolution or firefox or thunderbird each application stores them in + their own key storage. +- SSH Keys (which are in fact the same + sort as the above) are stored in `~/.ssh` + + + +It's a little bit like each application +not sharing a filesystem, but having their own part of the disk to write +their documents to. With GPG we have all applications sharing the same +keyring (per-user obviously), but so far this hasn't been the case with +X.509 certificates and keys. + + + + + + + + + + + + +Because of the development in +gnome-keyring around a standard called PKCS\#11 it's now possible to +integrate the key storage between applications, and in our talk we'll +discuss how to do this in a secure, transparent and configurable +way. + + + + + + + + + + + + + + +This also means it'll be easier for +applications to gain support for keys, and to have smart card related +features and other stuff like that in the future.</span> + + + + diff --git a/content/technical/the-security-devroom-at-fosdem.md b/content/technical/the-security-devroom-at-fosdem.md new file mode 100644 index 0000000..a7792be --- /dev/null +++ b/content/technical/the-security-devroom-at-fosdem.md @@ -0,0 +1,32 @@ +Title: The security devroom at FOSDEM +Date: 2011-02-13 +Tags: technical, security, gnome +Slug: security-devroom-at-fosdem + +Went to FOSDEM last weekend. It was a cool and crazy conference: packed +rooms, great talks, good friends, much beer. I enjoyed finally meeting +the [Collabora][] guys I'm now working with. + +I hung out in the absolutely packed security devroom the first day, +superbly [organized by Martin Paljak from OpenSC][]. Lots of interesting +and insightful talks, and met people that I'd previously only interacted +with online. + +Nikos and I both gave talks about using PKCS\#11 as glue to give a +better crypto user experience no matter which crypto library an +application uses. There was a lot of great discussion, ideas and +participation. I'm looking forward to working more folks on this stuff. + + + +[My talk][] discussed [research into trust assertions][], and a new +project called p11-kit. Video [here][]. + +Part of my work at Collabora has been to make certificates and crypto on +the desktop just work. Stay tuned! + + [Collabora]: http://www.collabora.co.uk/ + [organized by Martin Paljak from OpenSC]: http://www.opensc-project.org/opensc/wiki/FOSDEM2011 + [My talk]: http://thewalter.net/stef/misc/trust-assertion-notes.ps + [research into trust assertions]: http://people.collabora.co.uk/~stefw/trust-assertions.html + [here]: http://video.fosdem.org/2011/devrooms/security/security_1630__trust__walter.webm diff --git a/content/technical/these-arent-the-benchmarks-youre-looking-for.md b/content/technical/these-arent-the-benchmarks-youre-looking-for.md new file mode 100644 index 0000000..1a81e8b --- /dev/null +++ b/content/technical/these-arent-the-benchmarks-youre-looking-for.md @@ -0,0 +1,27 @@ +Title: These aren't the benchmarks you're looking for +Date: 2010-10-19 +Tags: technical, gnome +Slug: this-arent-benchmarks-youre-looking-for + + +I was evaluating use of [GObject][] for small plentiful +short-lived objects in [libgck][]. I wanted to see how their performance +compared to custom reference counted structures. Turns out it's not as +bad as I imagined. + +The speed difference on my system, with a [simple test program][], ended +up being around a factor of eight. Most of that cost is due to +`pthread_mutex_lock` and `pthread_mutex_unlock`. + + :::text + $ ./test-gobject-speed + struct x 10000000 = 1.091700 + object x 10000000 = 8.578848 + +Note that I didn't use heavy weight stuff like properties or signals in +my benchmark. But I don't need those for this use case. + + + [GObject]: http://library.gnome.org/devel/gobject/unstable/ + [libgck]: http://stef.thewalter.net/2010/10/introducing-libgck-pkcs11-gobject.html + [simple test program]: http://thewalter.net/stef/misc/test-gobject-speed.c diff --git a/content/technical/viewer-for-certificate-and-key-files.md b/content/technical/viewer-for-certificate-and-key-files.md new file mode 100644 index 0000000..cdbba5b --- /dev/null +++ b/content/technical/viewer-for-certificate-and-key-files.md @@ -0,0 +1,44 @@ +Title: Viewer for Certificate and Key files +Date: 2011-09-01 +Tags: technical, security, gnome +Slug: viewer-for-certificate-and-key-files + +So a lot of the work I do doesn't have any user interface. The best user +interface is no user interface, well one that isn't needed. But recently +I've been working some tools to view the plethora of certificate and key +formats out there. So I couldn't resist blogging about this, because I +get to use screenshots, heh. + +The [NLnet Foundation][] has been sponsoring Collabora to do some smart +card work, and this is part of that. This work is part of the [GCR +library][], and is merged into gnome-keyring master. + +Here's a certificate viewer showing a certificate: + + + +Details can then be expanded: + + + +And here's what a key looks like. + + + +When the file is locked (like a PKCS#12 file) it can be unlocked like +this video shows. It also shows the appalling state of affairs with +hundreds of certificate authoritities, dubious and otherwise. + +<iframe width="640" height="480" src="//www.youtube.com/embed/N67Zl6Zlx_g" frameborder="0" allowfullscreen></iframe> + +In the next release, we'll have an "Import" button in the bottom right +corner, so that the certificates and keys being viewed can be imported +and used [into common locations][]. Hopefully we'll also get able to +view PGP keys in files (before importing them). + +The widgets you see displaying the certificates can be used by any +application from the GCR library. + + [NLnet Foundation]: http://nlnet.nl/ + [GCR library]: http://developer.gnome.org/gcr/unstable/ + [into common locations]: https://live.gnome.org/CryptoGlue diff --git a/content/technical/vmware-player-on-fedora-16.md b/content/technical/vmware-player-on-fedora-16.md new file mode 100644 index 0000000..01f3938 --- /dev/null +++ b/content/technical/vmware-player-on-fedora-16.md @@ -0,0 +1,36 @@ +Title: VMWare Player on Fedora 16 +Date: 2011-10-28 +Tags: technical, security +Slug: vmware-player-on-fedora-16 + +I have some VMWare VM's I've been using here and there. I probably +should convert them to Virtual Box, but I've had a rough time getting +that working as well. + +So ... every time you upgrade the kernel, VMWare barfs because kernel +headers have changed. Usually I look around for patches to the VMWare +sources, but this time there were none I could find, so I figured it was +my turn. + +[This simple patch][] makes VMWare Player 4.0.0 work with Linux 3.1.0. +At least it seems to work. What I did to patch it in: + + :::sh + $ mkdir /tmp/vmware + $ cd /tmp/vmware + $ wget http://thewalter.net/stef/misc/vmnet-4.0.0-linux-3.1.0.patch + $ tar -xvf /usr/lib/vmware/modules/source/vmnet.tar + $ patch -p0 < vmnet-4.0.0-linux-3.1.0.patch + $ sudo cp /usr/lib/vmware/modules/source/vmnet.tar /usr/lib/vmware/modules/source/vmnet.tar.bak + $ sudo tar -cvf /usr/lib/vmware/modules/source/vmnet.tar vmnet-only + +And then run vmplayer and let it do its install thing. It says that the +services fail to start (systemd incompatibility), but it works +regardless. + +Note: If you try this and it doesn't work for you (or makes your doggy +sad), don't complain to me. [Complain to VMWare][]. + + + [This simple patch]: http://thewalter.net/stef/misc/vmnet-4.0.0-linux-3.1.0.patch + [Complain to VMWare]: http://communities.vmware.com/index.jspa |
