[arch-general] [pacman-dev] Privilege separation in the pacman downloader (Was: Pacman Database Signatures)
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 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Pacman Database Signatures
On 2/2/20 4:59 PM, Christopher W. via arch-general wrote: > Hi. The wiki states that database signatures for pacman are currently > a work in progress. It's been that way for a long time, so I assume > there is no "progress" happening. What is currently in the way of this > much-needed security feature to be fully implemented? As Levente said, this is supported by pacman, but not by Arch Linux -- and the reason for the latter is that it is complicated to come up with a signing scheme which everyone is happy with. It needs to support remote server signing by any of 74 different authorized individuals. Hopefully there will be wonderful news soon. In the meantime, I for one make sure that my personal repository hosted on https://pkgbuild.com includes database signatures. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Packages "jami-gnome" and "libjamiclient" out of date
Hi Bruno, *, happy to see You are alive ;o)) Am 03.02.20 um 01:39 schrieb Archange via arch-general: > Hi, > Le 3 février 2020 00:58:02 GMT+01:00, Friedrich Strohmaier > a écrit : [..] >> I retrieved the maintainers (Bruno Pagani) mail adress from this mailinglist. >> I suspect the mails didn't ever get there. > Yours did, but apparently my reply did not. I checked the mailserver logs for "archange" and Your gmail address but couldn't find anything suspicious with regard of one of them beeing blocked or something else. > So, as I’ve tried to say before, these updates are not straight-forward > because they have been some complex dependency changes, e.g. they switched to > unreleased versions of OpenDHT or restbed was ditched in favour of restinio. > I’ve already spent a bit of time trying to figure all this over Christmas, > but wasn’t able to figure everything out. And since then, I’ve considerably > lacked free time to spend into doing complex tasks for Arch. I hope this will > get better soon but I’m not very optimistic about it currently. Thank You for the explanation. I was afraid to hear something alike.. In fact I grabbed the PKGBUILD and gave it a shot, but the output is far beyond my skills to understand. > You’re free to submit working patches/PKGBUILDs for the new dependencies if > you want though, I’ll happily review and merge them. First thing to do is > figuring out which point of OpenDHT tree is required, whether it is suitable > for packaging, and what are the dependency changes in the tree up to this > point since the last release. I'm afraid I can't be of much help here. As I'm thinking about reporting bugs upstream, maybe this will be the first one ;o)) I am exited about the jami project - so let's see what I can contribute. Thank You for Your answer. -- Friedrich
Re: [arch-general] 5.5 kernel - Latest virtualbox testcase build for 5.2.37 fails to start Arch guest on Arch host
On 02/04/2020 12:42 PM, David C. Rankin wrote: > On 02/04/2020 04:18 AM, David C. Rankin wrote: >> lAll, >> >> After update to 5.5 kernel and rebuild of virtualbox from the 5.2.36 and >> the >> latest testcase build for 5.2.37 (all kernel modules build and load fine) >> >> https://www.virtualbox.org/download/testcase/VirtualBox-5.2.37-135942-Linux_amd64.run >> >> Arch guests fail to run on Arch host. network device enp0s3 not found, udev >> kernel rules fail, and the boot never complete. >> >> All fine with the 5.4 kernel. I've posted to the vbox-users list, but if >> anyone here has additional information I would appreciate it. >> > > This explains Virtualbox does not support the 5.5 kernel -- no fix yet: > > Ticket #19145 (accepted defect) > Opened 8 weeks ago > linux: kernel 5.5-rc1/rc2 - we need changes > https://www.virtualbox.org/ticket/19145 > OK, Need help from the smart folks. Downgrading the kernel/kernel-headers to 5.4.15 and downgrading virtualbox to the version working on 5.14 [testcase 5.2.35 (135458)] does not allow guests to start as they did before the last update to linux 5.5. Starting the guest headless - reports it started. However, when I open the guest via-rdesktop monitor the boot, but the boot process would not complete and could not create the network interface enp0s3, the udev kernel device manager will not start, the boot process cannot flush the journal to persistent storage (??) and boot cannot create volatile files and directories (??) All modules build for each version of virtualbox. (5.2.35, 5.2.36 and testcase 5.2.37 (135942)). I have tried on the downgraded 5.4.15 and LTS. There is no combination that will start the virtualbox guests as before. There must be another package that was updated that comes into play (python?). Is anyone else experiencing problems with Virtualbox and has anyone else seen similar behavior? Any workarounds. I have a number of virtualbox guests I use. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] 5.5 kernel - Latest virtualbox testcase build for 5.2.37 fails to start Arch guest on Arch host
On 02/04/2020 04:18 AM, David C. Rankin wrote: > lAll, > > After update to 5.5 kernel and rebuild of virtualbox from the 5.2.36 and the > latest testcase build for 5.2.37 (all kernel modules build and load fine) > > https://www.virtualbox.org/download/testcase/VirtualBox-5.2.37-135942-Linux_amd64.run > > Arch guests fail to run on Arch host. network device enp0s3 not found, udev > kernel rules fail, and the boot never complete. > > All fine with the 5.4 kernel. I've posted to the vbox-users list, but if > anyone here has additional information I would appreciate it. > This explains Virtualbox does not support the 5.5 kernel -- no fix yet: Ticket #19145 (accepted defect) Opened 8 weeks ago linux: kernel 5.5-rc1/rc2 - we need changes https://www.virtualbox.org/ticket/19145 -- David C. Rankin, J.D.,P.E.
[arch-general] 5.5 kernel - Latest virtualbox testcase build for 5.2.37 fails to start Arch guest on Arch host
lAll, After update to 5.5 kernel and rebuild of virtualbox from the 5.2.36 and the latest testcase build for 5.2.37 (all kernel modules build and load fine) https://www.virtualbox.org/download/testcase/VirtualBox-5.2.37-135942-Linux_amd64.run Arch guests fail to run on Arch host. network device enp0s3 not found, udev kernel rules fail, and the boot never complete. All fine with the 5.4 kernel. I've posted to the vbox-users list, but if anyone here has additional information I would appreciate it. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] omega won't build
Correction, it was the ncurses-5-compat package with the missing gpg key not ncurses-6. I found that out by ignoring all gpg checks and the other thing with pikaur is it didn't keep the gpg key that was unknown on the screen long enough for me to check with gpg2 and possibly import it. --
