makepkg would not abort on a missing download agent due to the
output variable being declared local on the same line as the
function call in the assignment. That would result in strange output
such as:
==> Retrieving Sources...
==> ERROR: There is no agent set up to handle foo URLs. Check /etc/makepkg.conf.
Aborting...
-> Downloading foobaz...
/home/arch/code/pacman/scripts/makepkg: line 401: foo://foobaz: No such file or directory
==> ERROR: Failure while downloading foobaz
Aborting...
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Declaring the variable as local on the same line as the assignment
results in result of the assignment being returned rather than the
result of the function on the righthand side of the assignment.
Declaring the variable as local on a separate line means the result
of the function on the r.h.s. is returned and our error function
will be invoked if necessary (although it is practically impossible
to ever trigger it...).
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Simplify the source tarball generation by unifying the handling of
local and remote files. This also allows local files to be found
in $SRCDEST (FS#26580) and makepkg will abort on missing local source
files (only possible to trigger in combination with --skipinteg).
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
This prevents user error in adding a file generated via `gpg --sign`
rather than `--detach-sign`, for example. The same 16KiB limit is used
we use in our pacman download code.
The section is moved above the checksum generation to avoid presenting
info messages to the user if the signature isn't valid.
Addresses a shortcoming pointed out in FS#27453.
Signed-off-by: Dan McGee <dan@archlinux.org>
Whereas comm will check inputs to see if they're sorted (and warn when
they aren't), grep doesn't even care about ordering. In this particular
instance -- neither do we. We're only interested that the two lists are
equivalent.
Fixes FS#26580.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
* Add last-minute changes to NEWS
* Don't treat '_' or '_n' special in scripts when finding translatable
strings; this breaks with one use of `read` and a dummy _ variable
Signed-off-by: Dan McGee <dan@archlinux.org>
This applies to pkgver, pkgrel, and epoch and ensures that any trailing
whitespace outside of the context of the variable declaration itself is
properly trimmed. The Bash parser will ignore this, and so should we.
We don't need to worry about leading space because it would force a
syntax error, or fail validation.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Bump the version, update the translation template files, and fill in
NEWS with relevant commits and changes since 4.0.0.
Signed-off-by: Dan McGee <dan@archlinux.org>
This prevent bsdtar from exploding when install= or changelog= are
present without a value.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Detached sgnature files with extension .sign are accepted by gnupg.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
The default is supposidely 30 seconds from the gpg manpage, but that
sure wasn't what I was seeing- it was somewhere closer to two minutes of
silence. Add a more reasonable 10 second timeout value which should be
good enough for any keyserver that doesn't totally stink at it's job.
Signed-off-by: Dan McGee <dan@archlinux.org>
This includes some fixes to the messages that are displayed when a
signal is caught in makepkg or repo-add:
* Instead of always showing "==> ERROR: TERM signal caught. Exiting...",
replace "TERM" by whatever signal is actually caught.
* Fix a typo in the SIGERR error message in repo-add ("occurred" instead
of "occured"). Francois already fixed this for makepkg in 1e51b81c.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Signed-off-by: Dan McGee <dan@archlinux.org>
There is a small chance that a user sends SIGINT (or any other signal
that is trapped) when we're already in clean_up() which used to lead to
trap_exit() being executed and the remaining code in clean_up() being
skipped due to the bash signal/trap handler blocking EXIT (since its
handler is already being executed, even if it's interrupted).
In practice, this behaviour caused unexpected results (primarily because
pressing ^C at the wrong time left a lock file behind):
$ ./repo-add extra.db.tar.gz foobar
==> Extracting database to a temporary location...
^C
==> ERROR: Aborted by user! Exiting...
$ ./repo-add extra.db.tar.gz foobar
==> Extracting database to a temporary location...
==> ERROR: File 'foobar' not found.
==> No packages modified, nothing to do.
^C
==> ERROR: Aborted by user! Exiting...
$ ./repo-add extra.db.tar.gz foobar
==> ERROR: Failed to acquire lockfile: extra.db.tar.gz.lck.
==> ERROR: Held by process 18522
Fix this and reduce the chance of race conditions in signal handlers by:
* Unhooking all traps in both clean_up() and trap_exit().
* Call clean_up() explicitly in trap_exit() to make sure we remove the
lock file and the temporary directory even if we send SIGINT when
clean_up() is already being executed but didn't reach the unhook code
yet.
Also, add an optional parameter to clean_up() to allow for setting an
explicit exit code when we call clean_up() from trap_exit().
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Signed-off-by: Dan McGee <dan@archlinux.org>
We have a few incomplete translations, but these should be addressable
before the 4.0.1 maint release that is surely not that far in the
future.
Signed-off-by: Dan McGee <dan@archlinux.org>
Inline comments after pkgver or pkgrel would cause the sanity
checks to fail so remove them before checking the value.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
This allows it to serve double-duty. In order to allow users to base
verification decisions off of both a valid signature and a trusted
signature, we need to assign some level of owner trust to the keys we
designate as trusted on import.
Signed-off-by: Dan McGee <dan@archlinux.org>
* --import now only imports keys from pubkey.gpg and does not import
owner trust; if you want to have both simply run the operations in
sequence.
* --import-trustdb has been simplified; it will overwrite existing
values in the trust database as before, but there is no need to export
it first as those values are safe if left untouched.
* Fix the manpage referring to a non-existent option.
Signed-off-by: Dan McGee <dan@archlinux.org>
If PKGEXT is not one of the recognized tar*'s, create_package() would
create an empty package file and fail, since bsdtar on the left side of
the pipe returns 141 on SIGPIPE (broken pipe).
This patch changes the behavior for an invalid PKGEXT. A warning is
printed on stderr, and a tar file is created. Also retire the obsolete
$EXT variable.
Add the obligatory comment why we don't use bsdtar's compression.
Finally, fix mixed-tab-space indentation.
Signed-off-by: lolilolicon <lolilolicon@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
We're ill equipped to be using this flag as we don't trap and respond to
the ERR signal. The result is that if is ever tripped, pacman-key will
instantly exit with no indication of why. At the same time, we're
already fairly good about doing our own error checking and verbalizing
it before dying.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
This prevents the error trap being set off when GPGDir is commented
in pacman.conf. Bug introduced in 507b01b9.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Always quote the right-hand side of expression when the == or != operator
is used, unless intended as a pattern.
Signed-off-by: lolilolicon <lolilolicon@gmail.com>
Always quote the righthand side of expression when the == or != operator
is used, unless intended as a pattern. Quoting bash(1):
When the == and != operators are used, the string to the right of the
operator is considered a pattern. Any part of the pattern may be quoted
to force it to be matched as a string.
Signed-off-by: lolilolicon <lolilolicon@gmail.com>
If '-' isn't the last item, it's interpreted as a range and not
literally, causing problematic behavior in parsing optdepends.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Keep the non-zero return val to let the caller know that the key wasn't
found.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Many PKGBUILDs use formatting whitespace when specifying optdepends.
This is removed when adding a package to a repo-database so the
output of "pacman -Si <package>" and "pacman -Qip <package file>"
becomes inconsistent. Instead, do the adjustment when creating
the .PKGINFO file.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Allow the specification of versioned optdepends with an epoch.
This also (partially) enforces a whitespace between ":" and the
description which is required for the future optdepends parsing
code.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
This is similar to the 'foo-revoked' file we had. This will be used to
inform the user what keys in the shipped keyring need to be explicitly
trusted by the user.
A distro such as Arch will likely have 3-4 master keys listed in this
trusted file, but an additional 25 developer keys present in the keyring
that the user shouldn't have to directly sign.
We use this list to prompt the user to sign the keys locally. If the key
is already signed locally gpg will print a bit of junk but will continue
without pestering the user.
Signed-off-by: Dan McGee <dan@archlinux.org>
We're putting the cart ahead of the horse a bit here. Given that our
keyring is not one where everything is implicitly trusted (ala gpgv),
keeping or deleting a key has no bearing on its trusted status, only
whether we can actually verify things signed by said key.
If we need to address this down the road, we can find a solution that
works for the problem at hand rather than trying to solve it now before
signing is even widespread.
Signed-off-by: Dan McGee <dan@archlinux.org>
Unlike our protégé apt-key, removing a key from our keyring is not
sufficient to prevent it from being trusted or used for verification. We
are better off flagging it as disabled and leaving it in the keyring so
it cannot be reimported or fetched at a later date from a keyserver and
continue to be used.
Implement the logic to disable the key instead of delete it, figuring
out --command-fd in the process.
Note that the surefire way to disable a key involves including said key
in the keyring package, such that it is both in foobar.gpg and
foobar-revoked.
Signed-off-by: Dan McGee <dan@archlinux.org>
This finishes the cleanup started in 710e83999b. We can do a straight
import from another keyring rather than all the funky parsing and piping
business we were doing.
Signed-off-by: Dan McGee <dan@archlinux.org>
Otherwise we're hiding extremely relevant bits like this one:
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Signed-off-by: Dan McGee <dan@archlinux.org>
