[pacman-dev] makepkg integrity check patches

Dan McGee dpmcgee at gmail.com
Thu May 6 03:10:05 CEST 2010

On Wed, May 5, 2010 at 7:51 PM, Allan McRae <allan at archlinux.org> wrote:
> Here is some justification for the patches on my working branch related to
> integrity checking.  Put in order from least controversial to most...
> 1) cd3910b makepkg -g: use checksums defined in the pkgbuild
> This is Xavier's patch.  I am not sure there was ever issues with this one,
> but I think it got caught up with the other patches.  This patch just makes
> it easier to maintain checksums in a PKGBUILD other than the default in
> makepkg.conf. e.g. if I have sha1sums in the PKGBUILD, "makepkg -g" will
> generate sha1sums even if generating md5sums is the default.  To generate
> md5sums only, you just need to remove the old checksums from the PKGBUILD or
> add an empty md5sum array to the PKGBUILD.

Already merged, I have zero problems here.

> 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.
> without patch:
>> /usr/bin/makepkg --skipinteg
> ...
> ==> Validating source files with md5sums...
>    abs- ... FAILED
> ==> ERROR: One or more files did not pass the validity check!
> with patch:
>> makepkg --skipinteg
> ...
> ==> WARNING: Skipping integrity checks.
> ==> Extracting Sources...
> 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.

Fine with me, and also merged locally.

> 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.

Part of me says this is at least a barrier they would have to work to
cross and defeat, and just downloading the darn source would be
quicker for most. I do understand that a quick `tar czf` would
circumvent the whole thing, but it has become so easy to create source
packages that I don't feel many people even think about it this way
anymore. Correct me if I'm wrong.

> Admittedly, this patch will see little use.  I used to use it in combination
> with #2 when checking that a modified patch compiled on both my i686 and
> x86_64 machines.  Now that I build both architectures on one machine, this
> is of less use to me.  I have also used it when commenting on a PKGBUILD
> that was sent to me with a query about the best way to implement something.
>  There I modified some of the build() function to be clearer and sent it to
> the author saying I would use this approach but it is not tested.  Note I
> could have used tar manually (in fact the tar file name would have been tab
> autocompleted so the command would probably be simpler to type), but then I
> would not get the other checks makepkg provides.
> Note that this patch does not make --skipinteg the default.  In fact, given
> how long the options is, it is very unlikely that a user could every
> accidentally type it!  There is no difference in behaviour to the current
> "makepkg --source" unless the user specifically requests it. The patch just
> makes --skipinteg do what its name says;  skip integrity checks.

Well after reading most of this you may have won me over. Maybe I can
get just one small concession- when you use both of these options
together (or --allsource I believe it is), we print one more warning
saying "this source package is not guaranteed to work for anyone
else!" or something along those lines.


More information about the pacman-dev mailing list