Re: Post-Lenny discussion on packages with external (potentially non-free) dependencies
Josselin Mouette wrote: Le mardi 17 février 2009 à 00:31 -0500, Michael S. Gilbert a écrit : 2. Components of the package may stop working in the midst of a stable release's lifetime This is a problem that affects much more than this kind of packages. All packages relying on an external service are affected. For example, it’s hard to expect the totem youtube plugin to keep working for the lifetime of the etch release. If we find a solution to this kind of issues, it should apply to all packages in this situation. Indeed, it's something to be discussed considering inclusion or not of the package in the main, volatile and backports archives. Maybe it's one of the discussions to put on the wiki page [1]? Cheers Luk [1] http://wiki.debian.org/DiscussionsAfterLenny -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Post-Lenny discussion on packages with external (potentially non-free) dependencies
Michael S. Gilbert wrote: 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. (...) [removing the long mail: too long to quote, too interesting to extract the best parts. my case (microcode.ctl): - the package is in contrib and not in main - I download only ascii file, converted to binary and feed to the kernel device only at loading time, so difficult to exploit - intel microcode is crypted, thus it is difficult to modify - user had the possibility to download the microcode manually and to put in the right position - no microcode no worrying: the computer work normally (but on new processors on a new family, with usually needs a lot of updates, but usually these are developer machine, not production machines.) - but with problem on distribution format. Intel (I think wrongly) changed the format (instead of a compressed file, it did a compressed tar of the file) thus breaking debian and ubuntu. - but with last versions, Intel changed (again) the microcode license (I think because of us [or better because of Ubuntu :'( ] ), so now microcode is distributed by a non-free package. The script to download microcode from intel side is only a convenience script. I could live (and I think also our user) fine, if I remove the script from postinst (BTW it was called after asking confirmation via debconf) - the microcode now could be installed also by the kernel firmware infrastructure, so I still had to decide a proper procedure with Intel and RedHat, and to debian firmware. After this the package will be a legacy only package. BTW: I still have the non-free.* domains, if Debian need it. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Post-Lenny discussion on packages with external (potentially non-free) dependencies
Le mardi 17 février 2009 à 00:31 -0500, Michael S. Gilbert a écrit : 2. Components of the package may stop working in the midst of a stable release's lifetime This is a problem that affects much more than this kind of packages. All packages relying on an external service are affected. For example, it’s hard to expect the totem youtube plugin to keep working for the lifetime of the etch release. If we find a solution to this kind of issues, it should apply to all packages in this situation. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and `-told that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Post-Lenny discussion on packages with external (potentially non-free) dependencies
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
Re: Post-Lenny discussion on packages with external (potentially non-free) dependencies
Michael S. Gilbert wrote: 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. If possible, the to be downloaded data should be packaged so most of below problems are solved or mitigated. 1. Provides a potential avenue for introducing malicious software onto users' systems Well, input validation is very common for web applications. The validation can consist of verifying the structure or a checksum etc, but should always be present IMHO. 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. If possible the package should self adjust to or give the user the opportunity to influence the location of the external files. Sometimes it's possible to fallback to a location under the maintainer's control so the package will continure to work. If that's not possible, the package should not be included in the stable release itself IMHO and people are encouraged to discuss the inclusion in the volatile archive. 3. Allows packages in main to depend on external files, violating the spirit of the Debian Policy Like Don explained it could be a convenience script, in that case the package is not really depending on the external files. Not packaging external files because it would be too small packages is not an argument IMHO as it could get included in the package itself in that case or similar things can be packaged together. 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. Well yes, depending on an internet connection should be avoided if possible. 5. Allows packages in main to potentially depend on non-free files If the functioning of the package needs the non-free files, it is not just a convenience script, and I would put the package in contrib. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
