[pacman-dev] makepkg integrity check patches

Loui Chang louipc.ist at gmail.com
Thu May 6 12:50:52 CEST 2010


On Thu 06 May 2010 12:09 +1000, Allan McRae wrote:
> On 06/05/10 11:41, Loui Chang wrote:
> >On Thu 06 May 2010 10:51 +1000, Allan McRae wrote:
> >>2) cd1378d makepkg: rework --skipinteg
> >>
> >>This is very, very, VERY useful.  I did not have makepkg-git on my
> >>new computer earlier this week and the current makepkg behaviour
> >>annoyed me A LOT.
> >>
> >>This is particularly useful when testing out a patch that you need to
> >>repeatedly modify.  You only need to update your checksums once it is
> >>working.  I use this very frequently, but then again I do more
> >>packaging than most.
> >
> >I believe this is bad behaviour. makepkg should be used to package
> >software, not help you develop patches for it.
> 
> Not being condescending here, but you obviously do not do much
> packaging.  Packaging software requires patching software.  e.g.
> gcc-4.x header changes, libpng API changes, etc.  It is a lot easier
> for me to run "makepkg --skipinteg" to test the state of a patch to
> fix build issues that it is to manually extract the tarball, apply
> the patch, configure, make...

I understand that, but it's not very efficient, nor does it usually make
much sense to fully package something just to test a patch. I've done
enough devel/patching to discover that I think.  You can skip part of
build, multiple extraction, copies, and compression. This has a
particular impact with very large packages, not so much with small ones.

> >>3) 5d911ae makepkg: allow skipping integrity checks when making
> >>source package
> >
> >>And here is the fun one... "makepkg --source" currently requires
> >>checking all checksums.  Using "-source --skipinteg" does not skip
> >>this, which in itself makes little sense to me.  The argument that
> >>this stops people distributing packages with bad checksums is flawed.
> >>There is nothing stopping them doing that now.  They just have to not
> >>use makepkg when creating the tarball, which could lead to even worse
> >>PKGBUILDs being distributed as none of makepkg's other checks would
> >>be performed.
> >
> >Just because someone can manually make a bad source package there's no
> >excuse to put bad behaviour into makepkg. The same applies to binary
> >packages.
> 
> Why is it bad behaviour?  I think you are just assuming the user is
> stupid and will use it unnecessarily.  "pacman -Rd" and "pacman -Sf"
> are stupid in most cases, but we do not remove them as they are also
> useful in others cases.  Similarly, I provided two usage cases where
> it is perfectly reasonable behaviour to skip integrity checks.
> 
> Skipping integrity checks is not going to be the default behaviour
> and does not even have a shorthand option.  The user has to
> specifically want to use it.  Lets make the assumption that if
> someone goes out of their way to type "--skipinteg", that they are
> doing it deliberately.
> 
> >Perhaps in the future if package signing is implemented for
> >packages it would also be possible to have signed source packages.
> 
> Yes it would, but entirely off topic.

This relates to package integrity. I guess I mean to present the odd
possibility where you trust the person who signed the package, but the
it hasn't even passed basic integrity checks.

I guess the debate is convenience versus correctness really.

I can understand if someone may value the convenience more, but I
contend that the gained convenience is not particularly valuable after
all, can be obtained in other ways, and should not be put into the
official tools at the potential sacrifice of correctness.



More information about the pacman-dev mailing list