The official pacman repository branch, master, updated. v4.0.0rc1-244-g1df9b2a
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The official pacman repository".
The branch, master has been updated
via 1df9b2aa79c5017d394e26619449ab0a49c65c16 (commit)
via 067721cbff9652d5c436d277f9be3f8fa2a71796 (commit)
via 33685b960d3f05841cfac5696a0946396c448a34 (commit)
via 595e1a437fab8d489736eff4811903aea4f5a38f (commit)
via 7d961c849bf4dab481e261bdb91304f6a4744d8c (commit)
via 6767de5380d97f6544ca3968b83b74120dfcbeca (commit)
via 213950afa370296b921230e6edc626e70a71b499 (commit)
via 491b656c548f13658c609784cf02af244ee97b23 (commit)
via 03e1b4caa9cf91ac3a3956b82e080dfc72b66a17 (commit)
via a7691ba6fd6f87cae6210c304235c709e4f9a60e (commit)
via 4b6a5ae1599807d60568bb617483ffe368745ac0 (commit)
via 765178c5bafe88e09f33ab67152b9bb3eabe7685 (commit)
via 0ef7129a4a7776db9d0c4dd52519e2ca21b428d5 (commit)
via 4849a4596d502376f66c327a48c5d78328acdfe0 (commit)
via 0a4a5cea97f75d5d38e9cb33d5f47f0c36c0dffb (commit)
via 3e4749fe3ec3f14e4107363a85b953b4a0a747f7 (commit)
via 361ed6a6001c41f08ee85a94d28ba5a7c79a6154 (commit)
via e4690232d61b8b7655df40feb417cf54c489d73c (commit)
via ca58e326dc8e7d347c8ce77cba58a8ea1a99fb49 (commit)
via 69694edd2cd282b513426cced5d885cec35f612e (commit)
via d36d70d2947b1c6a161f6bf55ddd19445f2c81cb (commit)
via 33f251853155fd1e04d03fbaffb3849ab8e953dc (commit)
via 01f5c9e79ab2e051349f941b7ecce80d9a251603 (commit)
via 5e7875ae6a42de40e3a7432ea758b27397a11aa7 (commit)
via 3a460a8be650437326507b5604243d8fccbcfe26 (commit)
via 47dd31560906fdd87f547940f5c7656d94d52b1b (commit)
from 8375ad214a2a8d6e01430f432aa7957688d8ec52 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
pacman-key: add an additional plain text 'foo-trusted' file
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.
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.
Because we aren't using gpgv and a dedicated keyring that is known to be
all safe, we should honor this flag being set on a given key in the
keyring to know to not honor it. This prevents a key from being
reimported that a user does not want to be used- instead of deleting,
one should mark it as disabled.
This finishes the cleanup started in 710e83999bbf. We can do a straight
import from another keyring rather than all the funky parsing and piping
business we were doing.
pacman-key: don't hide --verify details in populate
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.
Add two new static methods, key_search() and key_import(), to our
growing list of signing code.
If we come across a key we do not have, attempt to look it up remotely
and ask the user if they wish to import said key. If they do, flag the
validation process as a potential 'retry', meaning it might succeed the
next time it is ran.
These depend on you having a 'keyserver hkp://foo.example.com' line in
your gpg.conf file in your gnupg home directory to function.
Add _alpm_process_siglist() logic to failed package validation
This moves the result processing out of the validation check loop itself
and into a new loop. Errors will be presented to the user one-by-one
after we fully complete the validation loop, so they no longer overlap
the progress bar.
Unlike the database validation, we may have several errors to process in
sequence here, so we use a function-scoped struct to track all the
necessary information between seeing an error and asking the user about
it.
The older prompt_to_delete() callback logic is still kept, but only for
checksum failures. It is debatable whether we should do this at all or
just delegate said actions to the user.
This allows a frontend program to query, at runtime, what the library
supports. This can be useful for sanity checking during config-
requiring a downloader or disallowing signature settings, for example.
Move default siglevel value from backend to frontend
This takes the libraries hidden default out of the equation: hidden in
the sense that we can't even find out what it is until we create a
handle. This is a chicken-and-egg problem where we have probably already
parsed the config, so it is hard to get the bitmask value right.
Move it to the frontend so the caller can do whatever the heck they
want. This also exposes a shortcoming where the frontend doesn't know if
the library even supports signatures, so we should probably add a
alpm_capabilities() method which exposes things like HAS_DOWNLOADER,
HAS_SIGNATURES, etc.
This allows us to do all delta verification up front, followed by
whatever needs to be done with any found errors. In this case, we call
prompt_to_delete() for each error.
Add back the missing EVENT(ALPM_EVENT_DELTA_INTEGRITY_DONE) that
accidentally got removed in commit 062c391919e93f1d6.
Remove use of *data; we never even look at the stuff in this array for
the error code we were returning and this would be much better handled
by one callback per error anyway, or at least some strongly typed return
values.
If siglist->results wasn't a NULL pointer, we would try to free it
anyway, even if siglist->count was zero. Only attempt to free this
pointer if we had results and the pointer is valid.
This one can be overwhelming when reading debug output from a very large
package. We already have the output of each extracted file so we
probably can do without this in 99.9% of cases.
The official pacman repository branch, master, updated. v4.0.0rc1-244-g1df9b2a
