Re: [pacman-dev] [PATCH] makepkg: Only change debug prefix if making debug package
On 29/7/19 2:52 pm, Austin Lund wrote:
> Currently all debug builds will prefix /usr/src/build to the source
> paths. If debugging symbols are stripped into a separate package then
> these sources files are indeed in this path. But if the debug build is
> not stripped then one is left with a complex path rewriting to perform
> debugging. It's much easier to perform sensible path rewriting in this
> instance when the path is left untouched.
>
> Signed-off-by: Austin Lund
> ---
I think this is the wrong solution.
For a package with options=('debug' '!strip'), we should just include
the source files in the package. Debug information includes source files.
Allan
Re: [pacman-dev] [PATCH] pacman: new config to highlight testing packages
On 10/9/19 8:42 pm, Jan Alexander Steffens wrote: > On Tue, Sep 10, 2019, 12:17 Morten Linderud wrote: > >> If you turn it around and add a list instead? >> >> HilightRepositories = testing community-testing >> > > You could give each [repo] a Color= setting. > An option per repo would be fine. However, I'd prefer not an individual colour to each repo. It should be a single highlight "colour". Also, I don't like the idea of using the warning colour either. That reduces the impact of actual warnings - is just bolding the package names enough? Finally, I don't like that the option does nothing when VerbosePkgList is set. Allan
Re: [pacman-dev] [PATCH] pacman/pacman-conf: -i/--is-set switch, returns 0 if option set
On 11/9/19 10:29 am, Eli Schwartz wrote: > On 9/10/19 2:32 PM, Matthew Sexton wrote: >> Returns 1 if option not set. Returns 1 with error to stderr if >> flag does not exist. Case insensitive. > > As discussed on IRC, it seems like this may be easier and more reliable > to achieve by using exit statuses. Instead of exiting 1 on a missing > flag, and returning 0 otherwise while printing out the key (or not)... > > Maybe emulate e.g. grep. Return 2 if an error occurred, i.e. missing > option, and then even without -i, we can return 1 if the option is not set. > How to handle multiple directives? e.g. pacman-conf SigLevel LogFile NoColor
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.1.1-221-g8f89e509
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 8f89e509d2f3d369cb5adb30dd85713ff1c5305c (commit) via f2442bc2e9d41a68b9965c272794600836c36b8b (commit) via 0a295f3f396b990e03ab8faec37566de85c99fec (commit) via 0e3a4bd1fbb740b6bfce2ceb3e6acdfe84a4d486 (commit) via facd9533b002194e58cc47672ce7e23d40968e96 (commit) via c0da1ba13a22f099936f60a0d2a752c9ab739ae0 (commit) from de6249ce221aae4062ea131d4f676f7e3d44af28 (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. - Log - commit 8f89e509d2f3d369cb5adb30dd85713ff1c5305c Author: morganamilo Date: Sun Sep 8 22:45:29 2019 +0100 pacman: speed up deptest Try and find an exact match via pkgcache before iterating the entire localdb. Gives a noticeable speed up for exact matches e.g. `pacman -T zlib` Signed-off-by: Allan McRae commit f2442bc2e9d41a68b9965c272794600836c36b8b Author: morganamilo Date: Sun Sep 8 22:45:28 2019 +0100 libalpm: short circuit alpm_find_dbs_satisfier when a satisfying package is already installed, we always pick it instead of prompting the user. So we can return that package as soon as we find it, instead of waiting until we've iterated through all the databases. Signed-off-by: Allan McRae commit 0a295f3f396b990e03ab8faec37566de85c99fec Author: morganamilo Date: Sun Sep 8 22:45:26 2019 +0100 libalpm: fix incorrect documentation Signed-off-by: Allan McRae commit 0e3a4bd1fbb740b6bfce2ceb3e6acdfe84a4d486 Author: Eli Schwartz Date: Wed Oct 2 03:20:13 2019 -0400 meson: work around broken pkg-config file with private requires In addition to the general issue of staticlibs linkage, linking a static lib to a library() does not seem to generate the needed Libs.private. Rework how we handle this entirely. Instead of relying on convenience libraries, we will *sigh* go extract a boatload of .o files again, then relink those to the installable libalpm, while mentioning our dependencies again. We still have our guaranteed static library for linking arbitrary programs with (e.g. vercmp), and we still only generate one identical copy of the .o files, but now we potentially `ar` it up twice, which isn't so bad. And linking still works, and pkg-config files also still work. One alternative would be to explicitly list our dependencies to pkgconfig.generate with requires_private, but since gpgme might be an elevated config-tool dependency, this can fail with: meson.build:341:10: ERROR: requires argument not a string, library with pkgconfig-generated file or pkgconfig-dependency object, got Signed-off-by: Eli Schwartz Signed-off-by: Allan McRae commit facd9533b002194e58cc47672ce7e23d40968e96 Author: Eli Schwartz Date: Wed Sep 18 23:46:58 2019 -0400 meson: fix incorrect libalpm version LIB_VERSION is supposed to be something like 11.0.1, not simply reiterate the project version. As a result, we ended up with this: $ pacman -V [...] Pacman v5.1.0 - libalpm v5.1.0 [...] Signed-off-by: Eli Schwartz Signed-off-by: Allan McRae commit c0da1ba13a22f099936f60a0d2a752c9ab739ae0 Author: Eli Schwartz Date: Wed Sep 18 23:44:57 2019 -0400 meson: fix libcommon being publicly exposed as a static link dependency libcommon isn't even installed, so that means libalpm.a (if installed) is fatally broken as it misses objects. The problem is that meson doesn't handle this case correctly: https://github.com/mesonbuild/meson/issues/3934 https://github.com/mesonbuild/meson/issues/3937 https://github.com/mesonbuild/meson/pull/3939 Work around this by manually extracting libcommon's .o files into the list of objects used to create libalpm. Signed-off-by: Eli Schwartz Signed-off-by: Allan McRae --- Summary of changes: lib/libalpm/deps.c | 27 ++- meson.build | 28 +--- src/pacman/deptest.c | 4 +++- 3 files changed, 30 insertions(+), 29 deletions(-) hooks/post-receive -- The official pacman repository
Re: [pacman-dev] [PATCH 4/4] pacman: speed up deptest
On 9/9/19 7:45 am, morganamilo wrote:
> Try and find an exact match via pkgcache before iterating the entire
> localdb.
>
> Gives a noticeable speed up for exact matches e.g. `pacman -T zlib`
>
Thanks. Applied.
> ---
>
> Do note this fails for versioned exact matches. "zlib>1" will not take
> the faster route because alpm_db_get_pkgfromcache() does not work for
> versioned deps.
>
> I do have a solution for this in an alternative patch which adds
> alpm_db_find_local_satisfier() "62 insertions(+), 7 deletions(-)"
>
> But is that worth it just for a speed up on -T? Nowhere else really
> makes extensive use of searching the localdb.
Probably not worth the extra complexity given current usage of -T is
normally followed by a lot of compiling...
> ---
> src/pacman/deptest.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/pacman/deptest.c b/src/pacman/deptest.c
> index 597eee42..76bf223e 100644
> --- a/src/pacman/deptest.c
> +++ b/src/pacman/deptest.c
> @@ -32,11 +32,13 @@ int pacman_deptest(alpm_list_t *targets)
> alpm_list_t *i;
> alpm_list_t *deps = NULL;
> alpm_db_t *localdb = alpm_get_localdb(config->handle);
> + alpm_list_t *pkgcache = alpm_db_get_pkgcache(localdb);
>
> for(i = targets; i; i = alpm_list_next(i)) {
> char *target = i->data;
>
> - if(!alpm_find_satisfier(alpm_db_get_pkgcache(localdb), target))
> {
> + if(!alpm_db_get_pkg(localdb, target) &&
> + !alpm_find_satisfier(pkgcache, target)) {
> deps = alpm_list_add(deps, target);
> }
> }
>
Re: [pacman-dev] [PATCH 3/4] libalpm: short circuit alpm_find_dbs_satisfier
On 9/9/19 7:45 am, morganamilo wrote:
> when a satisfying package is already installed, we always pick it
> instead of prompting the user. So we can return that package as soon as
> we find it, instead of waiting until we've iterated through all the
> databases.
> ---
Ack.
> lib/libalpm/deps.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/lib/libalpm/deps.c b/lib/libalpm/deps.c
> index 322c4e7e..f69f24ad 100644
> --- a/lib/libalpm/deps.c
> +++ b/lib/libalpm/deps.c
> @@ -719,20 +719,19 @@ static alpm_pkg_t *resolvedep(alpm_handle_t *handle,
> alpm_depend_t *dep,
> }
> _alpm_log(handle, ALPM_LOG_DEBUG, "provider
> found (%s provides %s)\n",
> pkg->name, dep->name);
> +
> + /* provide is already installed so return early
> instead of prompting later */
> + if(_alpm_db_get_pkgfromcache(handle->db_local,
> pkg->name)) {
> + alpm_list_free(providers);
> + return pkg;
> + }
> +
> providers = alpm_list_add(providers, pkg);
> /* keep looking for other providers in the all
> dbs */
> }
> }
> }
>
> - /* first check if one provider is already installed locally */
> - for(i = providers; i; i = i->next) {
> - alpm_pkg_t *pkg = i->data;
> - if(_alpm_db_get_pkgfromcache(handle->db_local, pkg->name)) {
> - alpm_list_free(providers);
> - return pkg;
> - }
> - }
> count = alpm_list_count(providers);
> if(count >= 1) {
> alpm_question_select_provider_t question = {
>
Re: [pacman-dev] [PATCH 1/4] libalpm: fix incorrect documentation
On 9/9/19 7:45 am, morganamilo wrote: > --- > lib/libalpm/deps.c | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) > Changes look fine. A > diff --git a/lib/libalpm/deps.c b/lib/libalpm/deps.c > index 71185c68..ce7869c3 100644 > --- a/lib/libalpm/deps.c > +++ b/lib/libalpm/deps.c > @@ -643,10 +643,9 @@ int _alpm_recursedeps(alpm_db_t *db, alpm_list_t > **targs, int include_explicit) > * @param dep is the dependency to search for > * @param dbs are the databases to search > * @param excluding are the packages to exclude from the search > - * @param prompt if true, will cause an unresolvable dependency to issue an > - *interactive prompt asking whether the package should be removed > from > - *the transaction or the transaction aborted; if false, simply > returns > - *an error code without prompting > + * @param prompt if true, ask an alpm_question_install_ignorepkg_t to decide > + *if ignored packages should be installed; if false, skip ignored > + *packages. > * @return the resolved package > **/ > static alpm_pkg_t *resolvedep(alpm_handle_t *handle, alpm_depend_t *dep, > @@ -766,8 +765,11 @@ static alpm_pkg_t *resolvedep(alpm_handle_t *handle, > alpm_depend_t *dep, > > /** Find a package satisfying a specified dependency. > * First look for a literal, going through each db one by one. Then look for > - * providers. The first satisfier found is returned. > + * providers. The first satisfier that belongs to an installed package is > + * returned. If no providers belong to an installed package then an > + * alpm_question_select_provider_t is created to select the provider. > * The dependency can include versions with depmod operators. > + * > * @param handle the context handle > * @param dbs an alpm_list_t* of alpm_db_t where the satisfier will be > searched > * @param depstring package or provision name, versioned or not >
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.1.1-215-gde6249ce
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 de6249ce221aae4062ea131d4f676f7e3d44af28 (commit) from 2a792ac7bb1ceda42767c696e2664819b47ffc3b (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. - Log - commit de6249ce221aae4062ea131d4f676f7e3d44af28 Author: Eli Schwartz Date: Sun Aug 11 23:46:25 2019 -0400 Support file with seccomp enabled Not all compression types can be detected in the seccomp sandbox, so we need to disable it. This requires either configuring makepkg to know the sandbox is available, or checking for file >= 5.38 in which the sandbox option is a no-op even when seccomp is disabled. - Requires autoconf-archive for autotools version compare macro. - meson version comparison could be made a lot simpler using meson-git. Fixes FS#58626 Signed-off-by: Eli Schwartz Signed-off-by: Allan McRae --- Summary of changes: RELEASE | 1 + build-aux/edit-script.sh.in | 1 + configure.ac | 19 +++ meson.build | 10 ++ meson_options.txt| 3 +++ scripts/Makefile.am | 1 + scripts/libmakepkg/source/file.sh.in | 2 +- 7 files changed, 36 insertions(+), 1 deletion(-) hooks/post-receive -- The official pacman repository
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.1.1-214-g2a792ac7
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 2a792ac7bb1ceda42767c696e2664819b47ffc3b (commit) via f49233903521f19a1fcba6bf6c36abea71309a1e (commit) via 45e01e55c96d9abf8c73f6ee3766b16e5fbefc4d (commit) via 6d99a15f0bd9cba4500808114738065903312bf6 (commit) via a6ae5f0a04cd3cac70525f073bdb11e4bb9266e5 (commit) via b4e4b74acea3d652317b030e761300d5c7b437a2 (commit) via bcacb00fc89c04ec0b5e7ebefe3b605b266cef57 (commit) from 48752f1b4b16cd1dad56649cd36b253494aa9ff1 (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. - Log - commit 2a792ac7bb1ceda42767c696e2664819b47ffc3b Author: Eli Schwartz Date: Sun Oct 6 23:11:20 2019 -0400 pacman-key: clean keys on import to remove unknown signatures There is no good reason to bloat the keyring by importing tons of signatures we cannot use; drop any signatures that don't validate against another available key (probably the master keys). If any desired signatures get cleaned, the key can be refreshed after importing the new signing public key. Signed-off-by: Eli Schwartz Signed-off-by: Allan McRae commit f49233903521f19a1fcba6bf6c36abea71309a1e Author: Eli Schwartz Date: Sun Oct 6 23:11:19 2019 -0400 pacman-key: make sure we actually use the Web of Trust, which GnuPG doesn't. By default, the latest versions of GnuPG disable the Web of Trust and refuse to import signatures from public keyservers. This is to prevent denial of service attacks, because refusing to import signatures only if the key size is too big, is apparently too silly to consider. Either way, pacman needs the WoT. If pacman imports a key at all, it means everything failed and we are in fallback mode, trying to overcome a shortcoming in the availability of keys in the keyring package. (This commonly means the user needs to acquire a new key during the same transaction that updates archlinux-keyring.) In order for that new key to be usable, it *must* also import signatures from the Master Keys. I don't give credence to this supposed DoS, since the worst case scenario is nothing happening and needing to CTRL+C in order to exit the program. In the case of pacman, this is better than being unable to install anything at all (which is gnupg doing a much more harmful DoS to pacman), and in the already unusual case where something like --refresh-keys is being used directly instead of depending on the keyring package itself, gnupg supports WKD out of the box and will prefer that for people whose keys are marketed as being non-DOSable. Signed-off-by: Eli Schwartz Signed-off-by: Allan McRae commit 45e01e55c96d9abf8c73f6ee3766b16e5fbefc4d Author: Eli Schwartz Date: Mon Aug 5 12:53:09 2019 -0400 pacman-key: when refreshing gpg.conf, don't truncate option checking If an option is a two-part option, we print both (separated by IFS=' '), but when grepping to see if it already exists, we only checked the first component. This means that something like keyserver-options could only check if there were existing keyserver options of any sort, but not which ones. Signed-off-by: Eli Schwartz Signed-off-by: Allan McRae commit 6d99a15f0bd9cba4500808114738065903312bf6 Author: Matthew Sexton Date: Tue Sep 10 05:33:53 2019 -0400 pacman/pacman-conf, testpkg: Added translatable strings Added gettext macro to warnings, helps, and errors for translation. Signed-off-by: Matthew Sexton Signed-off-by: Allan McRae commit a6ae5f0a04cd3cac70525f073bdb11e4bb9266e5 Author: Matthew Sexton Date: Sun Sep 8 22:52:57 2019 -0400 pacman: pacman-conf: removed hputs macro for usage display Using the macro got in the way of _() macro for translation All the macro did was make it so the writer didn't have to type \n", stream); at the end of every line. Signed-off-by: Allan McRae commit b4e4b74acea3d652317b030e761300d5c7b437a2 Author: morganamilo Date: Sun Sep 8 22:45:27 2019 +0100 libalpm: resolvedep(): don't compare names twice If we failed to get the pkg from pkgcache then we know no satisfying package exists by name. So only compare provides. Signed-off-by: Allan McRae commit bcacb00fc89c04ec0b5e7ebefe3b605b266cef57 Author: Eli Schwartz Date: Sun Oct 6 21:33:41 2019 -0400 makepkg: add rust support for *FLAGS and debug-prefix-map The rust language supports $RUSTFLAGS to be used automatically in all rustc
[pacman-dev] [PATCH v2 3/3] pacman-key: clean keys on import to remove unknown signatures
There is no good reason to bloat the keyring by importing tons of
signatures we cannot use; drop any signatures that don't validate
against another available key (probably the master keys).
If any desired signatures get cleaned, the key can be refreshed after
importing the new signing public key.
Signed-off-by: Eli Schwartz
---
v3: introduce new followup which adds import-clean -- it has been around
for some time, and seems generally useful even if not directly
applicable to WoT fixes, so let us seize the opportunity to implement
it.
scripts/pacman-key.sh.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in
index 93600bc0..117acc40 100644
--- a/scripts/pacman-key.sh.in
+++ b/scripts/pacman-key.sh.in
@@ -209,6 +209,7 @@ initialize() {
add_gpg_conf_option "$conffile" 'no-permission-warning'
add_gpg_conf_option "$conffile" 'lock-never'
add_gpg_conf_option "$conffile" 'keyserver-options' 'timeout=10'
+ add_gpg_conf_option "$conffile" 'keyserver-options' 'import-clean'
local gpg_ver=$(gpg --version | awk '{print $3; exit}')
if (( $(vercmp "$gpg_ver" 2.2.17) >= 0 )); then
--
2.23.0
[pacman-dev] [PATCH v2 2/3] pacman-key: make sure we actually use the Web of Trust, which GnuPG doesn't.
By default, the latest versions of GnuPG disable the Web of Trust and
refuse to import signatures from public keyservers. This is to prevent
denial of service attacks, because refusing to import signatures only if
the key size is too big, is apparently too silly to consider.
Either way, pacman needs the WoT. If pacman imports a key at all, it
means everything failed and we are in fallback mode, trying to overcome
a shortcoming in the availability of keys in the keyring package.
(This commonly means the user needs to acquire a new key during the same
transaction that updates archlinux-keyring.)
In order for that new key to be usable, it *must* also import signatures
from the Master Keys.
I don't give credence to this supposed DoS, since the worst case
scenario is nothing happening and needing to CTRL+C in order to exit the
program. In the case of pacman, this is better than being unable to
install anything at all (which is gnupg doing a much more harmful DoS to
pacman), and in the already unusual case where something like
--refresh-keys is being used directly instead of depending on the
keyring package itself, gnupg supports WKD out of the box and will
prefer that for people whose keys are marketed as being non-DOSable.
Signed-off-by: Eli Schwartz
---
v2: drop no-import-clean as it is out of scope of this proposed change
and doesn't seem to aid the cause.
It is sufficient to avoid self-sigs-only for our purposes.
scripts/pacman-key.sh.in | 5 +
1 file changed, 5 insertions(+)
diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in
index c3b02850..93600bc0 100644
--- a/scripts/pacman-key.sh.in
+++ b/scripts/pacman-key.sh.in
@@ -210,6 +210,11 @@ initialize() {
add_gpg_conf_option "$conffile" 'lock-never'
add_gpg_conf_option "$conffile" 'keyserver-options' 'timeout=10'
+ local gpg_ver=$(gpg --version | awk '{print $3; exit}')
+ if (( $(vercmp "$gpg_ver" 2.2.17) >= 0 )); then
+ add_gpg_conf_option "$conffile" 'keyserver-options'
'no-self-sigs-only'
+ fi
+
# gpg-agent.conf
agent_conffile="${PACMAN_KEYRING_DIR}/gpg-agent.conf"
[[ -f $agent_conffile ]] || touch "$agent_conffile"
--
2.23.0
Re: [pacman-dev] [PATCH 2/2] pacman-key: make sure we actually use the Web of Trust, which GnuPG doesn't.
On 7/10/19 12:53 pm, Eli Schwartz wrote: > On 10/6/19 10:42 PM, Allan McRae wrote: >>> + if (( $(vercmp "$gpg_ver" 2.2.17) >= 0 )); then >>> + add_gpg_conf_option "$conffile" 'keyserver-options' >>> 'no-self-sigs-only,no-import-clean' >> >> Doesn't import-clean actually do what we want? Strips signatures from >> keys not in the keyring? Assuming users are not setting up the initial >> keyring by importing keys manually... > > Hmm, on second thought you're right. no-self-sigs-only will prevent the > main thing that annoys us, which is getting rid of sigs we want because > we have the WoT keys which match it. > > no-import-clean would return us to feature parity with the older gnupg > releases, but that's not the fundamental goal, and the only benefit it > would get us is being able to later on import a master key and have it > validate, which seems like an unlikely event. Anyway, it seems like > refreshing that key would re-acquire the cleaned signatures. > > Do you want to leave the import-clean setting out entirely, or take the > opportunity to start having the keyring be guaranteed to be cleaned? > no-self-sigs-only,import-clean seems a good trade off as default
Re: [pacman-dev] [PATCH 2/2] pacman-key: make sure we actually use the Web of Trust, which GnuPG doesn't.
On 10/6/19 10:42 PM, Allan McRae wrote: >> +if (( $(vercmp "$gpg_ver" 2.2.17) >= 0 )); then >> +add_gpg_conf_option "$conffile" 'keyserver-options' >> 'no-self-sigs-only,no-import-clean' > > Doesn't import-clean actually do what we want? Strips signatures from > keys not in the keyring? Assuming users are not setting up the initial > keyring by importing keys manually... Hmm, on second thought you're right. no-self-sigs-only will prevent the main thing that annoys us, which is getting rid of sigs we want because we have the WoT keys which match it. no-import-clean would return us to feature parity with the older gnupg releases, but that's not the fundamental goal, and the only benefit it would get us is being able to later on import a master key and have it validate, which seems like an unlikely event. Anyway, it seems like refreshing that key would re-acquire the cleaned signatures. Do you want to leave the import-clean setting out entirely, or take the opportunity to start having the keyring be guaranteed to be cleaned? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [pacman-dev] [PATCH 2/2] pacman-key: make sure we actually use the Web of Trust, which GnuPG doesn't.
On 6/8/19 2:53 am, Eli Schwartz wrote:
> By default, the latest versions of GnuPG disable the Web of Trust and
> refuse to import signatures from public keyservers. This is to prevent
> denial of service attacks, because refusing to import signatures only if
> the key size is too big, is apparently too silly to consider.
>
> Either way, pacman needs the WoT. If pacman imports a key at all, it
> means everything failed and we are in fallback mode, trying to overcome
> a shortcoming in the availability of keys in the keyring package.
> (This commonly means the user needs to acquire a new key during the same
> transaction that updates archlinux-keyring.)
> In order for that new key to be usable, it *must* also import signatures
> from the Master Keys.
>
> I don't give credence to this supposed DoS, since the worst case
> scenario is nothing happening and needing to CTRL+C in order to exit the
> program. In the case of pacman, this is better than being unable to
> install anything at all (which is gnupg doing a much more harmful DoS to
> pacman), and in the already unusual case where something like
> --refresh-keys is being used directly instead of depending on the
> keyring package itself, gnupg supports WKD out of the box and will
> prefer that for people whose keys are marketed as being non-DOSable.
>
> Signed-off-by: Eli Schwartz
> ---
>
> I've been sitting on this for a bit, but this does seem to be the best
> way to implement a reversion to the old method.
I think this fine.
> Feel free to bikeshed
> about version checks in pacman-key!
Well... see below...
> This is independent of the WKD patchset, and works for people without
> @archlinux.org uids, or more generally for pacman downstreams that don't
> have a WKD infrastructure.
>
> In the long run, I expect the keyservers to implement less insane DoS
> mitigations, for example, an evolution of hagrid that supports mutually
> signed keys. I don't know if I should hold my breath waiting for gnupg
> to get proper error checking, though!
> Once proper mitigations exist, we'd need to disable the builtin default
> self-sigs-only,import-clean anyway, assuming gnupg itself didn't roll
> back these settings.
>
> scripts/pacman-key.sh.in | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/scripts/pacman-key.sh.in b/scripts/pacman-key.sh.in
> index c3b02850..d6ba0e3b 100644
> --- a/scripts/pacman-key.sh.in
> +++ b/scripts/pacman-key.sh.in
> @@ -210,6 +210,11 @@ initialize() {
> add_gpg_conf_option "$conffile" 'lock-never'
> add_gpg_conf_option "$conffile" 'keyserver-options' 'timeout=10'
>
> + local gpg_ver=$(gpg --version | awk '{print $3; exit}')
I very much dislike relying on output format from some other piece of
software. But looking at the gpg code, this is quite stable, so allowable.
> + if (( $(vercmp "$gpg_ver" 2.2.17) >= 0 )); then
> + add_gpg_conf_option "$conffile" 'keyserver-options'
> 'no-self-sigs-only,no-import-clean'
Doesn't import-clean actually do what we want? Strips signatures from
keys not in the keyring? Assuming users are not setting up the initial
keyring by importing keys manually...
> + fi
> +
> # gpg-agent.conf
> agent_conffile="${PACMAN_KEYRING_DIR}/gpg-agent.conf"
> [[ -f $agent_conffile ]] || touch "$agent_conffile"
>
Re: [pacman-dev] [PATCH 2/4] libalpm: resolvedep(): don't compare names twice
On 9/9/19 7:45 am, morganamilo wrote:
> If we failed to get the pkg from pkgcache then we know no satisfying
> package exists by name. So only compare provides.
> ---
> lib/libalpm/deps.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Thanks. Applied.
> diff --git a/lib/libalpm/deps.c b/lib/libalpm/deps.c
> index ce7869c3..322c4e7e 100644
> --- a/lib/libalpm/deps.c
> +++ b/lib/libalpm/deps.c
> @@ -698,7 +698,8 @@ static alpm_pkg_t *resolvedep(alpm_handle_t *handle,
> alpm_depend_t *dep,
> for(j = _alpm_db_get_pkgcache(db); j; j = j->next) {
> alpm_pkg_t *pkg = j->data;
> if((pkg->name_hash != dep->name_hash ||
> strcmp(pkg->name, dep->name) != 0)
> - && _alpm_depcmp(pkg, dep) &&
> !alpm_pkg_find(excluding, pkg->name)) {
> + && _alpm_depcmp_provides(dep,
> alpm_pkg_get_provides(pkg))
> + && !alpm_pkg_find(excluding,
> pkg->name)) {
> if(alpm_pkg_should_ignore(handle, pkg)) {
> alpm_question_install_ignorepkg_t
> question = {
> .type =
> ALPM_QUESTION_INSTALL_IGNOREPKG,
>
Re: [pacman-dev] [PATCH v2] libmakepkg: when stripping split debug symbols, warn on duplicate paths
On 7/10/19 11:29 am, Eli Schwartz wrote:
> Trying to strip multiple files installed to the same filepath (in
> different components of a split package) can produce surprising results
> if those files are built using different options. Per FS#63356 this is
> not a supported PKGBUILD configuration. Instead, warn about such cases
> when producing debug packages.
>
> Fixes FS#63366
>
> Signed-off-by: Eli Schwartz
> ---
>
> v2: fix leading "./" in reported paths
>
> scripts/libmakepkg/tidy/strip.sh.in | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/libmakepkg/tidy/strip.sh.in
> b/scripts/libmakepkg/tidy/strip.sh.in
> index 5bc0a842..892daf49 100644
> --- a/scripts/libmakepkg/tidy/strip.sh.in
> +++ b/scripts/libmakepkg/tidy/strip.sh.in
> @@ -46,7 +46,13 @@ strip_file() {
> if check_option "debug" "y"; then
> local bid=$(build_id "$binary")
>
> - # has this file already been stripped
> + # has this filepath been stripped before under a different
> Build Id
> + if [[ -f "$dbgdir/$binary.debug" ]]; then
> + if [[ -n $bid && $bid != $(build_id
> "$dbgdir/$binary.debug") ]]; then
> + warning "Split package with multiple copies of
> the file '%s' have different Build Ids" "${binary#./}"
I suggest adding a consequence line after. e.g.
warning "Debug symbols are included for the first copy only"
> + fi
> + fi
> + # has this file's hardlink already been stripped
> if [[ -n "$bid" ]]; then
> if [[ -f "$dbgdir/.build-id/${bid:0:2}/${bid:2}.debug"
> ]]; then
> return
>
Re: [pacman-dev] [PATCH v3] makepkg: add rust support for *FLAGS and debug-prefix-map
On 7/10/19 11:33 am, Eli Schwartz wrote: > The rust language supports $RUSTFLAGS to be used automatically in all > rustc invocations. Allow setting this in makepkg.conf (e.g. for > optimization or debuginfo support), and teach debug+strip to pass the > rustc command line argument necessary to rewrite source file paths in > the debugging symbols. > > Signed-off-by: Eli Schwartz > --- > > v3: fix typo, srdir -> srcdir > Ack - with my comment remaining that makepkg.conf is getting to long and we should investigate something like including /etc/makepkg.conf.d/rustflags in the future. This serves as notice that future additions may be delayed until this is implemented... Allan
[pacman-dev] [PATCH v3] makepkg: add rust support for *FLAGS and debug-prefix-map
The rust language supports $RUSTFLAGS to be used automatically in all
rustc invocations. Allow setting this in makepkg.conf (e.g. for
optimization or debuginfo support), and teach debug+strip to pass the
rustc command line argument necessary to rewrite source file paths in
the debugging symbols.
Signed-off-by: Eli Schwartz
---
v3: fix typo, srdir -> srcdir
doc/makepkg.conf.5.asciidoc | 9 +
etc/makepkg.conf.in | 2 ++
scripts/libmakepkg/buildenv.sh.in | 2 +-
scripts/libmakepkg/buildenv/buildflags.sh.in | 2 +-
scripts/libmakepkg/buildenv/debugflags.sh.in | 2 ++
scripts/libmakepkg/lint_config/variable.sh.in | 8
6 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/doc/makepkg.conf.5.asciidoc b/doc/makepkg.conf.5.asciidoc
index 9292b2a6..3f37190d 100644
--- a/doc/makepkg.conf.5.asciidoc
+++ b/doc/makepkg.conf.5.asciidoc
@@ -72,6 +72,10 @@ Options
**CXXFLAGS=**"cxxflags"::
Flags used for the C++ compiler; see CFLAGS for more info.
+**RUSTFLAGS=**"rustflags"::
+ Flags used for the Rust compiler, similar in spirit to CFLAGS. Read
+ linkman:rustc[1] for more details on the available flags.
+
**LDFLAGS=**"ldflags"::
Flags used for the linker. Several options may be specified with common
usage resembling ``-Wl,--hash-style=gnu''. Read ld(1) for more details
on
@@ -89,6 +93,11 @@ Options
**DEBUG_CXXFLAGS=**"debug_cxxflags"::
Debug flags used for the C++ compiler; see DEBUG_CFLAGS for more info.
+**DEBUG_RUSTFLAGS=**"debug_rustflags"::
+ Additional compiler flags appended to `RUSTFLAGS` for use in debugging.
+ Usually this would include: ``-C debuginfo=2''. Read linkman:rustc[1]
for
+ more details on the available flags.
+
**BUILDENV=(**!distcc !color !ccache check !sign**)**::
This array contains options that affect the build environment; the
defaults
are shown here. All options should always be left in the array; to
enable
diff --git a/etc/makepkg.conf.in b/etc/makepkg.conf.in
index 7e5da993..caf5114b 100644
--- a/etc/makepkg.conf.in
+++ b/etc/makepkg.conf.in
@@ -40,11 +40,13 @@ CHOST="@CHOST@"
#CFLAGS="-O2 -pipe"
#CXXFLAGS="-O2 -pipe"
#LDFLAGS=""
+#RUSTFLAGS="-C opt-level=2"
#-- Make Flags: change this for DistCC/SMP systems
#MAKEFLAGS="-j2"
#-- Debugging flags
#DEBUG_CFLAGS="-g"
#DEBUG_CXXFLAGS="-g"
+#DEBUG_RUSTFLAGS="-C debuginfo=2"
#
# BUILD ENVIRONMENT
diff --git a/scripts/libmakepkg/buildenv.sh.in
b/scripts/libmakepkg/buildenv.sh.in
index a8d416c8..2ecd741e 100644
--- a/scripts/libmakepkg/buildenv.sh.in
+++ b/scripts/libmakepkg/buildenv.sh.in
@@ -36,5 +36,5 @@ prepare_buildenv() {
done
# ensure all necessary build variables are exported
- export CPPFLAGS CFLAGS CXXFLAGS LDFLAGS MAKEFLAGS CHOST
+ export CPPFLAGS CFLAGS CXXFLAGS LDFLAGS RUSTFLAGS MAKEFLAGS CHOST
}
diff --git a/scripts/libmakepkg/buildenv/buildflags.sh.in
b/scripts/libmakepkg/buildenv/buildflags.sh.in
index daccc9cc..85ee80fc 100644
--- a/scripts/libmakepkg/buildenv/buildflags.sh.in
+++ b/scripts/libmakepkg/buildenv/buildflags.sh.in
@@ -30,6 +30,6 @@ buildenv_functions+=('buildenv_buildflags')
buildenv_buildflags() {
if check_option "buildflags" "n"; then
- unset CPPFLAGS CFLAGS DEBUG_CFLAGS CXXFLAGS DEBUG_CXXFLAGS
LDFLAGS
+ unset CPPFLAGS CFLAGS DEBUG_CFLAGS CXXFLAGS DEBUG_CXXFLAGS
LDFLAGS RUSTFLAGS DEBUG_RUSTFLAGS
fi
}
diff --git a/scripts/libmakepkg/buildenv/debugflags.sh.in
b/scripts/libmakepkg/buildenv/debugflags.sh.in
index ce9c1556..4cd5d003 100644
--- a/scripts/libmakepkg/buildenv/debugflags.sh.in
+++ b/scripts/libmakepkg/buildenv/debugflags.sh.in
@@ -32,7 +32,9 @@ buildenv_debugflags() {
if check_option "debug" "y"; then
DEBUG_CFLAGS+="
-fdebug-prefix-map=$srcdir=${DBGSRCDIR:-/usr/src/debug}"
DEBUG_CXXFLAGS+="
-fdebug-prefix-map=$srcdir=${DBGSRCDIR:-/usr/src/debug}"
+ DEBUG_RUSTFLAGS+="
--remap-path-prefix=$srcdir=${DBGSRCDIR:-/usr/src/debug}"
CFLAGS+=" $DEBUG_CFLAGS"
CXXFLAGS+=" $DEBUG_CXXFLAGS"
+ RUSTFLAGS+=" $DEBUG_RUSTFLAGS"
fi
}
diff --git a/scripts/libmakepkg/lint_config/variable.sh.in
b/scripts/libmakepkg/lint_config/variable.sh.in
index 55ed6d6d..e73e13de 100644
--- a/scripts/libmakepkg/lint_config/variable.sh.in
+++ b/scripts/libmakepkg/lint_config/variable.sh.in
@@ -32,10 +32,10 @@ lint_config_variables() {
local array=(DLAGENTS VCSCLIENTS BUILDENV OPTIONS INTEGRITY_CHECK
MAN_DIRS
DOC_DIRS PURGE_TARGETS COMPRESSGZ COMPRESSBZ2 COMPRESSXZ
COMPRESSLRZ COMPRESSLZO COMPRESSZ)
- local string=(CARCH CHOST CPPFLAGS CFLAGS CXXFLAGS LDFLAGS DEBUG_CFLAGS
- DEBUG_CXXFLAGS DISTCC_HOSTS BUILDDIR
[pacman-dev] [PATCH v2] libmakepkg: when stripping split debug symbols, warn on duplicate paths
Trying to strip multiple files installed to the same filepath (in
different components of a split package) can produce surprising results
if those files are built using different options. Per FS#63356 this is
not a supported PKGBUILD configuration. Instead, warn about such cases
when producing debug packages.
Fixes FS#63366
Signed-off-by: Eli Schwartz
---
v2: fix leading "./" in reported paths
scripts/libmakepkg/tidy/strip.sh.in | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/scripts/libmakepkg/tidy/strip.sh.in
b/scripts/libmakepkg/tidy/strip.sh.in
index 5bc0a842..892daf49 100644
--- a/scripts/libmakepkg/tidy/strip.sh.in
+++ b/scripts/libmakepkg/tidy/strip.sh.in
@@ -46,7 +46,13 @@ strip_file() {
if check_option "debug" "y"; then
local bid=$(build_id "$binary")
- # has this file already been stripped
+ # has this filepath been stripped before under a different
Build Id
+ if [[ -f "$dbgdir/$binary.debug" ]]; then
+ if [[ -n $bid && $bid != $(build_id
"$dbgdir/$binary.debug") ]]; then
+ warning "Split package with multiple copies of
the file '%s' have different Build Ids" "${binary#./}"
+ fi
+ fi
+ # has this file's hardlink already been stripped
if [[ -n "$bid" ]]; then
if [[ -f "$dbgdir/.build-id/${bid:0:2}/${bid:2}.debug"
]]; then
return
--
2.23.0
[pacman-dev] [GIT] The official pacman repository branch, master, updated. v5.1.1-207-g48752f1b
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 48752f1b4b16cd1dad56649cd36b253494aa9ff1 (commit) via 80e2e1c7c9f2cc2795f497f2101b0aeb7b7e8638 (commit) via 0c4a8ae24b8395b0dd4f8046615336e394a8e3f8 (commit) via 5dd2b3776dedd85c196be737ea9c177216448756 (commit) via fd70c1c7bb0cb0681ab8a46d5f0494e0f9d992c6 (commit) via 6f3810793f4b1fc82094ccb1847ed82b85a203e6 (commit) via bcb44891ef8aa6feee3090cc0fd87b60e73aed5d (commit) from 024fde9748692c71f0d9e6c667439c912a78b6df (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. - Log - commit 48752f1b4b16cd1dad56649cd36b253494aa9ff1 Author: Jonas Witschel Date: Wed Oct 2 16:40:55 2019 +0200 signing: add ability to import keys using a WKD Currently pacman relies on the SKS keyserver network to fetch unknown PGP keys. These keyservers are vulnerable to signature spamming attacks, potentionally making it impossible to import the required keys. An alternative to keyservers is a so-called Web Key Directory (WKD), a well-known, trusted location on a server from where the keys can be fetched. This commit adds the ability to retrieve keys from a WKD. Due to the mentioned vulnerabilities, the WKD is tried first, falling back to the keyservers only if no appropriate key is found there. In contrast to keyservers, keys in a WKD are not looked up using their fingerprint, but by email address. Since the email address of the signing key is usually not included in the signature, we will use the packager email address to perform the lookup. Also see FS#63171. Signed-off-by: Jonas Witschel Signed-off-by: Allan McRae commit 80e2e1c7c9f2cc2795f497f2101b0aeb7b7e8638 Author: Jonas Witschel Date: Wed Oct 2 16:40:54 2019 +0200 signing: move key import confirmation before key_search Ask the user whether they want to import a missing key before even doing a search on the keyserver. This will be useful for getting Web Key Directory support in place: for a WKD, looking up and importing a key are a single action, so the current key_search -> QUESTION -> key_import workflow does not apply. Since only the ID of the package signing key is available before key_search, we display the packager variable in addition to the key ID for user convenience. Signed-off-by: Jonas Witschel Signed-off-by: Allan McRae commit 0c4a8ae24b8395b0dd4f8046615336e394a8e3f8 Author: Dave Reisner Date: Sun Oct 6 20:06:43 2019 -0400 dload: never return NULL from get_filename Downloads with a Content-Disposition header will typically not include slashes. When they do, we should most certainly only take the basename, but when they don't, we should treat the header value as the filename. Crash introduced in d197d8ab82cf when we started using get_filename in order to rightfully avoid an arbitrary file overwrite vulnerability. Signed-off-by: Allan McRae commit 5dd2b3776dedd85c196be737ea9c177216448756 Author: Allan McRae Date: Fri Oct 4 11:53:04 2019 +1000 makepkg.conf.5: Document PACKAGER format requirements Signed-off-by: Allan McRae commit fd70c1c7bb0cb0681ab8a46d5f0494e0f9d992c6 Author: Jonas Witschel Date: Wed Oct 2 16:40:56 2019 +0200 libmakepkg: check if PACKAGER has the expected format for WKD lookup pacman should be able to extract an email address from PACKAGER for WKD lookup, so issue a warning if it is not of the form "Example Name ". Neither the name nor the email address must contain additional angle brackets. Signed-off-by: Jonas Witschel Signed-off-by: Allan McRae commit 6f3810793f4b1fc82094ccb1847ed82b85a203e6 Author: morganamilo Date: Mon Sep 9 19:39:09 2019 +0100 libmakepkg: fix typo Signed-off-by: Allan McRae commit bcb44891ef8aa6feee3090cc0fd87b60e73aed5d Author: Eli Schwartz Date: Thu Aug 15 19:55:45 2019 -0400 autotools: distribute meson files If we use make dist to create the official, signed release tarballs, those will not have meson build files by default since autotools doesn't know what they are. Also distribute all src/common/ files. We never strictly needed any of them to be distributed with autotools, because the dist tarball dereferences the symlinks (???), but only some of them were being distributed, and meson needs them to be in the right location as we only build libcommon from the primary files. Signed-off-by: Eli Schwartz
Re: [pacman-dev] [PATCH v3 2/3] signing: add ability to import keys using a WKD
On 3/10/19 12:40 am, Jonas Witschel wrote:
> Currently pacman relies on the SKS keyserver network to fetch unknown
> PGP keys. These keyservers are vulnerable to signature spamming attacks,
> potentionally making it impossible to import the required keys. An
> alternative to keyservers is a so-called Web Key Directory (WKD), a
> well-known, trusted location on a server from where the keys can be
> fetched.
>
> This commit adds the ability to retrieve keys from a WKD. Due to the
> mentioned vulnerabilities, the WKD is tried first, falling back to the
> keyservers only if no appropriate key is found there.
>
> In contrast to keyservers, keys in a WKD are not looked up using their
> fingerprint, but by email address. Since the email address of the
> signing key is usually not included in the signature, we will use the
> packager email address to perform the lookup.
>
> Also see FS#63171.
>
> Signed-off-by: Jonas Witschel
> ---
> lib/libalpm/signing.c | 96 +--
> 1 file changed, 83 insertions(+), 13 deletions(-)
>
Thanks - looks good apart from one change I made:
> + /* Try to import the key from a WKD first */
> + email_from_uid(uid, );
> + ret = key_import_wkd(handle, email);
CC libalpm_la-signing.lo
signing.c: In function ‘_alpm_key_import’:
signing.c:285:12: error: ‘email’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
285 | gpg_err = gpgme_get_key(ctx, email, , 0);
|^~
signing.c:506:8: note: ‘email’ was declared here
506 | char *email;
|^
cc1: all warnings being treated as errors
if(email_from_uid(uid, ) == 0) {
ret = key_import_wkd(handle, email);
}
Re: [pacman-dev] [PATCH] dload: never return NULL from get_filename
On 7/10/19 10:06 am, Dave Reisner wrote: > Downloads with a Content-Disposition header will typically not include > slashes. When they do, we should most certainly only take the basename, > but when they don't, we should treat the header value as the filename. > > Crash introduced in d197d8ab82cf when we started using get_filename > in order to rightfully avoid an arbitrary file overwrite vulnerability. > --- > lib/libalpm/dload.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Pulled. A
[pacman-dev] [PATCH] dload: never return NULL from get_filename
Downloads with a Content-Disposition header will typically not include
slashes. When they do, we should most certainly only take the basename,
but when they don't, we should treat the header value as the filename.
Crash introduced in d197d8ab82cf when we started using get_filename
in order to rightfully avoid an arbitrary file overwrite vulnerability.
---
lib/libalpm/dload.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c
index e5696bb0..506dcb8e 100644
--- a/lib/libalpm/dload.c
+++ b/lib/libalpm/dload.c
@@ -53,9 +53,11 @@ static const char *get_filename(const char *url)
{
char *filename = strrchr(url, '/');
if(filename != NULL) {
- filename++;
+ return filename + 1;
}
- return filename;
+
+ /* no slash found, it's a filename */
+ return url;
}
static char *get_fullpath(const char *path, const char *filename,
--
2.23.0
