Search Results: "ana"

29 October 2008

Sami Haahtinen: OpenSSL is way too complicated

It's no wonder people hate dealing with certificates. I'm one of those people who really hate handling certificates. For some reason Linux lacks simple tools to manage certificates. Debian has one set of tools and I bet quite a few other distributions have their own set of tools. So nothing generic. In my opinion the problem lies in OpenSSL, which is an overly complicated piece of software. Sure it's able to encrypt your fries at the local fast food place, but most people never use anything more than the x509 module. And even that is complicated. I'm not saying that it should be point and click operation, but what I want is a tool that allows me to create, renew and verify SSL certificates. Which is pretty much the most common thing you do with OpenSSL. Now, lets assume you have a certificate and a key that you want to check if they match. Can you say from the top of your head how to do that? If so, you are either dealing with this stuff daily or you looked it up from a manual. The correct "magical mumbo jumbo" is:

server:/tmp# openssl rsa -noout -modulus -in /etc/ssl/private/some.key   openssl md5
94c5fa8b0fe1baa6e8dfcdec75444620
server:/tmp# openssl x509 -noout -modulus -in signed.crt   openssl md5
94c5fa8b0fe1baa6e8dfcdec75444620

Now, how easy was that. It only took me 10 minutes to construct that line. Most of the time went to searching Zimbra scripts for the correct magical line. The reason why I went through the scripts instead of the manual is that I had already seen the scripts do a appropriate check. And there is no way I could have constructed that in that kind of a time frame just by using the manual. Usually I think that people complain too much when they can't figure out how to make ls or something work like they want. A certain degree of manual reading is good for you, but in this case it's too much. In any case, I'm posting this rant as a reminder for myself so that the next time I can just look it up from here.

MJ Ray: Get Safe Online - but no encryption advice

One of the main UK computer security websites (Get Safe Online, GSO, a public/private partnership) has recently changed to using a website for security alerts, instead of sending emails that contained a “secret” word. Of course, a non-SSL website is not really safer or easier to verify than the emails, so I asked them: why don’t you use OpenPGP or GPG, like debian’s excellent security advisories? The reply essentially boils down to “our target audience doesn’t use encryption software and we’re not going to educate them and other countries don’t either.” The encryption instructions on their site consists of an extremely vague explanation and links to a dozen or so other websites, along with insulting open source programs (which is disappointingly usual for GSO). The site is a little better than it was last year, but not much. I think it’s a terrible shame that the gov.uk-supported site is failing to encourage encryption software use. Do you think this stems from a fear of strong encryption making it harder for the public sector to snoop on us? So I guess this falls to the common/civil sector to promote personal security. How could we spread encryption software to the masses? GnuPG and as many mail client plugins as you can find? Icedove/Thunderbird and Enigmail?

MJ Ray: Get Safe Online - but no encryption advice

28 October 2008

Russell Coker: Jabber

I’ve just been setting up jabber. I followed the advice from System Monitoring on setting up ejabberd [1]. I had previously tried the default jabber server but couldn’t get it working. The ejabberd is written in Erlang [2] which has it’s own daemon that it launches. It seems that Erlang is designed for concurrent and distributed programming so it has an Erlang Port Mapper Daemon (epmd) to manage communications between nodes. I’ve written SE Linux policy for epmd and for ejabberd, but I’m not sure how well it will work when there are multiple Erlang programs running in different security contexts. It seems that I might be the first person to try running a serious Jabber server on SE Linux. The policy was written a while ago and didn’t support connecting to TCP port 5269 - the standard port for Jabber inter-server communication and the port used by the Gmail jabber server. The ejabberd has a default configuration file that only requires minor changes for any reasonable configuration and a command-line utility for managing it (adding users, changing passwords, etc). It’s so easy to set up that I got it working and wrote the SE Linux policy for ejabberd in less time than I spent unsuccessfully trying to get jabber to work! It seems that Jabber clients default to using the domain part of the address to determine which server to talk to (it is possible to change this). So I setup an A record for coker.com.au pointing to my Jabber server, I’ll have the same machine run a web server to redirect http://coker.com.au to http://www.coker.com.au. For Jabber inter-server communication you need a SRV record [3] in your zone. I used the following line in my BIND configuration: _xmpp-server._tcp IN SRV 0 5 5269 coker.com.au. Also for conferencing the default is to use the hostname “conference” in the domain of your Jabber server. So I’ve created conference.coker.com.au to point to my server. This name is used both in Jabber clients and in sample directives in the ejabberd configuration file, so it seemed too difficult to try something different (and there’s nothing wrong with conference as an A record). I tried using the cabber client (a simple text-mode client), but found two nasty bugs within minutes (SEGV when a field is missing from the config file - Debian bug #503424 and not resetting the terminal mode on exit - Debian bug #503422). So I gave up on cabber as a bad idea. I am now testing kopete (the KDE IM client) and GAIM aka Pidgin. One annoying bug in Kopete is that it won’t let me paste in a password (see Debian bug #50318). My wife is using Pidgin (formerly known as GAIM) on CentOS 5.2 and finding it to work just as well as GAIM has always worked for her. One significant advantage of Pidgin is that it seems impossible to create a conference in Kopete. Kopete uses one window for each chat and by default Pidgin/GAIM uses a single window with a tab for each chat (with an option to change it). I haven’t seen an option in Kopete to change this, so if you want to have a single window for all your chats and conferences with tabs then you might want to use Pidgin/GAIM. Another annoying thing about Kopete is that it strictly has a wizard based initial install. I found it difficult to talk my mother through installing it because I couldn’t get my machine to see the same dialogs that were displayed on her machine. In retrospect I probably should have run “ssh -X test@localhost” to run it under a different account.

[1] http://sysmonblog.co.uk/?p=11

[2] http://en.wikipedia.org/wiki/Erlang_(programming_language)

[3] http://en.wikipedia.org/wiki/SRV_record

Ondřej Čertík: Google Mentor Summit III

On Sunday I checked out from the hotel and enjoyed the breakfast, basically the same as the first picture here. Which is cool, the best way to start a day is with a good breakfast in the morning.

At Google I finally met with Bart Massey, who works at the Portland State University where I was an intern (in 2005) and also he was sponsoring one SymPy GSoC student in 2007.

Then we started to port SymPy to Jython with Philip Jenvey. I first installed openjdk-6, which is in Debian main, then checked out Jython svn, typed "ant" and it just worked. This is so awesome, that we finally have a truly opensource and fully working java implementation in Debian. Philip fixed some bugs already, so SymPy imports just fine. Most of the tests run, but also quite a lot still fail.

We managed to isolate two bugs: issue 1158 and 1159. Then there was an annoying recursion bug, that took us several hours to dig into and I then had to leave at 6pm without a clue. But Philip kept saying, I just need to look more at the java stacktraces that Jython was generating and I'll figure it out. And he did! The next morning he filed an issue 412 in the PyPy tracker, because they seem to have the same problem. There are subtle differences in how to handle __mul__ and __rmul__ methods that are not well documented, so it works in CPython but fails in Jython/PyPy. I think we can fix that in SymPy too in the meantime, so I am very excited, because it seems SymPy will work on top of Jython soon.

There was also a git vs hg session with both hg and git developers. Since I recently switched from hg to git for all stuff where I can choose the vcs, it was very interesting for me. And I must say I am glad I switched. Mercurial works fine enough and with the recent rebase feature I think it is usable, but git just has a bigger momentum at the moment and it just doesn't get in my way.

During the day Steve sent an email to the GSoC list that Dirk forgot his jacket in the hotel room, so I said to myself, haha, that's a pity. And then I realized, oh shit, I left my jacket there as well. They didn't have it in the evening when I stopped there, but fortunately they sent me an email yesterday that they found it, so I'll stop there on my way back.

We also took couple of group pictures, here is just my lame attempt (I am sure people will soon post better ones):

On Monday morning I met with Fernando Perez, the author of ipython, he know works with Jarrod. Then I rented a car and came to visit Brian Granger and his family in San Luis Obispo.

We went to the beach in the evening:

And had a dinner together. Brian showed me his options pricing example he did with SymPy, so I made him create an issue 1175 with the code.
Then we played with the parallel stuff that Brian contributed to ipython and we tried sympy with it and to our disappointment, we found pickling bugs in sympy, it works with protocol 0, but not protocol 2, see the issue 1176 and 1177. This almost smells like a bug in Python itself, but I need to investigate that later more deeply.

Today is Tuesday and we'll work on doing atomic physics calculations with sympy. See also Brian's email to the sympy list about it.

27 October 2008

Decklin Foster: We could customer care less

(And now, a cathartic "I hate this company and I am never patronizing them again, please don't either" post. I should have done ones for at least Speakeasy/Covad and IBM's server division last year. Ah well.) I went to go register a new domain yesterday (announcement soon! Probably this weekend). I've been using Joker for a while, IIRC on the principle that the cooks were using it so it must be decent enough. While registering, I had a bunch of problems with the horrid, useless "Verified by Visa" popup [1] that you see everywhere these days, and eventually this must have looked like suspicious activity to the bank so my card was declined. I only actually found this out when I got mail saying my order was canceled. Okay, sure. I wrote back and explained what I thought was going on and that I'd like to resolve it. Another half hour later, I got this response:

Hello,
please use
   https://joker.com/goto/support/
for all support inquiries.
Regards, your Joker.com team

This is complete and utter bullshit [2]. If a company is going to mail me, I expect to be able to mail them. I have a mail client; it manages communication the way I want it to, and runs my preferred editor to compose messages (which is, in fact, how I am writing this very blog post). I am sick of dicking around on JavaScript-requiring web forms that all work differently and typing in postage-stamp-sized little textareas. Anything I do type in them is lost, because unlike my email client, web forms don't save sent messages unless the authors feel like letting you have a Cc:. When a company forces me to do this, I take it as a sign of disrespect. I tolerate a web browser [3] for reading pages; "applications" are universally painful [4]. One of the things I used to like about Joker was the PGP mail interface. AFAIK, they have not killed it (I didn't bother to check), but with automatic "we don't want to listen to you unless you inconvenience yourself" bounces like this, what's the point? I surmise that there is, or was, some smart person there who understood how (and more to the point, why) to hook a pseudo-mailbox up to a software system, and that they have been overridden by someone in management who realized it's much easier to have dime-a-dozen webmonkeys hook a form up to the same system since 90% of users just don't care (and even people who do notice and dislike this, but are not as inflamed as I, have come to expect it because everyone else refuses mail, so, y'know, pick yr battles son, etc.). Not the sort of culture I put faith my in. The irony of it all was that I was registering this domain to run a service I had decided to create specifically because of another site refusing mail and directing me to an even lamer web form. That would take incoming mail and, you know... process it with software. Suffice it to say, I am no longer going to be their customer. In deciding who to use instead, I figured I'd do a survey of where the domains in that "Subscription" column [5] on Planet Debian were registered, but... WHOIS is basically useless. Every server just returns free text, formatted differently by (apparently) every implementation under the sun. Cheaply parsing something out from .com/.org/.net is possible, but InterNIC kindly blacklists your IP after making more than a few requests in a few minutes. I guess I'm just gonna go with Gandi (but other suggestions would be welcome). In somewhat unrelated developments, I went to nic.at to update my nameservers for Where the Bus At? last week. There was no authentication or anything on the request form, so I just filled it in and sent it off. I got some automatic mail saying I need to print out a PDF, sign it, and fax it internationally. Annoying, and hardly as secure as mailing them with PGP, but whatever. But then, also yesterday, I got another mail saying the update was complete (lo and behold, it was). I am now somewhat concerned about the security of my domain: it seems like anyone can come by and put something in the form and if I'm not around to notice the courtesy mail and ask that they stop the request, it'll eventually go through, no questions asked. I have not yet written them to figure out what the deal is, though. Kinda burned out. I guess I didn't really have high hopes for dealing directly with a ccTLD registrar (this was the first time I've done it... I can't believe I blew 60 on a cutesy domain name) rather than a reseller who competes in a market, but then, I go and google "domain registrar" and look at all the AdWords dollars spent trying to compete with GoDaddy [6] and just kind of want to put my head in my hands. On DJB's DNS pages there's this bit about setting up a domain. It doesn't say "How to (buy register whatever) a domain name". It says, "How to receive a delegation from .com". Which is of course, how it works. And what I want to buy. I don't want "parking" or even gratis nameservers. Just a delegation from .com. Please. No AdWords came up when I googled for that phrase to copy the link. Sometimes I guess markets just sink to the bottom. Anyway. I feel like there's a free-software angle here. My continuing irrational hatred of using other people's forms, web-based mailing-list substitutes, nameservers, etc. stems not so much from their suckage but from the fact that there is no longer any software there, in front of me, for the four freedoms to possibly apply to. Being able to run your mail reader for any purpose doesn't win you much if no one uses mail. I don't really know what to do about this.

[1]

It was only twelve dollars! If I go to hipster market or some other place with brand-new POS systems they don't even make me sign a paper slip for less than $20 or so. But this is the sort of thing dreamed up by people who think good security is setting a cookie to denote that I've answered "what was your first dog's name" or whatever. IF YOU WANT TO BREAK INTO MY BANK ACCOUNTS: I've set the answer to every single one of these questions to "security theater". Easy to remember.

[2]	Not to mention a glaringly RESTless URI.

[3]

Also, as a rule I normally try not to have anything up on my desktop that I can't close and re-open at any time, thanks to screen, MPD, emacsclient, actually using my browser's bookmark function and resisting the lure of tab-bar.js, etc. Web browsers are supposed to suck at preserving state; HTTP is stateless. See also here (and for further reading on that in the Haskell world, check out Yi. I'm hoping to switch to it someday).

[4]	Debbugs, for example, may not have the slickest interface, but if I want to do flags, labels, archiving, threading, or whatever, I can; I'm not at the mercy of some front-end web developer. But we've all heard this litany before.

[5]	Thanks, Hpricot!

[6]	Even if GoDaddy's customer service were completely hacker-friendly, I would not use them, because their president Hates America.

Joey Hess: I voted

I voted early because Sullivan County, TN is phasing in new voting machines this election. On election day, they will use the old touch screen system, while early voters get to test the "new" paper system. The new system is sure to please fans of paper. However, it has two flaws that were obvious to me. I have no way of knowing that my vote will be counted as I filled it out, and I realized half way through that election officials can determine how I voted. Here's why... You have two pieces of paper during the vote. A registration sheet is signed by the voter. A paper ballot has little rectangles that the votor fills in with a ballpoint pen in the privacy of the voting booth. The instructions say to fill in choices completely. Since the voting booths have a hard top, it's difficult to write on them with a ballpoint, let alone fill in little squares completely. The natural thing to do? Slide your second piece of paper under the ballot, so the pen can dig in better. If you don't think about it, you'll probably do this unconciously. Half-way through, I realized that I was leaving imprints on the registration paper, with my name on it, that corresponded to my choices on the ballot. Due to the two-column layout, and the distinctive spacing between different choices, it's possible to look at those imprints and determine exactly how I voted. The registration paper has to be handed in at the end, so the official who sits there all day collecting these has plenty of time to work this out and determine the votes of anyone. (I moved my ballot around and re-filled in squares to try to confuse things.) (Relatedly, one has to carry the paper ballot around the room to take it to the voting machine. It's difficult to keep the ballot obscured while doing this, since you can't fold it, and since they take the registration paper before the ballot, so you can't keep the ballot covered with it either.) The second obvious flaw is that once I fed my ballot into the voting machine, which presumably scanned it and put it in a safe, there was only a confimation that "you've voted!". There was no way to verify that it had counted my vote as I'd marked it.

Most voting system work seems to be in the direction of advocating paper ballots for paper ballots' sake. This doesn't seem like the right approach to me. Is no-one working on writing down the characteristics that an ideal voting system would have, and trying to make them all requirements? My take on requirements of an ideal voting system are:

Only living people in the set of registered voters may vote.
Each votor can only vote once.
The votor should be able to verify that his vote was counted correctly.
There must be a way for the votor to prove if his vote was not counted.
The votor must not be able to prove which way he voted (to avoid payoffs, intimidation, etc).
Others must not be able to determine how a votor voted.
Individual votes must be retained to allow recounts.
The entire vote data should be published so that the results can be verified by third parties.
The system must scale to many millions of voters.
The correctness of the entire voting system should be formally provable.

The paper ballot system I experienced today fails on at least points #2 [A] , #3 (see above), #4 (I walked away with nothing I can use to prove anything), #5 (I can video my vote), #6 (see above), and #8 [B]. At least it scales well though. The old touch screen system failed most of the same points, though it made at least a small attempt to satisfy #3 (by confirming the vote onscreen) -- and it failed #7, and probably scaled worse. Outside of the American election system, I've participated in voting systems that seem able meet requirements #1 [C], #2, #3, #4, #7, #8, and #10. To me, #10 is the most important point, but it seems to be the one that is neglected most. Some of the points may be worth weakening if they block other points. Is it really worth avoiding giving me something to prove how I've voted, and banning taking cameras into the polling place, in order to meet point #5, if this defeats point #4? I'm curious what requirments I may have left out too. My list is just a rough stab at it. The real point is to analyze voting systems, and reject ones that don't provably meet criteria. Until it becomes accepted practice to do that, our voting systems will not get appreciably less flawed.

[A] If you can get two copies of the ballot, you can vote twice ... fairly easy with a friend on the inside to arrange for the two copies to get "stuck together", and another one at the vote scanner to allow you to scan both. [B] The ballots could be published, but there's no way to prove all of them, or the true ballots would be. And in reality, they're either shredded, or locked away, or tossed in a dumpster, or variously all three. [C] Mostly. Perfectly accomplishing #1 is harder than most of the other points, and may be worth leaving out of scope.

Romain Beauxis: About democracy (revisited)

After my last post about the ongoing debate on the new process to accept and handle debian project members, Rapha l Hertzog proposed an alternative organisation which could be a solution, but misses the most important fact: how the people in charge of the process would be chosed and dismissed. Rapha l Hertzog wants that we consider a group of skilled and trustfull people in charge of giving and revoking powers to lower class of developers, on a per-event basis. Their procedure would be an internal vote amongst this group, and they would be called the "Debian Community Managers". Although it could be a good idea, it really misses the MOST IMPORTANT FACT: how they are chosed and to whom are they responsible. As a reply to my comment, Rapha l propose that they would be elected at first, and then nominated/revoked on the basis of the decision procedure mentioned above. Not only is it exactly what have been in place for the last years in the various core teams, but also it is a dangerous naive vision of how powers and regulations must happen. Before the Debian project started to consider these issues, the various ideas to build a system where the majority is ruled by a minority and the means to prevent the most important issues has already been studied, in the field of Law and how to write a Constitution for a democratic system. The goal of a democratic system is to put some higher power in the hand of several, but prevent as much as possible any issue. And preventing means act before shit happens, not after. Furthermore, power has to be divided into several domains, where the people in charge of these domains are strongly seperated and share as less common interest as possible. Hence, the goal of a constitution is to weaken power and put barreers, even if this leads to slow and frustrating reform processes. In the same idea, elections, which redraw the positions, are planed on a regular basis, and if the previously elected people were good, they are relected, not the opposite, in which if they aren't good they are dismissed. Again, we prevent issues, so the requirement to be responsible for what you did is implicit. And, last, it is well known that the less direct a decision process is, the less democratic it is. Hence, one should always prefer direct elections to indirect nominations. Now, coming back to Debian, we can have a very similar distinction in the various powers available:

Legislative power: GR
Executive power: core teams and DPL
Justice power: no formal role.

Now, the propositions, and all the various discussions are motivated by either the fact that there are issues with some developper's behaviour, which falls into the justice side and for which we already have a wide history of long debates before we act whatever the act is, or the executive power to give rights and introduce a new member in the project. Yes, we clearly miss a role in the project for applying rules and sanctions and deciding about these issues. However, we really ought to fix it the right way. In particular, never should we, in any way, give any justice power to someone in charge of any of the other power, in particular core teams. And the same for the right to appoint new members. For instance, to name an issue, the Frans vs. Sven issue would have been really different if there wasn't any kind of personal interest and power in the people in charge of the decisions. In real social systems, the right to apply a sanction or give new rights is a very dangerous power. It suppose a high level of separation between your personal interest, and the decision you have to make, as well as a high level of responsability against the people who trust you. We used to claim that Debian was not a democracy, but a meritocracy where technical skills are the ultimate ranking for deciding who's good or bad when giving reponsabilities. I have never been convinced by this approach, which I consider, just as anarchy, as valid for a small group of developers, but completely naive for a big group. Now, it is clear that the issues that we are dealing with in this situation have nothing to do with technical skills. In particular, the original proposition creates a class of non technical contributors, documentation writers, or translators etc... Furthermore, if you look back in the past, there have been a lot of situation where the issue, and its solution had nothing to do at all with technical issues, like issue mentioned above, or the Duck Tank or whatever it was called. We really should drop this naive idea that technicals skills are the only way to put on decision on the project. That is no longer how it works, nor a solution to the human issues that we face now.

Raphaël Hertzog: Debian membership reform

Following Ganneff’s post to debian-devel-announce, several discussions have again started on the topic of Debian’s membership and several proposals have been made. Unfortunately none of these proposals try to resolve the underlying trust problem that has been growing over the years. Despite the NM process (or maybe due to it), we managed to give DD status to people who are motivated but whose technical skills are doubtful (at that point people ask for an example, and as much as I hate fingerpointing, here’s an example with #499201. The same maintainer created troubles with libpng during the etch release cycle and tried to take over a base package like mawk recently). With our current model, all DD can sponsor, NMU, introduce/adopt/hijack packages without review. This is fine as long as we trust the body of DD to contain only skilled and reasonable people. I believe that premise to be somewhat broken since Debian has become too big for people to know everybody and since the NM process had no way to grant partial rights to volunteers who were motivated but that clearly had not shown their ability to handle more complex stuff than what they had packaged during their NM period (like some trivial perl modules for example). Thus I strongly believe that any membership reform must provide a convincing answer to that trust problem before being implemented. I took several hours to draft a proposal last Friday and I’ve been somewhat disappointed that nobody commented on it. I hope to draw some attention on it with this blog post. The proposal builds on the idea that we should not have classes of contributors but simply two: a short-term contributor and a long-term contributor (those are called Debian Developers and have the right to vote). But all contributors can be granted privileges as they need them for their work and each privilege requires the contributor to fulfill some conditions. The set of privileges and the conditions associated all need discussions (but I have personal opinions here, see below). There’s however one privilege that is somewhat particular: it’s the right to grant privileges to other contributors. Handling it as a privilege like another is on purpose: it makes it clear that anyone can try to get that privilege and the procedure is clear. In practice, imagine that set of people as a big team encompassing the responsibilities split over DAM/AM/FD/DM-team and where all members can do all the steps required to grant/retire a privilege provided that 2 or 3 members agrees and that nobody opposes (in case of opposition a specific procedure is probably needed). I called that set of people the Debian Community Managers. It should contain only skilled and dedicated developers. One of their main duties would be to retain the trust that the project as a whole must have in all its members. They would have the powers to retire privileges if they discover someone that has not acted according to the (high) expectations of the project. Among the privileges would be limited upload rights (like DM have currently), full upload rights (like DD have currently although it might be that we want to split that privilege further in right to sponsor, right to package new software, right to maintain a package of priority > standard, etc.) and developer status (email + right to vote, once you can prove 6 months of contribution). There’s lots of stuff to discuss in such a proposal (like how to decide who gets what privileges among existing DD) but I think it’s a good basis and need some serious consideration by all the project members. The NM process is there only so that we can collectively trust that new members are as good as we expect them to be and trust can only be built over time so it’s good that we can grant privileges progressively. Some people believe that I’m reinventing a new NM process that will end up to be very similar to the current one. My answer is that the conditions associated to each privilege should be based on the work done by the contributor and the advocations that he managed to collect. It should not be a questionnaire like Task and Skills . This, together with the distribution of the power/work on many people, would render this system very different from today’s NM process. Some people believe that I’m copying Ubuntu when designing this since it’s somewhat similar to the process to become MOTU and/or get upload right to Ubuntu’s main component. Let me say that I’m not copying deliberately at least, I simply took the problem from the most important side. But remember that many aspects of Ubuntu have been designed by Debian developers that tried to avoid known pitfalls of Debian, and maybe they got some things right (or better at least) while doing this. Partagez cet article / Share This

26 October 2008

Chris Lawrence: Inside baseball

I’ve been remiss in pointing my readers recently to Zachary Schrag’s Institutional Review Blog, which patiently documents the overreach and misapplication of federal regulations regarding the protection of human subjects to the social and behavioral sciences, including research that by federal regulation is exempt from review by IRBs. While Schrag is cautiously optimistic that the new head of the Office of Human Research Protections will be an improvement, the continued domination of the process at most levels by biomedical researchers—along with the general sense that, as Schrag notes, “researchers cannot be trusted to apply the exemptions themselves”—is still troubling to those of us who want to conduct human subjects research, particularly secondary data analysis. Technically speaking (even though I dare say most social scientists observe this requirement in the breach), even the analysis of secondary data collected by others and fully anonymized before we see it (e.g. use of data such as the General Social Survey, American National Election Studies series, the Eurobarometer series, etc.) requires IRB oversight and approval beforehand.

Sean Finney: ps3-kboot for debian

now that ps3-utils is packaged, and it seems spufs didn't take much to get to work, i'd like to turn back to the installation procedure, which was admittedly manual and not exactly as "seamless" as i think it could be. the first step as i see it is to get the bootloader working both generally and also specifically for the installer. by "working", i mean the following:

that it can be used to start the installer
that it can be used to boot the system, of course
that it can be built within debian

the third of these being the most complicated, as will be detailed below. how a linux (kboot) "otheros" bootloader works on the ps3 okay, so i'm not intimately familiar with the powerpc architecture, nor with all the details of cross-compilation, but this is as much as i can tell.

the file "otheros.bld" which you use to start the installation is a compressed linux image with a built in ramdisk initrd.
it is a custom generated image made by kboot, which includes specialized versions of busybox and kexec-tools among others.
it is compiled with a locally bootstrapped compiler and uclibc library.
the initrd boots to a kboot script/prompt, which will then find and load the "real" or "system installed" kernel off of the disk.
you can also specify a different kernel to use, different boot params, etc.
you can also optionally get to a limited shell environment to poke around.

how kboot can be used on the installer including support for this "otheros.bld" bootloader on the installer is fairly easy from a technical point of view, whether it's a usb disk or netinst cdrom image. basically, in either case the media should have a directory called "ps3/otheros", in which the file is placed and named "otheros.bld". when running the PS3 in game-os mode, this is where it looks when you tell it to "scan for otheros". how kboot can be used/maintained, generally speaking beyond a kboot.conf file, nothing really needs to be done on the host os to use kboot. of course, it would be nice to be able to issue updates for an image, which should be possible with a package that makes use of ps3-flash-util from the ps3-utils package. nothing too difficult/complicated there. how kboot can be used/built within debian this is the tricky part. in additional to the standard Free Software guidelines which debian is so (in)famous for following, we also have some basic QA rules that are needed from a distribution release management / security perspective. one of these rules is that generally speaking it is considered taboo to include embedded copies of other software within a package, if that software is already available in debian. for example, i don't think it's very likely that the ftp-masters will look very kindly on some new software package that includes a copy of the entire kernel source tree, the gcc compiler, (uc)libc, busybox, coreutils, udev, etc. it may be that a certain subset will require special patches, in which case some convincing/justification will be in order, but for the big ones (i.e. the kernel) there will almost certainly need to be modifications made. ps3-kboot in ubuntu there are already source packages available for ps3-kboot in ubuntu. apart from the fact that i can't stand working with packages that use cdbs, this package can't be used because the package maintainers' solution to the previously mentioned problem is basically to ignore that it exists. it also seems that there's quite a bit of customization in this source package with respect to the initrd generation, which is probably worth some review... so i will likely still use this package as a base point of reference.

Ondřej Čertík: Google Mentor Summit II

On Saturday morning I met Steve McIntyre and Dirk Eddelbuettel, Steve took us by car to Google. Well, it was overwhelming.

For example we met there two other Debian developers, Jeff Bailey and Daniel Burrows. There are developers from all the famous projects, like git, Wine, Turbogears, Jython, ... There are still people I wanted to meet but didn't manage yesterday, need to fix that today. My plan is to get SymPy running on top of Jython, or at least do some more progress to take the advantage, that Philip Jenvey from Jython is here. Also I wanted to fix some RC bugs in Debian when Steve is here, to make some progress on my NM finally. We'll see how it goes.

There was also an excellent presentation from people behind Android. One thing I was curious if it's going to run native C applications, like Python and it seems it will happen eventually, all the sources are out there, so someone just needs to push it forward. Another very cool thing they did that I was always looking for is Gerrit for reviewing patches (see review.source.android.com for example how it looks like) -- basically a fork of Guido's codereview, but it has many nice features, like automatically applying the patch to the git repository as a new topic branch and one can then easily pull it, as well as review it over the web interface. When I get back to Prague I am going to install this for SymPy.

25 October 2008

David Welton: Slicehost + Ubuntu Intrepid Upgrade

As I wrote previously, I started looking around for a new hosting provider, as Layered Tech is jacking up their prices too much. This isn't something I consider 'fun', as it will involve a lot of time swapping things over, with the potential for problems, but the amount of money disappearing every month is too much to ignore at this point. After some dithering, I finally went ahead and spent some money for a minimal slice at Slicehost. Linode seems pretty competitive too, but I more or less flipped a mental coin. I was actually ready to go ahead the other day, but I stopped to think some more after seeing that Slicehost has been acquired by Rackspace. In terms of seeing hard working people rewarded for their efforts, I am of course happy for the guys at Slicehost, but it also leaves a few questions:

Sometimes, perhaps not immediately, but after a while, there is less incentive to bust your butt if you cashed in in a big way.
Rackspace is not my kind of hosting outfit: they don't even list their prices where people can see them, like Slicehost, Layered Tech, and most everyone else does. I've heard they're good, but quite expensive. I don't need 'managed' servers - I can do that myself.
The FAQ says that Slicehost will continue as a going concern in its own right, but there's always the chance that they were acquired for their tech, and that the FAQ just says that they will continue to operate to keep their current clients from bolting.

Of course, good things could come out of the deal too, so I decided to put my paranoia aside and test the waters. There are a lot of things to like about a system like Slicehost's: it's relatively quick and easy to set up new slices, fiddle with the resources that each slice has, and so on, compared with a physical server. Furthermore, they have a reputation for not 'overbooking' their servers, which is why I wanted to get away from a VPS in the first place, many years ago. Setting up a slice was very quick and easy, but unfortunately got off to a rough start: their "fraud detection" system had a problem with me being in a different place than my billing address. Luckily, they were very fast at correcting the problem. As an aside, I think that fraud detection is probably best left to the credit card companies, although of course I don't really know their business, so maybe that particular check has saved them some money/frustration in the past. Upgrading the Slicehost Ubuntu to Intrepid In any case, once I got it up and running, I wanted to test out the upgrade to Intrepid, as that's going to be out in less than a week, and I might as well upgrade while I have 'fresh' servers to play with, and prior to installing a bunch of stuff. It went very well. I did a do-release-upgrade -d, hit 'yes' to everything, rebooted, and everything was fine! Admittedly, I don't have anything running on the server yet, so that kept things short and sweet, and didn't require the upgrade of various systems which might have had troubles, but so far so good If you'd like to sign up for Slicehost, it looks like they give you a referral code. Mine can be utilized by going here.

Ondřej Čertík: Google Mentor Summit I

I flew via Atlanta and had only about an hour to my next flight to San Francisco, so after my last experience, when I went to the immigration, got stuck in the line for more than an hour and then had to run to catch my flight, I decided to try a different strategy this time: first run to the immigration and then walk to my gate. Unfortunately I was sitting near the back of the plane and I got out among the last ones. Fortunately, it was several hundreds meters to the immigration, so I run as fast as I could and I managed to get there as the first one and everything took about 5 minutes. That was just awesome, I finally figured this out.

Jarrod was waiting for me at the airport, went to his place. Here's his cat:

On Friday we did some work and then went to the Golden Gate, the traffic was quite dense:

Alcatraz:

San Francisco:

Then we had a cofee in San Francisco and went to Silicon Valey, Jarrod drove me around a little bit to see SLAC, Stanford campus and other things. In the evening we went to the common pub with other mentors and Google guys, where we for example met with Robert Bradshaw.

Today I am looking forward to meet with all the people I know from mailinglists, Debian and other places.

Jose Carlos Garcia Sogo: Blackerry in Debian

I have uploaded barry package to Debian some hours ago. It is still waiting for NEW processing, so if you want it you will have to download sources from Debian git repo, and compile the package yourself. It has just been accepted into the archive. Barry is a GPL program that will allow you to charge your Blackberry through the USB port, to make backup copies of your device databases, manage contacts and use your BB as a modem. So if you have a BlackBerry device, you can also enjoy it in Debian. Update 26/10/2008: Barry has just been accepted into the archive, so you can get it in every Sid repository mirror. Thanks!

24 October 2008

Gunnar Wolf: Free Software and the Democratic Construction of the Society

Last Wednesday I went for the first time in many years to FES Iztacala, the UNAM faculty where I worked for four years (1999-2003) and where I have most learnt and advanced in my career so far. I have a very special spot in my heart for Iztacala :-)
But it was not just a nostalgy drive - In no small part, I had not visited Iztacala -despite several invitations- because... It is really far away, in Tlalnepantla, Northern Mexico City (while I live in the South, just by UNAM). It takes me approximately 1.5 hours to get there via public transportation, and I would not venture less than 1 hour travel time by car. So... Having nothing to lose, I decided to go by bike - you can look at my route to get there (OpenStreetMap, SportsTracker) and safely back home (OpenStreetMap, SportsTracker). Some people I have talked with think it was a crazy thing to do - No, I don't feel that, by a long shot. A 26Km ride in slightly under two hours, and back. People insist on thinking that biking in such a large and chaotic city as Mexico is unsafe, dangerous, suicidal... I deeply disagree. Cycling is fun and got me to my destination in almost the same time I would have made by bus. And no, I would not buy four liters of gasoline just to cross my city.
Anyway, I am also happy about the reason that actually got me to go to Iztacala - I submitted a talk+paper I prepared together with Alejandro Miranda to Congreso Internacional Software Libre y Democratizaci n del Conocimiento organized by Universidad Polit cnica Salesiana in Quito, Ecuador. This conference is quite different to those I am used to, as it is quite more formal and academic; it is mainly targetted at social scientists working on understanding our movement. We prepared a talk called Software Libre y la Construcci n Democr tica de la Sociedad - which was accepted, to my amazement.
Neither Alejandro nor I were unable to travel to Ecuador to give the talk, so we arranged to present it via a videoconference call - Which was based on Iztacala. A nice session, although quite different to what I am used to. Our presentation was on a panel setting, under the global Ethical and political dimensions in the Free Software culture, with 20 minutes to present the topic (I am used to preparing one- or two-hour talks), and it was frankly rushed... We "met" with some friends (or were able at least to greet them shortly after the talk) who attended live to the conference, and... Well, all in all, it was one of those good, interesting experiences I would surely repeat. And besides, I have several things pending to show off about my current work to my Iztacalan fellows ;-)

Chris Lawrence: Satisficing or incomplete information?

It occurred to me this morning, as I was pondering our forthcoming ads for two political science positions and a conversation I had yesterday with some other social scientists, that had I accepted either of the tenure-track jobs I was offered before coming to TAMIU, I’d never have even applied for this job even though on most dimensions, at least in my personal judgment, it’s a better position than either of those were/are. I’m not really sure what this all means, but I figured letting my readers engage in something a step above dream analysis might be more interesting than not posting anything today.

Adeodato Sim : A use case for a DEP

I’ve read in a couple posts already that these changes to membership in the project would be appropriate to manage with a DEP: I agree. I agree, not because I think the end result should be a DEP (maybe it should be a GR after all), but because of the workflow the DEP procedure proposes. The key, in my opinion, is the driver (or drivers): somebody without an agenda but trusted by the project who should take care of fostering the discussion, summarizing it regularly while keeping all differences of opinion mentioned, helping the discussion get somewhere, and talking with people in the relevant roles if they, by any chance, would not participate in the discussion directly. The result would then be a solution which everybody has had a say on, and a text that can be passed by GR with an overwhelming majority. Or, in the worst case, a GR where most of the points are common between options, but that has a couple choices for the most conflicting points, should that be needed. I would love to see this happen first thing after Lenny: this can be so exciting if done well!

Joerg Jaspert: Developer status

Nice how some people (on purpose?) try to misunderstand everything. And love to flame. (Yes, it was my mistake to not explain the meaning of we right at the top - or in that mail at all -, sorry.) Lets address a few of the issues:

The whole thing adds more bureaucracy to NM and makes it harder to become a Developer. Entirely wrong. In fact it makes it a lot easier to enter the project. Imagine the old, current, way:
- Get DM for your package(s), signing SC/DFSG and get advocate(s).
- Get a DD to check your package and upload it with some obcure extra flag to allow you to upload it yourself. Sometimes, except for those bugs which block you from it.
- Or alternatively do all your package work through a sponsor, always searching for one for even the smallest bugfix.
- At some point you want to get a “real Developer”, so you apply as NM
- Get another advocate to speak for you
- Wait until you get an AM assigned.
- ID check
- P&P (lots of questions, including SC/DFSG/DMUP)
- T&S (again lots of questions and also Package checks)
- Wait for FrontDesk (usually fast)
- Wait for DAM (usually fast these days)
- Hello new DD.
This can easily take up weeks, if not months and means lots of double work, especially for the new maintainer. Now imagine the new way:
- Apply at nm.debian.org
- Get one or more advocate(s) to speak for you
- Wait until you get an AM assigned.
- ID check, together with SC/DFSG/DMUP
- Small P&P, with the size entirely depending on what the NM-Committee wants to see, so probably just the few bits about Debians philosophy.
- Yay, you are DC or DM now (whatever you wanted).
- In case you selected DM, to get a package into the list of (source) packages you are allowed to upload, every NM-Committee member can now do that, after they did a little check of it Which means your AM will set an initial list of them when he/she approves you, every NM-Committee member can then adjust it whenever needed. And as every Developer can easily become a member of that committee, basically everyone can do this.
- Let the time pass, get packages uploaded, be a member of the Debian community, whatever you want.
- Want to do more / have more rights? Say so in your nm.debian.org page[1]
- An AM will be assigned again, to check that your request is valid and should be granted, depending on what you want (DME/DD). Which should be along the lines of
  - passed the minimum waiting time?
  - has shown enough proof that they know what it means to be a DME/DD? (Ie. knows how to deal with packages, users, votes, whatever applies). Assuming one took the DM way and wants to get DD, this could be done by something as simple as a package check and then listing a number of URLs showing the DAMs the work the applicant did in the past. (Like, preparing lots of patches for RC bugs, doing lots of good maintenance within their own package / package teams, lots of documentation written, things translated, whatever). The exact action needed will IMO highly depend on the applicant. The goal should be to clearly show that they know what they do. How that is proved is something the AM can decide (and the NM Committee can give hints / examples). The question to answer is “Can a person that hasn’t dealt as close as you with the applicant fully support the statement Yes, this applicant should have the DD/DME status! or not?”. Currently this is achieved by using the template questions.
- The AM approves your request
- Wait for FrontDesk (will be easy, so fast)
- Wait for DAM (will be easy, so fast)
- Hello new DD/DME
This means you can pass the last step within a day (or two, add the usual delays that you always have in a medium that E-Mail is :) ) Granted, currently the time it takes to wait for an AM is just too long. We do not have enough AMs. I think thats partially due to the amount of work required as AM and partially due to the level of knowledge we require from AMs. I do think that this will get better in the future, thanks to the changes, as the work an AM has to do will be vastly different from today. [1] This, of course, needs to be coded in some way.
The DAMs can’t just decide this, they must ask everyone. Well, IMO the changes proposed are within the rights of the DPL’s delegation (and constitution) gives to the DAMs (and for the upload thing, Ftpmaster). This is account (archive) management. This is not taking away rights like voting, getting delegated, standing for DPL or starting a GR. This only opens a new, much easier, way to join Debian. And leaves everyone the option to join Debian in a non-technical, not package-bound, way. Yes, every DD can start a GR to override this, if they want to. This is part of the constitution and a way to let the project decide if it does not like a decision a delegate did.
This has to be stopped by a GR now, we can’t accept it. Or it should be discussed at length later. Keep in mind that this is not yet implemented, and won’t be for a bit more. It needs work on multiple places to be done first. And we sure will modify this including good suggestions/constructive critic. (Changes needed are some for the nm.debian.org interface, within dak to allow the new style for DM or keyring-maint to take the keyring, to name a few examples. This will take time.) But feel free to do the GR, as written above this is your right as a DD. This is IMO the way to go if you oppose the proposal because you do not want to make it easier to join Debian. Or because it does not go far enough (small steps anyone?) or for whatever other reason But then stop whining how hard it is to join Debian and that one should change this, please, you just lost every ground for it.
Debian is about packaging only and we should not welcome more people that do not do package works and everyone should have the same full set of rights. Err, sure.
The naming should be changed Hrm, maybe. I don’t think its so complicated, but well, why not.

There are many more things on the mailing list, but this post is already a little to long, so lets stop for now. I might blog more later on and reply to a bit more. I might also try and reply on the mailinglist, but erm, thats a HUGE thread already… What I won’t reply to are those few people who wish me to die or suffer from something painful. Sorry, I have to disappoint you, none of this is on todays agenda. Comments: 5

Lucas Nussbaum: Developer status: problems and solutions

For a minute, I’d like to think about The Announcement in terms of problems and solutions. Problem: We don’t have enough non-developing contributors in Debian
Solution in The Announcement: Give them special, official, statuses in the Debian community, so they are rewarded for their work.
Alternate solution: Are they really looking forward this status? Aren’t we just thinking that they are just as power-hungry as we are? Last time I checked, the Debian community wasn’t really welcoming non-developers. It isn’t a problem of official status. We have to work on ourselves to make Debian a better place to be for non-developing contributors. Also, giving those people a second-class citizenship, that won’t be widely recognized — “Debian Member” instead of “Debian Developer”, isn’t going to help. (or even worse, “Debian Contributor”, which doesn’t give any right except an email address). Problem: We have a trust and security problem. It’s difficult to give upload rights and access to Debian machines to more than 1000 people, with some of them not being active anymore, or not having much experience with security (in the case of non-developing contributors).
Solution in The Announcement: Remove rights based on classes of developers, so the group of people having full access stays within manageable boundaries.
Alternate solution: Have fine-grained control on who can do want. Problem: DMs can’t get access to Debian resources because their keys aren’t managed by the Debian keyring team, but by another team.
Solution in The Announcement: Keyring managers will take care of the Debian Maintainers keyring too. In the past, the keyring managers were the cause for huge delays in the NM process. It has improved a lot recently, but it doesn’t mean that it will always be like that.
Alternate solution: Make the DM keyring team, the keyring managers, and DSA, work together on a solution. it doesn’t sound impossible. If that’s necessary, merge the DM keyring team and the keyring managers. Problem: DM was done without the blessing of most of the members of the loosely defined group of powerful DDs (sometimes described as “cabal”).
Solution in The Announcement: Drop it, replace it with something very similar, but originating from the cabal.
Alternate solution: Why not keep it? Problem: Clueless DDs advocate clueless contributors for DMs. Then those DMs upload crap to the archive. (Note: I don’t necessarily agree with that problem, that’s just a problem that the announcement tries to solve)
Solution in The Announcement: Require answering a few questions before becoming a DM. Remove the right for every DD to decide which DM can upload which package. Give that control only to the NM committee.
Alternate solution: If we can’t trust one DD to take the good decision about advocating someone for DM, we could require that each person needs to be advocated by two different DDs. Or three, four, five. Asking the DM to answer a few questions, whose answers he can probably get by asking around on IRC, is not going to improve the average level of our DMs or DDs.

I believe that there are real problems that need to be solved, but that the decisions announced don’t solve the real underlying problem. Here is what I’d like to see:

Fine-grained access control for each DD or DM or …:
This would allow people to have specific rights inside Debian, like:

Right to login on each debian.org host (a per-host switch)
Right to upload packages for which the person is Maintainer or Uploader
Right to upload any package
Right to vote

All rights would default to “NO”. DDs would be allowed to change their rights for everything, while DMs would only be allowed to change specific rights. Of course, we need a secure way to change rights (HTTPS+confirmation using GPG, like the current “sudo password” thing?). But that would help with the security problem (you wouldn’t have access to all Debian hosts without enabling it). In fact, we already have that: many hosts require a switch to be enabled in LDAP before you can login, and we have tons of Unix groups to restrict access to specific areas of our infrastructure. I’m just proposing to extend that to basically everything, and to allow people to grant themselves some rights without going through DSA.

Modified NM process for non-developing contributors, that would still include many P&P and T&S questions, but would give “Debian Developer” status without any upload rights. That way, non-developing contributor would have an official status, and will still be able to write “Debian Developer” in their resume. Giving a different status to those people just because we don’t think that they should have the right to upload any package doesn’t feel right.

Is that enough? Probably not. We need to be more welcoming towards non-developing contributors, which is a social problem, not a technical one. But we are not going to solve that in a GR.

Next.

Previous.