LWN.net Logo

Advertisement

E-Commerce & credit card processing - the Open Source way!

Advertise here

LWN.net Weekly Edition for December 1, 2005

A day at FOSS.IN

FOSS.IN 2005 got underway on November 29. The conference got off to a bit of a rough start; funding problems and travel hassles led to the last-minute cancellation of a number of talks. On opening day, glitches in the registration process resulted in hundreds of attendees standing in line under the strong Bangalore sun while the (already delayed) sessions began without them. These little problems notwithstanding, FOSS.IN has the look of a successful conference.

Frequent attendees of technical conferences become used to spending their days in closed auditoriums and cavernous ballrooms. FOSS.IN, instead, consists of temporary buildings (essentially large, canvas tents with steel frames) set up in a dirt field. The Bangalore Palace makes an interesting backdrop for the event, but it hosts only a few of the sessions. Dogs wander between the lecture halls, though the cows have, so far, avoided the area in favor of the traffic-choked roads nearby. Inside, the conference buildings have all the usual facilities; they are a pleasantly airy space. Just watch out for the rough floor.

If there is an underlying theme to this event, it is participation. India's presence in the free software community, and its contributions to that community, are relatively small relative to its population and its use of free software. The conference's organizers and speakers would like to change that. In the opening remarks, organizer Atul Chitnis noted that, if even ten members of the audience were motivated to start hacking and giving back to the community, the event could be considered to be a success.

[Alan Cox] Alan Cox's opening talk on participation focused on nuts and bolts - how people can participate in the community. There are plenty of reasons for wanting to be a part of the process, according to Alan. Helping a free software project can be a way to learn skills, explore ideas and their implementations, have fun, create employment opportunities, and work for social good. Writing code is the first and foremost way of participating, and Alan dispensed a fair amount of advice on how that is best done. But he also took time to point out the many other ways to help, most of which do not require programming skills. These range from reporting bugs through writing documentation, translations and localization, creating artwork, and helping to maintain the infrastructure needed by free software projects. Localization was pointed out as an area in constant need of work. India has a long list of languages to translate into, and the Indians are the only ones who are well positioned to get that work done.

[Danese Cooper] Danese Cooper continued the participation theme with a talk on "gorilla tactics." A gorilla, in her terminology, is somebody who stands up for what is right and helps to push free software forward. Being a gorilla can hurt sometimes, but it is worth it.

Example: quite a few companies in India are doing free software work, but they are not contributing their changes back. Many of them, it seems, are afraid of the possibility that the community might fork their code. Indian companies fear that possibility so much that they are unable to relinquish control, and, as a result, keep their code to themselves. These companies need gorillas, somebody who will make the case for letting go and giving the code back to the community.

Another problem in need of attention is universities which make claims on the work done by their students. These universities need to let go and let their students take their ideas forward. The reputational benefit to the universities will far exceed the benefits of any revenue which might come from commercialization.

Danese is also concerned about the number of Indian startups which target the American market. Yes, that market is large, but it is also distant and highly competitive. Indians would be better advised to work on problems in India.

The talk also discussed reasons for participating. By participating in the free software community, countries like India can reap benefits beyond simply avoiding license payments to distant companies. Working on free software helps to improve the population's technical skills. The development of local expertise will lead to local wealth creation, and the establishment of a reputation for strong software development.

Zaheda Bhorat talked about how Google participates in the free software process. The talk covered Google's reasons (most of which will be well familiar to LWN readers), some of Google's released code (found on code.google.com, and various other things Google is doing to help. There was also a lengthy discussion of the "Summer of Code" program and the benefits that have come from it. There were a few Indian participants in the Summer of Code, but far fewer than from the US and Europe. Zaheda would like to see that change for any future programs.

A final inducement to participation could be seen in the small exposition area. Many of the participating companies had the obligatory product and service brochures, but quite a few of them are also using their booths to recruit developers. It would seem that, for Indian hackers with free software skills, now is a good time to be looking for a job.

Comments (4 posted)

When Is a Standard Truly Open? - When It's Universal, Reflections on Massachusetts and Microsoft's XML

November 30, 2005

By Pamela Jones, Editor of Groklaw

There are standards and there are standards. They are not all born equal.

What makes one standard open and not another? Massachusetts, when deciding to use the OpenDocument Format, as set forth in its Enterprise Information Technology Architecture (ETRM) document [PDF], set the bar here:

[Secretary of Administration & Finance for the Commonwealth of Massachusetts Eric] Kriss emphasized, however, that the state is not moving to open standards for economic reasons but to protect the right of the public to open and free access to public documents for the foreseeable future. "What we've backed away from at this point is the use of a proprietary standard and we want standards that are published and free of legal encumbrances, and we don’t want two standards," Kriss said.

A recent statement by the Governor's office in Massachusetts, expressing optimistic hopes that Microsoft's Office Open XML document formats will meet their standard for an "open format" someday raises two questions: Is the Microsoft covenant not to sue, assuming it is someday offered for their new version of XML schemas, and their plans to submit their XML to standards bodies ECMA and ISO sufficient to meet the Massachusetts requirements for openness? If so, what are the implications for the Internet? If not, will Massachusetts decide their bar was set too high, in order to include Microsoft? If the bar was set too high, which part shall we lop off?

Shall we say the public has no right to open and free access to documents their tax money paid for?

No. Massachusetts has a Public Records Law [PDF] that mandates [PDF] that "all people have an absolute right of access to public information". The law doesn't distinguish between paper documents and digital documents. The disabled have a right of access, but so do the rest of us.

Are proprietary standards acceptable if nonproprietary, universally available standards are available?

Can a government dictate which operating system you have to use to access those documents? More pointedly, can it favor one proprietary vendor and compel citizens to spend money on a proprietary system, when they already have a perfectly functional operating system on their computers already?

We already saw in the Katrina disaster what happens when a government agency enables Windows-only access. I wrote about that in "When Open Standards Really Matter: the Katrina Factor", which begins like this, trying to explain why standards matter:

If you have any doubts about the direction Massachusetts is following in requiring open standards for all government documents, consider what happened when Hurricane Katrina knocked out almost all communications except the Internet. Cell phones and walkie talkies failed, once again, just as they did in 9/11, as David Kirkpatrick tells us in an article in Fortune:

In the immediate aftermath of the hurricane, much of the region’s communication systems failed or didn’t work properly. Water and wind knocked out power, toppled phone lines, and destroyed cellphone towers. What systems remained were quickly overwhelmed. When rescue workers’ did have working equipment, like walkie-talkies, they often couldn’t connect with others on different communication systems.

Catch that? "On different communication systems." The same thing happened after the tsunami disaster in Thailand, as a report just released by the ePolicy Group reports:

"Responding agencies and nongovernmental groups are unable to share information vital to the rescue effort," the report recalls of the government in Thailand in the tsunami's immediate aftermath. "Each uses different data and document formats. Relief is slowed; coordination is complicated. The need for common, open standards for disaster management was never more stark or compelling."

Isn't it time, after so much suffering, to recognize that keeping people alive is more important than allowing private companies to lock in customers into proprietary systems that don't then work in an emergency? And why does the Internet always work, no matter who you are or what operating system you use? Because it was built, not on proprietary standards, but entirely on open standards. That's why you can send an email to me, even if you are using Microsoft Outlook. I don't run any Microsoft products currently, but because of open standards, I can still read your email, and in an emergency, we will not be disconnected because we are on "different communication systems."

Accepting Microsoft's proprietary XML *with its proprietary extensions* as the language of the Internet would certainly alter the openness and universality of the Internet. Proprietary, by definition, means it isn't universal. Is that what we want? If Massachusetts accepts proprietary extensions, it will inevitably be excluding some of its citizens, I think.

Can any government, including Massachusetts, in the Internet age, justify telling its citizens, by the decisions it makes, that they must stop using their operating system of choice -- one used by millions all over the world -- and instead purchase a proprietary vendor's product instead if they wish to interact with their government? In any case, in an emergency, it may not be possible to quickly buy a Windows operating system. People use what they have. Sometimes it's all they have access to; sometimes it's all they can afford. On what basis would you argue a government should do that? More pointedly, on what *legal* basis would you argue they can?

Should Massachusetts wait for a future, yet-to-be-developed proprietary standard, not yet published, on terms that are not yet fully known, controlled by a single vendor, when you have one that is vendor-neutral and is already available? On what basis could the Commonwealth justify such favoritism to a single company? In the FAQ on the Commonwealth's ETRM, they state this:

The Final ETRM Version 3.5 does not require that agencies use only one office product. To the contrary, it offers agencies many choices. Agencies may choose to retain their existing MS Office licenses, as long as they use a method to save documents in Open Document Format. They may also use one of the many office tools that support Open Document Format in native format--- OpenOffice, StarOffice, KOffice, Abiword, eZ publish, IBM Workplace, Knomos case management, Scribus DTP, TextMaker and Visioo Writer. Because the Open Document Format is an open standard, it increases the vendor pool available to state agencies by encouraging and permitting vendors not already in this field to develop products that support the standard. Adoption of the Final ETRM Version 3.5 will greatly increase competition among vendors for the sale of office applications to agencies.

What about legal encumbrances?

There are still questions about legal encumbrances on the MS XML and related licenses and EULAs. Is that going to be the part Massachusetts should wink at? They'd likely be sued if they tried, I think, and I doubt they will try, because it would be impossible to justify it in public, for one thing. That's the kind of thing that only works in back rooms, and nothing about this process will be hidden from the public's gaze.

On the issue of license clarity, obviously, if you can't understand the license, you won't dare to use the standard. I don't understand all the legalities of Microsoft's covenant not to sue and I don't know anyone who does. The danger is in establishing a standard that would, in effect, block Linux and GNU/Linux developers from participation. Do you imagine that could never happen? Consider your history.

Remember the SenderID flap? Who was to be left out in the EU Commissioner-MS deal? Do you really want to set up a world where Linux could never happen again, a world where the Linux we have is exiled to the backwaters of technology? Just being an ECMA standard doesn't mean it is open enough for *government* use. ECMA standards, by their own self-description, are for industry use:

Ecma is driven by industry to meet the needs of industry, generating a healthy competitive landscape based on differentiation of products and services, rather than technology models, generating confidence among vendors and users of new technology.

The needs of government are not identical to the needs of industry. It's up to industry to meet the needs of government, not the other way around. The government is the customer, after all, so they get to state what they need in a product and to choose whatever meets their needs best.

Finally, shall we have two standards?

That seems to be what they are leaning toward. The Commonwealth has already stated that the disabled can continue to use Microsoft's products, if there are no better options they like, so that might be one area of carve-out. From what I've heard, however, that will be a solved problem for ODF by the time of the 2007 rollout. So again, the issue is going to be: should a government favor a proprietary solution, when there is a universally available solution that isn't proprietary and excludes no one? Tim Bray has made a sensible suggestion:
The ideal outcome would be a common shared office-XML dialect for the basics—and it should be ODF (or a subset), since that’s been designed and debugged—then another extended vocabulary to support Microsoft features , whether they’re cool new whizzy features or mouldy old legacy features (XML Namespaces are designed to support exactly this kind of thing). That way, if you stayed with the basic stuff you’d never need to worry about software lock-in; the difference between portable and proprietary would be crystal-clear. And, for the basic stuff that everybody uses, there’d be only one set of tags.

This outcome is technically feasible. Who could possibly be against it?

Let's think about what we should look for in a standard, what elements justify even calling it a standard. I'd like to redefine the issue, if I may. I think the sine qua non for a standard isn't whether it's open or proprietary. If, for example, Microsoft can open up its XML to match ODF's, that's fine with me. The real issue isn't openness alone. It's universality. Let me explain.

In trying to understand fully the standards issue in Massachusetts, I came across a helpful list on Bob Sutor's blog dating back to September. I hadn't read it, and perhaps you didn't either, so I'd like to provide here the danger signs that a standard isn't as open as it needs to be. I think it's pertinent, because Microsoft folks are telling the world that by applying to ECMA, the conversation about whether their XML is open enough should be over. It's only just beginning, actually, as they will discover.

Consequently, let's list the elements Sutor provides that indicate there is a problem with a standard and you can judge for yourself:

In practice, I think it is probably easiest to tell when a standards effort is less open than you think it should be. Here are some danger signs:
  • control by a single vendor,
  • overly complicated license agreements,
  • license agreements that reserve certain special rights to individuals or vendors,
  • license agreements that prevent some kinds of implementations,
  • overly complicated procedural rules that can allow people to be less democratic than they should,
  • a history of disregard for backward compatibility,
  • costs of participation that exclude individuals or small organizations,
  • high costs of obtaining copies of the standards,
  • standard specifications not being openly available online, and
  • for XML-based standards, allowance for proprietary, vendor-specific extensions.

I see at least 6 items that would apply to Microsoft's XML. I'm sure I don't have to underline for you that the last is the deal-breaker, proprietary extensions. It's not a standard unless it's universally available and usable by everyone. The whole point of a standard is interoperability. Can everyone use it and have it work? Proprietary extensions, by definition, hamper interoperability.

The real question to me isn't just whether a standard is open. That's a continuum anyway, with various degrees of openness. The real question that matters is: is it universal? Can everyone freely use it? If not, should it be a standard?

XML Standards Impact the Internet, Not Just Massachusetts

When we're talking about XML, we're talking the Internet, not just about Massachusetts, because XML is the language of the future Internet. HTML was fine as the universal language for the Internet for its babyhood, but the future is XML, and so any discussion about standards for XML involve the Internet too. It's the next step, because it enables collaborative computing and universal data exchange.

No doubt Microsoft wants its proprietary version of XML to be adopted as a standard. But seriously, do you want the Internet's common language to belong, in essence, to one US company? And what a company! Ask yourself one question, and let your natural, first instinctive response answer: Do you trust Microsoft?

If you do, kindly tell me why, in light of their history. This is a company twice found guilty of antitrust violations, on two continents. What should that tell you? They had a version of the Internet too, remember? Happily no one was foolish enough to accept it. The theme of the Internet is universality, not proprietary walled gardens. Do you remember how Microsoft added proprietary extensions to HTML and degraded performance for competing browsers?

In the ETRM document, referenced above, the Commonwealth pointed out something very important:

Initiatives such as Homeland Security rely upon all parties adhering to Community of Interest XML specifications, defined by open standards bodies comprised of representatives from Government, Business and Technology Communities. Open formats for data files ensure that government records remain independent of underlying systems and applications thereby preserving their accessibility over very long periods of time.

Do you really think the Internet language should be determined by just one US proprietary company motivated by their own profit? The rest of the world will not go along with that, even if Massachusetts were to think so. And then how will they interchange data with countries and governments abroad? Massachusetts will be odd man out. Accepting Microsoft's version of XML with its proprietary extensions as the standard will thus result in serious issues ahead.

The Internet only works well if *everyone* uses the same language, and frankly, the whole world isn't going to accept Microsoft's proprietary XML as that common language. Can you imagine Europe agreeing to that? Or China? Or South America? FOSS developers? The next question is: Do we want two standards? Two Internets, in effect? That destroys the very purpose of the Internet, which is universality. Can there be justification for degrading the performance of something as important to us as utilities are for the sole benefit of a single proprietary vendor? I understand why Microsoft wants that, but why should you?

And there is a choice. ODF is here right now. There is no pie in the sky about it. It's not a year away. It's a universal standard, not vendor-controlled, which everyone can use, including Microsoft, without having to open up in any way themselves.

We're not just talking about Microsoft and Massachusetts, then. We're talking about the Internet, which doesn't belong to any company or any country. It's for everyone, and everyone uses it. Because it's universally available and usable, shouldn't the language of the Internet be universal too?

Comments (12 posted)

The Grumpy Editor's guide to music managers

Your editor's computerized music collection started small - a few CDs converted to Oggs and placed on the laptop to eliminate the need to carry a CD player when traveling. Then the live music trading community, of which your editor is occasionally a part, moved away from complex and unreliable tape formats to optical media, and, increasingly, online exchange. The digital music player showed up, replacing the old CD player as another gadget which must be hauled (along with charger) in your editor's increasingly heavy backpack; it brought with it a larger collection of highly compressed music files. Over time, the pile of digital music has become an unorganized mess of files in several formats, overflowing from its own, dedicated disk drive. There must be, one would think, a better way.

In search of better ways, and looking for an excuse to listen to more music while pretending to work, your editor delved into the world of free music managers. The manager part of that is key: the world is full of music players, but they are generally not helpful in organizing that big pile of music files. Your editor would like a tool which brings some order to the mess, makes finding and playing music easy, and helps with the management of one or more digital audio players. The search turned up three tools, all of which have some nice features, but none of which are, yet, a full solution.

Before getting into the specific tools, however, please indulge your editor with a topic which brings out his grumpiest side. Most of the tools discussed below offer iPod support. They can move files back and forth, interface with the on-device database, and generally perform the functions that an iPod owner might like to do.

Your editor does not own an iPod.

None of the applications reviewed has any useful concept of working with other digital audio players. Supporting only the iPod is as foreign to the free software way of doing things as supporting, say, only the i386 architecture or the Word document format. The iPod, as nice as it is, remains a highly proprietary device in a sea of alternatives. One can understand if iPods are supported first, since so many of them are out there; your editor very much hopes, however, that the developers have thought a little beyond the iPod and designed a digital audio player interface layer which is capable of a little more flexibility.

Beyond that, few of the managers reviewed appear to have much idea that a digital audio player is a separate domain, with, perhaps, its own rules. These players, for example, generally require lossy, compressed audio formats. But, when using a larger system, the idea that lossy audio is fit to be pumped through one's $1500 (each) speaker cables is insulting at its core. If much of one's audio collection is in lossless formats (FLAC, say), it would be nice to be able to move files to a portable player and have them automatically transcoded into a format that works on that player. In the absence of such a feature, it becomes necessary to keep music around in multiple formats - and most music managers do not deal well with that.

Rhythmbox

Rhythmbox is a longstanding GNOME music manager. It contains many of the expected features, but it has also been subject to a certain amount of muttering in the GNOME ranks. The biggest [Screenshot] complaint appears to be that the pace of development is slower than some would like. There have been comments to the effect that this project was slowed down recently by external events, but that development can be expected to pick up again soon.

The initial Rhythmbox display is sparse, essentially a large, blank window. Gaining access to music requires "importing" it into the "library." An entire directory tree can be imported at once, but Rhythmbox feels the need to complain about every non-music file it finds in the process. After the import process, the user is presented with a list of every known track in one very long, scrolling window. There is not a great deal of organization evident at this point.

A small button marked "show browser" opens a pair of panes allowing the selection of a subset of tracks based on the artist and/or album. There is also a "search" blank which restricts the list to tracks which contain (in the artist, album, or title field) a given string. Searching can be used, say, to find that recording of "Louie, Louie" that you know you have somewhere, or, for fans of a certain persuasion, to get a full list of all performances of "Dark Star" in the collection. The results form a sort of instant playlist, so one can perform a quick search, hit "play," and get hours of uninterrupted, out-of-tune Jerry Garcia goodness. Not that your editor would be into such a thing, of course.

Speaking of playlists: they are created from a menu entry, and appear in the left side pane. Creating playlists is a simple matter of dragging and dropping songs into it. It is not possible, however, to see the contents of a playlist and the library at the same time, so the creation process is somewhat blind.

One obnoxious feature of Rhythmbox is how it treats albums: it sorts the tracks by title if the track files do not, themselves, contain ordering information. Since much on-disk music is created with file names which describe the order of the tracks, it would be nice of Rhythmbox would use that information.

The music player itself is functional, if rudimentary. It has repeat and shuffle modes, as one would expect. There is a scrollbar which can be used to move within a track, but it is strangely located far from the other player controls. Rhythmbox, like most of the other applications reviewed here, puts an icon in the panel tray, allowing it to be controlled without having a window on-screen.

Rhythmbox also understands (and can "tune into") Internet radio stations. Of course, the out-of-the-box install fails to cope with the formats used by most stations, but some quick searching and installing takes care of that problem. Additional features (help in finding stations, recording from a stream) would be nice, but what's there is a start.

Rhythmbox has the ability to import tracks from CD - though it outsources the work to SoundJuicer. It is unable to burn tracks to CD. Rhythmbox also lacks any sort of digital audio player support; not even the iPod is supported.

Banshee

When GNOME users talk about replacing Rhythmbox, the most [Screenshot] commonly-suggested alternative is Banshee. Banshee is a Mono application which is coming along quickly, but which still lacks some important features.

The initial Banshee experience is similar to what one sees with Rhythmbox. After an import process, a long list of tracks appears. Unlike Rhythmbox, however, Banshee has no features for narrowing the list of tracks by artist or album. The search facility can often be pressed into service to obtain similar results, but it is more awkward. Playlists are handled in pretty much the same way as in Rhythmbox. Banshee lacks Internet radio capability.

Banshee does have a couple of nice features. One of those is the ability to edit the metadata in music files. A CD ripped using information from one of the online databases often ends up with some very strange metadata: it's always fun to find that whoever entered the information decided that Led Zeppelin belongs in the "ambient" genre, or that they decided to change the spelling of disk set name between the first and second CDs. Once you find the metadata editor (nicely hidden as "properties" on the "view" menu), you can fix problems like that.

By most accounts, Banshee has the best iPod support among the available free music managers. Among other things, it understands that it may have to transcode music as it moves it between the computer and the player. Banshee has a few different ways of controlling the movement of music to and from the iPod; it can be done entirely manually, or the library can be automatically synchronized with the player.

Banshee has a CD importer built into it, and it can import to a number of different formats. The ability to burn CDs is also there. At least, the web page says so; the version of Banshee from the Ubuntu repository does not appear to be able to perform either task.

Quod Libet

Quod Libet is a GTK+ [Screenshot] music manager written in Python. Its authors appear to place power and extendability above eye candy.

Quod Libet resembles other managers at startup time, and users go through the same sort of import process. Tracks are displayed in one big window. It is possible to get a browser which narrows based on artist and album, but the user must explicitly ask for it, and the browser is separate from the music player controls. In fact, there are two different browsers with very similar functionality.

When a playlist is created, a separate window is popped up; the usual drag-and-drop mechanism will populate the list. Access to playlists is via a pulldown menu slipped in between the player controls and the track list. It's a somewhat awkward interface, especially as the number of playlists gets large.

The distinguishing feature found in Quod Libet, perhaps, is its plugin mechanism. A simple Python interface makes it easy to add new features to the system; some of the available plugins include a song blacklist, various features for obtaining and displaying album cover art, a CD burning feature, an AudioScrobbler client, and a simple plugin for copying files to a portable player.

Amarok

Amarok appears, as of this writing, to be where much of the music management action is happening. The Amarok hackers have, in a short [Screenshot] time, put out a number of releases of this increasingly attractive and capable tool.

Amarok makes an immediate impression when it is started; the developers have clearly put quite a bit of effort into its appearance. The interface makes more use of color than the other music managers. It also never sits still; like a jukebox in a bar, Amarok is always flashing lights and generally trying to attract attention to itself. Some of the gaudier features (like the "on-screen display" which comes up every time Amarok starts playing a new track) can be turned off, but others (the flashing track name in the playlist display) are seemingly permanent. The work which has gone into creating a visually appealing tool is appreciated, but not everybody likes flashing distractions on their screen.

Needless to say, Amarok does album covers. They can be obtained from the net, browsed, and saved by the user, and come up with the relevant tracks are played. It also has features for digging up song lyrics and looking up artists in Wikipedia.

Tracks are imported into the "collection" in the usual way, but things change after that. The music collection is displayed in the left pane in file manager-like presentation. Nothing one might try in that pane, however, will cause a track to be played. In Amarok, everything is a playlist, and tracks must be added to a list before one can hear them. Double-clicking on an album will cause all of its tracks to be moved to the current playlist; from there, they can be heard. Individual tracks can also be dragged over. The playlist is cumulative, so a bit of wandering around in the collection can create a truly eclectic selection of tracks in the list. Playlists can be saved, at which point they appear in the hierarchical playlist display. The playlist display includes a section for Internet radio stations.

The music player itself has seen a fair amount of development attention. There is a small, xmms-like player window, a fancy frequency-amplitude display, and a built-in graphic equalizer. There is also a "queue manager" which can be used to program a sequence of tracks to be played; your editor is not entirely clear on how this feature differs from the regular playlist mechanism, however. There is a "dynamic playlist" feature which is poorly documented; it appears to try to find tracks (with help from AudioScrobbler) which are, in some way, similar to those which are already in the playlist.

There is reasonable player support built into Amarok, but, of course, it only supports iPods. Unlike the other players, Amarok allows the user to configure a mount command to make the player available.

Amarok is scriptable, and has a script manager built into it. Some of the available scripts can make the player stream out whatever is being played, perform transcoding of audio files, and more. There is also a "transfer to media device" script which can make Amarok move audio files to a USB-storage device. It knows nothing about the filesystem hierarchy on the destination device, however, not to speak of issues like encodings, so this script is not particularly useful.

There are many other features to this tool: fancy "visualizations," CD burning, track metadata editing, cross-fading between tracks, downloadable themes for the "context" window, automatic track rating (who knows how it works), basic podcast support, and more. Hopefully the idea is clear by now.

Conclusion

Readers who are mainly interested in iPod support may also want to have a look at gtkpod. Those of us with other devices will have to be content with advanced tools like rsync.

Clearly a lot is happening in this particular "type manager" niche. That is a good thing: computers are increasingly at the center of the audio experience, and we are going to need good tools to keep our music collections from looking like those piles of CDs, DATs, cassettes, records, eight-tracks, and other media that many of us have been surrounded by for much of our lives. The tools which are available now are far beyond what was out there even one year ago; once again, the free software community is showing how well it can create great applications when it gets fired up.

There is still some thinking which needs to be done in this area, however. The Rhythmbox and Amarok developers have realized that net-based audio is of increasing importance; their support for Internet radio streams is the result. Amarok's podcast support is also nice, if a little hard to get started with. Feed it an RSS file, however, and your playlist will always have a current listing of what's available from that podcast source. Now if we could just convince more podcasters to offer something other than the MP3 format, things would be even nicer.

Most of us want to take our music with us, and, thanks to the availability of high-capacity digital players, we can. The music management application developers are still figuring out how to cope with a music "library" which comes and goes, and which may or may not be a mirror (perhaps in a different encoding) of a local library. And they all seem to have difficulty with the idea that some of us folks - the more unfashionable ones, certainly - might use something other than an iPod. Your editor is looking forward to improvements in this area. An especially nice thing would be a cooperation with the Rockbox project to ensure that Rockbox-equipped players are seamlessly integrated. Given that, soon, iPods will also be able to run Rockbox, it seems that there should be a large enough user community to motivate some effort in that direction.

Your editor, if pressed to make a recommendation now, would have to go with Amarok. It has a feature set and visual appeal which is unmatched elsewhere. For those looking for a basic manager for music which lives only on the computer, Rhythmbox is also a stable and functional alternative. Banshee shows signs of developing into a highly capable application, but it is not there yet. Given some time, however, along with a broader willingness to install the whole Mono system, and Banshee may yet push its way toward the top of the list.

Now, if you don't mind, your editor has some tunes to listen to.

Comments (80 posted)

GPLv3 draft coming in January

The Free Software Foundation has sent out a press release describing the process for the upcoming discussions on the new version of the General Public License. "After publishing the first discussion draft of the GPL in January, the FSF will begin a structured process of eliciting feedback from the community, with the goal of producing a final license that best defends freedom and serves community and business. The process will include public discussion, identification of issues, considerations of those issues, and publication of responses. Publication of the second discussion draft is expected by summer 2006 and a last call, or final discussion draft, will be produced in the fall of 2006. The final GPLv3 license is expected no later than spring 2007."

Comments (2 posted)

Page editor: Rebecca Sobol

Security

Security news

An introduction to GNUnet

November 30, 2005

This article was contributed by Jake Edge.

Anonymity and deniability in distributing information are two of the goals of the GNUnet project. Recently revamped to use a new content encoding called Encoding for Censorship-Resistant Sharing (ECRS), GNUnet has released version 0.7.0 with an eye towards a stable version sometime during the next year.

At its heart, GNUnet is a mechanism to share content with others without revealing who generated the content or who accessed it. It also provides intermediate nodes in the network with the ability to deny knowledge of the contents of any traffic they forward because they are unable to decrypt it.

Anonymity relies on there being a large number of nodes participating in the network, forwarding traffic for each other. The GNUnet protocol attempts to make all traffic look the same, whether it is satisfying a request for information that resides locally or forwarding a request or response from another peer in the network. When traffic is light, GNUnet will delay requests to accumulate enough traffic before sending to other peers making it difficult for external analysis to pin down which peers are communicating and what content is being transferred.

Only the requester of content has the key necessary to decrypt the content which provides deniability for intermediate peers. In the default configuration, GNUnet peers automatically migrate content from the node where they were inserted to other peers. In the event that some hostile entity gets control of the node, breaks the encryption and determines the content stored by the node, node operators can plausibly claim that they had no knowledge of or control over the content stored on their node.

Once content has been inserted into GNUnet, users can search by keywords to find content of interest. ECRS guarantees that intermediaries cannot see the keyword being searched without guessing the keyword, applying the query hash and comparing the result. Only peers that have content with that keyword (or have guessed it) can generate valid responses. GNUnet depends on content providers generating proper keywords for their content and nothing in the protocols stops malicious peers from generating valid query results for a multitude of keywords. Easy to guess keywords could easily be overwhelmed by bogus results.

Namespaces provide resistance to the keyword spamming attack by generating keyword spaces that are cryptographically signed by some entity. That entity generates a public-private key pair (known as a pseudonym) and signs the content. Other users can form opinions about the trustworthiness of content in that namespace and can use that information to further restrict their search.

GNUnet tries to eliminate freeloading peers by relying on a trust-based economic model. If a node gets busy and has more requests than it can satisfy based on the amount of CPU and bandwidth its operator has allocated to GNUnet, it will drop requests from peers that it trusts least. Peers gain trust by satisfying query requests and lose trust by requesting content. Because ECRS can determine that a query response is valid without being able to decrypt the content, it resists attempts to gain trust by providing bogus results.

Much like other systems designed to promote anonymous speech, some of which were described in an LWN article two years ago, GNUnet suffers from a very slow user experience. Keyword searches can take many minutes to return results and downloading the content often takes a huge amount of time. In addition, the content available with some simple searches left a great deal to be desired. There appears to be very little of consequence available.

On the other hand, GNUnet does seem to have some excellent approaches to handling censorship and spamming kinds of attacks that have hampered other approaches to this problem. It seems to provide a very reasonable framework for anonymous content sharing that would be of use to groups that wish to circumvent the policies of authoritarian regimes. Unfortunately, deniability is only likely to work in places that have relatively sane legal systems and there are probably many places in the world where just having GNUnet running on one's machine is enough to be branded as a criminal.

Comments (7 posted)

New vulnerabilities

centericq: denial of service

Package(s):centericq CVE #(s):CVE-2005-3694
Created:November 30, 2005 Updated:November 30, 2005
Description: Wernfried Haas discovered that centericq, a text-mode multi-protocol instant messenger client, can crash when it receives certain zero length packets and is directly connected to the Internet.
Alerts:
Debian DSA-912-1 2005-11-30

Comments (none posted)

eix: insecure temp file

Package(s):eix CVE #(s):
Created:November 23, 2005 Updated:November 30, 2005
Description: eix can create an insecure temporary file. A local user can use this to overwrite arbitrary files.
Alerts:
Gentoo 200511-19 2005-11-22

Comments (none posted)

horde: cross site scripting vulnerability

Package(s):horde CVE #(s):CVE-2005-3570
Created:November 23, 2005 Updated:December 1, 2005
Description: Horde has a potential cross site scripting vulnerability. Error messages are not properly escaped. A user can be tricked into executing arbitrary scripts by reading specially crafted email messages, or using a maliciously created URL.
Alerts:
Debian DSA-914-1 2005-12-01
Gentoo 200511-20 2005-11-22

Comments (none posted)

horde3: missing input sanitizing

Package(s):horde3 CVE #(s):CVE-2005-3759
Created:November 23, 2005 Updated:November 30, 2005
Description: The MIME viewer in the horde3 web application suite has an input sanitizing vulnerability. It is possible for a remote attacker to use this to execute arbitrary code.
Alerts:
Debian DSA-909-1 2005-11-23

Comments (none posted)

ipmenu: insecure temp file

Package(s):ipmenu CVE #(s):CVE-2004-2569
Created:November 23, 2005 Updated:November 30, 2005
Description: The cursel iptables/iproute2 GUI ipmenu has a vulnerability involving the creation of an insecure temporary file. A local attacker can overwrite arbitrary files by performing a symlink attack.
Alerts:
Debian DSA-907-1 2005-11-23

Comments (none posted)

zope 2.7: design error

Package(s):zope CVE #(s):CVE-2005-3323
Created:November 25, 2005 Updated:December 13, 2005
Description: A vulnerability has been discovered in zope 2.7 that allows remote attackers to insert arbitrary files via include directives in reStructuredText functionality.
Alerts:
Ubuntu USN-229-1 2005-12-13
Debian DSA-910-1 2005-11-24

Comments (1 posted)

Updated vulnerabilities

a2ps: input validation error

Package(s):a2ps CVE #(s):CAN-2004-1170 CAN-2004-1377
Created:November 26, 2004 Updated:December 19, 2005
Description: The GNU a2ps utility fails to properly sanitize filenames, which can be abused by a malicious user to execute arbitrary commands with the privileges of the user running the vulnerable application. More information at Security Focus.
Alerts:
Fedora-Legacy FLSA:152870 2005-12-17
Mandriva MDKSA-2005:097 2005-06-07
OpenPKG OpenPKG-SA-2005.003 2005-01-17
Gentoo 200501-02 2005-01-04
Debian DSA-612-1 2004-12-20
Mandrake MDKSA-2004:140 2004-11-25

Comments (none posted)

bzip2: race condition and infinite loop

Package(s):bzip2 CVE #(s):CAN-2005-0953 CAN-2005-1260
Created:May 17, 2005 Updated:January 10, 2007
Description: A race condition in bzip2 1.0.2 and earlier allows local users to modify permissions of arbitrary files via a hard link attack on a file while it is being decompressed, whose permissions are changed by bzip2 after the decompression is complete. Also specially crafted bzip2 archives may cause an infinite loop in the decompressor.
Alerts:
rPath rPSA-2007-0004-1 2007-01-09
Debian DSA-741-1 2005-07-07
Red Hat RHSA-2005:474-01 2005-06-16
OpenPKG OpenPKG-SA-2005.008 2005-06-10
SuSE SUSE-SR:2005:015 2005-06-07
Debian DSA-730-1 2005-05-27
Mandriva MDKSA-2005:091 2005-05-18
Ubuntu USN-127-1 2005-05-17

Comments (2 posted)

chmlib: several vulnerabilities

Package(s):chmlib CVE #(s):CVE-2005-2659 CVE-2005-2930 CVE-2005-3318
Created:November 7, 2005 Updated:November 28, 2005
Description: Several vulnerabilities have been discovered in chmlib, a library for dealing with CHM format files.
Alerts:
Gentoo 200511-23 2005-11-28
Debian DSA-886-1 2005-11-07

Comments (none posted)

cpio: directory traversal

Package(s):cpio CVE #(s):CAN-2005-1111
Created:June 20, 2005 Updated:December 26, 2005
Description: There is a vulnerability in cpio (2.6 and previous) that allows a malicious cpio file to extract to an arbitrary directory of the attackers choice. cpio will extract to the path specified in the cpio file, this path can be absolute.
Alerts:
Mandriva MDKSA-2005:237 2005-12-23
Red Hat RHSA-2005:806-01 2005-11-10
Debian DSA-846-1 2005-10-07
Ubuntu USN-189-1 2005-09-29
Red Hat RHSA-2005:378-01 2005-07-21
Mandriva MDKSA-2005:116-1 2005-07-19
Mandriva MDKSA-2005:116 2005-07-11
Trustix TSLSA-2005-0030 2005-06-24
Gentoo 200506-16 2005-06-20

Comments (1 posted)

cyrus-imapd: buffer overflows

Package(s):cyrus-imapd CVE #(s):CAN-2005-0546
Created:February 23, 2005 Updated:April 9, 2006
Description: Cyrus-imapd, prior to version 2.2.12, contains several buffer overflows which could be exploited by an (authenticated) attacker to run code on the server system.
Alerts:
Fedora-Legacy FLSA:156290 2006-04-04
Red Hat RHSA-2005:408-01 2005-05-17
Fedora FEDORA-2005-339 2005-04-27
OpenPKG OpenPKG-SA-2005.005 2005-04-05
Conectiva CLA-2005:937 2005-03-17
Mandrake MDKSA-2005:051 2005-03-04
Ubuntu USN-87-1 2005-02-28
SuSE SUSE-SA:2005:009 2005-02-24
Gentoo 200502-29 2005-02-23

Comments (none posted)

dia: missing input sanitizing

Package(s):dia CVE #(s):CAN-2005-2966
Created:October 4, 2005 Updated:April 6, 2006
Description: Joxean Koret discovered that the SVG import plugin did not properly sanitize data read from an SVG file. By tricking an user into opening a specially crafted SVG file, an attacker could exploit this to execute arbitrary code with the privileges of the user.
Alerts:
Debian DSA-1025-1 2006-04-06
Mandriva MDKSA-2005:187 2005-10-20
Gentoo 200510-06 2005-10-06
Debian DSA-847-1 2005-10-08
SuSE SUSE-SR:2005:022 2005-10-07
Ubuntu USN-193-1 2005-10-04

Comments (none posted)

egroupware: multiple vulnerabilities

Package(s):egroupware CVE #(s):CVE-2005-0870 CVE-2005-2600 CVE-2005-3347 CVE-2005-3348
Created:November 17, 2005 Updated:December 9, 2005
Description: A number of vulnerabilities have been found in egroupware, a web-based groupware suite. Phpsysinfo has several cross-site scripting vulnerabilities, The the tree view of FUD Forum Bulletin Board Software has a cross-site scripting problem, phpsyinfo has a local variable overwrite problem, and phpsyinfo has an input sanitizing issue.
Alerts:
Debian DSA-918-1 2005-12-09
Debian DSA-899-1 2005-11-17

Comments (none posted)

emacs21: format string vulnerability in "movemail"

Package(s):emacs21 CVE #(s):CAN-2005-0100
Created:February 7, 2005 Updated:May 15, 2006
Description: Max Vozeler discovered a format string vulnerability in the "movemail" utility of Emacs. By sending specially crafted packets, a malicious POP3 server could cause a buffer overflow, which could be exploited to execute arbitrary code with the privileges of the user and the "mail" group.
Alerts:
Fedora-Legacy FLSA:152898 2006-05-12
Debian DSA-685-1 2005-02-17
Mandrake MDKSA-2005:038 2005-02-15
Gentoo 200502-20 2005-02-15
Fedora FEDORA-2005-146 2005-02-14
Fedora FEDORA-2005-145 2005-02-14
Red Hat RHSA-2005:133-01 2005-02-15
Red Hat RHSA-2005:110-01 2005-02-15
Red Hat RHSA-2005:134-01 2005-02-10
Red Hat RHSA-2005:112-01 2005-02-10
Fedora FEDORA-2005-116 2005-02-08
Fedora FEDORA-2005-115 2005-02-08
Debian DSA-671-1 2005-02-08
Debian DSA-670-1 2005-02-08
Ubuntu USN-76-1 2005-02-07

Comments (none posted)

enigmail: information disclosure

Package(s):enigmail CVE #(s):CVE-2005-3256
Created:October 20, 2005 Updated:December 13, 2005
Description: The key selection dialog from the Mozilla Thunderbird enigmail plugin has an information disclosure vulnerability. A key with an empty user id from a user's keyring will be used by default, allowing a message to be decrypted. This can lead to an unauthorized information disclosure.
Alerts:
Mandriva MDKSA-2005:226 2005-12-12
Debian DSA-889-1 2005-11-08
Ubuntu USN-211-1 2005-10-20

Comments (none posted)

enscript: arbitrary code execution

Package(s):enscript CVE #(s):CAN-2004-1184 CAN-2004-1185 CAN-2004-1186
Created:January 21, 2005 Updated:May 27, 2006
Description: Erik Sjölund has discovered several security relevant problems in enscript, a program to convert ASCII text into Postscript and other formats. Unsanitized input can cause the execution of arbitrary commands via EPSF pipe support. Due to missing sanitizing of filenames it is possible that a specially crafted filename can cause arbitrary commands to be executed. Multiple buffer overflows can cause the program to crash.
Alerts:
rPath rPSA-2006-0083-1 2006-05-26
Fedora-Legacy FLSA:152892 2005-12-17
Red Hat RHSA-2005:040-01 2005-02-15
Mandrake MDKSA-2005:033 2005-02-10
Gentoo 200502-03 2005-02-02
Red Hat RHSA-2005:039-01 2005-02-01
Fedora FEDORA-2005-096 2005-01-31
Fedora FEDORA-2005-092 2005-01-28
Fedora FEDORA-2005-091 2005-01-28
Fedora FEDORA-2005-016 2005-01-26
Fedora FEDORA-2005-015 2005-01-26
Ubuntu USN-68-1 2005-01-24
Debian DSA-654-1 2005-01-21

Comments (none posted)

ethereal: multiple vulnerabilities

Package(s):ethereal CVE #(s):CVE-2005-3241 CVE-2005-3242 CVE-2005-3243 CVE-2005-3244 CVE-2005-3245 CVE-2005-3246 CVE-2005-3247 CVE-2005-3248 CVE-2005-3249 CVE-2005-3184
Created:October 25, 2005 Updated:January 10, 2006
Description: A number of security flaws have been discovered in Ethereal. On a system where Ethereal is running, a remote attacker could send malicious packets to trigger these flaws and cause Ethereal to crash or potentially execute arbitrary code.
Alerts:
Fedora-Legacy FLSA:152922 2006-01-09
Mandriva MDKSA-2005:193-2 2005-10-31
Gentoo 200510-25 2005-10-30
Mandriva MDKSA-2005:193-1 2005-10-26
Mandriva MDKSA-2005:193 2005-10-25
Red Hat RHSA-2005:809-01 2005-10-25

Comments (none posted)

evolution: format string issues

Package(s):evolution CVE #(s):CAN-2005-2549 CAN-2005-2550
Created:August 15, 2005 Updated:March 23, 2006
Description: Evolution has format string issues. SITIC advisory SA05-001 contains more information.
Alerts:
Debian DSA-1016-1 2006-03-23
SuSE SUSE-SA:2005:054 2005-09-16
Red Hat RHSA-2005:267-01 2005-08-29
Gentoo 200508-12 2005-08-23
Mandriva MDKSA-2005:141 2005-08-17
Fedora FEDORA-2005-742 2005-08-11
Fedora FEDORA-2005-743 2005-08-11

Comments (2 posted)

firefox: multiple vulnerabilities

Package(s):firefox CVE #(s):CAN-2005-2701 CAN-2005-2702 CAN-2005-2703 CAN-2005-2704 CAN-2005-2705 CAN-2005-2706 CAN-2005-2707 CAN-2005-2968
Created:September 22, 2005 Updated:February 15, 2006
Description: The Firefox browser has multiple vulnerabilities including problems with XBM image file processing, Unicode sequence processing, XMLHttp requests, malicious XBL binding, a JavaScript engine buffer overflow, about: pages, opening of new windows, and command line URL processing.
Alerts:
Slackware SSA:2006-045-02 2006-02-15
Fedora-Legacy FLSA:168375 2006-01-09
Ubuntu USN-200-1 2005-10-11
Ubuntu USN-155-3 2005-10-04
Debian DSA-838-1 2005-10-02
Gentoo GLSA 200509-11:02 2005-09-18
SuSE SUSE-SA:2005:058 2005-09-30
Mandriva MDKSA-2005:170 2005-09-26
Mandriva MDKSA-2005:169 2005-09-26
Slackware SSA:2005-269-01 2005-09-26
Fedora FEDORA-2005-934 2005-09-26
Fedora FEDORA-2005-933 2005-09-26
Fedora FEDORA-2005-932 2005-09-26
Fedora FEDORA-2005-931 2005-09-26
Fedora FEDORA-2005-930 2005-09-26
Fedora FEDORA-2005-929 2005-09-26
Fedora FEDORA-2005-928 2005-09-26
Fedora FEDORA-2005-927 2005-09-26
Fedora FEDORA-2005-926 2005-09-26
Ubuntu USN-186-2 2005-09-25
Ubuntu USN-186-1 2005-09-23
Red Hat RHSA-2005:789-01 2005-09-22
Red Hat RHSA-2005:785-01 2005-09-22

Comments (none posted)

flash-plugin: buffer overflow

Package(s):flash-plugin CVE #(s):CVE-2005-2628
Created:November 10, 2005 Updated:November 25, 2005
Description: The Mozilla browser Macromedia Flash Player plug-in has a buffer overflow vulnerability. A user who opens a maliciously created Macromedia Flash file may be tricked into executing arbitrary code.
Alerts:
Gentoo 200511-21 2005-11-25
Red Hat RHSA-2005:835-00 2005-11-09

Comments (none posted)

Foomatic: Arbitrary command execution in foomatic-rip

Package(s):foomatic CVE #(s):CAN-2004-0801
Created:September 20, 2004 Updated:May 31, 2006
Description: There is a vulnerability in the foomatic-filters package. This vulnerability is due to insufficient checking of command-line parameters and environment variables in the foomatic-rip filter. This vulnerability may allow both local and remote attackers to execute arbitrary commands on the print server with the permissions of the spooler.
Alerts:
SuSE SUSE-SA:2006:026 2006-05-30
Fedora-Legacy FLSA:2076 2004-11-05
Conectiva CLA-2004:880 2004-10-27
Fedora FEDORA-2004-303 2004-09-21
Gentoo 200409-24 2004-09-20

Comments (none posted)

FUSE: mtab corruption through fusermount

Package(s):fuse CVE #(s):CVE-2005-3531
Created:November 22, 2005 Updated:January 24, 2006
Description: Thomas Biege discovered that fusermount fails to securely handle special characters specified in mount points. A local attacker could corrupt the contents of the /etc/mtab file by mounting over a maliciously-named directory using fusermount, potentially allowing the attacker to set unauthorized mount options.
Alerts:
Debian-Testing DTSA-27-1 2006-01-20
Mandriva MDKSA-2005:216 2005-11-24
Gentoo 200511-17 2005-11-22

Comments (none posted)

gaim: buffer overflow

Package(s):gaim CVE #(s):CAN-2005-2103
Created:August 10, 2005 Updated:February 27, 2006
Description: Gaim suffers from a heap-based buffer overflow which can be exploited via a hostile "away message" to execute arbitrary code.
Alerts:
Fedora-Legacy FLSA:158543 2006-02-25
Slackware SSA:2005-242-03 2005-08-31
Fedora FEDORA-2005-751 2005-08-17
Fedora FEDORA-2005-750 2005-08-17
Mandriva MDKSA-2005:139 2005-08-15
Gentoo 200508-06 2005-08-15
Ubuntu USN-168-1 2005-08-12
Red Hat RHSA-2005:589-01 2005-08-09

Comments (none posted)

gdb: multiple vulnerabilities

Package(s):gdb CVE #(s):CAN-2005-1704 CAN-2005-1705
Created:May 20, 2005 Updated:August 11, 2006
Description: Tavis Ormandy of the Gentoo Linux Security Audit Team discovered an integer overflow in the BFD library, resulting in a heap overflow. A review also showed that by default, gdb insecurely sources initialization files from the working directory. Successful exploitation would result in the execution of arbitrary code on loading a specially crafted object file or the execution of arbitrary commands.
Alerts:
Red Hat RHSA-2006:0354-01 2006-08-10
Red Hat RHSA-2006:0368-01 2006-07-20
Mandriva MDKSA-2005:215 2005-11-23
Fedora FEDORA-2005-1033 2005-10-27
Fedora FEDORA-2005-1032 2005-10-27
Red Hat RHSA-2005:801-01 2005-10-18
Red Hat RHSA-2005:763-01 2005-10-11
Red Hat RHSA-2005:709-01 2005-10-05
Red Hat RHSA-2005:673-01 2005-10-05
Red Hat RHSA-2005:659-01 2005-09-28
Fedora FEDORA-2005-498 2005-06-29
Fedora FEDORA-2005-497 2005-06-29
Gentoo 200506-01 2005-06-01
Trustix TSLSA-2005-0025 2005-05-31
Mandriva MDKSA-2005:095 2005-05-30
Ubuntu USN-136-2 2005-05-27
Ubuntu USN-136-1 2005-05-27
Ubuntu USN-135-1 2005-05-27
Gentoo 200505-15 2005-05-20

Comments (5 posted)

gtk-pixbuf, gtk2: denial of service

Package(s):gdk-pixbuf gtk2 CVE #(s):CAN-2005-0891
Created:March 30, 2005 Updated:December 19, 2005
Description: The BMP image processing code in gdk-pixbuf and gtk2 contains a denial of service vulnerability exploitable via a specially crafted image file.
Alerts:
Fedora-Legacy FLSA:155510 2005-12-17
Fedora-Legacy FLSA:154272 2005-07-15
SuSE SUSE-SR:2005:010 2005-04-08
Mandrake MDKSA-2005:069 2005-04-07
Mandrake MDKSA-2005:068 2005-04-07
Ubuntu USN-108-1 2005-04-05
Red Hat RHSA-2005:343-01 2005-04-05
Red Hat RHSA-2005:344-01 2005-04-01
Fedora FEDORA-2005-268 2005-03-30
Fedora FEDORA-2005-267 2005-03-30
Fedora FEDORA-2005-266 2005-03-30
Fedora FEDORA-2005-265 2005-03-30

Comments (none posted)

gdk-pixbuf: multiple vulnerabilities

Package(s):gdk-pixbuf gtk2 CVE #(s):CVE-2005-3186 CVE-2005-2976 CVE-2005-2975
Created:November 15, 2005 Updated:March 20, 2006
Description: The gdk-pixbuf package contains an image loading library used with the GNOME GUI desktop environment. A bug was found in the way gdk-pixbuf processes XPM images. An attacker could create a carefully crafted XPM file in such a way that it could cause an application linked with gdk-pixbuf to execute arbitrary code when the file was opened by a victim.

Ludwig Nussel discovered an integer overflow bug in the way gdk-pixbuf processes XPM images. An attacker could create a carefully crafted XPM file in such a way that it could cause an application linked with gdk-pixbuf to execute arbitrary code or crash when the file was opened by a victim.

Ludwig Nussel also discovered an infinite-loop denial of service bug in the way gdk-pixbuf processes XPM images. An attacker could create a carefully crafted XPM file in such a way that it could cause an application linked with gdk-pixbuf to stop responding when the file was opened by a victim.

Alerts:
Fedora-Legacy FLSA:173274 2006-03-16
Debian DSA-913-1 2005-12-01
Debian DSA-911-1 2005-11-29
Trustix TSLSA-2005-0066 2005-11-18
Mandriva MDKSA-2005:214 2005-11-18
Ubuntu USN-216-1 2005-11-16
SuSE SUSE-SA:2005:065 2005-11-16
Gentoo 200511-14 2005-11-16
Fedora FEDORA-2005-1088 2005-11-15
Fedora FEDORA-2005-1087 2005-11-15
Fedora FEDORA-2005-1086 2005-11-15
Fedora FEDORA-2005-1085 2005-11-15
Red Hat RHSA-2005:811-01 2005-11-15
Red Hat RHSA-2005:810-01 2005-11-15

Comments (none posted)

gettext: Insecure temporary file handling

Package(s):gettext CVE #(s):CAN-2004-0966
Created:October 11, 2004 Updated:March 1, 2006
Description: gettext insecurely creates temporary files in world-writeable directories with predictable names. A local attacker could create symbolic links in the temporary files directory, pointing to a valid file somewhere on the filesystem. When gettext is called, this would result in file access with the rights of the user running the utility, which could be the root user.
Alerts:
Mandriva MDKSA-2006:051 2006-02-28
Fedora-Legacy FLSA:136323 2006-01-09
Gentoo 200410-10:02 2004-10-10
OpenPKG OpenPKG-SA-2004.055 2004-12-23
Ubuntu USN-5-1 2004-10-27
Gentoo 200410-10 2004-10-10

Comments (1 posted)

groff: insecure temporary directory

Package(s):groff CVE #(s):CAN-2004-0969
Created:November 1, 2004 Updated:February 9, 2006
Description: Recently, Trustix Secure Linux discovered a vulnerability in the groff package. The utility "groffer" created a temporary directory in an insecure way, which allowed exploitation of a race condition to create or overwrite files with the privileges of the user invoking the program.
Alerts:
Mandriva MDKSA-2006:038 2006-02-08
Gentoo 200411-15 2004-11-08
Ubuntu USN-13-1 2004-11-01

Comments (none posted)

gzip: arbitrary command execution

Package(s):gzip CVE #(s):CAN-2005-0758
Created:August 1, 2005 Updated:January 9, 2007
Description: zgrep in gzip before 1.3.5 does not handle shell metacharacters like '|' and '&' properly when they occurred in input file names. This could be exploited to execute arbitrary commands with user privileges if zgrep is run in an untrusted directory with specially crafted file names.
Alerts:
OpenPKG OpenPKG-SA-2007.002 2007-01-08
Mandriva MDKSA-2006:027 2006-01-30
Mandriva MDKSA-2006:026 2006-01-30
Fedora-Legacy FLSA:158801 2005-11-14
Fedora-Legacy FLSA:157696 2005-08-10
Ubuntu USN-161-1 2005-08-04
Ubuntu USN-158-1 2005-08-01

Comments (2 posted)

htdig: cross site scripting

Package(s):htdig CVE #(s):CAN-2005-0085
Created:February 14, 2005 Updated:January 10, 2006
Description: Michael Krax discovered that ht://Dig fails to validate the 'config' parameter before displaying an error message containing the parameter. This flaw could allow an attacker to conduct cross-site scripting attacks.
Alerts:
Fedora-Legacy FLSA:152907 2006-01-09
Mandrake MDKSA-2005:063 2005-03-31
Red Hat RHSA-2005:090-01 2005-02-15
Debian DSA-680-1 2005-02-14
Gentoo 200502-16 2005-02-13

Comments (none posted)

imap: buffer overflow in c-client

Package(s):imap CVE #(s):CAN-2003-0297
Created:February 18, 2005 Updated:April 9, 2006
Description: A buffer overflow flaw was found in the c-client IMAP client. An attacker could create a malicious IMAP server that if connected to by a victim could execute arbitrary code on the client machine.
Alerts:
Fedora-Legacy FLSA:184074 2006-04-04
Fedora-Legacy FLSA:152912 2005-05-12
Red Hat RHSA-2005:114-01 2005-02-18

Comments (none posted)

inkscape: arbitrary code execution

Package(s):inkscape CVE #(s):CVE-2005-3737
Created:November 21, 2005 Updated:December 7, 2005
Description: A buffer overflow has been discovered in the SVG importer of Inkscape. By tricking an user into opening a specially crafted SVG image this could be exploited to execute arbitrary code with the privileges of the Inkscape user.
Alerts:
Debian-Testing DTSA-24-1 2005-12-05
Debian DSA-916-1 2005-12-07
Gentoo 200511-22 2005-11-28
Ubuntu USN-217-1 2005-11-21

Comments (none posted)

kdebase: local root vulnerability

Package(s):kdebase CVE #(s):CAN-2005-2494
Created:September 7, 2005 Updated:August 11, 2006
Description: The kdebase package (and kcheckpass in particular) found in KDE versions 3.2.0 through 3.4.2 suffers from a lock file handling error which can enable a local attacker to obtain root access. See this advisory for details.
Alerts:
Red Hat RHSA-2006:0582-01 2006-08-10
Debian DSA-815-1 2005-09-16
Slackware SSA:2005-251-01 2005-09-09
Ubuntu USN-176-1 2005-09-07
Mandriva MDKSA-2005:160 2005-09-06

Comments (none posted)

kdelibs: kate backup file permission leak

Package(s):kdelibs kate kwrite CVE #(s):CAN-2005-1920
Created:July 19, 2005 Updated:November 27, 2006
Description: Kate / Kwrite, as shipped with KDE 3.2.x up to including 3.4.0, creates a file backup before saving a modified file. These backup files are created with default permissions, even if the original file had more strict permissions set. See this advisory for more information.
Alerts:
Gentoo 200611-21 2006-11-27
Debian DSA-804-2 2005-11-10
Debian DSA-804-1 2005-09-08
Red Hat