Search Results: "cas"

4 January 2012

Matthew Garrett: Android, GPL violations and Google

A bit over a year ago, I wrote about how an incredible number of Android tablets on the market were in violation of the terms of the GPL. I've had rather a lot else to do since then so it's now awfully out of date - but taking a quick browse through the current stack of cheaper devices indicates that things aren't all that much better. We've got source code for some chipsets that were missing it before, but to compensate we've got a whole bunch of new hardware that's entirely lacking. It's all pretty poor, really.

At the time, I wrote the following:

"(Side note: People sometimes ask why Google aren't doing more to prevent infringing devices. For the vast majority of these cases, Google's sole contribution has been to put Android source code on a public website. Red Hat own more of the infringing code than Google do. There's no real reason why Google should be the ones taking the lead role here, and there's fairly sound business reasons why it's not in their interest to do so)"

Factually speaking, nothing's changed. Each of these devices contains code owned by Google, and Google could absolutely take legal action against the vendors. Equally, so could Red Hat, Intel, Nokia and dozens of other companies who hold copyright on portions of the code carried on these devices, and so could thousands of individuals around the world. Nobody's obliged to enforce their copyrights, and in the absence of anyone else doing so it's unreasonable to insist that Google should do it.

However.

Google gives Android away. This seems like an odd thing for them to do, given that it's a significant engineering effort and costs a lot of money to produce. But remember what Android brings to Google - it's a platform with a well-integrated mechanism for distributing advertising to users. Scanning the market shows a huge number of ad-supported apps, and Google's getting money for every single one of those that gets shown. The more Android devices, the bigger the market for apps - and the wider their advertising reach.

In other words: unscrupulous hardware vendors save money by ignoring their GPL obligations. This lets them appeal on price, increasing the number of Android devices in use and increasing Google's profits. Google makes money off other people's violation of the GPL.

Could Google do anything to stop this? Yes. They could sue for copyright infringement, but that kind of thing's time consuming and awkward and any argument about the GPL always seems to end up as a big argument involving conspiracy theories. Instead, Google could attach some extra conditions to the Android trademark. Requiring that the trademark only be attached to GPL-compliant products ought to allow Google to take advantage of the existing well-tested mechanisms for seizing counterfeit goods, providing a direct economic incentive for companies to come into compliance. For added marks, they could restrict the adwords code to devices that use the trademark - if the vendor removes the trademark, applications depending on the adwords functionality would refuse to run and Google wouldn't make money off the infringing hardware.

Or, of course, they could just carry on making extra money as a result of vendors denying users the freedoms granted by the copyright holders. Although that sounds kind of evil to me.

Edit: You probably also want to read the followup post here.

comments

3 January 2012

Matthew Garrett: TVs are all awful

A discussion a couple of days ago about DPI detection (which is best summarised by this and this and I am not having this discussion again) made me remember a chain of other awful things about consumer displays and EDID and there not being enough gin in the world, and reading various bits of the internet and wikipedia seemed to indicate that almost everybody who's written about this has issues with either (a) technology or (b) English, so I might as well write something.

The first problem is unique (I hope) to 720p LCD TVs. 720p is an HD broadcast standard that's defined as having a resolution of 1280x720. A 720p TV is able to display that image without any downscaling. So, naively, you'd expect them to have 1280x720 displays. Now obviously I wouldn't bother mentioning this unless there was some kind of hilarious insanity involved, so you'll be entirely unsurprised when I tell you that most actually have 1366x768 displays. So your 720p content has to be upscaled to fill the screen anyway, but given that you'd have to do the same for displaying 720p content on a 1920x1080 device this isn't the worst thing ever in the world. No, it's more subtle than that.

EDID is a standard for a blob of data that allows a display device to express its capabilities to a video source in order to ensure that an appropriate mode is negotiated. It allows resolutions to be expressed in a bunch of ways - you can set a bunch of bits to indicate which standard modes you support (1366x768 is not one of these standard modes), you can express the standard timing resolution (the horizontal resolution divided by 8, followed by an aspect ratio) and you can express a detailed timing block (a full description of a supported resolution).

1366/8 = 170.75. Hm.

Ok, so 1366x768 can't be expressed in the standard timing resolution block. The closest you can provide for the horizontal resolution is either 1360 or 1368. You also can't supply a vertical resolution - all you can do is say that it's a 16:9 mode. For 1360, that ends up being 765. For 1368, that ends up being 769.

It's ok, though, because you can just put this in the detailed timing block, except it turns out that basically no TVs do, probably because the people making them are the ones who've taken all the gin.

So what we end up with is a bunch of hardware that people assume is 1280x720, but is actually 1366x768, except they're telling your computer that they're either 1360x765 or 1368x769. And you're probably running an OS that's doing sub-pixel anti-aliasing, which requires that the hardware be able to address the pixels directly which is obviously difficult if you think the screen is one size and actually it's another. Thankfully Linux takes care of you here, and this code makes everything ok. Phew, eh?

But ha ha, no, it's worse than that. And the rest applies to 1080p ones as well.

Back in the old days when TV signals were analogue and got turned into a picture by a bunch of magnets waving a beam of electrons about all over the place, it was impossible to guarantee that all TV sets were adjusted correctly and so you couldn't assume that the edges of a picture would actually be visible to the viewer. In order to put text on screen without risking bits of it being lost, you had to steer clear of the edges. Over time this became roughly standardised and the areas of the signal that weren't expected to be displayed were called overscan. Now, of course, we're in a mostly digital world and such things can be ignored, except that when digital TVs first appeared they were mostly used to watch analogue signals so still needed to overscan because otherwise you'd have the titles floating weirdly in the middle of the screen rather than towards the edges, and so because it's never possible to kill technology that's escaped into the wild we're stuck with it.

tl;dr - Your 1920x1080 TV takes a 1920x1080 signal, chops the edges off it and then stretches the rest to fit the screen because of decisions made in the 1930s.

So you plug your computer into a TV and even though you know what the resolution really is you still don't get to address the individual pixels. Even worse, the edges of your screen are missing.

The best thing about overscan is that it's not rigorously standardised - different broadcast bodies have different recommendations, but you're then still at the mercy of what your TV vendor decided to implement. So what usually happens is that graphics vendors have some way in their drivers to compensate for overscan, which involves you manually setting the degree of overscan that your TV provides. This works very simply - you take your 1920x1080 framebuffer and draw different sized black borders until the edge of your desktop lines up with the edge of your TV. The best bit about this is that while you're still scanning out a 1920x1080 mode, your desktop has now shrunk to something more like 1728x972 and your TV is then scaling it back up to 1920x1080. Once again, you lose.

The HDMI spec actually defines an extension block for EDID that indicates whether the display will overscan or not, but doesn't provide any way to work out how much it'll overscan. We haven't seen many of those in the wild. It's also possible to send an HDMI information frame that indicates whether or not the video source is expecting to be overscanned or not, but (a) we don't do that and (b) it'll probably be ignored even if we did, because who ever tests this stuff. The HDMI spec also says that the default behaviour for 1920x1080 (but not 1366x768) should be to assume overscan. Charming.

The best thing about all of this is that the same TV will often have different behaviour depending on whether you connect via DVI or HDMI, but some TVs will still overscan DVI. Some TVs have options in the menu to disable overscan and others don't. Some monitors will overscan if you feed them an HD resolution over HDMI, so if you have HD content and don't want to lose the edges then your hardware needs to scale it down and let the display scale it back up again. It's all awful. I recommend you drink until everything's already blurry and then none of this will matter.

comments

Jon Dowland: instagr/am/bient

Artwork from track 17, by Richard Ginns. CC-By-SA

Via Boing Boing, I stumbled across an excellent audio/visual project called instagr/am/bient: 25 ambient pieces of music inspired by 25 photos on the instagram photo service. The original upload featured a high-resolution PDF of the pictures, with MP3 audio and low-quality embedded copies of each picture as each track's artwork. I was a little disappointed about this, as I thought the tracks would be best appreciated next to the higher-quality picture that inspired them. So, I fixed it: Instagr/am/bient (HD images) This was possible thanks the liberal licensing of the original, but also two excellent pieces of software: pdfimages (from the poppler-utils package) and eyeD3, which made it not just possible but trivial. See also the 9.5M accompanying PDF. I do like what people are creating with instagram; I also like the "tumble-blog" approach to sharing similar images. I occasionally rotate the indexpics on my site; perhaps I should do so more often, and publish the new ones on my blog, too.

Russell Coker: Standardising Android

Don Marti wrote an amusing post about the lack of standards for Android phones and the fact that the iPhone has a better accessory market as a result [1]. I d like to see some Android phones get standardised in a similar manner to the PC. The big thing about the IBM PC compatible market was that they all booted the same way, ran the same OS and applications, had the same expansion options, connectors, etc. The early PCs sucked in many ways (there were many other desktop computers in the 80 s that were better in various ways) but the larger market made the PC win. The PC even killed the Mac! This is something we should remember now when discussing the iPhone. I d like to see different Android phones that can run the same OS with the same boot loader. Having HTC, LG, Samsung, and others all sell phones that can run the same version of CyanogenMod and have the same recovery options if a mistake is made when loading CyanogenMod shouldn t be any more difficult than having IBM, Compaq, HP, DEC, Dell, and others selling PCs that run the same versions of all the OSs of the day and had the same recovery options. Then there should be options for common case sizes. From casual browsing in phone stores it seems that most phones on sale in Australia are of a tablet form without a hardware keyboard, they have a USB/charger socket, an audio socket, and hardware buttons for power, volume up/down, and home with the settings and back buttons being through the touch-screen on the Galaxy S but hardware in most others. A hardware button to take a picture is available in some phones. The variation in phone case design doesn t seem to be that great and there seems to be a good possibility for a few standards for common formats, EG large tablet, small tablet, and large tablet with hardware keyboard. The phone manufacturers are currently competing on stupid things like how thin a phone can be while ignoring real concerns of users such as having a phone that can last for 24 hours without being charged! But they could just as easily compete on ways of filling a standard case size, with options for screen resolution, camera capabilities, CPU, GPU, RAM, storage, etc. There could also be ways of making a standard case with several options, EG having an option for a camera that extends from the back of the case for a longer focal length such an option wouldn t require much design work for a second version of anything that might connect to the phone. Also standards would need to apply for a reasonable period of time. One advantage that Apple has is that it has only released a few versions of the iPhone and each has been on sale for a reasonable amount of time (3 different sizes of case in 4 years). Some of the Android phones seem to only be on sale in mass quantities for a few months before being outdated, at which time many of the stores will stop getting stock of matching accessories. Finally I d be a lot happier if there was good support for running multiple Android phones with the same configuration. Then I could buy a cheap waterproof phone for use at the beach and synchronise all the configuration before leaving home. This is a feature that would be good for manufacturers as it would drive the average rate of phone ownership to something greater than 1 phone per person.

[1] http://zgp.org/~dmarti/misc/little-android-phone-why-so-sad/

Raphaël Hertzog: My Debian Activities in December 2011

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (364.18 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects.

Dpkg and Multiarch I had some hope to have a multiarch-enabled dpkg in sid for Christmas as Guillem told me that it was realistic. Alas Guillem got sick. We re in January and we re still not there. While some of Guillem s commits in December were related to multi-arch, the size of his pu/multiarch/master branch did not really shrink. We still have 36 commits to merge most of the work he did was refactoring some parts of the code that were already merged. And he initiated some discussion on interface changes. I participated to those discussions hoping to bring them to a quick resolution. I m still maintaining my own pu/multiarch/full branch, it is based on Guillem s branch but with further fixes that I developed and that he has not yet merged and with a change reverted (Guillem s branch allows crossgrading packages between different architectures while dpkg does not manage this correctly yet). I can only hope that January will be the last month of this never-ending saga. It s been one year since I started working on this project.

Misc dpkg work I reviewed (and later merged) a patch of Kees Cook to enhance dpkg-buildflags so that it can report which hardening features are enabled. This feature might then be used by tools like lintian to detect missing hardening features. I mentored Gianluca Ciccarelli who is trying to enhance dpkg-maintscript-helper to take care of replacing a directory by a symlink and vice-versa. I took care of #651993 so that dpkg-mergechangelogs doesn t fail when it encounters an invalid version in the changelog, and of #652414 so that dpkg-source --commit accepts a relative filename when a patch file is explicitly given. Guillem also merged a fix I developed for LP#369898. Packaging work WordPress 3.3 came out so I immediately packaged it. Despite my upstream bug report, they did not update their GPL compliance page which offers the corresponding sources for what s bundled in the tarball. So I hunted for the required sources myself, and bundled them in the debian.tar.xz of the Debian source package. It s a rather crude solution but this allowed me to close the release critical bug #646729 and to reintroduce the Flash files that were dropped in the past which is great since the Flash-based file uploader is nicer than the one using the browser s file field. Quilt 0.50 came out after 2 years of (slow) development. The Debian package has many patches and several of them had to be updated to cope with the new upstream release. Fortunately some of them were also merged upstream. It still took an entire morning to complete this update. I also converted the packaging from CDBS to dh with a short rules file. Zim 0.54 came out and I immediately updated the package since it fixed a bug that was annoying me. Review of the ledgersmb packaging As the sql-ledger maintainer (and a user of this software for my accounting), I have been hoping to get ledgersmb packaged as a possible replacement for it. I have been following the various efforts initiated over time but none of them resulted in a real package in Debian. This is a real pity so I tried to fix this by offering to sponsor package uploads. That s why I did a first review of the packaging. It took several hours because you have to explain everything that s not good enough. I also filed a wishlist bug against lintian (#652963) to suggest that lintian should detect improper usage of dpkg-statoverride (this is a mistake that was present in the package that I reviewed). nautilus-dropbox work I wanted to polish the package in time for the Ubuntu LTS release and since Debian Import Freeze is in January, I implemented some of the important fixes that I wanted. The Debian package diverges from upstream in that the non-free binaries are installed in /var/lib/dropbox/ instead of $HOME.
Due to a bug, the files were not properly root-owned so I first fixed this (unpacking the tarball as root lead to reuse of the embedded user & group information, and those information changed recently on the Dropbox side apparently). Then we recently identified other problems related to proxy handling (see #651065). I fixed this too because it s relatively frequent that the initial download triggered during the package configuration fails and in that case it s the user that will re-trigger a package download after having given the appropriate credentials through PackageKit. Without my fix, usage of pkexec would imply the loss of the http_proxy environment variable and thus it would not be possible for a user to download through a proxy. Last but not least I reorganized the Debian specific patches to better separate what can and should be merged upstream, from the changes that upstream doesn t want. Unfortunately Dropbox insists on being able to auto-update their non-free binaries, they are, thus, against the installation under /var/lib/dropbox and the corresponding changes. Book update We re making decent progress in the translation of the Debian Administrator s Handbook, about 6 chapters are already translated (not yet reviewed though). The liberation campaign is also (slowly) going forward. We re at 67% now (thanks to 90 new supporters!) while we were only at 60% at the start of December. Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

Jaldhar Vyas: Watch Me on Jeopardy! This Wednesday

<video controls="controls" poster="http://www.braincells.com/debian/images/jaldhar_jeopardy_howdy.jpg">
<source src="http://www.braincells.com/debian/images/jaldhar_jeopardy_howdy.mpg" type="video/mpeg">
<source src="http://www.braincells.com/debian/images/jaldhar_jeopardy_howdy.ogv" type="video/ogg">
HTML 5 Video does not seem to be supported by your browser. Download the video of my Jeopardy! "Hometown Howdy" here (MPG format) or here (OGG format). </video> Some time ago, I mentioned auditioning for Jeopardy!, Americas top TV quiz show. I didn't hear back from the producers for quite a while so I assumed I hadn't been selected but then suddenly one day in October I got a call inviting me to come out to Sony Studios in Culver City California for a taping in November. I went and it is finally airing now. So if you are in the US or Canada (the show is possibly syndicated elsewhere but I'm not sure) please be sure to watch me on Wednesday, January the 4th. I won't say how well I did until afterwards but I was quite pleased with my performance.

2 January 2012

Maximilian Attems: CPhT visit automn 2011

On my new particle physics blog (yupie to ikiwiki, thanks joey) posted some recollection of a fine, productive and busy Paris research visit to the Ecole Polytechnique. The feed agregegator for particle physics blogs got relaunched too that automn. In case you are interested in particle physics this should keep any reader updated on the Higgs hunt, black holes searches, fundamental interactions and much more.

Michal Čihař: ColorHug for Debian and in Czech

Today, I've spent some time on ColorHug software (which I've preordered some time ago). The first missing bit there were Debian packages. There are already some packages available for Ubuntu, but I've chosen clean start and did all the packaging on my own. The packages are now waiting in NEW queue (which is amazingly empty in last months) and will hopefully get accepted soon. In case you are too impatient, you can look to git repository on Alioth (you will need libgusb as well). Packaging effort lead to writing (quite minimalistic) man page for colorhug-ccmx, which I've also sent upstream. The other thing, where I can help right now (not owning the device itself) is translation. As you can see on Transifex, my task is done here and Czech translation is complete :-).

Filed under: Debian English Photography 0 comments Flattr this!

1 January 2012

Lucas Nussbaum: Re: Ubuntu vs Ruby

(original post) > If Ubuntu 12.04 if a LTS release, and Ruby 1.8.7 goes out of support in June of
> 2013, then why is the default still 1.8.7?
>
> Ruby 1.9.2 was released in 2010. Ruby 1.9.3 was released in October of this year. First, there s almost nobody in the Ubuntu development community doing any Ruby work. Packages are just imported from Debian, and Ubuntu follows what is done on the Debian side. In the Debian/Ruby team, we are currently transitioning to a new packaging helper (gem2deb) that makes it much
easier to support several Ruby versions. Once this will be done, switching to 1.9.3 by default will be very easy. We already provide a way for the sysadmin to change the default on a system. Now, doing that transition takes time, and we could have used *your* help (and could still use it). We are still quite on time to do it for Debian wheezy, but it sounds very hard to do it for Ubuntu 12.04 unless someone from Ubuntu steps
up to help.

31 December 2011

Russell Coker: Links December 2011

Barry Ritholtz wrote an insightful post quoting Federal Reserve Bank of Kansas City President Thomas Hoenig, who warns that the nation s biggest banks are putting the U.S. capitalist society at risk [1]. Big banks oppose capitalism. Glenn Greenwald has written an insightful article for Salon about the modern definition of American excellence being the killing of supposedly bad people without any due process [2]. Mazuma Mobile buys used mobile phones [3]. They can send a post-pack to ship your old mobile to them. This is good for the environment and also saves some money. Sam Varghese has written an informative article about the Trans Pacific Partnership Agreement that will probably end up benefiting US corporations at the expense of Australian citizens [4]. Cory Doctorow has written an informative article for The Guardian about the BBC DRM plans[5]. He received information that was denied in a FOI request which shows how poor the BBC case is and how bad the Ofcom oversight is. Sam Harris has written an insightful blog post about self-defense [6]. He also has many other posts that are worth reading. Aparna Roa gave an interesting TED presentation about her robotic art [7].

Russell Coker: My Blog Server was Cracked

On the 1st of August I noticed that the server which runs my blog among other things was having an occasional SEGV from a sshd process. Unfortunately I was busy and didn t pay much attention to this, which turned out to be a big mistake. On the 12th of September I started investigating this properly and noticed that when someone tried to connect to ssh with password authentication sshd would SEGV after it was denied access to a shared memory region or a semaphore which had a SE Linux type of unconfined_t. I added some SE Linux auditallow rules and discovered that the memory region in question was created by the ssh client. Shortly after that I came to the conclusion that this wasn t some strange feature of ssh (or one of the many shared objects it uses) but hostile activity. The ssh client appeared to be storing passwords that it used in a shared memory region and sshd was also collecting passwords in the same region and presumably offering them to a ssh client which uses some extension to the ssh protocol. The sshd process was crashing because it couldn t handle EPERM on access to shared memory or semaphores. Presumably if the system in question wasn t running SE Linux then the exploit would have remained undetected for a lot longer. At this stage we don t know how the attacker got in. Presumably one of the people with root access ran a ssh client on a compromised system and had their password sniffed. One such client system was mysteriously reinstalled at about that time, the sysadmin of the system in question claimed to have no backups which made it impossible to determine if that system had been compromised. I believe that the sysadmin of the client system knew that their system was compromised, kept that information secret, and allowed other systems to become and remain compromised. The attacker made no good effort to conceal their presence, they replaced ssh, sshd, and ssh-add and didn t bother changing the Debian checksums so the debsums program flagged the files as modified. Note that I have kept copies of the files in question and am willing to share them with anyone who wants to analyse them. Steinar H. Gunderson has named this trojan Ebury [1]. Recovery By the evening of the 13th of September I had the system mostly working again. Jabber still isn t working because ejabberd is difficult to get working at the best of times, I am now investigating whether there is a better Jabber server to use, but as I don t use Jabber often this hasn t been a priority for me. Some of the WordPress plugins I use and all of the WordPress themes that are installed were outside the Debian packaging system, as I couldn t be sure that they hadn t been altered (because the people who wrote WordPress plugins don t keep old versions online) I had to upgrade to the newer versions. Of course the newer versions weren t entirely compatible so I had to use a different theme and I couldn t get all plugins working. Link Within no longer works, not that it ever worked properly [2], I wanted to try Outbrain again but their web site won t let me login (and they haven t responded to my support request). Does anyone know of a good WordPress plugin to provide links to related content? Either related content on my blog or on the Internet in general will be OK. Some people have asked me about the change in appearance of my blog. It was simply impossible (for someone with my PHP skills) to get my blog looking the same way as it did before the server was cracked. I think that the new look is OK and don t mind if people think it looks likw a VW advert VW make great cars, I was very satisfied with the VW Passat I used to drive. Future Plans I had bought some Yubikeys (USB devices that generate one-time passwords) [3] to control access to that server, if I had configured the software to use them then this might not have happened. The use of one-time password devices can prevent passive password-sniffing attacks. It would still allow active attacks (such as using ControlPath/ControlMaster options on the ssh client to allow a hostile party to connect later (EG the -M, -S, and -o ControlPersist options for the ssh client). It s a pity that there doesn t seem to be a way to configure the ssh server to disable ControlMaster. Conclusion It would be good to have some changes to sshd to allow more restrictions on what a client can request, as ControlMaster functionality isn t needed by most users it should be possible to disable it. SE Linux doesn t protect against a compromised client system or any other way of stealing passwords. It did do a good job of stopping Ebury from doing all the things it wanted to do and thus making me aware of the problem. So I count this as a win for SE Linux. Yubikeys are the cheapest and easiest way of managine one-time passwords. I had already bought some for use on the system in question but hadn t got around to configuring them. I have to make that a priority.

28 December 2011

Wouter Verhelst: Rsync'ing over a newer subversion (fsfs) repository

So there are two servers; let's call them srv1 and srv2. Srv1 contains a bunch of subversion repositories, but these are to be migrated to srv2. Since the repositories are not (just) used for ascii-only files, they're fairly big (several tens of gigabytes, altogether), so copying them from one server to the other would take a while. In order to make sure this would happen quickly, we had already copied them over to the new server, so that on the final switch would be quick (an rsync that would copy over just the new done transactions). That final switch was today. Only I didn't know that instead of just testing, the customer had already started using one of the repositories (and they'd forgotten to remind me), so the subversion repository suddenly jumped backwards in time. In addition, the new server wasn't being backed up yet (at least not for the subversion bits), so restoring from backups wasn't an option. Oops. Luckily the solution is fairly simple. You see, fsfs stores each revision in a unique file; that means that as long as nobody has committed to the repository yet (which they couldn't, since system users aren't the same on both servers, so the webserver didn't have write permissions on the repository after the rsync), nothing is lost. One only needs to manually change the repository so that whatever subversion thinks is the latest commit, actually is the latest commit. That information is stored in a file called db/current inside the repository. What's in that file depends on the repository version, which is stored in a file called db/format in the repository. For versions 1 and 2, the format is a single line with three space-separated values, of which the first is the last revision number used in the repository. The other two are counters that are used to give transactions unique names; and they, too, need to be up-to-date. For version 3 and above, the file contains only the revision number; there, the other two are derived from that instead of having their own unique number. Figuring out the last used revision number in an fsfs repository is ridiculously easy:

ls -v db/revs tail -n1

So if you've got a repository of fsfs version 3 or above, just change the revision number in the db/current file (after taking backups and making sure nobody can access the repository while you're doing this, of course), and you're all set. Unfortunately, in my case, the repository was still in fsfs version 2, which meant I could not change just the revision number and not expect trouble. I suppose it should've been possible to figure out what the last transaction numbers are, somehow, so that I could fix the current file completely, but I reasoned that upgrading to a newer repository format might have other advantages too, so I just dumped the repository and reloaded it, and everything worked at that point.

Russell Coker: Secure Boot and Protecting Against Root

There has been a lot of discussion recently about the recent Microsoft ideas regarding secure boot, in case you have missed it Michael Casadevall has written a good summary of the issue [1]. Recently I ve seen a couple of people advocate the concept of secure boot with the stated idea that root should be unable to damage the system, as Microsoft Software is something that doesn t matter to me I ll restrict my comments to how this might work on Linux. Restricting the root account is something that is technically possible, for much of the past 9 years I have been running SE Linux Play Machines which have UID 0 (root) restricted by SE Linux such that they can t damage the system [2] there are other ways of achieving similar goals. But having an account with UID 0 that can t change anything on the system doesn t really match what most people think of as root , I just do it as a way of demonstrating that SE Linux controls all access such that cracking a daemon which runs as root won t result in immediately controlling the entire system. As an aside my Play Machine is not online at the moment, I hope to have it running again soon. Root Can t Damage the System One specific claim was that root should be unable to damage the system. While a secure boot system can theoretically result in a boot to single user mode without any compromise that doesn t apply to fully operational systems. For a file owned by root to be replaced the system security has to be compromised in some way. The same compromise will usually work every time until the bug is fixed and the software is upgraded. So the process of cracking root that might be used to install hostile files can also be used at runtime to exploit running processes via ptrace and do other bad stuff. Even if the attacker is forced to compromise the system at every boot this isn t a great win for the case of servers with months of uptime or for the case of workstations that have confidential data that can be rapidly copied over the Internet. There are also many workstations that are live on the Internet for months nowadays. Also the general claim doesn t really make sense on it s own. root usually means the account that is used for configuring the system. If a system can be configured then the account which is used to configure it will be able to do unwanted things. It is theoretically possible to run workstations without external root access (EG have them automatically update to the latest security fixes). Such a workstation configuration MIGHT be able to survive a compromise by having a reboot trigger an automatic update. But a workstation that is used in such a manner could be just re-imaged as it would probably be used in an environment where data-less operation makes sense. An Android phone could be considered as an example of a Linux system for which the root user can t damage the system if you consider root to mean person accessing the GUI configuration system . But then it wouldn t be difficult to create a configuration program for a regular Linux system that allows the user to change some parts of the system configuration while making others unavailable. Besides there are many ways in which the Android configuration GUI permits the user to make the system mostly unusable (EG by disabling data access) or extremely expensive to operate (EG by forcing data roaming). So I don t think that Android is a good example of root being prevented from doing damage. Signing All Files Another idea that I saw advocated was to have the secure boot concept extended to all files. So you have a boot loader that loads a signed kernel which then loads only signed executables and then every interpreter (Perl, Python, etc) will also check for signatures on files that they run. This would be tricky with interpreters that are designed to run from standard input (most notably /bin/sh but also many other interpreters). Doing this would require changing many programs, I guess you would even have to change mount to check the signature on /etc/fstab etc. This would be an unreasonably large amount of work. Another possibility would be to change the kernel such that it checks file signatures and has restrictions on system calls such as open() and the exec() family of calls. In concept it would be possible to extend SE Linux or any other access control system to include access checks on which files need to be signed (some types such as etc_t and bin_t would need to be signed but others such as var_t wouldn t). Of course this would mean that no sysadmin work could be performed locally as all file changes would have to come from the signing system. I can imagine all sorts of theoretically interesting but practically useless ways of implementing this such as having the signing system disconnected from the Internet with USB flash devices used for one-way file transfer because you can t have the signing system available to the same attacks as the host system. The requirement to sign all files would reduce the use of such a system to a tiny fraction of the user-base. Which would then raise the question of why anyone would spend the effort on that task when there are so many other ways of improving security that involve less work and can be used by more people. Encrypted Root Filesystem One real benefit of a secure boot system is for systems using encrypted filesystems. It would be good to know that a hostile party hasn t replaced the kernel and initrd when you are asked for the password to unlock the root filesystem. This would be good for the case where a laptop is left in a hotel room or other place where a hostile party could access it. Another way of addressing the same problem is to boot from a USB device so that you can keep a small USB boot device with you when it s inconvenient to carry a large laptop (which works for me). Of course it s theoretically possible for the system BIOS to be replaced with something that trojans the boot process (EG runs the kernel in a virtual machine). But I expect that if someone who is capable of doing that gets access to my laptop then I m going to lose anyway. Conclusion The secure boot concept does seem to have some useful potential when the aim is to reboot the system and have it automatically apply security fixes in the early stages of the boot process. This could be used for Netbooks and phones. Of course such a process would have to reset some configuration settings to safe defaults, this means replacing files in /etc and some configuration files in the user s home directory. So such a reboot and upgrade procedure would either leave the possibility that files in /etc were still compromised or it would remove some configuration work and thus give the user an incentive to avoid applying the patch. Any system that tries to extend signature checks all the way would either be vulnerable to valid but hostile changes to system configuration (such as authenticating to a server run by a hostile party) or have extreme ease of use issues due to signing everything. Also a secure boot will only protect a vulnerable system between the time it is rebooted and the time it returns to full operation after the reboot. If the security flaw hasn t been fixed (which could be due to a 0-day exploit or an exploit for which the patch hasn t been applied) then the system could be cracked again. I don t think that a secure boot process offers real benefits to many users.

27 December 2011

David Welton: 2011 in Books

Since I got my Kindle a bit more than a year ago, I have finally been able to slake my thirst for reading materials, something that was prohibitively expensive when ordering English language books via Amazon.co.uk, and took lots of time to boot. Here are some of the interesting books I've happened on in the past year: The big one was "Start Small, Stay Small": which has tons of ideas on how to do small, niche startups, "for the rest of us". Those of us who aren't in Silicon Valley, who aren't seeking millions in VC funding, those who don't want to aim for "astronomically rich", but just a comfortable lifestyle with more control over our own destiny. This book gets special mention for being a big inspiration for LiberWriter. Here is a list of the others.

Thinking, Fast and Slow: http://amzn.to/sXQGSR - probably makes my list because I just finished it, and as he writes, "what you see is all there is" - we're biased towards things that come to mind easily. Actually, it is a pretty good book even looking through all the others I've read.
1491: http://amzn.to/uaR0yf - about the Americas prior to the arrival of "Cristoforo Colombo". I have the sequel, 1493 in my reading list, but haven't gotten to it just yet.
Built to Sell: http://amzn.to/ukmyNP - how to create a business that is something that you can sell because it can exist without you. Not quite so relevant to startups working on a product, but some good concepts nonetheless. A good summary is probably just as good as reading the book, as the core concepts are fairly simple.
A History of the World in 6 Glasses: http://amzn.to/vF9FgN and An Edible History of the World: http://amzn.to/w1kTg3 - two interesting looks at the history of the world based on what we drink and eat.
Empires of the Word: A Language History of the World: http://amzn.to/tVvltK the history of the world as seen through languages. It's interesting to read about why some languages lasted so long even though their speakers were conquered, why others swept all before them and disappeared, and so on.
The Long Divergence: How Islamic Law Held Back the Middle East: http://amzn.to/spQCF7 - a look at how the legal systems of 'the west' and the middle east differed and the results those systems led to. Limited liability companies are an important innovation. The book can be a bit dry and repetitive at times, but the material is very interesting.
Warlord: http://amzn.to/spjf73 - Winston Churchill's "war years".
Positioning: http://amzn.to/sSJRnw - a classic about branding.
The Intelligent Investor: http://amzn.to/tffzgJ and A Random Walk Down Wall Street: http://amzn.to/vXIsTT two classics on investing. I'm more inclined towards the 'random' view of things myself.
The Great Stagnation: http://amzn.to/vccI3c about "what ails us" as a country. One of the recommendations is that we need to "raise the social status of scientists."
The Party: http://amzn.to/tWX1hA an interesting, and balanced (well, it seemed that way to me, but knowing essentially nothing about the place I could be completely wrong) book on how China is run.

And for fun, a variety of Sci fi and Western books, but nothing particularly noteworthy. Neal Stephenson's REAMDE was fun, but I'm not sure I'd read it more than once, like some of his other books. Here are my Amazon wishlists of things I'm considering reading at some point in the future. Comments welcome on the value of the books listed. "Regular" books: http://amzn.com/w/20I0Y1YGD1FUB and random fun books and movies. Business books: http://amzn.com/w/5B2JQOP8VZEW - although some of them are not strictly business books. Yes, if you're curious, the book links do have referral codes in them, to help sustain my reading habit.

26 December 2011

Asheesh Laroia: Short key IDs are bad news (with OpenPGP and GNU Privacy Guard)

Summary: It is important that we (the Debian community that relies on OpenPGP through GNU Privacy Guard) stop using short key IDs. There is no vulnerability in OpenPGP and GPG. However, using short key IDs (like 0x70096AD1) is fundementally insecure; it is easy to generate collisions for short key IDs. We should always use 64-bit (or longer) key IDs, like: 0x37E1C17570096AD1 or 0xEC4B033C70096AD1. TL;DR: This now gives two results: gpg --recv-key 70096AD1

Some background, and my two keys Years ago, I read dkg's instructions on migrating the Debian OpenPGP infrastructure. It told me that the time and effort I had spent getting my key into the strong set wasn't as useful as I thought it had been. I felt deflated. I had put in quite a bit of effort over the years to strongly-connect my key to a variety of signatures, and I had helped people get their own keys into the strong set this way. If I migrated off my old key and revoked it, I'd be abandoning some people for whom I was their only link into the strong set. And what fun it was to first become part of the strong set! And all the eyebrows I raised when I told people I was going meet up with people I met on a website called Biglumber... I even made it my Facebook.com user ID. So if I had to generate a new key, I decided I had better really love the short key ID. But at that point, I already felt pretty attached to the number 0x70096AD1. And I couldn't come up with anything better. So that settled it: no key upgrade until I had a new key whose ID is the same as my old key. That dream has become a reality. Search for my old key ID, and you get two keys!

$ gpg --keyserver pgp.mit.edu --recv-key 0x70096AD1
gpg: requesting key 70096AD1 from hkp server pgp.mit.edu
gpg: key 70096AD1: public key "Asheesh Laroia <asheesh@asheesh.org>" imported
gpg: key 70096AD1: public key "Asheesh Laroia <asheesh@asheesh.org>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 2
gpg:               imported: 2  (RSA: 1)

I also saw it as an opportunity: I know that cryptography tools are tragically easy to mis-use. The use of 32-bit key IDs is fundamentally incorrect -- too little entropy. Maybe shocking people by creating two "identical" keys will help speed the transition away from this mis-use.

A neat stunt abusing --refresh-keys Thanks to a GNU Privacy Guard bug, it is super easy to get my new key. Let's say that, like many people, you only have my old key on your workstation:

$ gpg --list-keys   grep 70096AD1
pub   1024D/70096AD1 2005-12-28

Just ask GPG to refresh:

$ gpg --keyserver pgp.mit.edu --refresh-keys
gpg: refreshing 1 key from hkp://pgp.mit.edu
gpg: requesting key 70096AD1 from hkp server pgp.mit.edu
gpg: key 70096AD1: public key "Asheesh Laroia <asheesh@asheesh.org>" imported
gpg: key 70096AD1: "Asheesh Laroia <asheesh@asheesh.org>" not changed
gpg: Total number processed: 2
gpg:               imported: 1  (RSA: 1)
gpg:              unchanged: 1
gpg: no ultimately trusted keys found

You can see that it set out to refresh just 1 key. It did that by querying the keyserver for the short ID. The keyserver provided two hits for that query. In the end, GPG refreshes one key and actually imports a new key into the keyring! Now you have two:

$ gpg --list-keys   grep 70096AD1
pub   1024D/70096AD1 2005-12-28
pub   4096R/70096AD1 2011-03-11

There is a bug filed in GNU Privacy Guard about this. It has a patch attached. There is, at the moment, no plan for a new release.

A faster attack, but nothing truly new My friend Venkatesh tells me there is an apocryphal old Perl script that could be used to generate key ID collisions. Here in the twenty-first century, l33t h4x0rz like Georgi Guninski are trying to create collisions. In May 2010, "halfdog" posted a note to the full-disclosure list that generates PGP keys with chosen short key IDs. I haven't benchmarked or tested that tool, but I have used a different tool (private for now) that can generate collisions in a similar fashion. It takes about 3 hours to loop through all key IDs on a dinky little netbook. You don't have to use any of these tools. You can just rent time on an elastic computing service or a botnet, or your own personal computer, and generate keys until you have a match. I think that it's easy to under-estimate the seriousness of this problem: tools like the PGP Key Pathfinder should be updated to only accept 64-bit (or longer) key IDs if we want to trust their output.

My offer: I will make you a key I've been spending some time wondering: What sort of exciting demonstration can I create to highlight that this is a real problem? Some ideas I've had:
Publish a private/public key pair whose key ID is the same as Phil Zimmerman's, original author of PGP
Publish a private/public key pair whose key ID is the same as Werner Koch's, maintainer of GNU Privacy Guard
Publish a set of public keys that mimic the entire PGP strong set, except where I control the private key of all these keys
The last one would be extremely amusing, and would be a hat-tip to some work discussed in Raph Levien's Google Tech Talk about Advogato. For now, here is my offer: If you send me a request signed with a key in the strong set, I will create a 4096-bit RSA public/private key pair whose 32-bit key ID is one greater than yours. So if you are 0x517DD4E4 I will generate 0x517DD4E5. I will post the keys here, along a note about who requested it, and instructions on how to import them into your keyring. (Note: I will politely decline to create a new key whose 32-bit key ID would create a collision; apologies if your key ID is just one away from someone else's.) P.S. The prize for best sarcastic retort goes to Ian Jackson. He said, "I should go and create a lot of keys with your key ID. I'll set the real name to 'Not Asheesh Laroia' so everyone is totally clear about what is going on."

Tanguy Ortolo: GNOME 3 killing interface consistency

I used to recommend the GNOME desktop for simple users for two main advantages over Windows:

the logical, automatically filled and translated applications menu (compare that to the messy Windows Programs menu );
the general interface consistency (compare that with Windows Explorer, Windows Media Player, Avast! and each piece of crap^Wsoftware whose author believed developing yet another custom interface was the way to go).

Both points are what I call calm advantages, because users will usually enjoy them without noticing. Instead, they will enhance their experience so that they will miss them when they come back to a system which does not provide these features. In fact, being used to that, I do not really consider these points as actual advantages, but rather as a bare minimum for any decent desktop and as very important lacks of some competitors.Well, GNOME 3 already reduced the first point by replacing the menu by a single loooong list of all the available software, although there are still categories at least. Now, with a recent upgrade, it appears that they destroyed the second one, the interface consistency. There used to be a thing called the GTK theme, that the user could choose according to his taste and needs, and all the GTK-based graphical software, including GNOME programs, used to follow that theme. This is no longer the case: now, for instance, Nautilus will look clear, while for some reason Eye of GNOME and Totem will look dark, with no option to make them look like the others.

Nautilus

Eye of GNOME

I used to be a GNOME user, but it has been some time since I stopped using a desktop at all and switched to a window manager that was more efficient according to my usage. However I kept using GNOME software, and I recommended GNOME to new users. Now it seems my arguments for that have reduced to a point where I should really consider recommending Xfce instead.

Russ Allbery: Testing PAM modules

I maintain a couple of PAM modules, pam-afs-session and pam-krb5. I'm also a big fan of test-driven development and automated regression testing, and have been slowly converting all of my software over to using a test suite. But therein lies a challenge, since PAM modules are hard to test. First, Linux PAM doesn't offer a good way to run a module in a test environment. Specifically, it doesn't offer a way to use an alternative PAM configuration other than the system PAM configuration, so that one can load only the module being tested (or it and some glue modules to set things up). One has to resort to dedicated test systems that do things like symlink part of their PAM configuration into a shared build tree. Second, even if this problem were solved, Linux PAM doesn't (rightfully) allow a lot of introspection and digging around in its guts. This makes it harder to test whether data items, environment variables, and so forth are set properly and make sense. It also doesn't provide facilities for intercepting logging output that would otherwise go to syslog. So, about a year and a half ago (and then with substantial improvements a year ago), I wrote a fake PAM library to test pam-afs-session. This library provides all of the PAM API that's called by a PAM module (at least the modules I'm testing), but has a much-simplified interface and allows test cases to look through its internals and be sure the module did things properly. This was great as far as it goes. But writing the wrapper code to invoke a PAM module entry point and then check its return status, its logging, and so forth was complicated, messy, and difficult to understand. It also didn't handle testing prompting and other important aspects of PAM modules. So earlier this fall I wrote the beginnings of a PAM test driver that would move as much of the complexity as possible into shared code and into configuration files, and since then I've been expanding and improving it until it could handle the major testing required for pam-krb5 (which is much more complex than pam-afs-session). Yesterday, I released the results as part of rra-c-util. Here's an example configuration file, this one for a pam-krb5 test that simulates prompting the user for a password and then obtaining credentials (but not creating a ticket cache):

    [options]
        auth    = no_ccache
        account = no_ccache
        session = no_ccache
    [run]
        authenticate  = PAM_SUCCESS
        acct_mgmt     = PAM_SUCCESS
        open_session  = PAM_SUCCESS
        close_session = PAM_SUCCESS
    [prompts]
        echo_off = Password:  %p
    [output]
        INFO user %u authenticated as %u

That's a complete and fairly complex test. The test framework takes care of running the listed entry points, passing them the given PAM configuration, and checking the return status. It provides a conversation function that checks the prompt and its type and replies with the text after . As you can see, it supports some escapes that are replaced by data passed into the test suite driver, in this case the password to use for testing. And it checks the logging output, including the priority level, and similarly supports escapes there. Running simple tests is very easy and is doable with a tiny C program. Here's a complete test program from pam-krb5, one that tests functionality that doesn't require a valid password and hence doesn't need to do much setup:

    #include <config.h>
    #include <portable/system.h>
    #include <tests/fakepam/script.h>
    int
    main(void)
     
        struct script_config config;
        plan_lazy();
        memset(&config, 0, sizeof(config));
        config.user = "root";
        run_script_dir("data/scripts/basic", &config);
        return 0;

That's all there is to it. That finds every configuration file like the above in the tests/data/scripts/basic directory in the package source and runs through each one, checking the results, and outputing the results as TAP output (the protocol used for the Perl test suite, and also my C TAP Harness package). There are, of course, other things that it can do: more substitutions, setting the authtok in advance of calling the module, and a callback so that one can inspect PAM state before the PAM session is shut down. I've started writing some documentation, although so far it primarily covers the configuration file syntax and the headers are the best reference for the API. The source code of the pam-krb5 package are the best reference so far. The library itself is part of rra-c-util and, like the rest of that package, is designed to be copied into the package that uses it and built alongside it so that it can be linked easily with the test programs. It's worth noting that there isn't a way to use it to test installed PAM modules that are already bound to the system libpam library. The way one builds test programs currently is to link the test program with the individual objects making up the PAM module and then link with this library and the TAP library, since that ensures the right symbols are called. But it may be possible to do something tricky using LD_PRELOAD if anyone feels inspired.

24 December 2011

Uwe Hermann: HOWTO: Using OpenVPN on Debian GNU/Linux

Here's a quick HOWTO for setting up an OpenVPN server and client on any (Debian, in this case) Linux machine of your choice. I'm running an OpenVPN server on a box at home, and a client on my laptop, so I can securely route all my laptop traffic through my OpenVPN server, no matter where I am. I highly recommend reading the official OpenVPN HOWTO from top to bottom, at least once. But here's a short, condensed HOWTO (specifically geared towards my needs, yours might be different): On the server: Install OpenVPN (apt-get install openvpn), then copy the "easy-rsa" files to /etc/openvpn/easy-rsa from where we'll use them to create our keys and certificates:

  $ cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa
  $ cd /etc/openvpn/easy-rsa

In the vars file change the KEY_SIZE variable from 1024 to 4096 for good measure:

  export KEY_SIZE=4096

Then, read in the vars file, clean old keys and certificates (if any) and create new ones:

  $ . ./vars
  $ ./clean-all
  $ ./build-ca

You'll now have the chance to enter some data such as country code (e.g. "DE"), state/province, locality, organization name, organizational unit name, common name, name, and email address. The values you choose don't really matter much (except for commonName, maybe, which could be your hostname or domain or such). Finally, the ca.key (root CA key) and ca.crt (root CA certificate) files will be created. Next, we'll create the server key:

  $ ./build-key-server server

You'll have to enter lots of info again (see above), commonName could be "server" or such this time. Upon "Sign the certificate? [y/n]" say y, as well as upon "1 out of 1 certificate requests certified, commit? [y/n]". Finally, the server.key and server.crt files will be created. Same procedure for creating a client key (I used "client1" as filename and commonName here):

  $ ./build-key client1

Next up we'll generate Diffie Hellman parameters (this will take a shitload of time due to keysize=4096, go drink some coffee):

  $ ./build-dh

When this step is done, you'll have a dh4096.pem file. As we want to use OpenVPN's "tls-auth" feature for perfect forward secrecy (it "adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification"), we'll have to generate a shared secret:

  $ openvpn --genkey --secret ta.key
  $ mv ta.key keys

So much for creating keys. Now, we'll have to configure OpenVPN. Copy the default server config file and edit it:

  $ cd /etc/openvpn
  $ cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz .
  $ gunzip server.conf.gz

The most important change in my setup is that I use port 443/TCP instead of the usual OpenVPN default of 1194/UDP. This increases the chances that you'll be able to use OpenVPN in almost all places, even in environments which firewall/block lots of stuff. Port 443/TCP (for https) will almost always be usable. I also uncommented the following line, which tells the client to use the VPN interface (usually tun0) per default, so that all the client's traffic (web browsing, DNS, and so on) goes over the VPN:

  push "redirect-gateway def1 bypass-dhcp"

Here's my server config file (comments and commented out lines stripped):

  port 443
  proto tcp
  dev tun
  ca /etc/openvpn/easy-rsa/keys/ca.crt
  cert /etc/openvpn/easy-rsa/keys/server.crt
  key /etc/openvpn/easy-rsa/keys/server.key  # This file should be kept secret
  dh /etc/openvpn/easy-rsa/keys/dh4096.pem
  server 10.8.0.0 255.255.255.0
  ifconfig-pool-persist ipp.txt
  push "redirect-gateway def1 bypass-dhcp"
  keepalive 10 120
  tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0 # This file is secret
  comp-lzo
  user nobody
  group nogroup
  persist-key
  persist-tun
  status openvpn-status.log
  log-append openvpn.log
  verb 3

You can now start the OpenVPN server, e.g. via

  $ /etc/init.d/openvpn restart

Server firewall setup/changes: I'm running a custom iptables script on pretty much all of my boxes. Here's the relevant changes needed to allow the OpenVPN server to work properly. Basically, you need to enable IP forwarding, accept/forward tun0 traffic and setup masquerading (change "eth0" below, if needed):

  echo 1 > /proc/sys/net/ipv4/ip_forward
  iptables -A INPUT -i tun+ -j ACCEPT
  iptables -A FORWARD -i tun+ -j ACCEPT
  iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
  iptables -t nat -F POSTROUTING
  iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

My firewall script gets run upon every reboot. If you don't use such a script, you could add the above stuff to your /etc/rc.local file. On the client: Install OpenVPN (apt-get install openvpn), then copy the default client config file and edit it:

  $ cd /etc/openvpn
  $ cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf .

Change the parameters to match the server config (port 443/TCP, and so on) and use "tls-auth /etc/openvpn/ta.key 1" (note the "1" on the client, and the "0" on the server!). Replace xxx.xxx.xxx.xxx with the public IP address of your OpenVPN server. If it doesn't have a public, static IP address already, you can use services such as DynDNS, or (my preferred method), my ssh-based DIY poor man's dynamic DNS setup. Here's my full client config:

  client
  dev tun
  proto tcp
  remote xxx.xxx.xxx.xxx 443
  resolv-retry infinite
  nobind
  user nobody
  group nogroup
  persist-key
  ca /etc/openvpn/ca.crt
  cert /etc/openvpn/client1.crt
  key /etc/openvpn/client1.key
  ns-cert-type server
  tls-auth /etc/openvpn/ta.key 1
  comp-lzo
  verb 3

Now you only need to copy the required certificates and keys to the client (into /etc/openvpn): ca.crt, and ta.key. Do not copy the other, server-specific private keys and such to the client(s)! Also, the root CA key (ca.key) should not even be left on the server, but rather moved to some offline storage/box, so that it cannot fall into the wrong hands, e.g. in the case of a server compromise. I prefer to manually start the client on my laptop when needed, so I use AUTOSTART="none" in /etc/default/openvpn and then start the client via:

  $ openvpn /etc/openvpn/client.conf

That's it. Comments and suggestions for improving the setup and/or the security aspects of it are highly welcome!

23 December 2011

Wouter Verhelst: Static program analysis with LLVM and clang

"Static program analysis" is a technique whereby a program is verified for errors without actually running it. Finding bugs manually with a debugger and one's brain is tedious, so every shortcut that can help you avoid having to do so is great. There are some commercial tools available to do such analysis, some of which are rather expensive; but there are also some open source tools available to do similar things. One of these is built into clang, the C compiler of the LLVM project. Using it is fairly simple. Instead of compiling something with 'make', compile it with 'scan-build make'. This will set the CC (and similar) environment variable(s) so that before the compiler is ran, the clang static-analysis checker is run over the very same source code. The output of this checker is an HTML file with your source, but with comments added to explain the bugs which the tool found. What does that mean? well, let's look at an example, shall we? <iframe height="500px" src="http://barbershop.grep.be/~wouter/scan-view-example#LN1493" width="80%"></iframe> The iframe above contains one out of three reports produced by a scan-build run over the nbd source code (if there's no iframe, someone scrubbed some HTML in your RSS reader. Just follow the link just above instead). The other two are 'dead assignments', which might mean that I'm currently depending on some undefined behaviour (which would be bad), or it might mean that I'm being overly cautious (which makes my code future-proof, which would be good), or it might mean something else I still need to investigate. But this one is pretty interesting. In the example, there are eight, numbered, comments in the source code. The first seven show the code path which scan-build took through my code before getting at the eighth comment; and the eighth is where things go bad. In this case, when going through the function as shown, we have a NULL pointer dereference. When looking at the scan-build output, it's important to realize a few things. First, the code path shown may be just one of a number of possible code paths. For instance, the null pointer dereference would still happen if the phase function parameter would not contain the NEG_INIT bit with the client pointer set to NULL. However, clang does not show these other code paths; this is presumably an optimization ("if we've already shown that this kind of bug is possible at a particular location through one code path, don't bother recording future instances of that very same bug at the exact same location through another code path"). This means that sometimes, some of the branches shown may be completely irrelevant to the bug at hand. In this particular case, in fact, it's possible to show the bug with just the eighth comment; the first seven are in fact totally irrelevant. Second, the fact that the clang static analyser found a bug does not mean that it's possible to crash the application. Yet. In this particular case, the negotiate function will never be called with the NEG_INIT or NEG_MODERN bits not set, and with the client parameter set to NULL. That's an implicit assertion; there are a few ways in which this function may be called, but the client parameter may only be NULL if NEG_INIT and NEG_MODERN are both set at the same time. Since nbd-server doesn't currently call the negotiate function in that way, it is not currently possible to crash the server by exploiting this bug. But that doesn't mean it won't ever be possible, nor that there isn't a bug in the code. We may assume that the above rules are true, but we never check it. Adding an assertion to that effect should make sure that no future change to the code will accidentally introduce that error and cause a NULL pointer dereference. Is this a silly and useless precautionary measure? Not really. Usually, bugs happen in code not because someone wasn't thinking straight, but because there's so much going on inside a piece of software that it can be too much for any programmer to remember. If a function assumes that its parameters are within a given subset of all possible states, but does not check that this is in fact true, then when (not if) some future change incorrectly introduces a state that is outside of the assumed states, things will break. And that's Bad(TM).

22 December 2011

Biella Coleman: The Best of NYC

Now that the semester is done and now that I have compiled my crazy paperwork for Canada (wow, it is a lot), I will be heading in six days to the wonderful city of Montreal to settle down, at least for a few years. I am ready to leave but it is not an easy move, as I like NYC and my job. I came to New York City for the first time at the age of 19 after spending a year on a ship and I rather did not like the city for those 5 years, although loved my college years and all the time I spent chasing a Frisbee while running on grassy fields all over the east coast. When I left in 1998, I said, never again. But the future is impossible to predict so of course I came back when I got a job, my only job, at NYU MCC and headed quite happily here (incidentally from Canada). And NYC was much much much better the second time around, most likely as I had a salary, and here is what I <3 and loved about the city. 1. Not having a car (which will still be the case in Montreal)
2. The bike path on the Hudson, especially the gardens and the Irish famine memoriall
3. The farmer s markets (won t miss the prices though)
4. High walkability factor (and though I did not love my hood, I loved being 1.5 blocks from my office)
5. The music jam circles in Washington Square Park (I was always left wondering if they were spontaneously generated or long standing groups // prolly both) and the occasional but mighty impressive hawks in the park.
6. Coney Island especially under certain special conditions when you can rly enjoy the lights radiating out of the amusement park
7. Leaving the city for some nature time
8. 24 hour trains (despite not loving them cuz the noise robbed some life from me every time I took them)
9. Grand Central Station s ceiling
10. The gluten free options (this is going to be the hardest to give up as Montreal sort of sucks in comparison)
11. Being able to take your small dog on the train

which is only a recent pleasure
12. My department
13. East Asian Starr library at Columbia University (still my favorite library in the world) and totally loathed NYU s Bobst, ugly on the outside, ugly on the inside
14. NYC sunrises which I have like only seen 3 times (sadly) but they have been stunning every time
15. Walking across the Brooklyn Bridge
16. HOPE
17. The Highline
18. The Strand
19. My favorite thing = Massive Snow Storms in the City (good thing I am moving to Canada, eh?)

Next.

Previous.