Bug#392362: [PROPOSAL] Add should not embed code from other packages
Russ Allbery [EMAIL PROTECTED] writes: I'm not sure that the last bit really applies to Gnulib, and I'm not sure it's easily measured. I'm inclined to leave it off and just go with this: I have applied this version of the wording to my Policy arch repository. --- orig/policy.sgml +++ mod/policy.sgml @@ -2077,6 +2077,34 @@ the file to the list in filedebian/files/file./p /sect + sect id=embeddedfiles + headingConvenience copies of code/heading + + p + Some software packages include in their distribution convenience + copies of code from other software packages, generally so that + users compiling from source don't have to download multiple + packages. Debian packages should not make use of these + convenience copies unless the included package is explicitly + intended to be used in this way.footnote + For example, parts of the GNU build system work like this. + /footnote + If the included code is already in the Debian archive in the + form of a library, the Debian packaging should ensure that + binary packages reference the libraries already in Debian and + the convenience copy is not used. If the included code is not + already in Debian, it should be packaged separately as a + prerequisite if possible. + footnote + Having multiple copies of the same code in Debian is + inefficient, often creates either static linking or shared + library conflicts, and, most importantly, increases the + difficulty of handling security vulnerabilities in the + duplicated code. + /footnote + /p + /sect + /chapt -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
Colin Watson [EMAIL PROTECTED] writes: This has the unfortunate property of excluding Gnulib, which is a library of code explicitly designed by the GNU build system folks to live alongside the Autotools and be copied into packages to provide replacements for missing functions. Perhaps something like this would work? Debian packages should not make use of these convenience copies unless the intent of the other package is explicitly to be copied in this wayfootnoteFor example, parts of the GNU Build System work like this./footnote, and the other package provides a straightforward mechanism for keeping the copy up to date. I'm not sure that the last bit really applies to Gnulib, and I'm not sure it's easily measured. I'm inclined to leave it off and just go with this: --- orig/policy.sgml +++ mod/policy.sgml @@ -2077,6 +2077,34 @@ the file to the list in filedebian/files/file./p /sect + sect id=embeddedfiles + headingConvenience copies of code/heading + + p + Some software packages include in their distribution convenience + copies of code from other software packages, generally so that + users compiling from source don't have to download multiple + packages. Debian packages should not make use of these + convenience copies unless the included package is explicitly + intended to be used in this way.footnote + For example, parts of the GNU build system work like this. + /footnote + If the included code is already in the Debian archive in the + form of a library, the Debian packaging should ensure that + binary packages reference the libraries already in Debian and + the convenience copy is not used. If the included code is not + already in Debian, it should be packaged separately as a + prerequisite if possible. + footnote + Having multiple copies of the same code in Debian is + inefficient, often creates either static linking or shared + library conflicts, and, most importantly, increases the + difficulty of handling security vulnerabilities in the + duplicated code. + /footnote + /p + /sect + /chapt After all, simply satisfying this requirement doesn't give one a free pass through the security team evaluation, and they can always reject packages for other reasons. Unless there are any objections, I'll commit this for the next version, since I think we've pretty much reached consensus on it. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
Colin Watson writes (Bug#392362: [PROPOSAL] Add should not embed code from other packages): Gnulib in fact provides a number of other useful utility functions as well as simply replacement functions (e.g. xmalloc, xasprintf, compile_csharp_using_pnet, execute_java_class) so this assumption may well not be correct. When we find a /tmp handling vulnerability in gnulib, will we not have a serious problem ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
Ian Jackson [EMAIL PROTECTED] writes: Colin Watson writes: Gnulib in fact provides a number of other useful utility functions as well as simply replacement functions (e.g. xmalloc, xasprintf, compile_csharp_using_pnet, execute_java_class) so this assumption may well not be correct. When we find a /tmp handling vulnerability in gnulib, will we not have a serious problem ? The sort of functions that gnulib provides are generally not going to have this sort of problem, but yes. It's a worry. On the other hand, gnulib simply doesn't support a library model of use, and has a lot of infrastructure built up around *not* being used that way. To turn it into a library and modify source packages to link against it would be quite a bit of work on the Debian side that's not the direction that upstream is going. So I think we're on the bad end of that tradeoff. In the interest of getting *something* into Policy, even if it doesn't give us everything that we want, I'm inclined to accept Colin's suggestion and exempt cases where upstream intends the code to be embedded and not used as a separate library. It means that Policy won't be helping with a few of our annoying cases, but at least we say something about the general case and the specific cases can still be dealt with on a case-by-case basis the way that we do now. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Wed, Dec 05, 2007 at 05:08:49PM +, Colin Watson wrote: This has the unfortunate property of excluding Gnulib, which is a library of code explicitly designed by the GNU build system folks to live alongside the Autotools and be copied into packages to provide replacements for missing functions. Perhaps something like this would work? I expect that on a Sid system, there will be no missing functions to replace, so Gnulib will not actually embed code. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Wed, Dec 05, 2007 at 06:26:17PM +0100, Bill Allombert wrote: On Wed, Dec 05, 2007 at 05:08:49PM +, Colin Watson wrote: This has the unfortunate property of excluding Gnulib, which is a library of code explicitly designed by the GNU build system folks to live alongside the Autotools and be copied into packages to provide replacements for missing functions. Perhaps something like this would work? I expect that on a Sid system, there will be no missing functions to replace, so Gnulib will not actually embed code. Gnulib in fact provides a number of other useful utility functions as well as simply replacement functions (e.g. xmalloc, xasprintf, compile_csharp_using_pnet, execute_java_class) so this assumption may well not be correct. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Thu, Nov 29, 2007 at 09:02:43PM -0800, Russ Allbery wrote: Okay, here's yet another try at the wording for this that tries to exclude Autotools and friends without making the wording too awkward. Word-smithing welcome (as are any other comments). --- orig/policy.sgml +++ mod/policy.sgml @@ -2077,6 +2077,32 @@ the file to the list in filedebian/files/file./p /sect + sect id=embeddedfiles + headingConvenience copies of code/heading + + p + Some software packages include in their distribution convenience + copies of code from other software packages, generally so that + users compiling from source don't have to download multiple + packages. Debian packages should not make use of these + convenience copies unless they are used only during the package + build and are not included or linked into generated binary + packages. This has the unfortunate property of excluding Gnulib, which is a library of code explicitly designed by the GNU build system folks to live alongside the Autotools and be copied into packages to provide replacements for missing functions. Perhaps something like this would work? Debian packages should not make use of these convenience copies unless the intent of the other package is explicitly to be copied in this wayfootnoteFor example, parts of the GNU Build System work like this./footnote, and the other package provides a straightforward mechanism for keeping the copy up to date. Alternatively, maybe we might want to explicitly sign off on exceptions somehow. I can see that the security team might not be terribly happy about supporting libinsecure by Inexperienced Developer [EMAIL PROTECTED] who thinks everyone should copy his library into their own programs ... -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
Bill Allombert [EMAIL PROTECTED] writes: On Thu, Nov 29, 2007 at 09:02:43PM -0800, Russ Allbery wrote: Okay, here's yet another try at the wording for this that tries to exclude Autotools and friends without making the wording too awkward. Word-smithing welcome (as are any other comments). I am not objecting to this wording, but I am afraid it covers situation where there is no easy solution, in particular, it does not offer solutions when the convenience copy is not a library. I think that generally, the severity of a policy violation should differ whether there is an 'easy' way out or not. However, it might be that the word 'convenience copy' address this concerns. (A embedded copy is a convenience copy as long as you could reasonnably do without it). Yeah, I think the convenience word does help there. For example, I share some common support code between multiple packages, but I wouldn't consider this requirement relevant to that, since it's not a convenience copy of code from other packages. It's code that just happens to be duplicated across multiple packages but which has no independent existence (and different packages often have subtlely different versions). Also, this is where should comes in; if there's a good reason not to do it, one can not do it. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On pe, 2007-11-30 at 11:59 +0100, Bill Allombert wrote: On Thu, Nov 29, 2007 at 09:02:43PM -0800, Russ Allbery wrote: Okay, here's yet another try at the wording for this that tries to exclude Autotools and friends without making the wording too awkward. Word-smithing welcome (as are any other comments). I am not objecting to this wording, but I am afraid it covers situation where there is no easy solution, Policy does not override common sense, of course. If Policy prescribes something that is technically bad for a particular package, the package maintainer has the ability to document why Policy is wrong in that case, and do the right thing instead. So I would not worry too much about this in this instance. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Thu, Nov 29, 2007 at 09:02:43PM -0800, Russ Allbery wrote: Okay, here's yet another try at the wording for this that tries to exclude Autotools and friends without making the wording too awkward. Word-smithing welcome (as are any other comments). I am not objecting to this wording, but I am afraid it covers situation where there is no easy solution, in particular, it does not offer solutions when the convenience copy is not a library. I think that generally, the severity of a policy violation should differ whether there is an 'easy' way out or not. However, it might be that the word 'convenience copy' address this concerns. (A embedded copy is a convenience copy as long as you could reasonnably do without it). Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
Okay, here's yet another try at the wording for this that tries to exclude Autotools and friends without making the wording too awkward. Word-smithing welcome (as are any other comments). --- orig/policy.sgml +++ mod/policy.sgml @@ -2077,6 +2077,32 @@ the file to the list in filedebian/files/file./p /sect + sect id=embeddedfiles + headingConvenience copies of code/heading + + p + Some software packages include in their distribution convenience + copies of code from other software packages, generally so that + users compiling from source don't have to download multiple + packages. Debian packages should not make use of these + convenience copies unless they are used only during the package + build and are not included or linked into generated binary + packages. If the included code is already in the Debian archive + in the form of a library, the Debian packaging should ensure + that binary packages reference the libraries already in Debian + and the convenience copy is not used. If the included code is + not already in Debian, it should be packaged separately as a + prerequisite if possible. + footnote + Having multiple copies of the same code in Debian is + inefficient, often creates either static linking or shared + library conflicts, and, most importantly, increases the + difficulty of handling security vulnerabilities in the + duplicated code. + /footnote + /p + /sect + /chapt -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Mon, Jul 16, 2007 at 11:57:18PM +0200, Kurt Roeckx wrote: On Wed, Jul 04, 2007 at 12:22:42PM -0700, Russ Allbery wrote: Steve Langasek [EMAIL PROTECTED] writes: Perhaps common code or duplicated code instead of shared code, to avoid ambiguity wrt shared libraries? How about duplicated code? New patch: I would like to stress the point that is is better to get a limited version of this in the policy and then expand it with hindsight than to try to cover all cases from the start. I have 2 comments about this: - It was suggested that this shouldn't only cover libraries. This version still only takes about libraries. When I wrote this, I meant library in the general sense, not in the shared library sense to cover perl, python, php, ruby, haskell modules etc. A library being a piece of code set up to be used in a larger programm rather than on its own. I find the wording convenience copy of library from other software packages much more telling than convenience copy of code from other software packages that could be misinterpreted. For example, a lot of packages include a convenience copy of scripts part of automake (install-sh, depcomp, etc.). The sentence Debian packages should not make use of these convenience copies. seems to imply that they should not be used. - Some packages contain a forked version of a library. Policy should say to try and merge them in the Debian package. This might not work for all packages since the changes aren't compatible, in which case I see 2 options: - Keep it internal and link staticly - Make a seperate source package of it. It would be nice if policy suggested one of those approaches. But I'm not really sure this belongs in policy. This is a non-Debian-specific best practice, so probably does not belong in policy. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
Bill Allombert [EMAIL PROTECTED] writes: I find the wording convenience copy of library from other software packages much more telling than convenience copy of code from other software packages that could be misinterpreted. For example, a lot of packages include a convenience copy of scripts part of automake (install-sh, depcomp, etc.). The sentence Debian packages should not make use of these convenience copies. seems to imply that they should not be used. Bleh. That's a valid point and I'm not sure how to deal with it without going back to the previous wording. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
Kurt Roeckx [EMAIL PROTECTED] writes: On Wed, Jul 04, 2007 at 12:22:42PM -0700, Russ Allbery wrote: Steve Langasek [EMAIL PROTECTED] writes: Perhaps common code or duplicated code instead of shared code, to avoid ambiguity wrt shared libraries? How about duplicated code? New patch: I have 2 comments about this: - It was suggested that this shouldn't only cover libraries. This version still only takes about libraries. A valid point. See a proposed new wording patch below which uses code instead of libraries and tries to be more general. Does this look good to you? And do the other people who reviewed the previous wording proposals have any objections? - Some packages contain a forked version of a library. Policy should say to try and merge them in the Debian package. This might not work for all packages since the changes aren't compatible, in which case I see 2 options: - Keep it internal and link staticly - Make a seperate source package of it. It would be nice if policy suggested one of those approaches. But I'm not really sure this belongs in policy. I can see wanting to do one of those things in some cases and another in other cases. I think the wording below encourages the separate source package where possible, but allows for the internal use and static linkage where it isn't, which from a Policy perspective is probably the best that we can do. --- orig/policy.sgml +++ mod/policy.sgml @@ -2077,6 +2077,30 @@ the file to the list in filedebian/files/file./p /sect + sect id=embeddedfiles + headingConvenience copies of code/heading + + p + Some software packages include in their distribution convenience + copies of code from other software packages, generally so that + users compiling from source don't have to download multiple + packages. Debian packages should not make use of these + convenience copies. If the included code is already in the + Debian archive in the form of a library, the Debian packaging + should ensure that binary packages reference the libraries + already in Debian and the convenience copy is not used. If the + included code is not already in Debian, it should be packaged + separately as a prerequisite if possible. + footnote + Having multiple copies of the same code in Debian is + inefficient, often creates either static linking or shared + library conflicts, and, most importantly, increases the + difficulty of handling security vulnerabilities in the + duplicated code. + /footnote + /p + /sect + /chapt -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Mon, Aug 06, 2007 at 12:08:04AM -0700, Russ Allbery wrote: --- orig/policy.sgml +++ mod/policy.sgml @@ -2077,6 +2077,30 @@ the file to the list in filedebian/files/file./p /sect + sect id=embeddedfiles + headingConvenience copies of code/heading + + p + Some software packages include in their distribution convenience + copies of code from other software packages, generally so that + users compiling from source don't have to download multiple + packages. Debian packages should not make use of these + convenience copies. If the included code is already in the + Debian archive in the form of a library, the Debian packaging + should ensure that binary packages reference the libraries + already in Debian and the convenience copy is not used. If the + included code is not already in Debian, it should be packaged + separately as a prerequisite if possible. + footnote + Having multiple copies of the same code in Debian is + inefficient, often creates either static linking or shared + library conflicts, and, most importantly, increases the + difficulty of handling security vulnerabilities in the + duplicated code. + /footnote + /p + /sect + /chapt I second this proposal. Kurt signature.asc Description: Digital signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Wed, Jul 04, 2007 at 12:22:42PM -0700, Russ Allbery wrote: Steve Langasek [EMAIL PROTECTED] writes: Perhaps common code or duplicated code instead of shared code, to avoid ambiguity wrt shared libraries? How about duplicated code? New patch: I have 2 comments about this: - It was suggested that this shouldn't only cover libraries. This version still only takes about libraries. - Some packages contain a forked version of a library. Policy should say to try and merge them in the Debian package. This might not work for all packages since the changes aren't compatible, in which case I see 2 options: - Keep it internal and link staticly - Make a seperate source package of it. It would be nice if policy suggested one of those approaches. But I'm not really sure this belongs in policy. Kurt --- orig/policy.sgml +++ mod/policy.sgml @@ -2077,6 +2077,30 @@ the file to the list in filedebian/files/file./p /sect + sect id=embeddedfiles + headingConvenience copies of libraries/heading + + p + Some software packages include in their distribution convenience + copies of libraries from other software packages, generally so + that users compiling from source don't have to download multiple + packages. Debian packages should not make use of these + convenience copies. If the included library is already in the + Debian archive, the Debian packaging should ensure that binary + packages reference the libraries already in Debian and the + convenience copy is not used. If the included library is not + already in Debian, it should be packaged separately as a + prerequisite. + footnote + Having multiple copies of the same code in Debian is + inefficient, often creates either static linking or shared + library conflicts, and, most importantly, increases the + difficulty of handling security vulnerabilities in the + duplicated code. + /footnote + /p + /sect + /chapt -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
Neil McGovern [EMAIL PROTECTED] writes: On Tue, Jun 26, 2007 at 08:36:51AM -0700, Russ Allbery wrote: Some software packages include in their distribution convenience copies of libraries from other software packages, generally so that users compiling from source don't have to download multiple packages. Debian packages should not make use of these convenience copies. If the included library is already in the Debian archive, the Debian packaging should ensure that the software is linked with the libraries already in Debian and the convenience copy is not used. If the included library is not already in Debian, it should be packaged separately as a prerequisite. I've tried to stay away from compile type language (and to some extent 'link') as it's not only C* programs that this effects. Having multiple copies of the same code in Debian is inefficient, often creates either static linking or shared library conflicts, and, most importantly, increases the difficulty of handling security vulnerabilities in the shared code. Hrm... does rationale belong in policy? I like the wording though :) Here's a proposed patch based on that wording, with the correction already previously noted. Comments? --- orig/policy.sgml +++ mod/policy.sgml @@ -2077,6 +2077,30 @@ the file to the list in filedebian/files/file./p /sect + sect id=embeddedfiles + headingConvenience copies of libraries/heading + + p + Some software packages include in their distribution convenience + copies of libraries from other software packages, generally so + that users compiling from source don't have to download multiple + packages. Debian packages should not make use of these + convenience copies. If the included library is already in the + Debian archive, the Debian packaging should ensure that binary + packages reference the libraries already in Debian and the + convenience copy is not used. If the included library is not + already in Debian, it should be packaged separately as a + prerequisite. + footnote + Having multiple copies of the same code in Debian is + inefficient, often creates either static linking or shared + library conflicts, and, most importantly, increases the + difficulty of handling security vulnerabilities in the shared + code. + /footnote + /p + /sect + /chapt -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Wed, Jul 04, 2007 at 01:00:39AM -0700, Russ Allbery wrote: + footnote + Having multiple copies of the same code in Debian is + inefficient, often creates either static linking or shared + library conflicts, and, most importantly, increases the + difficulty of handling security vulnerabilities in the shared + code. Perhaps common code or duplicated code instead of shared code, to avoid ambiguity wrt shared libraries? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
Steve Langasek [EMAIL PROTECTED] writes: Perhaps common code or duplicated code instead of shared code, to avoid ambiguity wrt shared libraries? How about duplicated code? New patch: --- orig/policy.sgml +++ mod/policy.sgml @@ -2077,6 +2077,30 @@ the file to the list in filedebian/files/file./p /sect + sect id=embeddedfiles + headingConvenience copies of libraries/heading + + p + Some software packages include in their distribution convenience + copies of libraries from other software packages, generally so + that users compiling from source don't have to download multiple + packages. Debian packages should not make use of these + convenience copies. If the included library is already in the + Debian archive, the Debian packaging should ensure that binary + packages reference the libraries already in Debian and the + convenience copy is not used. If the included library is not + already in Debian, it should be packaged separately as a + prerequisite. + footnote + Having multiple copies of the same code in Debian is + inefficient, often creates either static linking or shared + library conflicts, and, most importantly, increases the + difficulty of handling security vulnerabilities in the + duplicated code. + /footnote + /p + /sect + /chapt -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Wed, Jul 04, 2007 at 12:22:42PM -0700, Russ Allbery wrote: Perhaps common code or duplicated code instead of shared code, to avoid ambiguity wrt shared libraries? How about duplicated code? New patch: Looks good to me. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Mon, Jun 25, 2007 at 05:33:53PM +0200, Bill Allombert wrote: Any suggestions for improved wording? If this is that what you want, then I will certainly not object, but the current draft seems to imply something else. Especially the expected meaning of package does not seems to capture what you need. How's this version? (attached) Neil -- * hermanr feels like a hedgehog having sex... --- policy.sgml 2006-10-11 08:44:02.684306000 +0100 +++ policy.sgml 2007-06-26 13:58:10.160026885 +0100 @@ -2105,6 +2105,19 @@ the file to the list in filedebian/files/file./p /sect +sect id=embeddedfiles + headingEmbedding code provided in other packages/heading + p + Should the upstream source ship with a convenience copy of an external + library, and this library is already packaged in Debian, the Debian + package should not embed or include this code. + Instead, the package should be modified to reference the required + files in the library package provided by Debian, and a Depends and/or + Build-Depends relationship declared as required. + Optionally, the convenience copy should not be compiled in the + build-process. + /p + /sect /chapt signature.asc Description: Digital signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Tue, Jun 26, 2007 at 01:59:58PM +0100, Neil McGovern wrote: On Mon, Jun 25, 2007 at 05:33:53PM +0200, Bill Allombert wrote: Any suggestions for improved wording? --- policy.sgml 2006-10-11 08:44:02.684306000 +0100 +++ policy.sgml 2007-06-26 13:58:10.160026885 +0100 @@ -2105,6 +2105,19 @@ the file to the list in filedebian/files/file./p /sect +sect id=embeddedfiles + headingEmbedding code provided in other packages/heading + p + Should the upstream source ship with a convenience copy of an external + library, and this library is already packaged in Debian, the Debian + package should not embed or include this code. + Instead, the package should be modified to reference the required + files in the library package provided by Debian, and a Depends and/or + Build-Depends relationship declared as required. + Optionally, the convenience copy should not be compiled in the + build-process. + /p + /sect /chapt Two comments: 1) this library is already packaged in Debian: If it is not packaged, it should be packaged instead of using the convenience copy. Otherwise three problems can appear: 1.1) if the library is packaged separately afterward. 1.2) if two packages include independently a convenience copy of the same library. 1.3) the security team might miss security issues in a library if it is not packaged but only used through a convenience copy. The keyword is convenience here: it does not apply to copy shipped as part of a larger tarball as the main distribution medium. 2) Optionally ... should not seems internally inconsistent. I would expect either Optionally ... may not or Preferably,... should not and I would prefer the second because compiling librairies we won't use is a waste of time and might cause linking inadvertently to them instead of the system one. But I certainly lift my objection. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. signature.asc Description: Digital signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Tue, Jun 26, 2007 at 04:54:31PM +0200, Bill Allombert wrote: Updated :) 1) this library is already packaged in Debian: Removed 2) Optionally ... should not seems internally inconsistent. Changed to: Preferably,... should not But I certainly lift my objection. Great :) Not sure if these changes need re-seconding now though. Any thoughts from people on the list? Neil -- Maulkin Damned Inselaffen. Oh, wait, that's me. signature.asc Description: Digital signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
Neil McGovern [EMAIL PROTECTED] writes: How's this version? (attached) Neil -- * hermanr feels like a hedgehog having sex... --- policy.sgml 2006-10-11 08:44:02.684306000 +0100 +++ policy.sgml 2007-06-26 13:58:10.160026885 +0100 @@ -2105,6 +2105,19 @@ the file to the list in filedebian/files/file./p /sect +sect id=embeddedfiles + headingEmbedding code provided in other packages/heading + p + Should the upstream source ship with a convenience copy of an external + library, and this library is already packaged in Debian, the Debian + package should not embed or include this code. + Instead, the package should be modified to reference the required + files in the library package provided by Debian, and a Depends and/or + Build-Depends relationship declared as required. + Optionally, the convenience copy should not be compiled in the + build-process. + /p + /sect /chapt I find this wording a little confusing in that I can't figure out whether it implies the Debian maintainer should remove the embedded external library from the upstream source tarball (which I don't think is what you meant). The last line in particular seems to present as an alternative the approach that I'd expect to be the most common. Something like: Some software packages include in their distribution convenience copies of libraries from other software packages, generally so that users compiling from source don't have to download multiple packages. Debian packages should not make use of these convenience copies. If the included library is already in the Debian archive, the Debian packaging should ensure that the software is linked with the libraries already in Debian and the convenience copy is not used. If the included library is not already in Debian, it should be packaged separately as a prerequisite. Having multiple copies of the same code in Debian is inefficient, often creates either static linking or shared library conflicts, and, most importantly, increases the difficulty of handling security vulnerabilities in the shared code. perhaps? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Tuesday 26 June 2007 18:15:47 Neil McGovern wrote: Great :) Not sure if these changes need re-seconding now though. well, if there's any possibility that they do, consider them re-seconded :) sean signature.asc Description: This is a digitally signed message part.
Bug#392362: [PROPOSAL] Add should not embed code from other packages
Bill Allombert wrote: On Tue, Jun 26, 2007 at 01:59:58PM +0100, Neil McGovern wrote: On Mon, Jun 25, 2007 at 05:33:53PM +0200, Bill Allombert wrote: Two comments: 1) this library is already packaged in Debian: If it is not packaged, it should be packaged instead of using the convenience copy. Otherwise three problems can appear: 1.1) if the library is packaged separately afterward. 1.2) if two packages include independently a convenience copy of the same library. 1.3) the security team might miss security issues in a library if it is not packaged but only used through a convenience copy. The keyword is convenience here: it does not apply to copy shipped as part of a larger tarball as the main distribution medium. A convenience copy is AFAIK always part of the upstream tarball. The main reason for not using convenience copies is security related IMHO and not package size or having (a possibly other version of) the same library (package) available at some point. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Tue, Jun 26, 2007 at 08:36:51AM -0700, Russ Allbery wrote: Something like: Some software packages include in their distribution convenience copies of libraries from other software packages, generally so that users compiling from source don't have to download multiple packages. Debian packages should not make use of these convenience copies. If the included library is already in the Debian archive, the Debian packaging should ensure that the software is linked with the libraries already in Debian and the convenience copy is not used. If the included library is not already in Debian, it should be packaged separately as a prerequisite. Having multiple copies of the same code in Debian is inefficient, often creates either static linking or shared library conflicts, and, most importantly, increases the difficulty of handling security vulnerabilities in the shared code. perhaps? I'm seconding this proposal. It seem to be worded much better. Kurt signature.asc Description: Digital signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Tue, Jun 26, 2007 at 03:43:14PM -0700, Russ Allbery wrote: This is one of the things that was discussed at the Policy BoF at DebConf, and Manoj and I would both like to start adding it. In the future, we'll be doing so in a new format that allows rationale to be tagged separately and marked as informative rather than normative. But it's very valuable to have rationale so that years later we can figure out why we changed something. (See the difficulties in figuring out just why Policy requires -D_REENTRANT, for example.) Good point. I tried to make that BoF, but was a bit busy running around madly :| New patch attached. Neil -- twb I don't see why anyone would want to cyber with a 16yo. IME none of them can spell, and they probably haven't had the relevant experience to write convincing prose. It's not like their ASCII is going to be any more supple for them being sixteen. --- /usr/share/doc/debian-policy/policy.sgml 2006-10-11 08:44:02.684306000 +0100 +++ ./policy.sgml 2007-06-26 17:12:56.325983530 +0100 @@ -2105,6 +2105,18 @@ the file to the list in filedebian/files/file./p /sect +sect id=embeddedfiles + headingEmbedding code provided in other packages/heading + p + Should the upstream source ship with a convenience copy of an external + library, the Debian package should not embed or include this code. + Instead, the package should be modified to reference the required + files in the library package provided by Debian, and a Depends and/or + Build-Depends relationship declared as required. + Preferably, the convenience copy should not be compiled in the + build-process. + /p + /sect /chapt signature.asc Description: Digital signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Mon, Jun 18, 2007 at 07:27:43PM +0200, Bill Allombert wrote: On Mon, Jun 18, 2007 at 03:59:12PM +0200, Stefan Fritsch wrote: I second Neil's proposal from Sun, 15 Oct 2006 09:49:58, i.e. the latest version. and I have to object to it because the proposal seems to mix build-time and run-time dependencies. At least I did not get an answer to my later post on the subject. It should be clarified whether the proposal apply to source packages and build-dependencies or binary packages and run-time dependencies. I don't think it does. The proposal is for source packages, and a run-time (well, install time) dependancy should be declared on the relevent lib* package. I'm not sure there's a need to explicitly state that a lib*-dev builddep should be declared, as the package will FTBFS if it can't find that libraries it needs. Any suggestions for improved wording? And I did reply to your last mail, copying here at the end :) Cheers, Neil snip - In that case, I suggest you change package by source package and Depends by Build-Depends. Or am I missing something ? Well, this section is an amendment to the source package section. Essentially, there's been a large number of packages recently that embed code from other packages in their own. Included in this is static complilation, but this seems to be covered by another bit of policy. We want to avoid packages shipping their own versions of libraries, as then if a security problem or major bug is discovered in that library, we have lots of packages to update, and there's no garuntee we'll even know which packages it affects. snip - -- weasel dpkg: shut up dpkg No, I won't, and you can't make me. :P weasel hah. _I_ can signature.asc Description: Digital signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Mon, Jun 25, 2007 at 02:02:21PM +0100, Neil McGovern wrote: On Mon, Jun 18, 2007 at 07:27:43PM +0200, Bill Allombert wrote: On Mon, Jun 18, 2007 at 03:59:12PM +0200, Stefan Fritsch wrote: I second Neil's proposal from Sun, 15 Oct 2006 09:49:58, i.e. the latest version. and I have to object to it because the proposal seems to mix build-time and run-time dependencies. At least I did not get an answer to my later post on the subject. It should be clarified whether the proposal apply to source packages and build-dependencies or binary packages and run-time dependencies. I don't think it does. The proposal is for source packages, and a run-time (well, install time) dependancy should be declared on the relevent lib* package. I'm not sure there's a need to explicitly state that a lib*-dev builddep should be declared, as the package will FTBFS if it can't find that libraries it needs. Any suggestions for improved wording? If this is that what you want, then I will certainly not object, but the current draft seems to imply something else. Especially the expected meaning of package does not seems to capture what you need. I think you should clarify that: 1) This is meant to apply to source packages where upstream include convenience copy of external libraries (in the large sense) that are normally distributed as stand-alone tarball, and where the build-process link against the convenience copy of the libraries (instead of the system one). 2) The package should build against the libraries as provided by Debian and not the convenience copy. Preferably, the convenience copy should not even be compiled in the build-process. +sect id=embeddedfiles + headingEmbedding code provided in other packages/heading + p + A package should not embed or include code from other + packages. Instead, the package should be modified to reference the + required files provided by the other package, and a Depends + relationship declared./p + /sect /chapt Suppose the upstream tarball of foo include a copy of libjpeg and link statically the program against it. It is not obvious that package foo embed or include code from package libjpeg. Some one could think precisely it doesn't since it uses its own copy of libjpeg. On the other hand, bar is compiled staticaly against libjpeg. I am sure some one would say bar include code from libjpeg. By no mean do I want to encourage static linking, but it does not seems to be what you had in mind, and forbidding static linking has other issues that it is best to address separately. In any case it is too generic this way. And I did reply to your last mail, copying here at the end :) Sorry I missed it, then. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
I second Neil's proposal from Sun, 15 Oct 2006 09:49:58, i.e. the latest version. Stefan pgp89ONN0IXjc.pgp Description: PGP signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Mon, Jun 18, 2007 at 03:59:12PM +0200, Stefan Fritsch wrote: I second Neil's proposal from Sun, 15 Oct 2006 09:49:58, i.e. the latest version. and I have to object to it because the proposal seems to mix build-time and run-time dependencies. At least I did not get an answer to my later post on the subject. It should be clarified whether the proposal apply to source packages and build-dependencies or binary packages and run-time dependencies. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. signature.asc Description: Digital signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
Chris Waters wrote: We want to avoid packages shipping their own versions of libraries, as then if a security problem or major bug is discovered in that library, we have lots of packages to update, and there's no garuntee we'll even know which packages it affects. I don't know if it can always be avoided. In any case it should be mandatory that these embedded code copies need to be documented by maintainers, preferably in a central place. Many cases of embedded code copies have only been discovered by accident and the Security Team can't keep track of the whole archive. In theory each maintainer and upstream should monitor security-related changes in such embedded copies, in practice is just fails. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Sun, Oct 15, 2006 at 09:13:11PM +0100, Neil McGovern wrote: On Sun, Oct 15, 2006 at 11:57:47AM -0700, Chris Waters wrote: I don't know if it can always be avoided. [snip lots of good examples where this is unavoidable] I would go for strongly discouraging the practice, but I think that flat-out forbidding it might be excessive at this point. Hence this being should not, rather than must not. We're aware that it's not alwars possible, and you phrased it wonderfully. We want to strongly discourage it, rather than flat-out forbidding it :) Should not says that it's always a bug--just not an RC bug. I'm saying that perhaps sometimes it's not a bug. Although I strongly agree that it should _usually_ be a bug. In fact, as the tcl/tk maintainer, I have a vested interest in making it always be a bug. But I'm trying to bend over backwards to be fair to my dependents...or non-dependents, as the case may be. I would love to see perl-tk built against my packages. But I realize there are valid reasons why it's currently not. Anyway, I'm not going to formally object or anything. I just wanted to toss the notion out and see what happened. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Mon, 16 Oct 2006, Chris Waters wrote: Should not says that it's always a bug--just not an RC bug. I'm saying that perhaps sometimes it's not a bug. Although I strongly agree that it should _usually_ be a bug. I really can't imagine when it would not be a bug; in some cases, it may just be a wishlist or minor bug because the libraries don't expose the proper interfaces or need to be modified before being compiled. In either case, the proper solution is to eventually fix the interfaces or library so the extra code can be jettisoned. Don Armstrong -- What I can't stand is the feeling that my brain is leaving me for someone more interesting. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Sat, Oct 14, 2006 at 05:30:10PM +0100, Neil McGovern wrote: On Wed, Oct 11, 2006 at 11:45:39AM +0100, Neil McGovern wrote: I'm including a patch that adds a should not to policy. Now updated, removed C-ism and fix some typos. And this time *with* the patch... Neil -- * hermanr feels like a hedgehog having sex... --- policy.sgml +++ policy.sgml @@ -2105,6 +2105,14 @@ the file to the list in filedebian/files/file./p /sect +sect id=embeddedfiles + headingEmbedding code provided in other packages/heading + p + A package should not embed or include code from other + packages. Instead, the package should be modified to reference the + required files provided by the other package, and a Depends + relationship declared./p + /sect /chapt signature.asc Description: Digital signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Sun, Oct 15, 2006 at 11:16:47AM +0200, Bill Allombert wrote: On Sun, Oct 15, 2006 at 09:49:58AM +0100, Neil McGovern wrote: --- policy.sgml +++ policy.sgml @@ -2105,6 +2105,14 @@ the file to the list in filedebian/files/file./p /sect +sect id=embeddedfiles + headingEmbedding code provided in other packages/heading + p + A package should not embed or include code from other + packages. Instead, the package should be modified to reference the + required files provided by the other package, and a Depends + relationship declared./p + /sect /chapt This does not address my concern. Every compiled C programs embed code from the C library headers file but should not Depend on libc6-dev. However, every C program doesn't ship with it's own version of the C library header files, which is what we're trying to avoid. Neil -- 02:14:04 stockholm crap. my squirrelmail does not work 02:14:07 stockholm Maulkin: ping signature.asc Description: Digital signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Sun, Oct 15, 2006 at 09:49:58AM +0100, Neil McGovern wrote: --- policy.sgml +++ policy.sgml @@ -2105,6 +2105,14 @@ the file to the list in filedebian/files/file./p /sect +sect id=embeddedfiles + headingEmbedding code provided in other packages/heading + p + A package should not embed or include code from other + packages. Instead, the package should be modified to reference the + required files provided by the other package, and a Depends + relationship declared./p + /sect /chapt This does not address my concern. Every compiled C programs embed code from the C library headers file but should not Depend on libc6-dev. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Sun, Oct 15, 2006 at 10:44:10AM +0100, Neil McGovern wrote: +sect id=embeddedfiles + headingEmbedding code provided in other packages/heading + p + A package should not embed or include code from other + packages. Instead, the package should be modified to reference the + required files provided by the other package, and a Depends + relationship declared./p + /sect /chapt This does not address my concern. Every compiled C programs embed code from the C library headers file but should not Depend on libc6-dev. However, every C program doesn't ship with it's own version of the C library header files, which is what we're trying to avoid. In that case, I suggest you change package by source package and Depends by Build-Depends. Or am I missing something ? In the example above, the binary package does embed code from the C header file. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Sun, Oct 15, 2006 at 12:04:20PM +0200, Bill Allombert wrote: On Sun, Oct 15, 2006 at 10:44:10AM +0100, Neil McGovern wrote: +sect id=embeddedfiles + headingEmbedding code provided in other packages/heading + p + A package should not embed or include code from other + packages. Instead, the package should be modified to reference the + required files provided by the other package, and a Depends + relationship declared./p + /sect /chapt This does not address my concern. Every compiled C programs embed code from the C library headers file but should not Depend on libc6-dev. However, every C program doesn't ship with it's own version of the C library header files, which is what we're trying to avoid. In that case, I suggest you change package by source package and Depends by Build-Depends. Or am I missing something ? Well, this section is an amendment to the source package section. Essentially, there's been a large number of packages recently that embed code from other packages in their own. Included in this is static complilation, but this seems to be covered by another bit of policy. We want to avoid packages shipping their own versions of libraries, as then if a security problem or major bug is discovered in that library, we have lots of packages to update, and there's no garuntee we'll even know which packages it affects. Cheers, Neil -- * stockholm calls netapp * stockholm calls someone else Ganneff you are typing random numbers on your phone? stockholm yes. my newest attempt to close our budget hole signature.asc Description: Digital signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Wed, 11 Oct 2006, Bill Allombert wrote: I am not sure we can realistically add a requirement higher than: A package should not link against copy of libraries packaged separately by Debian. Any needless code duplication is bad, be it in libraries, perl or python modules, or even things like documentation. I don't have a better suggestion for verbiage at this point, but packages should not be duplicating code that is present in other packages, especially when already established mechanisms are in place to utilize that code without duplication. [Actually having the code duplicated in the upstream source may not be so bad, but it definetly should not be used to build the binary package.] Of course, it's true that this would be a should directive; things that fail to meet it are buggy, but it's not an RC bug. Don Armstrong -- Clint why the hell does kernel-source-2.6.3 depend on xfree86-common? infinity It... Doesn't? Clint good point http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Sun, Oct 15, 2006 at 11:24:22AM +0100, Neil McGovern wrote: We want to avoid packages shipping their own versions of libraries, as then if a security problem or major bug is discovered in that library, we have lots of packages to update, and there's no garuntee we'll even know which packages it affects. I don't know if it can always be avoided. The perl-tk package, for example, embeds its own versions of tcl and tk, but that's an upstream choice. Basically, they maintain their own fork. On the one hand, if a hole is found in tcl or tk, it might go unnoticed in perl-tk BUT on the other hand, there's no guarantee that any other version of tcl or tk will even work with perl-tk! Can we force perl-tk upstream to merge their fork? I doubt it would be easy, but you're welcome to try. Should we re-fork perl-tk on our own? That sounds like madness, but you're welcome to try. In either case, though, I think there's a whole lot of required work before perl-tk could be brought in line with this proposal. Also, some libraries come with compile-time options, and a particular package may need a version built with different options than the main version of the library in Debian. Ideally, we would provide an alternate version of the library package, but it's not always that easy. I would go for strongly discouraging the practice, but I think that flat-out forbidding it might be excessive at this point. At the very least, I think we should get some feedback from the people who are engaging in this practice before passing any absolute bans. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Sun, Oct 15, 2006 at 11:57:47AM -0700, Chris Waters wrote: On Sun, Oct 15, 2006 at 11:24:22AM +0100, Neil McGovern wrote: We want to avoid packages shipping their own versions of libraries, as then if a security problem or major bug is discovered in that library, we have lots of packages to update, and there's no garuntee we'll even know which packages it affects. I don't know if it can always be avoided. [snip lots of good examples where this is unavoidable] I would go for strongly discouraging the practice, but I think that flat-out forbidding it might be excessive at this point. Hence this being should not, rather than must not. We're aware that it's not alwars possible, and you phrased it wonderfully. We want to strongly discourage it, rather than flat-out forbidding it :) Cheers, Neil -- Tincho 'Maybe you can try to find a nice hotel by shouting in the Mexico DF streets where could a gringo find a decent hotel in this dirty third world lame excuse for a country?. I'm sure the people will rush to help you, as we south americans love to be called third world in a demeaning way.' signature.asc Description: Digital signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On 10804 March 1977, Neil McGovern wrote: Title:Embedding code provided in other packages Synopsis: Packages should not include or embed code that is available in other packages. Rationale:If a package contains embeded code, it becomes vulnerable to security bugs in the code it embeds. It's a) very hard to track this and b) makes it very hard to fix, as we have to issue multiple DSAs and fixed packages for any particular issue. A current list of packages we know to embed code are at [0]. Oh yeah, seconded. Its in most cases already a reject in NEW. -- bye Joerg [http://www.youam.net/stuff/info...-hosting.de/server-info.php] Die Anbindung des Servers: Unser Server ist mit 100 MBits/s (=12MB pro Sekunde) an unser lokales Netzwerk angebunden, unsere Internetanbindung sind 768 kbit/s Downstream und 128 kbit/s Upstream. Dies hört sich in manchen Ohren langsam an, allerdings wird unsere Geschwindigkeit in der Regel eher gelobt als kritisiert, denn der Upstream kann auch überzogen werden, wenn der Server überlastet wird (wurde von uns an Beispielen getestet, ist allerdings nicht 100%-ig zu erklären). pgpfyiHIKDjx8.pgp Description: PGP signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Wed, Oct 11, 2006 at 11:45:39AM +0100, Neil McGovern wrote: I'm including a patch that adds a should not to policy. Now updated, removed C-ism and fix some typos. I'm not sure we can say libraries instead of files, as some programs embed bits of libraries, instead of the whole lot. Which makes it even harder to work out what has security holes :| I'm aware that in some cases it's very hard to avoid this, which is why it's a should, rather than a shall. Cheers, Neil -- [..] But, up to now, this Friday was the best Debconf day ever and, no I'm not on some drugs that makes you happy. I'm just a happy Debconfer. -- Christian Perrier signature.asc Description: Digital signature
Bug#392362: [PROPOSAL] Add should not embed code from other packages
Package: debian-policy Version: 3.7.2.2 Severity: wishlist Tags: patch Hi all, I'm including a patch that adds a should not to policy. Title: Embedding code provided in other packages Synopsis: Packages should not include or embed code that is available in other packages. Rationale: If a package contains embeded code, it becomes vulnerable to security bugs in the code it embeds. It's a) very hard to track this and b) makes it very hard to fix, as we have to issue multiple DSAs and fixed packages for any particular issue. A current list of packages we know to embed code are at [0]. Cheers, Neil [0] http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies?op=filerev=0sc=0 --- policy.sgml +++ policy.sgml @@ -2105,6 +2105,14 @@ the file to the list in filedebian/files/file./p /sect +sect id=embededfiles + headingEmbedding code provided in other packages/heading + p + A package should not embed or include code from other + packages. Instead, the package should me modified to link against the + required files provided by the other package, and a Depends + relationship declared./p + /sect /chapt
