Send patches - preferably formatted by git format-patch - to patches at archlinux32 dot org.
summaryrefslogtreecommitdiff
path: root/scripts/libmakepkg/source/git.sh.in
AgeCommit message (Collapse)Author
2019-05-08scripts: protect against unintended glob matching in [[ ]] RHSEli Schwartz
The right-hand side of the [[ ... = ... ]] keyword is an exception to the general rule that quoting is unnecessary with [[ This is usually not a problem, e.g. in libmakepkg, lint_one_pkgname will already fail if pkgname has an asterisk, but it certainly doesn't hurt to be "more proper" and go with the spec; it is more dangerous in repo-add, which can get caught in an infinite loop instead of safely asserting there is no package named 'foo*'. Reported-by: Rafael Ascensão <rafa.almas@gmail.com> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-03-19makepkg: use "shared" git clones when checking out sourcesEli Schwartz
In order to cache sources offline, makepkg creates *two* copies of every git repo. This is a useful tradeoff for network time, but comes at the cost of increased disk space. Normally, git can smooth this over automagically. Whenever possible, git objects are hardlinked to save space, but this does not work when SRCDEST and BUILDDIR are on separate filesystems. When the repo in question is both very large (linux.git for example is 2.2 GB) and crosses filesystem boundaries, this results in a lot of extra disk space being used; the most likely scenario is where BUILDDIR is a tmpfs for bonus ouch. git(1) has a builtin feature which serves this case handily: the --shared flag will create the info/alternates file instructing git to not copy or hardlink or create objects/packs at all, but merely look for them in an external location (that being the source of the clone). The downside of using shared clones, is that if you modify and drop commits from the original repo, or simply delete the whole repo altogether, you break the copy. But we don't care about that here, because 1) the BUILDDIR copy is meant to be a temporary copy strictly derived via PKGBUILD syntax from the SRCDEST, and must be able to be recreated at any time, 2) if the SRCDEST disappears, makepkg will redownload it, thus restoring the objects needed by the BUILDDIR clone, 3) if the user does non-default things like hacking on the BUILDDIR copy then deleting and re-cloning the SRCDEST may result in momentary breakage, but ultimately should be fine -- the unique objects they created will be stored in the BUILDDIR copy. While it's theoretically possible that upstream will force-push to overwrite the base tree from which makepkg is building (which they should not do), *and* the user deleted their SRCDEST which they should not do, *and* they saved work in makepkg's working directory which they should not do either... ... this is an unlikely chain of events for which we should not care. Using --shared is therefore helpful in immediately useful ways and IMHO has no actual downsides; we should use it. An alternative implementation would be to use worktrees. I've rejected this since it is essentially the same as shared clones, except adding additional restrictions on the branch namespace, and could potentially break existing use cases such as manually handling the SRCDEST in order to share repositories with normal working copies. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-01-22libmakepkg: implement extendable source protocolsEli Schwartz
Lookup the existence of matching functions for each protocol, and fallback on the generic file handler. New source protocols can then be added via thirdparty libmakepkg drop-ins without requiring modifications to source.sh Fixes FS#49076 Signed-off-by: Allan McRae <allan@archlinux.org>
2018-03-14Update coyrights for 2018Allan McRae
make update-copyright OLD=2017 NEW=201 Signed-off-by: Allan McRae <allan@archlinux.org>
2017-09-13libmakepkg: check for invalid tags in gitEli Schwartz
As per https://lists.archlinux.org/pipermail/arch-general/2017-July/043876.html git doesn't check that the tag name matches what an annotated tag object *thinks* it should be called. This is a bit of a theoretical attack and some would argue that we should always use commits since upstream can legitimately change a tag, but nevertheless this can result in a downgrade attack if the git download transport was manipulated or the upstream repository hacked. So, check the tag blob to make sure the tag actually matches the name we used for `git checkout`. This really should be fixed in git itself, rather than forcing all downstream users of git verify-tag to implement their own checks, but the git developers disagree, see the discussion surrounding https://public-inbox.org/git/xmqqk2hzldx8.fsf@gitster.mtv.corp.google.com/ Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2017-01-04makepkg: Verify git signaturesEli Schwartz
A git repository is marked as signed if it contains the query "signed" as defined by https://tools.ietf.org/html/rfc3986 Adds two utility functions in util/source.sh.in to extract fragments and queries, and modifies source/git.sh.in to use them. Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2017-01-04Update copyright yearsAllan McRae
Signed-off-by: Allan McRae <allan@archlinux.org>
2016-01-04Update copyright years for 2016Allan McRae
make update-copyright OLD=2015 NEW=2016 Signed-off-by: Allan McRae <allan@archlinux.org>
2015-05-19libmakepkg: extract functions for source download and extractionAllan McRae
Signed-off-by: Allan McRae <allan@archlinux.org>