Hi again, Two long answers:
- In the fist I propose that the 'patch' rule could only be provided by snippets such as those of dpatch, quilt, and CDBS, so that there is no security risk running this command. - In the second I question the VCS model, mostly because I still do not fully understand how to keep the advantages of the patch systems in this alternative workflow. > > On to, 2008-01-31 at 20:03 +0900, Charles Plessy wrote: > > > I am wondering if just mandating 'debian/rules patch' to work if > > > debian/patches exist shouldn't be just sufficient. > On Thu, Jan 31, 2008 at 01:09:44PM +0200, Lars Wirzenius wrote: > > The only big problem I have with that is that is required some unknown > > subset of build-dependencies to be installed, and to run code _from_ > > _the_ _package_, just to unpack a source package. This makes me > > uncomfortable: you have to install and run complicated tools and > > untrusted code, with all the potential for bugs and security trouble > > that involves, just to see the source code. Le Thu, Jan 31, 2008 at 11:54:18AM +0000, Colin Watson a écrit : > I have a similar discomfort. We regard bugs in tar that allow malicious > tarballs to do bad things as security vulnerabilities, and rightly so. > > That said, we could have this behaviour controlled by an option, so that > if you knew you were fetching a trusted signed package from the Debian > archive then you could supply the option, and otherwise (say you were > examining a package provided by a sponsored developer whom you didn't > know very well) then you could omit the option and get safe behaviour. Le Thu, Jan 31, 2008 at 11:51:05PM +1100, Ben Finney a écrit : > It's no security risk to unpack a tarball, apply a patch to it via GNU > 'patch', and examine the result. (I don't even have to trust debhelper > for that, since it's not part of unpacking the source.) > > I'm *not* happy to need to run some target with arbitrary commands in > the 'debian/rules' file, just to allow me to examine the source. A big > part of the reason for unpacking the source could be to find out > what's in there *before* executing any part of it. I do not know if it would be reasonnable to extend the scope of the discussion to third-party packages. For the packages distributed by Debian, there are quite many safety guards that should make people think that it is not unsafe to run 'debian/rules patch' (for the moment it has not been proposed to go through another mechanism). - The package has been signed by a DD. - In some cases, it has been built on trusted machines, and the build logs are publically available. - What 'debian/rules patch' is doing can be inferred by remotely examinating the diff.gz file. - In many cases, the 'patch' and 'unpatch' rules are factorised code that can be read from /usr/share/{cdbs|quilt|dpatch}. Each of these points have their flaws, and in the end, I agree tha the process is not very convenient. But I am still surprised that the risk of running 'debian/rules patch' from official Debian pacakages is felt to be so high. I have proposed in an earlier mail to "qualify" tools a bit in the same way as Debian qualifies release architectures. If the Policy would put constraints on the 'patch' and 'unpatch' rules, it could be for instance that they must be inherited from the /usr/share/foo/bar.make snippets of "qualified" patch systems. Would it help to solve the security problem? > Charles Plessy <[EMAIL PROTECTED]> writes: > > But I am still missing something: how can we get the benefits of > > using a patching strategy, that is to break up changes into logical > > components, with the VCS strategy? Le Fri, Feb 01, 2008 at 12:01:15AM +1100, Ben Finney a écrit : > Make commits to the VCS branch for the package, at the same level of > granularity (or finer) as you would write individual patches. Be sure > to describe the commit with a good message, just as you would comment > a patch file. With any decent modern VCS, each individual commit can > be inspected at any later date, including generating a patch against > another arbitrary revision. The major flaw I see in this proposal is that the information conveyed in the paches of debian/patches are separated from the Debian source package. Internet connection would be required, unless the logs are shipped as part of the package in some organised format. In the end, the use of debian/patch is — at least in my hands — not a technical tool to manage changes, but a communication tool to make the changes easily understandable to fellow team members. Unlike commits, patches are a single entity. In the VCS approach, how can we avoid situations like "Building with GCC 4.3 is acheived with commit 1223, commit 1224 (fixes typo), commit 1345 (reverts part of commit 1223 because the behaviour of gcc-snapshot changed), and commit 1453 (but only the bottom part, the upper part fixes Unicode support)." We are not robots, just look at the commits of the Debian-Med's SVN if you want an example. I am proud of our work, but it the bar raises so hight that each commit must be perfect, I guess I would not have other choice than give up. Another flaw that is being discussed is that team-working on the package requires to have the full source in a VCS, and I do not understand Pierre's argument when he says that the imported sources are lighter than the compacted source in a orig.tar.gz. Fellow team members are not happy to checkout hundread of megaoctets when they have no optic fiber at home. This is again a question of raising the bar or not. Can we afford losing contributions of those who do not have permanent broadband access? Have a nice day, -- Charles Plessy Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]