The kernel and BitKeeper part ways
Back in early 1999, your editor got a call from Larry McVoy. He was
worried that Linus Torvalds was on the verge of burning out as the kernel
project grew. The problems in those days were quite evident; Linus, it was
being said, did not scale. But, according to Larry,
a complete burnout was not inevitable. If Linus could be given the right
tools, many of his problems (and the frustrations of other kernel
developers) could be solved, and the system would run smoothly again. The
right tool, according to Larry, was a thing called BitKeeper; if some sort
of agreement could be made on licensing, Larry (along with his company, BitMover)
was willing to make
BitKeeper available for kernel development. In fact, Larry wanted to see
BitKeeper used for
all free software development; see
this article from the
March 25, 1999 LWN Weekly Edition for a view of how things looked at
that time.
Three years later, the situation did not look any better. The 2.4 kernel
had taken almost a full year to stabilize after 2.4.0 came out. 2.5 had
begun, but the process was looking rocky at best. Patches were being
dropped, developers were complaining, and Linus was getting tired. After
convincing himself that the tool had reached a point where it could do what
he needed, Linus decided to give BitKeeper a try. There was no looking
back.
Some of the development process issues could have been addressed by
adopting any source code management system. But BitKeeper brought
more than that; it established a model where there is no central
repository. Instead, each developer could maintain one or more fully
independent trees. When the time came, patches of interest could be
"pulled" from one tree to another while retaining the full revision
history. Rather than send patches in countless email messages - often
multiple times - developers could simply request a pull from their
BitKeeper trees. Meanwhile, the current development trees could be pulled
automatically into the -mm kernel, allowing patches to be tested by a wider
audience prior to merging into the mainline. BitKeeper enabled a work
method and patch flow which naturally supported the kernel's development
model.
Once the developers and the tools got up to speed, kernel development took
off like never before. The rate at which patches were merged skyrocketed,
the developers were happy, and the whole system ran smoothly. The public
version of Linus's BitKeeper repository (and the repositories of many other
developers) made the development process more transparent than ever.
Anybody could look to see the up-to-the-minute state of the kernel and how
it got there. Larry was right: with the right tools, Linus really
could scale.
The only problem was that BitKeeper is proprietary software. Instead, it
came (in binary-only form) with a license
which allowed free use, but which imposed some significant restrictions.
The free version of BitKeeper could only be used with open source projects;
users could be required to make their repositories available on demand.
The free version posted all changelog information on openlogging.org, and disabling the
logging was not allowed. Users were required to upgrade to new versions,
which could come with different licenses. And users were not only
prohibited from reverse engineering the software, but they were prohibited
from working on any sort of source code management system at all.
Larry wanted to have his cake and eat it too. He truly wanted to support
the development of free software - as long as that software didn't threaten
his own particular business niche. Supporting the kernel development cost
real money - and supporting the business which created BitKeeper cost even
more. Whenever BitMover felt that its business model was threatened, it
responded; often the BitKeeper licensing terms were changed in response to
perceived threats - to the point that the BitKeeper license became known in
some circles as the "don't piss off Larry license."
Well, somebody pissed off Larry one time too many. The final straw, it
seems, was a certain high-profile developer who refused to stop reverse
engineering work while simultaneously doing some work for OSDL. BitMover
is now withdrawing support for the free version of BitKeeper, and Linus has
ceased to use it. BitKeeper is no longer the source code management system
for the kernel. Proprietary software can be good stuff, but it always
carries this threat: you never really know if it will be there for you
tomorrow or not. BitMover has decided that it can no longer afford to make
BitKeeper available for the free software community.
BitMover has issued a
press release on this change:
BitMover looks forward to implementing our extensive roadmap and
delivering advanced SCM technology to a wider market. As part of
this focus, BitMover has replaced the free version of BitKeeper
with the recently released open source BitKeeper client. Those
developers who desire additional functionality may choose to
migrate to the more powerful commercial version of BitKeeper.
The open source client, incidentally, enables the extraction of the current
version from a repository, but does little else.
The PR also states that "Our relationship with the Open Source
community has been evolving and many of the key developers have already
migrated to the commercial version of BitKeeper." Linus has,
however, made it clear that he is not one
of those "key developers":
Right now, the only real thing that has happened is that I've
decided to not use BK mainly because I need to figure out the
alternatives, and rather than continuing "things as normal", I
decided to bite the bullet and just see what life without BK looks
like. So far it's a gray and bleak world ;)
What happens next is far from clear. The kernel developers will not go
back to the previous way of doing things - no source code management system
at all. Even the developers who can continue to use BitKeeper are unlikely
to continue doing so if Linus is unable to pull their patches.
So a replacement will have to be found. It is not clear that any
of the free alternatives is up to the task of handling a project as large
as the kernel. One of them may end up growing up in a hurry in order to
take the load. Thanks partly to the example and motivation provided by
BitKeeper, the free alternatives do look far more viable than they did
three years ago, when Linus first started using BitKeeper.
Larry has made it clear that
he blames the free software community for this turn of events:
I'm far from blameless but the majority of this problem is an open
source community problem. They simply don't want to play with
non-open source. At least some of them don't and they ruin it for
the rest of us. The problem here is one of policing. By
ignoring/tolerating the bad apples the community punishes itself.
If BitKeeper users were violating the license under which they received the
software, they have indeed done something wrong. Every time we release
code under a free license, we do so with the expectation that the terms of
that license will be respected. To treat somebody else's license with less
respect is hypocritical; if the license terms are not acceptable, do not
use the software. That said, one could note a couple of other things.
The notion that developers of proprietary software do not
engage in reverse engineering - that it's "an open source community
problem" - is debatable at best. And how, exactly, might the community be
expected to do this sort of "policing"?
The ironic result of all this is likely to be the accelerated development
of exactly what Larry claims to most fear: a free source code management
system that, while it lacks much of what makes BitKeeper great, is "good
enough" for a large portion of the user base. As the BitKeeper developers
found out, hosting the kernel project is an effective way to shake out
scalability and usability problems. Whichever system ends up hosting the
kernel can be expected to go through a period of rapid improvement.
BitMover did, in fact, get a few benefits from hosting the
kernel, even if, in the company's view, the benefits do not come close to
equaling the associated costs.
BitKeeper is a more scalable and robust system as
a result of the use it saw in that role. There were also substantial PR
benefits; see, for example, this 2004 press
release with nice quotes from David Miller and Linus Torvalds. There
can be no doubt that working with the kernel has brought a great deal of
visibility to BitKeeper, and that must have resulted in some new business.
The cynical among us might conclude (and some already have concluded) that
BitMover simply decided that it had obtained most of the benefits it was
going to get from hosting the kernel and decided to move on.
Whether or not that is the case, it cannot be doubted that Linux, too, has
benefited strongly from its association with BitKeeper. We would not have
a 2.6 kernel with anything near its level of capability, scalability, and
robustness without the role played by BitKeeper. One could easily argue
that the free source code management systems would not be as good as they
are had BitKeeper not come along. BitKeeper was a gift to the community
that was well worth accepting; now that it is gone, the best thing to do is
to say "thanks" (with sincerity!) and figure out what comes next.
Comments (65 posted)
Ubuntu and UserLinux
Despite what you may have heard on
Slashdot,
UserLinux and
Ubuntu aren't going to be merging
anytime soon.
A few weeks ago, Ubuntu's Jeff Waugh
invited
the UserLinux project to "
collaborate with Ubuntu to build the finest
platform and community for FOSS service providers." This was after a
discussion about the problems of trying to build UserLinux around Debian
when
it's
taking a long time for a new stable release from Debian.
Waugh's invitation generated a fair amount of additional
discussion
on the UserLinux list, but little comment from UserLinux founder Bruce
Perens. It's become clear that Ubuntu and UserLinux will remain separate
for the foreseeable future, but we decided to check in with Perens to see
what he had to say about the whole thing.
Perens was quick to note that he supports Ubuntu, but doesn't think that
Ubuntu's corporate-sponsored model is the way to go for UserLinux.
When Mark [Shuttleworth] started to work on Ubuntu, he called me up and we
talked about whether I'd be interested in taking a leadership position in
Ubuntu and I decided not to pursue that, because I feel that a non-profit
is the correct paradigm for a Linux distribution. A Linux distribution is
inherently not a profit-making enterprise and we are seeing [some of] the
commercial Linux distributions abuse the open source paradigm because of
that fact.
In addition, Perens said that Debian's development process allows anyone to
become a developer and run for Project Leader or hold another Debian
office, which doesn't exist in other projects. "You can be part of
Ubuntu's community or Fedora's community, you don't get the chance to be
boss."
Shortly after Waugh's invitation on the UserLinux mailing list, some of the
Ubuntu team created experimental
UserLinux packages for Ubuntu. The metapackages would allow creating
"a sort of Ubuntu-flavored UserLinux." Unfortunately, the
packages were also in violation of the UserLinux trademark policy. When we
asked about the situation, Perens noted the importance of having a
trademark policy, given the abuse of the Debian trademark "in various
ways" and that "the UserLinux guys get to say what can be
called UserLinux when they do their version of the Debian release."
He also said he didn't have a problem with labeling the packages "ul" or
something similar to distinguish them from official UserLinux packages. It
would appear, after a bit of friction, that the projects are
sorting
out the trademark issue so Ubuntu can include the metapackages.
But the Ubuntu effort highlights the problem of perceived inertia for
UserLinux. Perens announced UserLinux in December of 2003. There was a
great deal of interest in the idea at the time, but the wait for a Debian
release has certainly had an impact on the momentum of the project.
Perens conceded that there was a perception among the Linux community that
UserLinux had stagnated, but said that the perception can be overcome.
A lot of people would have given up now, because the time-to-market is
totally blown, but this was never intended to be a start-up
business. Having been on board or watching the last five companies that
were attempting to commercialize Debian, I have some idea what went wrong
and what went right and I think we can make this idea work with
businesses.
As far as UserLinux, I think what I would like to do, is once Debian has
made a release, have our roster of support companies ready to support it,
and to just start giving these things out at Linux-related business events
and saying 'here's a system with full support, here's a price sheet, and
we're going to give you a lower cost of ownership than Linux. We're going
to beat other Linux distributions on TCO and we're going to give you more
control because, more than Fedora, more than Ubuntu, you get a chance to
determine exactly how the system is built, because it's tracking what the
Debian organization does, it's not a Debian variant.
Perens also told LWN that the best way for someone to help with UserLinux
is to be involved with Debian.
For people in the community, my main desire is that they work on Debian,
okay? We can use some people on the UserLinux project, but the UserLinux
policy is when we make software, we do it on Debian teams, and check it
into Debian Subversion, don't issue as separate UL packages unless there's
a Debian freeze...I think that Debian is a very healthy community, despite
the challenges.
To outsiders, however, it may appear at times that the Debian Project is too
mired in political disagreements and flame wars to actually get anything
done -- which is a significant objection to wanting to be involved with
Debian. Perens said that there is a need to convince "a significant
portion of 1,000 active developers that your policy is right" when
working with Debian, but "that in itself is a quality assurance
process."
Perens said he was "heartened" by the recent announcement that
Debian will soon be doing a release, and that "when Debian wants to
get off the dime, they can." He also said that the Debian developers
have been "pretty embarrassed by the long delay of the
release" and have bit the bullet to get it out the door. He also
predicted that the next Debian release after Sarge will be scheduled, and
it will be kept on schedule.
It will be interesting to see what happens after Debian Sarge is released,
and whether the UserLinux project can succeed as distribution for
"businesses of all sizes."
Comments (4 posted)
GCJ - past, present, and future
April 6, 2005
This article was contributed by Mark Wielaard
GCJ (the GNU Compiler for the java programming language) is part of GCC
(the GNU Compiler Collection) and provides a compiler, runtime
environment, core libraries and tools for the Java language - it's an
object oriented, strongly
typed, garbage collected programming framework with a rich core
library. GCJ is modeled after, and is a free replacement for, the
proprietary Java platform. But like GNU is Not Unix, GCJ is not Java.
The traditional Java platform is clearly not an ideal system,
especially when combined with the traditional GNU system, but it is
not too bad. The essential features seem to be good ones. Lots of
Free Software is already written in the Java programming language so a
free system compatible with the Java platform would be convenient for
many hackers. GCJ is an extension of GCC and facilitates integration
with other languages supported by GCC. GCJ 4, part of GCC 4.0, adds
more features to easily integrate programs written using the GCJ
development environment with the rest of the GNU platform while being
even more compatible with the traditional Java platforms then previous
releases. GCC 4.0 is scheduled to be released around April 15.
GCJ design history
Originally GCJ was designed as a “radically
traditional” compiler for the Java programming language. It is an
AOT (Ahead Of Time) compiler which automatically uses every GCC
optimization available during compile time for a given architecture
and produces binaries or (shared) libraries for the given platform.
These programs run at full native speed without needing any
interpreter or JIT (Just In Time) compilation. GCC is available for a
large number of architectures and platforms so compiling directly to
native code using the GCC back-ends makes programs written with GCJ
much more portable then the traditional (proprietary) Java platform.
This radically traditional approach makes all normal GNU tools like
GDB available to the programmer writing code in the Java programming
language just like when programming in any other language supported by
GCC.
Thereafter,
support for generating and interpreting byte code .class and
.jar files was added. This made GCJ more compatible with
traditional applications written in the Java programming language
that are compiled to byte code. GCJ can be used in various modes:
- Compile and link .java source files to binaries,
.o or .so files.
- Compile and link .class or .jar byte code files
to binary.
- Compile .java source files to .class byte code
files (
gcj -C).
- Interpret .class or .jar byte code files during
runtime (
gij).
The byte code interpreter is included as part of the standard runtime
libgcj and can be used by programs to switch between
interpreting byte code and executing natively compiled code on demand.
So not all of the program has to be completely interpreted or
completely compiled ahead of time at the same time.
To facilitate integration with code written in other languages, GCJ
defines the CNI
(Compiled Native Interface). CNI makes it easy to mix and match
code and classes written in C, C++ and Java by allowing you to write
some methods of a class in C++ and to catch and throw exceptions
directly to and from parts of the program written in different
languages. GCJ also support the more traditional JNI (Java Native
Interface) for using code written in C from your programs.
Anthony Green posted the
original design
document for GCJ from 1998.
Drawbacks of the GCJ 3.x approach
GCJ 3.x provides a good “better than Java” development
environment that allows tight integration with the rest of the GNU
platform. But it has disappointed some traditional Java programmers.
The possibility to mix and match native code with byte code in the
compiler and libgcj runtime makes GCJ very flexible. But falling back
to interpreting byte code doesn't really take full advantage of the
whole “radically traditional” approach. Especially
programs using advanced byte code based class loader tricks used to
work slowly because they fell back to using the interpreter during
runtime.
There are GCJ extensions to add support for using natively compiled
code all the time. But programs had to be adapted to use these
extensions. Instead of using .jar files containing byte code
definitions of new classes programs would have to use a new URL scheme
(gcjlib:) for their URLClassLoader uses. The
first “Fast Free
Eclipse” port to GCJ was done this way. The source code of
the plugin loading mechanism was adapted to search for natively
compiled plugins in shared library .so files besides ordinary
.jar byte code files. There was even a moderately popular
project, rhug, that
maintained a lot of patched versions of traditional free Java programs
that were adapted to gcj's view of the world. But these
patches were almost never adopted upstream and the maintenance of
these forks took a lot of time. So the benefits of the GCJ approach
were only seen by programs written explicitly for it, but not by
traditional Java programs.
One of the main goals of the GCJ 4 effort was to bring all the
advantages of the “radically traditional” approach to any
program written in the Java programming language without needing any
application-level changes.
GCJ 4 enhancements
Probably the most visible enhancement of GCJ 4 comes from merging the
libgcj runtime with the GNU Classpath core
class library project. By collaborating with other free runtimes like
the traditional kaffe environment and around 20
other projects, GCJ 4 is able to offer a core class library comparable to
JDK 1.3 or 1.4. The collaboration of all these projects on a common
core library implementation means that a lot of the libraries needed by
applications, except for advanced Swing, Corba and sound usage, are
available out of the box. Kaffe, for example, is being used by the
Apache project to track the build of most of the jakarta projects
using their Gump auto-builder.
The other big change is the addition of the
-findirect-dispatch switch to the compiler. Using that
option causes GCJ to generate native code for classes and methods that follow
the precise same binary compatibility rules as described in the Java
Language Specification. This means that native compiled code can now
be used everywhere, even in the most tricky class loader situations,
where previously the program would fall back to interpreted byte code.
At the 2004 GCC Summit Tom Tromey and Andrew Haley described this
new
binary compatibility ABI for GCJ in more detail.
The new binary compatibility (BC) ABI makes it possible to transparently
compile programs to native code using gcj
-findirect-dispatch without having to change the application
source code or even the build process. To map byte code to GCJ
compiled native code, GCJ 4 introduces gcj-dbtool. This tool
is used by the packager during deployment of the application or
library to create a database mapping the bytecode of a class to the
native code during runtime. Programs can use different databases
using the gnu.gcj.precompiled.db.path system property. The
databases make it possible to create a cache of all native compiled
code that can be shared by different programs installed on the system.
The How
to BC compile with GCJ GCC wiki page has examples.
This approach is used by the native Eclipse packages in Fedora Core 4.
No changes to the eclipse code base are necessary anymore and, after
the project is bootstrapped, all resulting .jar files are BC
compiled. To almost completely automate this process, Thomas Fitzsimmons
created java-gcj-compat.
A collection of wrapper scripts, symlinks and jar files that provide a
Java-SDK-like interface to this new GCJ 4 tool set.
Future plans
The -findirect-dispatch switch can currently only be used for byte code
and not in combination with CNI (JNI is already supported). This limitation
currently prevents parts of the core class libraries from being BC
compiled. Lifting this restricting will facilitate more integration
with GNU Classpath.
With GCJ and GDB a programmer can step through native C, C++ and Java
source code using the same tool. Traditional Java developers are more
used to JDWP (Java Debugging Wire Protocol) for debugging their
applications. Eclipse comes with built-in support for JDWP. Work is
in progress to provide JDWP debugging support for the different
execution mechanisms. This code will also be shared with the GNU
Classpath project.
Benchmarks show that GCJ
is comparable (sometimes faster, sometimes slower) to traditional
execution mechanisms for Java programs. But GCJ currently doesn't
really take advantage of the new GCC 4.0 Tree SSA optimizer
framework. For 4.1 the GCJ developers hope to add a couple of GCJ
specific optimizations.
Tom Tromey is currently working on GCJX, a new GCC frontend that will
include support for the new 1.5 language additions, such as generics. And
the GNU Classpath project has a separate branch for the core class
libraries that depend on the new 1.5 language additions.
Escaping the Java Trap
GCJ 4 is the result of seven years of work by a large and active community of
Free Software hackers. This new version is complete enough to
replace most interesting uses of the proprietary Java platform. It
adds a whole new set of core libraries and adds some new features to
help integration with the rest of the GNU platform. Upcoming versions
of some GNU/Linux distributions will use GCJ
4 to provide much more Java-based Free Software, including Eclipse, Jonas,
OpenOffice.org 2, Tomcat and the Jakarta libraries.
There is also a great deal of free software to
integrate with traditional GNU/Linux distributions provided by the JPackage project. Both Debian and
Fedora are working with the jpackage hackers to support more
of these packages “out of the box”.
All this doesn't mean that we have escaped the Java trap yet. As
pointed out by Richard Stallman in “Free But Shackled
- The Java Trap” we have to actively work together to keep
code safe and free. It looks like the main target projects for GCJ 4
(Apache Jakarta, Eclipse and OpenOffice.org 2), have all reacted
positively to the feedback and patches provided to support free
alternatives to the Java platform.
The fact that the
changes requested were for making the projects more portable
("don't use undocumented com.sun internal classes")
rather than requests to dramatically change the code, (core) libraries
used or build infrastructure has helped a lot. But the above
projects were already free software projects at heart. It remains to
be seen if other more traditional java projects will adapt so easily
to support GCJ 4 out of the box.
Comments (44 posted)
Page editor: Jonathan Corbet
Security
Blocking popups in FireFox
One of the most compelling features of Firefox, for many users, is its
built-in pop-up blocking. However, the advertising networks and webmasters
looking to inflict pop-up ads on users weren't content to allow Firefox
users (or anyone else, for that matter) to browse in peace. It's not
surprising that, as Firefox gains in popularity, the Mozilla team would be
faced with an "arms race" with advertisers determined to spawn pop-ups on
all visitors to sponsored sites.
This writer has recently noticed that some sites had begun spawning
pop-ups, despite the fact that Firefox's preferences had been configured to
block them. After so long without having to cope with pop-ups, it was
doubly annoying to see the nuisance starting all over again.
For the most part, before Firefox and other pop-up blockers appeared on the
scene, pop-ups and pop-unders were spawned by JavaScript as soon as a site
loads. The Firefox pop-up blocking settings were very successful in
blocking almost all pop-up ads. The notable exception, at least for this
user, was the New York Times website, which was one of the first sites to
find a workaround for Firefox's pop-up blocking.
JavaScript, however, is not the only method that can be used to spawn
pop-ups. Notably, Flash, Java and other plugins are capable of spawning
pop-ups and bypass the restrictions used to stop pop-ups spawned by
JavaScript. To start blocking pop-ups on sites that take advantage of
features in Flash or Java to spawn pop-ups, users can install the Pop-ups
Must Die! extension.
Alternately, users can get the same effect by manually fine-tuning
Firefox's settings. The first change, adding
"privacy.popups.disable_from_plugins" is described here.
The extension also changes the value of
"dom.popup_allowed_events" to block all allowed pop-up
events. This can be done by entering "about:config" in the Firefox address
bar, and finding "dom.popup_allowed_events," and removing all
of the options. These are the only two changes made by the extension.
The changes seem to have been very effective -- perhaps a little too
effective. Several users have complained that the extension blocks
requested pop-ups as well. This is true, but Firefox still allows users to
whitelist sites after a pop-up has been blocked by the new settings. This
writer considers it a small price to pay to avoid unrequested pop-ups. For
those who would rather deal with the occasional unrequested pop-up, one may
change "privacy.popups.disable_from_plugins" to "1" to allow
pop-ups to be opened when a link is clicked. This will limit the number of
windows opened by a link, so nefarious webmasters cannot open an unlimited
number of windows.
Determined webmasters, however, can find ways to inflict advertising on
users in other ways. Consider this site which was pointed out
in the discussion
about the "Pop-ups Must Die!" extension. Rather than spawning a pop-up, it
creates a frame within the window that blocks the content of the site until
the frame "window" is closed. Without disabling frames, which would cause a
great deal of problems for sites that use them legitimately, it's difficult
to imagine how one could avoid this kind of "pop-up." (Note, disabling
frames by changing the value of "browser.frames.enabled" to
false appears to break Firefox entirely.)
Ultimately, the best solution may not rest with Firefox. Users who are
offended by pop-ups, and other intrusive advertising, have an infallible
weapon at their disposal -- stop visiting sites that insist on using
pop-ups. While it would require a great number of users to be effective,
even the most persistent webmasters and advertisers would have to
reconsider their methods if they have no audience for their ads.
Comments (7 posted)
New vulnerabilities
Dnsmasq: poisoning and DoS
| Package(s): | dnsmasq |
CVE #(s): | |
| Created: | April 4, 2005 |
Updated: | July 21, 2005 |
| Description: |
Dnsmasq does not properly detect that DNS replies received do not
correspond to any DNS query that was sent. Rob Holland of the Gentoo Linux
Security Audit team also discovered two off-by-one buffer overflows that
could crash DHCP lease files parsing. |
| Alerts: |
|
Comments (none posted)
gaim: buffer overflow, DoS
| Package(s): | gaim |
CVE #(s): | CAN-2005-0965
CAN-2005-0966
|
| Created: | April 5, 2005 |
Updated: | May 15, 2005 |
| Description: |
Jean-Yves Lefort discovered a buffer overflow in the
gaim_markup_strip_html() function. This caused Gaim to crash when
receiving certain malformed HTML messages. (CAN-2005-0965)
Jean-Yves Lefort also noticed that many functions that handle IRC
commands do not escape received HTML metacharacters; this allowed
remote attackers to cause a Denial of Service by injecting arbitrary
HTML code into the conversation window, popping up arbitrarily many
empty dialog boxes, or even causing Gaim to crash. (CAN-2005-0966) |
| Alerts: |
|
Comments (none posted)
kernel: multiple vulnerabilities
| Package(s): | kernel |
CVE #(s): | CAN-2005-0400
CAN-2005-0749
CAN-2005-0750
CAN-2005-0815
CAN-2005-0839
|
| Created: | April 1, 2005 |
Updated: | July 1, 2005 |
| Description: |
More kernel vulnerabilities have been discovered including:
- Mathieu Lafon discovered
an information leak in the ext2 file system driver. (CAN-2005-0400)
- Yichen Xie discovered a Denial of Service vulnerability in the ELF
loader. (CAN-2005-0749)
- Ilja van Sprundel discovered that the bluez_sock_create() function
did not check its "protocol" argument for negative values.
(CAN-2005-0750)
- Michal Zalewski discovered that the iso9660 file system driver fails
to check ranges properly in several cases. (CAN-2005-0815)
- Previous kernels did not restrict the use of the N_MOUSE line
discipline in the serial driver. (CAN-2005-0839)
|
| Alerts: |
|
Comments (1 posted)
limewire: input validation errors
| Package(s): | limewire |
CVE #(s): | CAN-2005-0788
CAN-2005-0789
|
| Created: | March 31, 2005 |
Updated: | April 6, 2005 |
| Description: |
LimeWire, a Java-based peer-to-peer client that works
with the Gnutella file-sharing protocol, has two input
validation errors that can allow a remote attacker to
read arbitrary files with the permissions that LimeWire is
running under. |
| Alerts: |
|
Comments (none posted)
remstats: tempfile, missing input sanitizing
| Package(s): | remstats |
CVE #(s): | CAN-2005-0387
CAN-2005-0388
|
| Created: | April 4, 2005 |
Updated: | April 6, 2005 |
| Description: |
Jens Steube discovered several vulnerabilities in remstats, the remote
statistics system. When processing uptime data on the unix-server a
temporary file is opened in an insecure fashion which could be used for a
symlink attack to create or overwrite arbitrary files with the permissions
of the remstats user. (CAN-2005-0387) The remoteping service can be
exploited to execute arbitrary commands due to missing input
sanitizing. (CAN-2005-0388) |
| Alerts: |
|
Comments (none posted)
php4: denial of service vulnerabilities
| Package(s): | php4 |
CVE #(s): | CAN-2005-0524
CAN-2005-0525
|
| Created: | April 5, 2005 |
Updated: | May 26, 2005 |
| Description: |
Two DoS vulnerabilities exist in PHP versions 4.2.2, 4.3.9, 4.3.10 and
5.0.3. One in the php_handle_iff function in image.c allows remote
attackers to cause a denial of service (infinite loop) via a -8 size
value. The php_next_marker function in image.c allows remote attackers to
cause a denial of service (infinite loop) via a JPEG image with an invalid
marker value, which causes a negative length value to be passed to
php_stream_seek. This later vulnerability also exists in PHP 3. |
| Alerts: |
|
Comments (none posted)
sharutils: insecure temporary files
| Package(s): | sharutils |
CVE #(s): | |
| Created: | April 4, 2005 |
Updated: | April 14, 2005 |
| Description: |
Joey Hess discovered that "unshar" created temporary files in an
insecure manner. This could allow a symbolic link attack to create or
overwrite arbitrary files with the privileges of the user invoking the
program. |
| Alerts: |
|
Comments (1 posted)
sylpheed: buffer overflow on message
| Package(s): | sylpheed sylpheed-claws |
CVE #(s): | |
| Created: | April 4, 2005 |
Updated: | April 6, 2005 |
| Description: |
Sylpheed and Sylpheed-claws fail to properly handle messages containing
attachments with MIME-encoded filenames. |
| Alerts: |
|
Comments (none posted)
wu-ftpd: missing input sanitizing
| Package(s): | wu-ftpd |
CVE #(s): | CAN-2005-0256
|
| Created: | April 4, 2005 |
Updated: | April 6, 2005 |
| Description: |
The wu_fnmatch function in wu_fnmatch.c for wu-fptd 2.6.1 and 2.6.2 allows
remote attackers to cause a denial of service (CPU exhaustion by recursion)
via a glob pattern with a large number of * (wildcard) characters, as
demonstrated using the dir command. |
| Alerts: |
|
Comments (none 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: |
|
Comments (none posted)
cdrecord: insecure temp file
| Package(s): | cdrecord |
CVE #(s): | CAN-2005-0866
|
| Created: | March 24, 2005 |
Updated: | April 28, 2005 |
| Description: |
The cdrecord utility makes insecure temp files if DEBUG is
enabled in /etc/cdrecord/rscsi. This can allow a local user
to launch a sym link attack and execute code with the user's
privileges. |
| Alerts: |
|
Comments (1 posted)
cpio - file permissions error
| Package(s): | cpio |
CVE #(s): | CAN-1999-1572
|
| Created: | February 2, 2005 |
Updated: | July 19, 2005 |
| Description: |
Some versions of cpio contain an ancient vulnerability where files created by that utility have overly generous access permissions. |
| Alerts: |
|
Comments (none posted)
cURL: buffer overflow
| Package(s): | curl |
CVE #(s): | CAN-2005-0490
|
| Created: | February 28, 2005 |
Updated: | July 19, 2005 |
| Description: |
Multiple stack-based buffer overflows in libcURL and cURL 7.12.1, and
possibly other versions, allow remote malicious web servers to execute
arbitrary code via base64 encoded replies that exceed the intended buffer
lengths when decoded. |
| Alerts: |
|
Comments (none 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: |
|
Comments (none posted)
devhelp: buffer overflow
| Package(s): | devhelp |
CVE #(s): | |
| Created: | March 24, 2005 |
Updated: | March 30, 2005 |
| Description: |
A buffer overflow in the Mozilla GIF file handling code (used by devhelp) can
be exploited by specially crafted images, causing arbitrary code
execution. |
| Alerts: |
|
Comments (none posted)
dhcp: format string vulnerability
| Package(s): | dhcp |
CVE #(s): | CAN-2004-1006
|
| Created: | November 4, 2004 |
Updated: | July 13, 2005 |
| Description: |
Dhcp has a format string vulnerability in the log functions of dhcp 2.x
that may be exploited via a malicious DNS server. |
| Alerts: |
|
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: |
|
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: |
|
Comments (none posted)
epiphany: buffer overflow
| Package(s): | epiphany |
CVE #(s): | |
| Created: | March 24, 2005 |
Updated: | March 30, 2005 |
| Description: |
A buffer overflow in the Mozilla GIF file handling code can
be exploited by specially crafted images, causing arbitrary code
execution. |
| Alerts: |
|
Comments (none posted)
evolution: arbitrary code execution
| Package(s): | evolution |
CVE #(s): | CAN-2005-0102
|
| Created: | January 24, 2005 |
Updated: | May 19, 2005 |
| Description: |
Max Vozeler discovered an integer overflow in camel-lock-helper. A
user-supplied length value was not validated, so that a value of -1
caused a buffer allocation of 0 bytes; this buffer was then filled by
an arbitrary amount of user-supplied data. A local attacker or a malicious
POP3 server could exploit this to execute arbitrary code with root
privileges (because camel-lock-helper is installed as setuid root). |
| Alerts: |
|
Comments (1 posted)
evolution: message crash vulnerability
| Package(s): | evolution |
CVE #(s): | CAN-2005-0806
|
| Created: | March 17, 2005 |
Updated: | August 11, 2005 |
| Description: |
The Evolution mail client can be crashed when reading
certain types of messages. |
| Alerts: |
|
Comments (none posted)
evolution: buffer overflow
| Package(s): | evolution |
CVE #(s): | |
| Created: | March 24, 2005 |
Updated: | March 30, 2005 |
| Description: |
A buffer overflow in the Mozilla GIF file handling code (used by evolution) can
be exploited by specially crafted images, causing arbitrary code
execution.
|
| Alerts: |
|
Comments (none posted)
f2c: insecure temp files
| Package(s): | f2c |
CVE #(s): | CAN-2005-0017
CAN-2005-0018
|
| Created: | January 27, 2005 |
Updated: | April 20, 2005 |
| Description: |
The f2c fortran to C translator has a vulnerability due to
insecure opening of temporary files. A local attacker can use this
to launch a symlink attack. |
| Alerts: |
|
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: |
|
Comments (none posted)
gaim: client freezes
| Package(s): | gaim |
CVE #(s): | CAN-2005-0472
CAN-2005-0473
|
| Created: | February 22, 2005 |
Updated: | April 27, 2005 |
| Description: |
The Gaim client freezes when receiving certain invalid messages and crashes
when receiving specific malformed HTML. See this Secunia Advisory for
additional information. |
| Alerts: |
|
Comments (none 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: |
|
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: |
|
Comments (1 posted)
gftp: missing input sanitizing
| Package(s): | gftp |
CVE #(s): | CAN-2005-0372
CAN-2004-1376
|
| Created: | February 17, 2005 |
Updated: | July 13, 2005 |
| Description: |
gftp has a directory traversal vulnerability.
A remote server could use specially crafted filenames to overwrite
local files.
|
| Alerts: |
|
Comments (none posted)
ghostscript: symlink vulnerabilities
| Package(s): | ghostscript |
CVE #(s): | CAN-2004-0967
|
| Created: | October 20, 2004 |
Updated: | September 28, 2005 |
| Description: |
The ghostscript package (prior to version 7.07.1-r7) contains several scripts which are vulnerable to symlink attacks. |
| Alerts: |
|
Comments (none posted)
glibc: Information leak with LD_DEBUG
| Package(s): | glibc |
CVE #(s): | CAN-2004-1453
|
| Created: | August 17, 2004 |
Updated: | May 26, 2005 |
| Description: |
Silvio Cesare discovered a potential information leak in glibc. It allows
LD_DEBUG on SUID binaries where it should not be allowed. This has various
security implications, which may be used to gain confidential information.
An attacker can gain the list of symbols a SUID application uses and their
locations and can then use a trojaned library taking precedence over those
symbols to gain information or perform further exploitation. |
| Alerts: |
|
Comments (1 posted)
glibc: tempfile vulnerability in catchsegv script
| Package(s): | glibc |
CVE #(s): | CAN-2004-0968
|
| Created: | October 21, 2004 |
Updated: | November 14, 2005 |
| Description: |
The catchsegv script in the glibc package has a symlink vulnerability
that may allow a local user to overwrite arbitrary
files with the permissions of the user that is running the script. |
| Alerts: |
|
Comments (none posted)
gnupg: information leak
| Package(s): | gnupg |
CVE #(s): | CAN-2005-0366
|
| Created: | March 16, 2005 |
Updated: | August 19, 2005 |
| Description: |
GnuPG (and other PGP-like systems) suffers from an information leak which could, in some situations, be used by an attacker to obtain plain text from an encrypted message. See this message for a detailed explanation of the problem. "We know of no real-world application that is affected by this type of attack. It is an attack that requires the active participation of someone who holds the actual key required to decrypt a message. Thus, it is not something you are likely to see." |
| Alerts: |
|
Comments (none posted)
grip: buffer overflow
| Package(s): | grip |
CVE #(s): | CAN-2005-0706
|
| Created: | March 10, 2005 |
Updated: | September 16, 2005 |
| Description: |
Grip, a CD ripper, has a buffer overflow vulnerability that can
occur when the CDDB server returns more than 16 matches. |
| Alerts: |
|
Comments (none 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: |
|
Comments (none posted)
gtkhtml: malformed messages cause crash
| Package(s): | gtkhtml |
CVE #(s): | CAN-2003-0133
CAN-2003-0541
|
| Created: | April 14, 2003 |
Updated: | April 18, 2005 |
| Description: |
GtkHTML is the HTML rendering widget used by the Evolution mail reader.
GtkHTML supplied with versions of Evolution prior to 1.2.4 contain a bug
when handling HTML messages. Alan Cox discovered that certain malformed
messages could cause the Evolution mail component to crash. |
| Alerts: |
|
Comments (none 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: |
|
Comments (none posted)
imagemagick: format string vulnerability
| Package(s): | imagemagick |
CVE #(s): | CAN-2005-0397
|
| Created: | March 3, 2005 |
Updated: | April 4, 2005 |
| Description: |
The ImageMagick file
name handling code has a format string vulnerability.
Specially crafted file names can be used to crash ImageMagick
and possibly execute arbitrary code. |
| Alerts: |
|
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: |
|
Comments (none posted)
imlib2: buffer overflows
| Package(s): | imlib2 |
CVE #(s): | CAN-2004-0802
CAN-2004-0817
|
| Created: | September 8, 2004 |
Updated: | October 26, 2005 |
| Description: |
The imlib2 library contains buffer overflows in the BMP handling code. |
| Alerts: |
|
Comments (none posted)
IPsec-Tools: denial of service
| Package(s): | ipsec-tools setkey racoon |
CVE #(s): | CAN-2005-0398
|
| Created: | March 14, 2005 |
Updated: | April 5, 2005 |
| Description: |
The IPsec-Tools package is used to build other programs such as setkey and
racoon. There is a potential denial of service vulnerability when parsing
ISAKMP headers in racoon. |
| Alerts: |
|
Comments (none posted)
kdelibs: unsanitzied input
| Package(s): | kdelibs |
CVE #(s): | CAN-2004-1165
|
| Created: | January 10, 2005 |
Updated: | July 19, 2005 |
| Description: |
Thiago Macieira discovered a vulnerability in the kioslave library,
which is part of kdelibs, which allows a remote attacker to execute
arbitrary FTP commands via an ftp:// URL that contains an URL-encoded
newline before the FTP command. |
| Alerts: |
|
Comments (none posted)
kdelibs: dcopserver vulnerability
| Package(s): | kdelibs |
CVE #(s): | CAN-2005-0396
CAN-2005-0237
CAN-2005-0365
|
| Created: | March 17, 2005 |
Updated: | May 17, 2005 |
| Description: |
The KDE Desktop Communication Protocol daemon (dcopserver)
is vulnerable to lockup by a local user, leading to a denial
of service. |
| Alerts: |
|
Comments (none posted)
kernel: multiple vulnerabilities
Comments (none posted)
libdbi-perl: insecure temporary file