Dear All,
First of all, congratulations on getting the Lenny release out the
door! I understand that it was a lot of work, and you're probably
looking forward to at least somewhat of a break. So I don't want
to treat this problem with too much urgency (yet), but I would like to
get a dialog going as people find the time to weigh in with their
opinions.
In the following, I recap the core problems at hand (listed in terms of
importance/relevance) and the arguments on both sides that have been
developed in the bug report [1].
Summary of the problem: Some packages such as foo2zjs, pciutils,
ttf-mathematica4.1, etc. have components that download files external
to the Debian archives (from the internet) at runtime, which is
problematic in many ways.
1. Provides a potential avenue for introducing malicious software onto
users' systems
Argument: Since the standard checks and balances (digital signing of
packages by developers) is circumvented by fetching files from an
unreliable source, it is possible for an attacker to either hijack or
spoof the upstream site to introduce malicious software onto users'
systems. This may seem obscure, for example, for foo2zjs's printer
firmwares, but the getweb script does provide an update mechanism, so
the attacker could use that to introduce his malicious code.
Regardless of how obscure an attack vector may be, I just don't think
that it is worth the risk to allow it to remain open.
Rebuttal: "Since this script explicitely downloads stuff from an
author's webpage (and it is stated like that), the user knows the risk.
Are you proposing to call this a security issue? Then packages like
iceweasel are also affected and many others ..."
Response: The user may not, and likely does not, fully appreciate the
risk. I'm sure that most users trust that the Debian developer has
considered and appropriately mitigated the risk for them, or more
likely, they do not consider risk at all. They just use their
computer. Iceweasel is not a very good analogy because it is
generally not run as root and is not permitted to execute downloaded
files without a smart (chmod'ing) user involved.
2. Components of the package may stop working in the midst of a
stable release's lifetime
Argument: Since the location and composition of external files is
outside of the package maintainer's control, upstream changes can break
stable scripts.
Rebuttal: This is a simple bug. If it happens, "we'll fix it, full
stop."
Response: This may be a permissable fix for a stable point release,
but it leaves the system potentially broken for an indeterminant
amount of time (e.g. foo2zjs's getweb in etch was broken for over a
year) between those releases (depending on when the break happens).
This also depends on users' willingness to report bugs in stable. This
usually doesn't happen because people know that stable is stable and
doesn't get changed. It may also be possible to address this problem
via maintainence in volatile, but do they want to take on more
responsibility?
3. Allows packages in main to depend on external files, violating the
spirit of the Debian Policy
Argument: Section 2.2.1 of the Debian Policy Manual states that
"...packages in main must not require a package outside of main for
compilation or execution...," and section 2.2.2 states that "[e]xamples
of packages which would be included in contrib are free packages which
require contrib, non-free packages or packages which are not in our
archive at all for compilation or execution, ..." This seems to make
it very clear that external dependencies are unacceptable in terms of
"packages," but does not make clear the policy on general data and
files. However, given an honest attempt at interpretation, it would
seem that the same conclusion shoud apply equally to general files as
well as packages.
Rebuttal 1: This is a grey area of Debian Policy, and a litteral
interpretation of the manual says that the current behavior is OK.
Response 1: We shouldn't make judgements based solely on the wording as
written, but instead based on the original intent of the author (as
an aside, this is why the judicial branch's role in the government is
so complicated and controvercial). Just because the writer chose to use
the term "package" does not mean that they did not intend to cover all
files in general.
Rebuttal 2: Objection to single script packages (maintainers do not
want to maintain separate packages in contrib that contain only these
externally depending scripts).
Response 2: Decisions should not be made based on potential
inconveniences or work load. Besides, it is not that difficult to build
and maintain additional binary packages. The offending scripts can
remain within the original the source packages.
4. Parts of the package work as intended only under certain
circumstances
Argument: Since an internet connection is not guaranteed on the user's
end, the program does not work as intended when the net is either down
or unavailable. For example, a user with a printer supported by
foo2zjs's getweb will not be able to make that printer work if they use
their machine as a standalone. As much of Debian as possible should be
fully functional even when standalone. Hence, non-free components (if
they are to be supported at all) should be included in the non-free
archive instead of fetched externally.
Rebuttal: None yet.
5. Allows packages in main to potentially depend on non-free files
Argument: This is a hard argument to make, but since main is supposed
to be 100% free, it only makes sense that all dependencies shoud be
free as well.
Rebuttal 1: In the case of foo2zjs, the script is provided for
convenience for the user, it is not run as part of the maintainer
scripts, and the user can choose to not run it.
Response 1: This is a reasonable argument, but with 100% free software
as the goal for main and with decisions about non-free documentation
and firmware, doesn't it feel a bit like giving up when you're close
to the finish line? Scripts like this just seem to fit better under
contrib.
Rebuttal 2: "It doesn't matter how many people needs external files to
fully use foo2zjs: if only one person can use it without, then
everything which is completely DFSG-free *must* be in main. This is
another point, exactly like the firmware issues in the kernel: the
Intel iwl3945 driver is not usable on my ThinkPad X60 [4] without the
non-free firmware, yet the correct place for the driver is main."
Response 2: The number of users is irrelevent to whether components
should be considered free or not. Also, the permission for non-free
firmware to remain in main was a temporary compromise in order to get
the release out in a timely manner. Now that Lenny is done, decisions
should be made based on long-term goals, rather than short-term
compromises.
Rebuttal 3:
- getweb is an optional script included in the package that
can be used to download certain non-free files from the upstream
website.
- The script is not run by default from the maintainer scripts when
installing the package.
- Running the script is not required for the operation of the
package in the general case: the package has a significant use case
in terms of the printers it supports which don't require non-free
downloads, and probably even a majority use case (though I'm
personally not sure the latter is a distinction that should matter
for inclusion in main).
Response 3: These are all very good points, but why include a script
whose sole purpose is to fetch non-free files in main? That doesn't
seem like the right thing to do in the "free" archive. It seems much
more appropriate for contrib. vrms won't realize that you've got
non-free after you've run getweb even though you do.
Rebuttal 4: From debian-legal [2]: "It's commonly accepted that a
package can still be in main if only some part of it depends on non-main
software, and in this case there is not even such a dependency."
Response 4: This practice seems to violate the spirit of Debian's
Social Contract ("Debian will remain 100% free" in main), and I hope
that developers are not systemically ignoring such violations for
convenience.
Looking forward to a constructive conversation.
Best wishes,
Mike
[1] http://bugs.debian.org/449497
[2] http://lists.debian.org/debian-legal/2007/11/msg00103.html
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
