Move along, nothing to read

Ok, so I've totally slacked off, and not posted about the rest of OLS2008 yet, but this post is more important than that for now. I was out at the Pride Parade today, then went to meet up with a friend. I locked up my bike at ~17h20, to the racks outside Waterfront Station (I wrote Centre in my Twitter posts, but then realized it was actually Waterfront Station at that spot). I came back at 20h30, to find my bike was gone :-(.

Description: Norco model 7030 (only 95% certain, can't remember exactly), mountain bike. Olive Green and Beige, with some white lines. Front white LED from PlanetBike (batteries quite worn down), no rear light. Stock seat. Rear aluminum pannier rack. Bike lock was an OnGuard Doberman combination lock.

I bought the bike used, almost 3 years ago, from the antiques/junk store on the corner of 31st and Main, for $50. It was probably hot merchandise at the time, but it was a good deal, and in reasonable condition. I've put in probably $50 of maintenance, and the lock+rack were another $40 approximately. Not a lot of money, just enough to be annoying.

I met lisanys and sarahemm for brunch, originally planning to go to Cora's, but the lineup was extremely long, and we gave up after 15 minutes - and wandered over to the Bymarket area instead. Ate club sandwiches, not that good, chicken was very bland next to the prosciutto.

From there, ambled over to the park over the canal from parliament hill, up to parliament hill (without going down to the canal), then down sparks street, before returning to Les Suites hotel to chill for a moment before picking up luggage and split ways.

Now on the flight back I get to write up the rest of my OLS days, as well as the Blackthorn party.

So I previously wrote about the fun with clearing security. My flights were reasonably uneventful. Had an overpriced, soggy prime rib sandwich on the first flight, watched "Flawless" with Demi Moore and Micheal Caine - pretty good movie, on the overhead screen. Air Canada fun in that they have the frames for the in-seat TVs, but there aren't TVs, just little cushions.

Got in to Toronto on time, dashed over the length of terminal one to get to my other flight, it's nicer now with a lot of construction finished. Stopped at the Chocolate store and bought some honeycomb toffee (the stuff inside Crunchie bars).

Next hop was Ottawa, in a small Embrauer jet. In-seat touchscreen displays, with a USB A socket, but no accessible system (it did video for the safety, then had a windows cursor on a logo).

My luggage beat me off the plane, and I picked up a folding plastic map of Ottawa. Grabbed bus tickets at the info desk, and caught the bus to downtown. Nice on dedicated busways, 25 minutes to downtown, then a short walk to the hotel.

Checked in, massive suite - nearly the size of my basement. Living room, bedroom (w/ queen size bed), bathroom, laundry (washer+dryer), kitchen (fridge, stove, microwave, dishwasher) - all old appliances, late 80s look, but functional. Not much in the cupboards, just the bare minimals.

Finished my book from the plane, showered, wrote an email to John Linville to see about the wireless mini-summit. Walked out to the elevator, and ran into John. He was recruiting a group for dinner, which I joined after doing my conference registration. Walked out toward Byward Market, trying to find a place for 14 people for dinner, ended up in the back of a Vietnamese place.

Ate a very tasty lamb, mushroom, onion stir-fry, with two Stellas to drink. Afterwards, the east coast people as well as those from Europe were all heading for bed, but west-coast folk were getting together for drinking - since it was still quite early by our clocks. Went with them, the four of us ended up at an Irish place, that didn't have mint for Mojitos or any other drinks, so we were to drink beer instead. Talking lots accidently lead to too many beers. I previously reported 7 beers, that was drunken miscounting, because we only ordered 4 pitchers, and each of the pitchers held 3.5 beers. Divided by four people, that's only 3.5 beers - added to the other two from dinner, leads to a total of 5.5.

However that was clearly too much, as it didn't sit well later, and made returns before I went to bed.

I'm not sure what's with the sudden wave of spammers hitting livejournal. However they are using some smarted behavior now.

They came to my attension as their spam engines are taking some comments or posts, using them as input data for google, and then using the google results for posting their comment. it's statistical noise, but it's exactly similar to the input noise, so it's beating Bayesian analysis as well.

There is, really, no difference between people stuck in poverty, unless it's a matter of degrees.

It's a matter of degrees, and while I think those degrees matter let's not pretend lawful companies are much better.

There is actually a user and group for trousers. Also gentoo tends to like certain id/groups as certain UID/GID. If that group is used it will then user the next available GID/UID. Sometimes through later upgrades this becomes an issue. Usually badly written ebuilds. That is why I let the script make it.

Of course, not all, but many ebuilds are plainly badly written or gives bad implementations. One example, I update my OpenLDAP setup.

Yesterday:
gemmawasyl
dorottyaniqof

In a wave, over the last 3 hours:
amandafedij
bridgetuhimo
kaileymuseq
katyajuxek
annabellehusiq

They have a single post, with a large block of filler text from somewhere totally random. Followed by a bunch of links with pornish titles, and matching the following pattern:
RANDOM = appears to be foreign dictionary words
CC = belgique, espana, france, quebec, suissse
TLD = .com, except for espana, which is under .es
WORDS = title words for porn stuff, no spaces
http://${RANDOM}.i${CC}.${TLD}/${WORDS}.html

So on Slashdot today, there was a link to the latest research into Package manager security. Specifically, their focus was on defeating signed packages by use of malicious mirrors and replay attacks of signed content. Recording the source of client requests, and possibly denying specific security updates (having an older tree that doesn't contain the security updates).

This plays into some of my long-ongoing tree-signing research in Gentoo. The GLEPs with the exception of 02 and 03 have been mailed to the GLEP editors as well as the portage-dev mailing list, and will be going to the gentoo-dev mailing list after the GLEP editors have reviewed them.

For dealing with the new issues raised by Cappos et al, at Gentoo we are really lucky to have our own infra maintained hardened rotation of mirrors at rsync://rsync.gentoo.org/ in addition to the community mirrors at rsync://rsync$N.$CC.gentoo.org/. Nobody using just the infra-maintained mirrors (barring MITM attacks) would be vulnerable to the new attacks described by Cappos, however those using a community-maintained mirror could be.

Using the main mirrors for new signing purposes, this will enable us to deliver the new MetaManifests reliably via our own infrastructure, even when the user has a community mirror for their actual tree content. The actual changes to the GLEP for this weren't very big at all. Just a timestamp header inside the signed area, as well as distributing the MetaManifests via a trusted medium.

As a minor side note on the infra-maintained rsync.gentoo.org rotation, this would be a good time to consider sponsering a box to Gentoo for that purpose. Each of the 5 existing boxes in the rotation does 50-65GiB of traffic every day - averaging to 6.5Mbit/sec, over a 24-hour period. These boxes are bandwidth, memory and CPU intensive, however they don't hit disk very hard (we serve the trees directly from memory). 4GiB RAM, 2+ 64-bit processors (single core or dual core is fine), ~16GiB of disk (optional: software RAID1 is nice for avoiding downtime, and fancy fast disks aren't needed). We need a serial console or KVM to install it securely - you just boot the box to a livecd, get the access details to infra, we install it from there with our own stage4 tarball that links into cfengine. The machine continues to be owned by the sponsor, in your data centre.

Up until recently, I had thought most Gentoo users and developers to be adults, who made sensible choices in their actions (but not always their words). This may be generalized to acting professionally. I am saddened to report on the ongoing degradation of the community in this regard, and how infra will deal with their side of it.

I've been with the infrastructure team in general for a very long time, however, up until April 2007, I was only the CVS administrator, and had no roles nor access outside of that. Since then, I stepped in as an extra sysadmin, and I've ended up as one of the operational leads, which still means I do most of the work, I just get to make the choices about it too. While the 'old' infra were in some cases called tyrants, dictators, cabals, and other nasty things, we as the 'new infra' hoped to change this view.

We're charged with a lot for developers and users: procuring machines to run them on, maintaining them, developing new services, troubling some user and developer issues (eg: cvs/mirrors) and more.

For myself, in addition to the CVS/SVN/Git services that grew out of my CVS administration, I presently maintain LDAP, Lists and Bugzilla. I have also been the infra liaison to the releng team since 2007.0.

The various VCS and LDAP services are only of primary concern to developers, because extremely few users interact directly with them. However, Bugzilla and Lists are used by significantly more users than developers, and the interactions show.

All messages to mailing lists with 'unsubscribe' in the subject line get moderation and passed to me, and a great many of them are in the realm of blunt and abusive - usually on generic-sounding email accounts that have changed ownership to clueless people. There's also the fun of keeping the spam off (see my recent post to the mlmmj list, of which I should possibly blog about). That's the mundane side. There's also moderation of the actual moderated announcement lists, and tracing mis-delivered list bouncemail as it gets reported. Lastly, and perhaps most important to some, we are held accountable to userrel and devrel for enacting list bans.

Bugzilla gets less direct abuse, however when it happens, it's usually quite flagrant. jakub used to complain to me once or twice a month about users refusing to take no for an answer, and repeatedly filing duplicates, or deleting entire CC lists, or spamming a bug. Since his absence, I've caught less of these early on, simply because he basically read every bug that was filed, and I don't have the time for that (yes, I'd like him back, he did a good job). Bots that ignore robots.txt are a hassle, but are mostly manageable.

For developer issues, we haven't been offering executable homedirs for several years, since some former developers tried running BOINC, and various servers. It seems however that there has never been any codified warning, merely action on a case-by-case basis.

As of today, we're formalizing the handling of this. All infra-maintained machines either already, or will shortly have an AUP banner as follows:

 Any or all uses of this system and all files on this system may be
 intercepted, monitored, recorded, copied, audited, inspected, and
 disclosed to authorized site personnel, as well as authorized officials
 of federal law enforcement agencies, both domestic and foreign. By 
 using this system, the user consents to such interception, monitoring,
 recording, copying, auditing, inspection, and disclosure at the
 discretion of authorized site personnel. Use of this system constitutes
 consent to security monitoring and testing. All activity is logged with
 your host name and IP address. Unauthorized or improper use of this
 system may result in civil and criminal penalties. By continuing to use
 this system you indicate your awareness of and consent to these terms
 and conditions of use. -- Gentoo Linux Infrastructure Admins.

To make it more concise without the legalese: If you abuse a Gentoo infrastructure system, we have no compunctions about kicking your ass and handing you to the suitable authorities (userrel, devrel, $GOV_AUTHORITY).

What does this not mean? Aside from being proactive about patching security issues, we are not intended, nor do have no plans to target people that some of our group don't get along with - we're meant to be accountable and responsible to other authorities in Gentoo. We'll collect the evidence (logging) and execute you (retirement), but somebody else (devrel) gets to sentence you - the only exceptions to this are preemptive actions where we consider security to be at risk.

On the matter of logging, we aren't the Stasi either, we have far better things to do than babysit logs, and we've been logging a lot longer than I was ever even a Gentoo developer. Some former developers and infra folk automated the log analysis, so the only time we really need to look is when something has been brought to our direct attention and needs logs to back it up. The most common uses for the logs are finding abusive users and bots against rsync and bugzilla, plus doing audits after (in)security events.

Ok, so it seems that I'm blogging again a bit, but only about software bugs and treachery. Today's post is about how I've burnt about 6 hours of development time, working through what seemed to be a simple bug.

Some background first. I'd like to switch away from an older system that's presently only used as a display head, with dual 20" LCDs on an Nvidia card. It's too old and limited to run a lot of things on directly. The new system would be both a display head and runs most apps already is a quad G5, with 12GiB of RAM. The great holdup has been in graphics. While I have access to both the stock GeForce 6600 NV43 that shipped with the machine, and an ATI X1900 G5 edition that I purchased later, my luck with graphics drivers has been less than stellar. My choices are between Nouveau, of which this tale ensues, and the competing free ATI drivers (which, at my last testing, were both still stuck, unable to read the AtomBIOS from the G5 card).

Some months ago, I filed a bug for Nouveau, that the first display output worked perfectly, but the second did not. It sat for about a month, before I got a response to go and try again. I didn't get to it until yesterday, because I was away in South Africa for two weeks, and busy with a myriad other things.

Update to the latest Nouveau and x11-drm trees yesterday afternon, and I find that it no longer even starts up a single display now. The debugging thus begins.

1. The Device Control Block datastructure seems to have a bad data signature.
2. Trace it. This is because the pointer to it is byteswapped.
3. Hack in a byteswap. The signature is also byteswapped, something more central is wrong.
4. The functions for "le{16,32}_to_cpu" seem to be broken. Just force them to byteswap for now.
5. Update the nouveau bug again.
6. Now we get an -ENOMEM from a memory allocation seemingly, but digging deeper, it's actually from ioctl.
7. Update the nouveau bug again. Give up for the night.
8. Update the x11-drm Git tree in the morning, and see that there's a fix for the ioctl stuff. Rebuild with it, and find that X will now start, but...
9. The colors are badly swapped too! Red and Green are exchanged, and everything white is in a horrible shade of yellow.
10. Try to initialize the second screen. "xrandr --display DVI-D-1 --right-of DVI-D-0". The taskbar expands as if it was covering both screens, but the second display is still not actually enabled.
11. Update the nouveau bug again. Go and do other stuff.
12. Start prodding into the nouveau driver source for the third time, looking to see about color issues. Mention this in the IRC channel. pq mentions to check that actual X_BYTE_ORDER macro.
13. Doing a quick C program gives the correct output, however during the Nouveau compile, it's defined to _X_BYTE_ORDER (with a leading underscore), and THAT isn't defined.
14. Look at the FreeDesktop.org bugzilla again, locate a bug for the new issue.
15. Leave a comment with some useful output on the bug, and then set out to trace it myself.
16. Revert a Gentoo patch that removes _X_BYTE_ORDER (with the underscore) from xorg-server's configure.ac.
17. Notice that _X_BYTE_ORDER is being defined to an EMPTY string now. That is NOT right.
18. Start reading the rest of configure.ac. _X_BYTE_ORDER should have the value of "$ENDIAN".
19. $ENDIAN is in turn defined by AC_C_BIGENDIAN([ENDIAN="X_BIG_ENDIAN"], [ENDIAN="X_LITTLE_ENDIAN"]).
20. Absolutely great. So what the hell is the problem? Well, on powerpc, the macro returns "universal".
21. Just what the hell is "universal"??? Well it seems that in autoconf-2.6.2, the autoconf maintainers made AC_C_BIGENDIAN take another input.
22. AC_C_BIGENDIAN([ACTION-IF-TRUE], [ACTION-IF-FALSE], [ACTION-IF-UNKNOWN], [ACTION-IF-UNIVERSAL]).
23. So where does leave us? Up the creek with a broken autoconf I think. I haven't figured out why autoconf is telling us that we are universal yet, beyond that it's designed for the OSX universal binaries.

Hopefully I'm not tromping off into the depths of Mordor (aka the hell of autoconf M4 as maintained by vapier and flameeyes.

• 10:15 Going to lunch w/ Jack #