February 2020 - Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH] Add pacman-hooks.5 man page symlink
by Allan McRae 10 Feb '20

10 Feb '20

Improve discoverability of the alpm-hooks man page by adding a pacman-hooks symlink. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- doc/Makefile.am | 13 ++++++++++++- doc/meson.build | 4 ++++ 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/doc/Makefile.am b/doc/Makefile.am index c61110fc..4de67566 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -47,7 +47,8 @@ EXTRA_DIST = \ $(DOXYGEN_MANS) # Files that should be removed, but which Automake does not know. -MOSTLYCLEANFILES = *.xml $(MANPAGES) $(HTML_DOCS) repo-remove.8 website.tar.gz +MOSTLYCLEANFILES = *.xml $(MANPAGES) $(HTML_DOCS) \ + pacman-hooks.5 repo-remove.8 website.tar.gz # Ensure manpages are fresh when building a dist tarball dist-hook: @@ -140,12 +141,22 @@ repo-remove.8: repo-add.8 $(RM) repo-remove.8 $(LN_S) repo-add.8 repo-remove.8 +pacman-hooks.5: alpm-hooks.5 + $(RM) pacman-hooks.5 + $(LN_S) alpm-hooks.5 pacman-hooks.5 + install-data-hook: cd $(DESTDIR)$(mandir)/man8 && \ $(RM) repo-remove.8 && \ ( $(LN_S) repo-add.8 repo-remove.8 || \ ln repo-add.8 repo-remove.8 || \ cp repo-add.8 repo-remove.8 ) + cd $(DESTDIR)$(mandir)/man5 && \ + $(RM) pacman-hooks.5 && \ + ( $(LN_S) alpm-hooks.5 pacman-hooks.5 || \ + ln alpm-hooks.5 pacman-hooks.5 || \ + cp alpm-hooks.5 pacman-hooks.5 ) uninstall-hook: $(RM) $(DESTDIR)$(mandir)/man8/repo-remove.8 + $(RM) $(DESTDIR)$(mandir)/man5/pacman-hooks.5 diff --git a/doc/meson.build b/doc/meson.build index a5bcd5b3..e24172fd 100644 --- a/doc/meson.build +++ b/doc/meson.build @@ -129,6 +129,10 @@ meson.add_install_script(MESON_MAKE_SYMLINK, 'repo-add.8', join_paths(MANDIR, 'man8/repo-remove.8')) +meson.add_install_script(MESON_MAKE_SYMLINK, + 'alpm-hooks.5', + join_paths(MANDIR, 'man5/pacman-hooks.5')) + doxygen = find_program('doxygen', required : get_option('doxygen')) if doxygen.found() and not get_option('doxygen').disabled() doxyconf = configuration_data() -- 2.25.0

1 0

[pacman-dev] [arch-general] Privilege separation in the pacman downloader (Was: Pacman Database Signatures)
by Eli Schwartz 07 Feb '20

07 Feb '20

On 2/2/20 4:59 PM, Christopher W. via arch-general wrote: > Right now, pacman is taking untrusted input from the internet as root. > That's very bad. Most of the comments I've seen say that an attacker > could hold back vulnerable packages, but this is assuming the attacker > does not have bigger plans. The pacman tool is not immune to bugs in > the way it parses the database files. It has no privilege separation > in the download/parsing code as far as I can see (apt and others have > had this for a long time) so it's really an even more dire situation. > Pacman should not perform any operations as root until it has verified > the signature of all files being used to install/upgrade the packages, > but it currently does everything (downloading, verifying, etc) as root. > > I'd like to get a discussion going about how and when these two issues > could be resolved so that all Arch users can be safer. Thanks. This is a more interesting topic to me, personally (as opposed to the first half of your email which I responded to separately) because it's a proposal for something that pacman itself could do better, without waiting on distro policy. It's also a discussion that will go nowhere, and then die alone, on arch-general, since pacman development and proposals happen exclusively on the pacman-dev mailing list. Therefore, I am cc'ing the pacman-dev mailing list so that this has a chance to go somewhere. :) Since I'm unfamiliar with apt and other tools, what exactly do they do? Given pacman/apt/your-choice-of-package-manager must somehow write to a cachedir, e.g. /var/cache/pacman/pkg, it would need a dedicated download user, which would then exclusively hold ownership of the cachedir. pacman is one big binary at the moment, it doesn't fork+exec to run collections of binaries implementing different parts of the package manager (which is actually a plus when it comes to speed), so this might entail major re-architecturing of that part of pacman. Doing it for external XferCommand programs could be a start. Is this a topic you're interested in exploring? -- Eli Schwartz Bug Wrangler and Trusted User

2 2

[pacman-dev] [PATCH] libmakepkg: when stripping split debug symbols, warn on duplicate paths
by Eli Schwartz 03 Feb '20

03 Feb '20

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 <eschwartz(a)archlinux.org> --- 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 5937e13c..eaa764b7 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.22.0

2 4