I haven't been doing Debian work for a while now, due to various reasons. However, I try to keep reading (but not posting to) the mailing list, such as to keep in touch (in a virtual way). What surprises me is how the community evolves: in some ways not at all (was there an init-system flamewar this week already or not?), in some ways a lot (mailing list bans!). Since I don't post to the mailing lists, consider this post as my +1 towards the listmaster's work: yes, we should limit the damage that abusive people do to the project. I'm surprised at how some people call list bans as censorship (it's not, IMHO), and how they treat abuse as something light. Another thing that surprises me is how abuse and arrogance go hand in hand. In the explanations for bans, I've seen not just one example where the abusive person is not only, well, abusive, but also considers themselves superior (morally, technically, etc.). If you're already so much superior, why hit on people? If you already know so much, why the personal attacks? And no, being immature is not the whole or even the only explanation This page has a nice collection of quotes around the same motive: how you treat other people, especially people whom you regard less knowledgeable than you, tells a lot about your character. One quote is nice in how succinct and how applicable it is to the kind of abuse I've seen:

To insult or to abuse those who cannot resist, or dare not resent the injury, is a sure mark of cowardice, [ ].

From 1852 September 30, Farmer s Cabinet, Courtesy to Inferiors, Page 1, Column 2, Volume 51, Number 8, Amherst, New Hampshire. The rest of the quote also contains a somewhat sexist remark, so I've left that part out (but I'm surprised they still talked about swords in the 1850s). And yes, I hope that this spring I'll be able to get back to my Debian work.

During the month of December, we have been working with folks from En Vente Libre to create a shop with Debian products: http://www.enventelibre.org/debian We have now a shop with plenty of Debian products. The design has been done by Ahmet DEMIR. Most of them are already known by the community (they were sold during FOSDEM or various Debconf) like the Buff, Swiss Army knife or the classical polos. But, t-shirts based on Wheezy theme are brand new: They are available in three colors:
* Red
* Blue
* Grey For now, the website is only French, an English version might come in the future.

We just released LLVM & Clang 3.4 (already available in Debian Jessie and Ubuntu Trusty). The clang new release introduces some more warning and error detections. The point of the blog post is not to detail the changes (LLVM / Clang) but more to take a step back on the LLVM and Clang toolchains, usages and dissemination. For the last couple years, I have been presenting our work on the Debian side to make Clang part of the Debian infrastructure. I add the chance to speak at many events (Debconf 12 & 13, FOSDEM 2013, Linux Plumbers 2013, Distro recipes, etc). I even had Linus Torvalds attending to one of these talks (and proposing new approach). I had many feedback from the Debian/Ubuntu communities but also from other communities.
More and more projects are using Clang as part of their workflows, in term of development, production and QA. For example, some of them are running continuous integration using clang instead of gcc, others are running scan-build (Wireshark or LLVM itself) or Address Sanitizer (asan) (Firefox for example), etc.
More and more actors are moving from gcc to clang for their developments (Sony with their PS4, Chrome under Mac OS X, Apple, the Linux Kernel with the LLVMLinux project, FreeBSD, etc).
I stopped counting the number of times when people answered me "Yeh, I am now using Clang" when I said I am involved upstream. In parallel, more and more projects are using LLVM as a backend or computing engine and, in the meantime, getting more and more attraction (not because they are based on LLVM but just because they are great projects). For example, Mesa (llvmpipe), Julia, Rust, Emscripten or Native Client (NaCL) are excellent examples of this. The two last are excellent proofs that LLVM based technologies have an impact which goes further than geek-tools and will be used on a daily basis by millions of users. I also saw an interesting and growing number of new projects using libclang and libTooling. My feeling is that the lack of plugin capabilities in gcc for a long time and, now, its current complexity limited the innovation in term of compilation capabilities, analysis and fun tools. The features and the quality of this library are enabling new developments and I am sure we will see more and more excellent tools based on this library during 2014.
For example, the LLVM toolchain ships Clang modernize and clang format and some cool projects like include-what-you-use, DXR, OCLint or creduce are emerging. Thanks to this great competition, gcc is also improving (ASAN, JIT, better warnings, etc), remaining still relevant as before. No doubt that 2014 will be a great year for compilers.

Packt Publishing sent me Krzysztof Niki ski's Instant Haml to do a short blog review... Thing is, and those who read me know, I cannot write short reviews ;-) So lets see how this goes. Packt's Instant series First, as for the format this book follows and the series it fits in: They are very short books. I was the tech reviewer for their Instant Debian Build a Web Server , and when I opened it for the first time, I thought I had received only the first chapter. This series' motto is Short Fast Focused so, yes, the books are ~50 pages long, with ample margins and many big screenshots. I told the editors I was quite unsure about the value this kind of publications add, as they are very similar to online tutorials, but given they have so many books in this series (printed and electronic), there must be a market for them. They surely know their business better than me! There is one other detail regarding the publisher I'll stick in this section, although it is not specific to their Instant series: I do most of my reading in my Kindle. Packt seems to have chosen to specify a very small font for their texts. Besides the two books mentioned, I also have their Object Oriented JavaScript book. For all of the other books I read, I use the smallest font setting. Packt books in mobi format (what they present as Amazon format in their web site) are basically illegible without bumping up the font size through the roof. As I understand it, publishers should use industry-wide default sizes, and let the reader adjust their reading experience. Yes, books of technical nature (such as Packt's) often benefit from having more displayed information than what an ebook reader normally shows... But that's for me to decide! And no, this is not a Kindle-specific glitch: I also get a similar experience when opening it from Calibre. And as for the book... I am a long-time Haml convert/fan; I packaged its Ruby implementation for Debian (and should update it soon :-/ as new versions have appeared), the corresponding Emacs Lisp mode, and I use it for basically all of my static HTML sites and Ruby-based Web systems. Haml is a great templating language, meant to make dynamic HTML generation leaner and easier. It is a clean and elegant technology, and can clearly sell itself. And the project webpage has very good documentation, ranging from a short tutorial and a full API documentation for people to contribute to the project. The first part of this book, of course, covers the "why is Haml so great?" part, presenting the basic equivalences with HTML. In my opinion, the book could be structured a bit differently and would generate a stronger following. Why? Because, even given that Haml is greatly benefited from its Ruby integration and has many hooks to be tightly integrated in a Rails workflow, it can also be used by people who don't want to do Ruby. I have some static websites that are just a bunch of Haml files, compiled by a very simple Makefile and calling the haml command from the shell. I think there would be some value in presenting this invocation before learning how to call it from the Gems environment (i.e. bundle install). Using Haml as a standalone tool is only presented almost as an appendix ("Using HAML outside of Rails" section). Even more so if the author presents four different static-site solutions (probably more non-programmer-friendly than my trusty Makefile). Oh, and this little section uses the (old? obsolete?) uppercase HAML notation for the project's name instead of the now-standard Haml. Dirty screenshots About the screenshots presented in this first section (and I refer mainly to the scaffolding examples), they are meant to show how easy things are, but have an important stylistic mistake: Terminals with transparency might look cool (I hate using them, but then again I'm a very boring person when it comes to my computer habits ;-) ), but transparencies have no place in a book (be it printed or e-book), as the images appear very uncrisp. In the Kindle, they just seemed dirty Now that I'm browsing the PDF from my desktop, I see that the screenshot in "Step 1" has a photo of Earth from space behind the terminal, and even worse, in "Step 2" it is shown over a Web page detailing the installation! These elements are just distracting, and the text would be much cleaerer if it were presented typeset just as a regular code fragment. Opening many of those screenshots in the Kindle was plain useless. Editor integration It is perfectly clear from this text that the author strongly prefers Sublime Text, sometimes uses TextMate, and has just heard reports that Haml has some support in Vim, Rubymine, Emacs and Coda. Of course, devoting a full page (as it is for the first case) for each editor would be out of proportion for this size of book... I just felt the imbalance too big, specially given that most editors will sport approximately the same feature set. Text redundancy If the Instant series is about making short books, I would expect them to be loaded with easy to follow content (as they are), but free of repetition. I felt, however, a large chunk of step 1 of the "Quick start" chapter to be repeated with the the first section of the "Top 6 features" chapter. Yes, the second one adds some depth, but very little. Still, in the later parts of this "Top 6 features" chapter, a more thorough explanation could be used for the Filters, Multiline attributes/code/strings and helpers and extensions sections. It seems the author was on a hurry trying to get it finished, as it is barely explained Explaining a bit more deeply would surely benefit readers. Wrapping up Reading my review, I'm mostly talking about negative issues. IMO, the book is not excellent, but it is clearly not bad. Specially given it fits very well the format for which it was designed. There are many items that could be fixed, and I hope some of them can be fixed (i.e. the screenshots) before the book goes to print If I understand Packt's page correctly, it is currently only available as ebook, contrary to most of the Instant series' titles.

One of those enlightenment moments that I should have had sooner: every time I have seen someone set up an OpenVPN VPN, they have generated all the certificates on the VPN server as root using easy-rsa. This is kind of strange, because you end up with an incredibly sensitive directory on the VPN server containing every private key for every client. Another angle is whether you trust the random number generators used to create all these keys - does your hosting provider use a weak RNG? Instead, you could set up your CA using easy-rsa on a separate machine - perhaps even air-gapped. Then private keys can be generated on each machine that wants to join the VPN, and the certificates can get signed by the CA and returned. (The easy-rsa package has been split out of the openvpn package in Debian unstable, which makes this more understandable.) Is there a security benefit? You could argue that if your VPN server has been compromised, then you are already in trouble. But I'm thinking about a setup where I could run multiple VPN servers for redundancy, signed by the same CA - then if one server gets broken into, you could kill it without having to revoke all the client keys. By the way, the default RSA key size used by easy-rsa is 1024 bits at the time of writing (fixed upstream: Debian bug #733905). This is simple to change, but you need to know to do it. One of the 30c3 lightning talks was about bettercrypto.org - a guide to which cryptography settings to choose for commonly used software.

Review: The Female Man, by Joanna Russ

Publisher:	Beacon
Copyright:	1975
Printing:	1986
ISBN:	0-8070-6299-5
Format:	Trade paperback
Pages:	214

The Female Man is one of the most famous novels of feminist science fiction, written by a giant of the field. Joanna Russ was one of the strongest writers of the first era of explicitly feminist SF and one of the most challenging. Along with Alice Sheldon (James Tiptree, Jr.) and Sheri Tepper, she's probably the best known author whose approach tended towards the directly confrontational. She was also a noted essayist, critic, and reviewer; her book How to Suppress Women's Writing is one of the most famous works of feminist literary criticism. That said, I wasn't sure what to expect from this book. I'd heard that it was about four different women: Jeannine, Joanna, Janet, and Jael. They're parallels of sorts but from far different cultures, alternate worlds displaced in time. I'd also heard that it was full of biting, accurate sarcasm, which is certainly the case. This is a book written from a place of righteous anger combined with keen social observation and a desire to point out how different the world could be. And how toxic male behavior towards women currently is. What it's not, however, is much of a novel, in the sense of having a clear plot that carries the reader through the book. There is a story of sorts, which revolves around the appearance of Janet in Joanna's time. Janet is a native of Whileaway, an alternate future Earth in which there are no men at all and social organization is significantly different. We get a fairly detailed description of her life and of some Whileaway customs over the course of the book. But they're mixed with excerpts from the lives of both Jeannine (from an alternate past in which the Great Depression never ended) and Joanna. If Janet's story is a sort of utopian alternate future, following the basic model of female separatist societies, Jeannine's is the dystopia drawn from our past. She's locked entirely into traditional gender roles and the desire to catch a man and be a wife. I found her the hardest character to read about by far, largely because she locks herself into the worst constraints of that role. She's almost entirely passive, and she's devoted to a man for whom it's difficult to have any respect at all. Janet is interesting in part because she's not particularly exceptional in either ability or intelligence. She just reflects the Whileaway culture, which leads to some sharp conflicts with the norms of Joanna's time. It's a very effective tactic for alienating the reader from current gender roles (or, at least, roles from the 1970s) and showing how absurd they appear with a different set of starting assumptions. Russ makes the point clearly; this is not a book that tends towards the subtle, although it can be a little hard to track the characters' progress through alternate timelines. Towards the end of the book, they meet the fourth character. (This is not really the sort of book that is possible to spoil by summary.) Jael is by far the most aggressive of any of them, the closest that any of them come to the caricature of a "man-hating feminist." One of the strengths of The Female Man is that, by the time the story reaches her, I at least was feeling quite a lot of sympathy towards her aggressively violent approach, after watching Joanna be put down and Jeannine simper ineffectually. However, it's worth nothing that Janet, the representative of the supposed utopia, does not agree with Jael or her methods, and the relationship between their worlds is interestingly complex. None of the four characters are exactly wrong (although Jeannine comes close); none of them are entirely right either. They're all struggling in different ways with how to define femininity. While the quiet and simplicity of Janet's world has definite appeal, it's the sort of utopia that one isn't sure one would actually want. And Jael has some pointed commentary on how wanting such a world is one thing, but the acts required to create it is quite another. I can see why this book is so well-known. Many of the scenes that show gender relations and male behavior are both painful and funny. Reading it forty years after it was written, it's clear that social norms have changed; men do and say things here that they would no longer be able to get away with, that are clearly from another era. But it's also clear that some of the underlying attitudes have not changed, just been cloaked in different language. And Russ's bluntness here is refreshing: this book does not pull its punches, both in openly ridiculing sexist behavior, and in showing how oppressive it is for women. That said, it didn't work as a story for me, in part because the plot is sketchy at best. It's a collection of individual excerpts and commentary, only some of which are shaped like a story. Much of it feels stream of consciousness, and when cut between three different viewpoints, it's also occasionally confusing. There are also a few too-obvious characters: some of the men, particularly in Jael's section, but also Jeannine, who I never liked even after she starts changing her mind about women's roles. I wanted a bit more story and a bit less introspection. I think this is an important book that's worth reading, and sadly it's not as obsolete as one would like. But I don't think it's entirely successful as a novel. Best treated as a piece of literary history. Rating: 6 out of 10

Review: The Incrementalists, by Steven Brust & Skyler White

Publisher:	Tor
Copyright:	September 2013
ISBN:	0-7653-3422-4
Format:	Hardcover
Pages:	304

The Incrementalists are a secret society that has been in continuous existence for forty thousand years. The members are immortal... sort of (more on that in a moment). They are extremely good at determining what signals, triggers, and actions have the most impact on people, and adept at using those triggers to influence people's behavior. And they're making the world better. Not in any huge, noticeable way, just a little bit, here and there. Incrementally. Brust and White completely had me with this concept. There are several SF novels about immortals, but (apart from the vampire subgenre) they mostly stay underground and find ways to survive without trying to change the surrounding human society. I love the idea of small, incremental changes, and I was looking forward to reading a book about how that would work. How do they choose what to do? How do they find the right place to push? What long-term goals would such an organization pursue, and what governance structure would they use? I'm still wondering about most of those things, sadly, since that isn't what this novel is about at all. I should be fair: a few of those questions hover in the background. There are some political arguments (that parallel arguments on Brust's blog), and a tiny bit about governance. But mostly this is a sort of romance, a fight over identity, and an extensive exploration of the mental "garden" that the Incrementalists use and build to hold their memories and share information with each other. The story revolves around two Incrementalists: Phil, who is one of the leaders and has one of the longest continuous identities of any of the group, and Renee, a new recruit by Phil who picks up the memories and capabilities (sort of) of the recently-deceased Incrementalist Celeste. Phil is the long-term insider, although a fairly laid-back one. Renee is the outsider, the one to which the story is happening at the beginning, who is taught how the Incrementalists' system works. The Incrementalists is told in alternating first-person viewpoint sections by Phil and Renee (making me wonder if the characters were each written by one of the authors). Once I got past my disappointment over this book not being quite what I wanted, the identity puzzles that Brust and White play with here caught my attention. The underlying "magic" of the Incrementalists is based on the "memory palace" concept of storing memories via visualizations, but takes it into something akin to personal alternate worlds. Their immortality isn't through physical immortality, but rather the ability to store their memories and personality in their garden, which is their term for the memory palace, and then have it imposed on someone else: a combination of reincarnation, mental takeover, and mental merging. This makes for complex interpersonal relationships and complex interactions between memory, belief, and identity, not to mention some major ethical issues, which come to a head in Phil and Renee's relationship and Celeste's lingering meddling. I think Brust and White are digging into some interesting questions of character here. There's a lot of emphasis in The Incrementalists on the ease with which people can be manipulated, and the Incrementalists themselves are far from immune. Choice and personal definition are both questionable concepts given how much influence other people have, how many vulnerabilities everyone carries with them, and how much one's opinions are governed by one's life history. That makes identity complex, and raises the question of whether one can truly define oneself. But, while all these ideas are raised, I think The Incrementalists dances around them more than engages them directly. It's similar to the background hook: yes, these people are slowly improving the world, and we see a little bit of that (and a little bit of them manipulating people for their own convenience), but the story doesn't fully engage with the idea. There's a romance, a few arguments, some tension, some world-building, but I don't feel like this book ever fully committed to any of them. One of the occasional failure modes of Brust for me is insufficient explanation and insufficient clarity, and I hit that here. My final impression of The Incrementalists is interesting, enjoyable, but vaguely disappointing. It's still a good story with some interesting characters and nice use of the memory palace concept, and I liked Renee throughout (although I think the development of the love story is disturbingly easy and a little weird). But I can't strongly recommend it, and I'm not sure if it's worth seeking out. Rating: 7 out of 10

Andres Lozano gave an interesting TED talk about the use of electrodes inside the brain (deep brain stimulation) to treat Alzheimers disease, Parkinson s disease, and depression [1]. Daniel Pocock wrote an interesting post commenting on some bad political decisions being made in Australia titled Evacuating Australia [2]. You can read that as a suggestion to leave Australia or to try and make Australia better. Marco Tempest gave an interesting TED talk about Nikola Tesla [3]. The presentation method is one that I ve never seen before so I recommend watching the talk even if you already know all about Tesla. Charmian Gooch gave an interesting TED talk about global corruption [4]. I think we need people to send the information on shell company ownership to organisations like Wikileaks. The punishment for leaking such information would be a lot less than Chelsea Manning is getting and the chance of getting caught is also low. Rich Mogul wrote an interesting and insightful article for Macworld about the Apple approach to security problems [5]. To avoid the problem of users disabling security features they work to make the secure way of doing things EASIER for the user. That won t work with all security problems but it s something we need to think about when working on computer security. Ray Raphael gave an interesting TED talk about the parts of the US revolution that don t appear in history books [6]. He warns the listener to beware of the narrative forms, but another way to interpret his talk is that you should present your version of history in the narrative form that is best accepted. That lesson is well known and it s easy to see history being deliberately distorted in most media outlets. Will Wright gave an interesting TED talk about how he designed the game Spore and his ideas about games in general [7]. Spore is a really good game. Chris Lintott gave an interesting TED talk about crowd-sourced astronomy titled How to Discover a Planet from Your Sofa [8]. He referenced the Zooniverse.org site which lists many crowd-sourced science projects [9]. Jake Socha gave an interesting TED talk about flying snakes, you have to see this to believe it [10]. Nikita Bier gave an interesting TED talk about his webapp to analyse economic policies [11]. Apparently 60% of people were going to vote in their best economic interest before seeing his site and 66% would do so afterwards that could change an election result. Anya Kamenetz wrote an interesting article for Salon about The Iliad Project which aims to use Indigogo to help identify new anti-biotics [12]. The current ways of discovering anti-biotics aren t working, lets hope this one does. Peter Finocchiaro wrote an interesting Salon article about how right-wing politicians in the US were opposed to Nelson Mandela [13] racism meets anti-communism. Katie McDonough wrote an interesting Salon article about Rick Santorum and Bill O Reilly comparing Obamacare to apartheid while supposedly honoring Nelson Mandela [14], Katie also notes that Nelson enshrined universal healthcare in the South African constitution something all countries should do. Mary Elizabeth Williams wrote a Salon article about Susan Boyle s announcement about being diagnosed with Asperger Syndrome [15]. Not a surprise though, some people can be diagnosed with Autism by merely watching them on TV. Amelia Hill wrote an article for The Guardian/The Observer about the educational results of Home Schooling [16]. Apparently Home-Schooled kids learn significantly more and home-educated children of working-class parents achieved considerably higher marks in tests than the children of professional, middle-class parents and that gender differences in exam results disappear among home-taught children . Wow, Home Schooling beats gender and class problems! I m sure it s even better for GLBT kids too. Robert Reich wrote an interesting Salon article about the way rich people in the US give tax-deductable (taxpayer supported) donations to charities that benefit themselves [17]. Dan Savage wrote a very funny review of Sarah Palin s latest Christmas book, one classic quote is why should I have to read the whole thing? Lord knows Sarah Palin didn t write the whole thing [18]. He makes a good point that we should use the term happy holidays instead of happy Christmas just to show that we aren t assholes.

• [1] http://tinyurl.com/d9dugzc
• [2] http://progressivedirection.com/evacuating-australia
• [3] http://tinyurl.com/7fzntxz
• [4] http://tinyurl.com/n8mnrcl
• [5] http://tinyurl.com/lpej6pz
• [6] http://tedxtalks.ted.com/video/Revolution-A-Success-Story-Ray
• [7] http://www.ted.com/talks/will_wright_makes_toys_that_make_worlds.html
• [8] http://tedxtalks.ted.com/video/How-to-Discover-a-Planet-from-Y
• [9] https://www.zooniverse.org/
• [10] http://www.youtube.com/embed/fVa397fMEv4
• [11] http://www.youtube.com/embed/k9QTVII_lkg
• [12] http://tinyurl.com/l746nwn
• [13] http://tinyurl.com/kl6zbkk
• [14] http://tinyurl.com/k346brd
• [15] http://tinyurl.com/nd9estw
• [16] http://www.theguardian.com/uk/2000/aug/13/education.educationnews1
• [17] http://tinyurl.com/n327zal
• [18] http://tinyurl.com/ndp3o3p

I've said recently that pervasive surveillance is wrong. I don't think anyone from the NSA should have a leadership position in the development or deployment of Internet communications, because their interests are at odds with the interest of the rest of the Internet. But someone at the NSA is in exactly such a position. They ought to step down. Here's the background: The Internet Research Task Force (IRTF) is a body tasked with research into underlying concepts, themes, and technologies related to the Internet as a whole. They act as a research organization that cooperates and complements the engineering and standards-setting activities of the Internet Engineering Task Force (IETF). The IRTF is divided into issue-specific research groups, each of which has a Chair or Co-Chairs who have "wide discretion in the conduct of Research Group business", and are tasked with organizing the research and discussion, ensuring that the group makes progress on the relevant issues, and communicating the general sense of the results back to the rest of the IRTF and the IETF. One of the IRTF's research groups specializes in cryptography: the Crypto Forum Research Group (CFRG). There are two current chairs of the CFRG: David McGrew <mcgrew@cisco.com> and Kevin M. Igoe <kmigoe@nsa.gov>. As you can see from his e-mail address, Kevin M. Igoe is affiliated with the National Security Agency (NSA). The NSA itself actively tries to weaken cryptography on the Internet so that they can improve their surveillance, and one of the ways they try to do so is to "influence policies, standards, and specifications". On the CFRG list yesterday, Trevor Perrin requested the removal of Kevin M. Igoe from his position as Co-chair of the CFRG. Trevor's specific arguments rest heavily on the technical merits of a proposed cryptographic mechanism called Dragonfly key exchange, but I think the focus on Dragonfly itself is the least of the concerns for the IRTF. I've seconded Trevor's proposal, and asked Kevin directly to step down and to provide us with information about any attempts by the NSA to interfere with or subvert recommendations coming from these standards bodies. Below is my letter in full:

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: cfrg@ietf.org, Kevin M. Igoe <kmigoe@nsa.gov>
Date: Sat, 21 Dec 2013 16:29:13 -0500
Subject: Re: [Cfrg] Requesting removal of CFRG co-chair
On 12/20/2013 11:01 AM, Trevor Perrin wrote:
> I'd like to request the removal of Kevin Igoe from CFRG co-chair.
Regardless of the conclusions that anyone comes to about Dragonfly
itself, I agree with Trevor that Kevin M. Igoe, as an employee of the
NSA, should not remain in the role of CFRG co-chair.
While the NSA clearly has a wealth of cryptographic knowledge and
experience that would be useful for the CFRG, the NSA is apparently
engaged in a series of attempts to weaken cryptographic standards and
tools in ways that would facilitate pervasive surveillance of
communication on the Internet.
The IETF's public position in favor of privacy and security rightly
identifies pervasive surveillance on the Internet as a serious problem:
https://www.ietf.org/media/2013-11-07-internet-privacy-and-security.html
The documents Trevor points to (and others from similar stories)
indicate that the NSA is an organization at odds with the goals of the IETF.
While I want the IETF to continue welcoming technical insight and
discussion from everyone, I do not think it is appropriate for anyone
from the NSA to be in a position of coordination or leadership.
----
Kevin, the responsible action for anyone in your position is to
acknowledge the conflict of interest, and step down promptly from the
position of Co-Chair of the CFRG.
If you happen to also subscribe to the broad consensus described in the
IETF's recent announcement -- that is, if you care about privacy and
security on the Internet -- then you should also reveal any NSA activity
you know about that attempts to subvert or weaken the cryptographic
underpinnings of IETF protocols.
Regards,
	--dkg

I'm aware that an abdication by Kevin (or his removal by the IETF chair) would probably not end the NSA's attempts to subvert standards bodies or weaken encryption. They could continue to do so by subterfuge, for example, or by private influence on other public members. We may not be able to stop them from doing this in secret, and the knowledge that they may do so seems likely to cast a pall of suspicion over any IETF and IRTF proceedings in the future. This social damage is serious and troubling, and it marks yet another cost to the NSA's reckless institutional disregard for civil liberties and free communication. But even if we cannot rule out private NSA influence over standards bodies and discussion, we can certainly explicitly reject any public influence over these critical communications standards by members of an institution so at odds with the core principles of a free society. Kevin M. Igoe, please step down from the CFRG Co-chair position. And to anyone (including Kevin) who knows about specific attempts by the NSA to undermine the communications standards we all rely on: please blow the whistle on this kind of activity. Alert a friend, a colleague, or a journalist. Pervasive surveillance is an attack on all of us, and those who resist it are heroes.

If you maintain software in debian, one of your regular maintenance tasks is checking for new upstream versions, reviewing them, and preparing them for debian if appropriate. One of those steps is often to verify the cryptographic signature on the upstream source archive. At the moment, most maintainers do the cryptographic check manually, or maybe even don't bother to do it at all. For the common case of detached OpenPGP signatures, though, uscan can now do it for you automatically (as of devscripts version 2.13.3). You just need to tell uscan what keys you expect upstream to be signing with, and how to find the detached signature. So, for example, Damien Miller recently announced his new key that he will be using to sign OpenSSH releases (his new key has OpenPGP fingerprint 59C2 118E D206 D927 E667 EBE3 D3E5 F56B 6D92 0D30 -- you can verify it has been cross-signed by his older key, and his older key has been revoked with the indication that it was superceded by this one). Having done a reasonable verification of Damien's key, if i was the openssh package maintainer, i'd do the following:

cd ~/src/openssh/
gpg --export '59C2 118E D206 D927 E667  EBE3 D3E5 F56B 6D92 0D30' >> debian/upstream-signing-key.pgp

And then upon noticing that the signature files are named with a simple .asc suffix on the upstream distribution site, we can use the following pgpsigurlmangle option in debian/watch:

version=3
opts=pgpsigurlmangle=s/$/.asc/ ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-(.*)\.tar\.gz 

I've filed this specific example as debian bug #732441. If you notice a package with upstream signatures that aren't currently being checked by uscan (or if you are upstream, you sign your packages, and you want your debian maintainer to verify them), you can file similar bugs. Or, if you maintain a package for debian, you can just fix up your package so that this check is there on the next upload. If you maintain a package whose upstream doesn't sign their releases, ask them why not -- wouldn't upstream prefer that their downstream users can verify that each release wasn't tampered with? Of course, none of these checks take the the place of the real work of a debian package maintainer: reviewing the code and the changelogs, thinking about what changes have happened, and how they fit into the broader distribution. But it helps to automate one of the basic safeguards we should all be using. Let's eliminate the possibility that the file was tampered with at the upstream distribution mirror or while in transit over the network. That way, the maintainer's time and energy can be spent where they're more needed.Tags: crypto, devscripts, openpgp, package maintenance, signatures, uscan

Cleaning up X server warnings So I was sitting in the Narita airport with a couple of other free software developers merging X server patches. One of the developers was looking over my shoulder while the X server was building and casually commented on the number of warnings generated by the compiler. I felt like I had invited someone into my house without cleaning for months embarrassed and ashamed that we d let the code devolve into this state. Of course, we ve got excuses the X server code base is one of the oldest pieces of regularly used free software in existence. It was started before ANSI-C was codified. No function prototypes, no const , no void * , no enums or stdint.h. There may be a few developers out there who remember those days (fondly, of course), but I think most of us are glad that our favorite systems language has gained a lot of compile-time checking in the last 25 years. We ve spent time in the past adding function prototypes and cleaning up other warnings, but there was never a point at which the X server compiled without any warnings. More recently, we ve added a pile of new warning flags when compiling the X server which only served to increase the number of warnings dramatically. The current situation With the master branch of the X server and released versions of the dependencies, we generate 1047 warnings in the default build. -Wcast-qual considered chatty The GCC flag, -Wcast-qual, complains when you cast a pointer and change the const qualifier status. A very common thing for the X server to do is declare pointers as const to mark them as immutable once assigned. Often, the relevant data is actually constructed once at startup in allocated memory and stored to the data structure. During server reset, that needs to be freed, but free doesn t take a const pointer, so we cast to (void *), which -Wcast-qual then complains about. Loudly. Of the 1047 warnings, 380 of them are generated by this one warning flag. I ve gone ahead and just disabled it in util/macros for now. String constants are a pain The X server uses string constants to initialize defaults for font paths, configuration options, font names along with a host of other things. These end up getting stored in variables that can also take allocated storage. I ve gone ahead and declared the relevant objects as const and then fixed the code to suit. I don t have a count of the number of warnings these changes fixed; they were scattered across dozens of X server directories, and I was fixing one directory at a time, but probably more than half of the remaining warnings were of this form. And a host of other warnings Fixing the rest of the warnings was mostly a matter of stepping through them one at a time and actually adjusting the code. Shadowed declarations, unused values, redundant declarations and missing printf attributes were probably the bulk of them though. Changes to external modules Instead of just hacking the X server code, I ve created patches for other modules where necessary to fix the problems in the right place.

• proto/fontsproto. Declares FontPathElement names as const char *
• mesa/drm. Adds printf attribute to the debug_print function
• util/macros. Removes -Wcast-qual from the default warning set.

Getting the bits In case it wasn t clear, the X server build now generates zero warnings on my machine. I m hoping that this will also be true for other people. Patches are available at:

xserver - git://people.freedesktop.org/~keithp/xserver warning-fixes
fontsproto - git://people.freedesktop.org/~keithp/fontsproto fontsproto-next
mesa/drm - git://people.freedesktop.org/~keithp/drm warning-fixes
util/macros - already upstream on master

Keeping our house clean Of course, these patches are all waiting until 1.15 ships so that we don t accidentally break something important. However, once they re merged, I ll be bouncing any patches which generate warnings on my system, and if other people find warnings when they build, I ll expect them to send patches as well. Now to go collect the tea cups in my office and get them washed along with the breakfast dishes so I won t be embarrassed if some free software developers show up for lunch today.

Last year I told you that I spent two full-time days working on Debian as a part of initiative sponsored by my current employer. This year I ve devoted these two days again for Debian. Quick summary of what I was able to do during these two days. 11 bugs, 4 lintian errors and 43 warnings were fixed. In addition 3 packages now use new source format (usually that means repackaging software from scratch). 4 uses new copyright format and the newest Standards-Version. 5 packages were updated to the newest upstream version. Changelog entries:
potrace (1.11-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream version.
* Completely repackaged from scratch (funny experience as usual):
- uses new copyright format
- uses debhelper compatibility level 9 w/hardening options
- uses the newest Standards-Version
- fixes 11 lintian warnings and 2 errors
* Fixes typo in manpage. (Closes: #694492) -- Bartosz Fenski Mon, 9 Dec 2013 11:23:32 +0100 makeself (2.2.0-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream release. (Closes: #690105)
- handles df output in more portable way (Closes: #641804)
* Repackaged from scratch.
- uses new packaging format 3.0 (Closes: #670738)
- uses new copyright format
- uses debhelper compatibility level 9
- uses the newest Standards-Version
- fixes 2 lintian errors and 6 warnings -- Bartosz Fenski Mon, 09 Dec 2013 17:32:45 +0100 dibbler (1.0.0~rc1-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream release candidate 1 version (Closes: #686539)
- doesn't drop dhcp session during pppd restarts (Closes: #641237)
- doesn't hang indefinitely on 'stop' (Closes: #675272)
* Calls dh --with autotools_dev to prevent build failures (Closes: 727356)
* Includes Japanese debconf translation (Closes: #718921)
* Updated Standards-Version (no changes needed)
* Uses debhelper compatibility level 9 w/hardening options
* init scripts now source init functions
* Fixes 20 lintian warnings. -- Bartosz Fenski Tue, 10 Dec 2013 10:05:56 +0100 calcurse (3.1.4-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream version.
* ACK previous NMU - thanks!
* Bumped Standards-Version (no changes needed) -- Bartosz Fenski Tue, 10 Dec 2013 12:22:06 +0100 ipcalc (0.41-4) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* Fixes overzealous input checking (Closes: #332468)
* Martin F Krafft removed as co-maintainer (Closes: #719098)
+ package now uses new copyright format
* Bumped Standards-Version (no changes needed) -- Bartosz Fenski Tue, 10 Dec 2013 13:05:15 +0100 msort (8.53-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream release.
* ACK previous NMUs, thanks!
* Switched to new source format.
* Switched to new copyright format.
* Moved patches to new quilt format and described them.
* Bumped Standards-Version (no changes needed)
* Has correct tcl/tk dependencies (Closes: #545135)
* Doesn't segfault with certain input (Closes: #630485) -- Bartosz Fenski Tue, 10 Dec 2013 16:39:44 +0100
Thank you Akamai

Today was my last day working at Bytemark, and I found it a lot harder than expected. For better or worse I finished earlier than expected; having been gradually removing my accounts and privileges over the past few weeks I'd revoked my OpenVPN key this morning. Mid-afternoon my openvpn connection tried to renegotiate session keys, or similar, and failed. So I stopped work a few hours early. That meant I managed to avoid sending my "goodbye world" email, which is probably for the best - after all a lovely company, lovely people, and a good environment, what can you say besides things that are lovely? I think I largely wrapped things up neatly, and I'm pleased that one of my photos is hanging on the office wall. (I look forward to seeing that actually, I've only rarely made canvas prints.) The only other thing of note this week has been the sharp rise in blogspam I've detected. Black Friday alive and well, on the internets ..

Background I upgraded from Linux 3.8 to 3.11 among with newer Mesa, X.Org and Intel driver recently and I found a small workaround was needed because of upstream changes.

The upstream change was the Add "Automatic" mode for "Broadcast RGB" property, and defaulting to the Automatic. This is a sensible default, since many (most?) TVs default to the more limited 16-235, and continuing to default to Full from the driver side would mean wrong colors on the TV. I've set my screen to support the full 0-255 range available to not cut the amount of available shades of colors down.

Unfortunately it seems the Automatic setting does not work for my HDMI input, ie blacks become grey since the driver still outputs the more limited range. Maybe there could be something to improve on the driver side, but I'd guess it's more about my 2008 Sony TV actually having a mode that the standard suggests limited range for. I remember the TV did default to limited range, so maybe the EDID data from TV does not change when setting the RGB range to Full.

I hope the Automatic setting works to offer full range on newer screens and the modes they have, but that's probably up to the manufacturers and standards.

Below is an illustration of the correct setting on my Haswell CPU. When the Broadcast RGB is left to its default Automatic setting, the above image is displayed. When set to Full, the image below with deeper blacks is seen instead. I used manual settings on my camera so it's the same exposure.


Workaround For me the workaround has evolved to the following so far. Create a /etc/X11/Xsession.d/95fullrgb file:

if [ "$(/usr/bin/xrandr -q --prop   grep 'Broadcast RGB: Full'   wc -l)" = "0" ] ; then
/usr/bin/xrandr --output HDMI3 --set "Broadcast RGB" "Full"
fi

And since I'm using lightdm, adding the following to /etc/lightdm/lightdm.conf means the flicker only happens once during bootup:

display-setup-script=/etc/X11/Xsession.d/95fullrgb

Important: when using the LightDM setting, enable executable bits (chmod +x) to /etc/X11/Xsession.d/95fullrgb for it to work. Obviously also check your output, for me it was HDMI3.

If there is no situation where it'd set back to "Limited 16:235" setting on its own, the display manager script should be enough and having it in /etc/X11/Xsession.d is redundant and slows login time down. I think for me it maybe went from 2 seconds to 3 seconds since executing xrandr query is not cheap.
Misc Note that unrelated to Full range usage, the Limited range at the moment behaves incorrectly on Haswell until the patch in bug #71769 is accepted. That means, the blacks are grey in Limited mode even if the screen is also set to Limited.

I'd prefer there would be a kernel parameter for the Broadcast RGB setting, although my Haswell machine does boot so fast I don't get to see too many seconds of wrong colors...

This is part 6 in a series on organizational design and growth.

The change from a business that the owner-entrepreneur can run with helpers to a business that requires management is a sweeping change. [...] One can compare the two kinds of business to two different kinds of organism: the insect, which is held together by a tough, hard skin, and the vertebrate animal, which has a skeleton. Land animals that are supported by a hard skin cannot grow beyond a few inches in size. To be larger, animals must have a skeleton. Yet the skeleton has not evolved out of the hard skin of the insect; for it is a different organ with different antecedents. Similarly, management becomes necessary when an organization reaches a certain size and complexity. But management, while it replaces the hard-skin structure of the owner-entrepreneur, is not its successor. It is, rather, its replacement. Peter Drucker

What it means Management is the art of enabling people to cooperate in achieving shared goals. I ve written elsewhere about what management is not. Management is a multifaceted discipline which is centered on people and the environment in which they work. Why it s important In very small organizations, management can be comparatively easy, and happen somewhat automatically, especially between people who have worked together before. But as organizations grow, management becomes a first-class concern, requiring dedicated practice and a higher degree of skill. Without due attention to management, coordination becomes excessively difficult, working systems are outgrown and become strained, and much of the important work described in this series just won t happen. Management is part of the infrastructure of the organization, and specifically the part which enables it to adapt and change as it grows. Old Status Quo People generally just do stuff , meaning there is little conscious understanding of the system in which people are working. If explicit managers exist, their jobs are poorly understood. Managers themselves may be confused or uncertain about what their purpose is, particularly if they are in such a role for the first time. The organization itself has probably developed more through accretion than deliberate design. New Status Quo People work within systems which help coordinate their work. These systems are consciously designed, explicitly communicated, and changed as often as necessary. Managers guide and coordinate the development and continuous improvement of these systems. The role of managers in the organization is broadly understood, and managers receive the training, support and coaching they need to be successful. Behaviors that help

• It can be helpful to bring more experienced managers into the organization at this stage, especially if there isn t much management experience in house.
• Show everyone in the organization (including managers themselves) what managers do and why it matters.
• Consider very carefully whether someone should become a manager.
• If someone does take on a management role, treat this as a completely new job, which requires handing off their existing responsibilities and learning a new discipline. Don t treat it as just an extension of their work. Write a new job description and discuss it up front.

Obstacles that stand in our way

• Management misbeliefs
• Granting promotions to management roles as rewards for performance
• Many people, when they experience what management work is like, don t enjoy it and aren t motivated by it. It can be hard to predict when this will be the case, and people can feel trapped in a management role that they don t want. Make sure there are mechanisms to gracefully transition out of roles that don t fit for the people holding them.

Tor is a proxy server which allows its users to hide their IP address from the websites they connect to. In order to provide this level of anonymity however, it introduces latency into these connections, an unfortunate performance-privacy trade-off which means that few users choose to do all of their browsing through Tor. Here are a few things that I have found work quite well through Tor. If there are any other interesting use cases I've missed, please leave a comment!

Tor setup There are already great docs on how to install and configure the Tor server and the only thing I would add is that I've found that having a Polipo proxy around is quite useful for those applications that support HTTP proxies but not SOCKS proxies. On Debian, it's just a matter of installing the polipo package and then configuring it as it used to be recommended by the Tor project.

RSS feeds The whole idea behind RSS feeds is that articles are downloaded in batch ahead of time. In other words, latency doesn't matter. I use akregator to read blogs and the way to make it fetch articles over Tor is to change the KDE-wide proxy server using systemsettings and setting a manual proxy of localhost on port 8008 (i.e. the local instance of Polipo). Similarly, I use podget to automatically fetch podcasts through this cron job in /etc/cron.d/podget-francois:

0 12 * * 1-5 francois   http_proxy=http://localhost:8008/ https_proxy=http://localhost:8008/ nocache nice ionice -n7 /usr/bin/podget -s

Prior to that, I was using hpodder and had the following in ~/.hpodder/curlrc:

proxy=socks4a://localhost:9050

GnuPG For those of us using the GNU Privacy Guard to exchange encrypted emails, keeping our public keyring up to date is important since it's the only way to ensure that revoked keys are taken into account. The script I use for this runs once a day and has the unfortunate side effect of revealing the contents of my address book to the keyserver I use. Therefore, I figured that I should at least hide my IP address by putting the following in ~/.gnupg/gpg.conf:

keyserver-options http-proxy=http://127.0.0.1:8008

However, that tends to makes key submission fail and so I created a key submission alias in my ~/.bashrc which avoids sending keys through Tor:

alias gpgsendkeys='gpg --send-keys --keyserver-options http-proxy=""'

Instant messaging Communication via XMPP is another use case that's not affected much by a bit of extra latency. To get Pidgin to talk to an XMPP server over Tor, simply open "Tools Preferences" and set a SOCKS5 (not Tor/Privacy) proxy of localhost on port 9050.

GMail Finally, I found that since I am running GMail in a separate browser profile, I can take advantage of GMail's excellent caching and preloading and run the whole thing over Tor by setting that entire browser profile to run its traffic through the Tor SOCKS proxy on port 9050.

In his blog, Lars puts words on my feelings of weariness in these situations where we are asked much efforts to make our packages modifiable by contributors who can not or want not to use Git. Most of the core Debian tools, dpkg, debhelper, litnian, debian-installer and many others are developed in Git repositories. Somebody serious about contributing to Debian can hardly avoid Git. It is time for our tools and methods to evolve and take advantage of Git. This requires to say no thank you to contributions based on source packages downloaded from our FTP server, instead of being cloned from the Git repository where the package is actually developed, and this calls the question of what is the real source of the binary packages, but this is a question that is becoming unavoidable.