A changelog by Daniel Mettler

i lack the time for an in-depth coverage, but it looks like the recent security issue had a beneficial effect in that it made some more people think about the future development inside gentoo :) nice!

portage-ng requirements sheet (natural language, sure ;). it’s really time for a re-engineered, modular architecture as a) this is probably a pre-condition for any production-quality package signing feature (now: module) in portage b) modularity will improve manageability and quality assurance of portage-ng in general
gentoo release roadmap 2004

regarding the compromised rsync mirror: the attackers seem to have exploited a heap overflow in rsync (glsa: exploitable heap overflow in rsync) to gain access to the box and the recent brk() vuln to gain root privileges. (btw another nice novelty, gentoo now lists glsas on a dedicated web page. yet another thing i’ve been asking for yesterday fullfilled today. thanks! :).

now we know what kind of exploit was used [my assumption that this might well concern all of us who run gentoo was absolutely right] and which box was compromised. i think we can qualify this as “full disclosure”).

all in all: much better now, folks! :)

(see also the news on ln -s)

[note: this server always runs the most current software available. if there are any security announcements (bugtraq, full-disclosure, glsa) regarding software used on this server, i usually update the said software within minutes/hours. further, it’s hardened against some kind of attacks and constantly monitored.]

recently we were discussing about the quality of websites of popular open source applications regarding their usefulness for stakeholders (end-users, devs, media etc.). we did both agree in our judgements.

an example of a very good site: the relaunched mozilla website.

some improvable sites: eclipse.org, openoffice.org (both sites are too much developer-oriented and confusing for end-users despite that the according applications have reached stable status long ago).

recently, i’ve stumbled over openvpn.sourceforge.net. first, this seems to be an interesting project (haven’t tested it yet), second they’ve done a good job in creating a useful website. some points:

* no silly claptrap (think of flash intros and such), just the information visitors expect
* concise, informative overview what openvpn is about
* information about users’ benefits of openvpn
* information why to choose openvpn instead of any other vpn implementation (differences)
* quicklinks to download the application. note that package signatures are also available.
* quick installation notes (who wants to read tons of manuals to install an app?)
* changelog/what’s new
* content-overview with direct deep linking
* language selection
* no frames, good for bookmarking (meaningful page titles)

so content-wise every important thing is accessible from within the main/entry page.

downside:

* the site is not valid xhtml/html
* the site doesn’t satisfy any web content accessibility conformance level. it’s not that bad though, i could easily view the site using lynx and links (both are text-based browsers)

talking about hacked debian (btw. isn’t it typical that the pgp signature was missing in the first post?):

according to ripclaw, the new debian-based linux distro adamantix (formerly known as trusted debian) supports package signing. nice to see that there’s finally a linux distro taking security seriously.

i tried to convince gentooers long enough to introduce package signing (the currently used portage architecture is highly insecure despite of sandboxing). i therefore made a (actually pretty simple – remember “kiss”) concept and a prototype, but i lacked interest to do the necessary clearing of the rampant portage code base (take a look at its “architecture” and source code and you know what i’m talking about ;) for a production quality implementation. several later attempts by gentoo devs to implement a production quality package signing feature for portage showed no success (probably for the same reason). now the core-devs are finally thinking aloud about a portage rewrite from scratch (this time hopefully using a more sophisticated architecture, wiser decisions and a better implementation), a thing gert suggested (and actually started doing) about 1.5 years ago already.

the trouble with package-signing is not only a technical one (implementing a secure architecture can be pretty difficult). depending on the chosen model there are also social consequences. for example my concept was to put users in control instead of devs which is the right thing to do considering that in the end, only users can decide whom they trust – through a decentrialized trust-model heavily leveraging the already existing openpgp web of trust (why re-invent the wheel?). note that my proposition didn’t make centralization impossible (you could still sign dev keys with a master dev key), but rather enabled decentralization.

one of my intents was to make secure (aka trustworthy), decentralized software development and deployment possible through a decentralized, user-centric package signing trust model. there are many reasons for this, among others (see also those mentioned above) the scalability (mostly qa) and security problems most distros suffer from.

btw recently i’ve been very pleased to read that markus aka maol seems to have a similar vision (at least regarding decentralized development and distribution) for crux :)

miguel de icaza has published his impressions of the pdc. insightful non-ms perspective.

the thing still irritating me is that since the release of the clr/cli specs the gnome/ximian ppl seem to be much more interested in clr/cli compatibility than in co-operation with kde. on one hand, the first is probably important for the long-term success of linux on the desktop, on the other hand the latter is crucial for the short-term survival of gnome/gtk as more and more distros bet on kde/qt. maybe it’s time for novell (backed by bigbrother and strategist ibm) to stimulate the kde/gnome/ximian/mono/qt/gtk co-operation as well, now as they own both ximian and suse.

hddtemp is a great little tool for all those who already experienced hard disk crashes/failures caused by overheating. to prevent future crashes, i’ve hacked a tiny bash-script, hddtempmonitor as a simple wrapper. with this script, i’m “deliberately” on the safe side – preventing a fatal disk failure has priority over maximizing server uptime (at least atm, when time is scarce). for now, it does the job it’s supposed to do, but it really should be improved (feel free to do so). some random points: season awareness, fuzzy logic, adaptation, state awareness, increasing temperature thresholds to prevent possible endless rebooting, moving average, mean, confidence interval, confidence level, combination with external temperature sensor, combination with an ids, selective process kill, command line options instead of hardcoded vars, sms gateway, logging. etc. etc.

the script is called from /etc/crontab:

# mettlerd: hddtempmonitor (hard disk temperature monitor)
*     * * * *   root    /usr/local/bin/hddtempmonitor >/dev/null 2>&1

vold volume daemon for linux:

But there already is an automounter in Linux! Why do we need this ‘vold’?
Something I did never like about the automounter is that its auto mounting is somehow special. Devices are not mounted automatically when they are available but when they are accessed. Another point that really annoyed me was that when I plugged in my Memory Stick in Windows or in Mac OS X, I needn’t do anything else – it just worked. I plugged it in on Linux and … nothing happened (as usual..). I could live with the mount process but its not only that. The device names may change if you have more that one hotpluggable device depending on which device you plug in first.

according to clemens, vold is in fact very similar to the volume daemon ‘vold’ found on Solaris or the ‘autodiskmount’ on Mac OS X. hmm.. polling/busy waiting?

i need to check it out as soon as i find some spare time (a rare thing lately and probably also for the next few months). i wonder whether there are any synergies with the new, planned devfs replacement.. possibly. perhaps an opportunity to get rid of hardcoded devices in the “scan file”.