Re: How to cope with patches sanely
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 <charles-debian-nospam@plessy.org> 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
Reply to: