Re: [arch-general] Clarification on pacman signature verification
On 01/25/2016 01:35 PM, Solomon Lam wrote: > Thanks for the reply. I think I got my answer. > > I noticed that the 'desc' file of a package(inside the db) contains 'md5' > and 'sha256' checksums as well. So, does pacman perform pgp verification or > checksum verification during installation? It just uses the best verification available. Test it by running `pacman -Sw --debug somepackage` Any package in the main repos will have a signature -- it will only verify that. A custom repo for AUR packages (I keep one) will likely not be signed, and if not will be verified with sha256sum. md5sum is only there for old times' sake I think. I guess if you have a repo generated by really old versions of repo-add, it will only have an md5sum and verify that. -- Eli Schwartz
Re: [arch-general] Clarification on pacman signature verification
Thanks for the reply. I think I got my answer. I noticed that the 'desc' file of a package(inside the db) contains 'md5' and 'sha256' checksums as well. So, does pacman perform pgp verification or checksum verification during installation? On Mon, Jan 25, 2016 at 8:08 PM, Eli Schwartz wrote: > On 01/25/2016 04:43 AM, Solomon Lam wrote: > > Hi, This is regarding package verification performed by pacman. > > > > Does pacman download the .sig file of a package while installing one? > All I > > could find are the local cached copies of packages only but not their > > signatures. If thats the case, how does pacman verify the integrity of > the > > downloaded package? > > It could be that .sig file could have been downloaded into /tmp during > > installation or to another location that I'm not aware yet. This brings > me > > to my next point. > > > > I've manually downloaded just the package file (of some random package) > > from a mirror and disconnected from the Internet. I used both 'pacman -U > > ' and 'pacman -S ' to install the package and the > > installation went just fine. I was expecting Pacman to emit an error > > stating that signature was missing but nothing happened. Could someone > care > > to explain this. > > BTW, I have SigLevel = Required DatabaseOptional in my pacman.conf. > > > > - Solomon > > > > Packages from the Sync database have their signatures (if any) embedded > in the db itself. > > If you really don't trust your own computer, set: > LocalFileSigLevel = Required > > That will make installing AUR packages slightly awkward... > > > Local files default to Optional, Remote files to Required, so if you use > `pacman -U http://address.of/package.tar.xz` then it will download the > package *and* signature for you, once there is a *.sig pacman will > demand it be a valid one. > > -- > Eli Schwartz >
Re: [arch-general] [tor] User and group entries are left over in passwd and gshadow after removal, makes pwck and shadow.service fail
On Mon, 25 Jan 2016 17:45:17 +0100 Doug Newgard wrote: Dev discussion here: https://lists.archlinux.org/pipermail/arch-dev-public/2015-February/026953.html Thanks, that's the context I needed to understand your decision. Reading the dev discussion and the clear consensus emerging from it, I wonder about corner (?) cases like tor where an important service fails due to the absence of user removal in package management. Central to this particular issue is the specification of a home directory which is deleted upon package removal because empty, which trips pwck. For it not to fail on those cases, a possible solution would be to add package-specific home dirs to PKGBUILDs backup=() array, but that's kind of an ugly workaround. I'll leave it here for now, Cheers
Re: [arch-general] [tor] User and group entries are left over in passwd and gshadow after removal, makes pwck and shadow.service fail
On Mon, 25 Jan 2016 17:29:51 +0100 Bastien Traverse wrote: > Hi, > > I opened FS#47893 [1] to discuss this issue, but it's been closed with > no delay and I can't really have a discussion via re-opening requests. > > Upon installation of the tor package, directory /var/lib/tor is created > (see PKGBUILD#40 [2]). Upon uninstallation, it is automatically deleted > **only if empty**: > > # pacman -S tor > # touch /var/lib/tor/test > # pacman -Rns tor > # ls -lah /var/lib/tor > total 8,0K > drwx-- 2 tor tor 4,0K 25 janv. 16:50 . > drwxr-xr-x 39 root root 4,0K 25 janv. 16:50 .. > -rw-r--r-- 1 root root 0 25 janv. 16:50 test > > # rm -rf /var/lib/tor > > # pacman -S tor > ... > (1/1) installing tor > error: command failed to execute correctly > ... > # pacman -Rns tor > # ls -lah /var/lib/tor > ls: cannot access /var/lib/tor: No such file or directory > > However, tor user and group (UID/GID 43) created via post_install() hook > [3] are not removed: > > # pacman -Rns tor > $ id tor > uid=43(tor) gid=43(tor) groupes=43(tor) > > This makes shadow.service fail at bootup: > > pwck[718]: tor user: directory « /var/lib/tor » does not exist > pwck[718]: pwck : no change > systemd[1]: shadow.service: Main process exited, code=exited, > status=2/INVALIDARGUMENT > systemd[1]: Failed to start Verify integrity of password and group files. > systemd[1]: shadow.service: Unit entered failed state. > systemd[1]: shadow.service: Failed with result 'exit-code'. > > Same for pwck. > > What I asked in FS#47893 was to add a post_uninstall() hook to remove > tor user (e.g. with `userdel tor`), so that **if /var/lib/tor has been > deleted automatically** because it was empty, pwck doesn't trip on home > dir verification. > > Note that if /var/lib/tor isn't empty, `userdel tor` would merely remove > the user entry and not delete its home directory (-r switch). Therefore, > no data loss. Moreover, I believe it is possible to condition user > deletion on directory existence (e.g. `if [ ! -e /var/lib/tor ]; then > userdel tor; else :`), so that could do it too. > > Reason for closing was "Not a bug / So fix it. This isn't something that > can be dealt with automatically". I fail to see how it is so, but if I'm > wrong please tell me so and why. > > Thanks, > Bastien > > [1] https://bugs.archlinux.org/task/47893 > [2] > https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/tor#n40 > [3] > https://projects.archlinux.org/svntogit/community.git/tree/trunk/tor.install?h=packages/tor Dev discussion here: vhttps://lists.archlinux.org/pipermail/arch-dev-public/2015-February/026953.html
[arch-general] [tor] User and group entries are left over in passwd and gshadow after removal, makes pwck and shadow.service fail
Hi, I opened FS#47893 [1] to discuss this issue, but it's been closed with no delay and I can't really have a discussion via re-opening requests. Upon installation of the tor package, directory /var/lib/tor is created (see PKGBUILD#40 [2]). Upon uninstallation, it is automatically deleted **only if empty**: # pacman -S tor # touch /var/lib/tor/test # pacman -Rns tor # ls -lah /var/lib/tor total 8,0K drwx-- 2 tor tor 4,0K 25 janv. 16:50 . drwxr-xr-x 39 root root 4,0K 25 janv. 16:50 .. -rw-r--r-- 1 root root 0 25 janv. 16:50 test # rm -rf /var/lib/tor # pacman -S tor ... (1/1) installing tor error: command failed to execute correctly ... # pacman -Rns tor # ls -lah /var/lib/tor ls: cannot access /var/lib/tor: No such file or directory However, tor user and group (UID/GID 43) created via post_install() hook [3] are not removed: # pacman -Rns tor $ id tor uid=43(tor) gid=43(tor) groupes=43(tor) This makes shadow.service fail at bootup: pwck[718]: tor user: directory « /var/lib/tor » does not exist pwck[718]: pwck : no change systemd[1]: shadow.service: Main process exited, code=exited, status=2/INVALIDARGUMENT systemd[1]: Failed to start Verify integrity of password and group files. systemd[1]: shadow.service: Unit entered failed state. systemd[1]: shadow.service: Failed with result 'exit-code'. Same for pwck. What I asked in FS#47893 was to add a post_uninstall() hook to remove tor user (e.g. with `userdel tor`), so that **if /var/lib/tor has been deleted automatically** because it was empty, pwck doesn't trip on home dir verification. Note that if /var/lib/tor isn't empty, `userdel tor` would merely remove the user entry and not delete its home directory (-r switch). Therefore, no data loss. Moreover, I believe it is possible to condition user deletion on directory existence (e.g. `if [ ! -e /var/lib/tor ]; then userdel tor; else :`), so that could do it too. Reason for closing was "Not a bug / So fix it. This isn't something that can be dealt with automatically". I fail to see how it is so, but if I'm wrong please tell me so and why. Thanks, Bastien [1] https://bugs.archlinux.org/task/47893 [2] https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/tor#n40 [3] https://projects.archlinux.org/svntogit/community.git/tree/trunk/tor.install?h=packages/tor
Re: [arch-general] Clarification on pacman signature verification
On 01/25/2016 04:43 AM, Solomon Lam wrote: > Hi, This is regarding package verification performed by pacman. > > Does pacman download the .sig file of a package while installing one? All I > could find are the local cached copies of packages only but not their > signatures. If thats the case, how does pacman verify the integrity of the > downloaded package? > It could be that .sig file could have been downloaded into /tmp during > installation or to another location that I'm not aware yet. This brings me > to my next point. > > I've manually downloaded just the package file (of some random package) > from a mirror and disconnected from the Internet. I used both 'pacman -U > ' and 'pacman -S ' to install the package and the > installation went just fine. I was expecting Pacman to emit an error > stating that signature was missing but nothing happened. Could someone care > to explain this. > BTW, I have SigLevel = Required DatabaseOptional in my pacman.conf. > > - Solomon > Packages from the Sync database have their signatures (if any) embedded in the db itself. If you really don't trust your own computer, set: LocalFileSigLevel = Required That will make installing AUR packages slightly awkward... Local files default to Optional, Remote files to Required, so if you use `pacman -U http://address.of/package.tar.xz` then it will download the package *and* signature for you, once there is a *.sig pacman will demand it be a valid one. -- Eli Schwartz
Re: [arch-general] Clarification on pacman signature verification
On Mon, 25 Jan 2016 15:13:24 +0530 Solomon Lam wrote: > Hi, This is regarding package verification performed by pacman. > > Does pacman download the .sig file of a package while installing one? All I > could find are the local cached copies of packages only but not their > signatures. If thats the case, how does pacman verify the integrity of the > downloaded package? > It could be that .sig file could have been downloaded into /tmp during > installation or to another location that I'm not aware yet. This brings me > to my next point. > > I've manually downloaded just the package file (of some random package) > from a mirror and disconnected from the Internet. I used both 'pacman -U > ' and 'pacman -S ' to install the package and the > installation went just fine. I was expecting Pacman to emit an error > stating that signature was missing but nothing happened. Could someone care > to explain this. > BTW, I have SigLevel = Required DatabaseOptional in my pacman.conf. > > - Solomon Signatures are kept in the databases.
Re: [arch-general] Mounting root according to fstab the first time (fstab in initrd)?
Hi!
I was a bit busy and just got to hacking my mkinitcpio now.
I decided to follow ProgAndy's idea and remove the current way of
mounting (default_mount_handler function) and instead create and use
mount hooks (by default the default_mount_handler and the mount call's
nearest lines is a new, enabled hook now).
This makes it easier to configure custom mount scenarios, even with
exotic configurations such as my /etc on a separate partiton*. Another
advantage is that it is compatible with most mkinitcpio features e.g.
the breakpoints.
Do you think it'd worth to try discussing and submitting my patch to
mkinitcpio's maintainers?
Thank you all for the help! :)
* It is in real a btrfs subvolume and needed in case of a flat
subvolume layout so I can easily snapshot only my /etc while
experimenting with new configurations. Obviously this is impossible in
case of the original mkinitcpio ramdisk because /etc/fstab is not on
the root volume.
Regards,
Garmine
On 20 January 2016 at 21:58, ProgAndy wrote:
> Am 20.01.2016 um 21:34 schrieb Garmine 42:
>>
>> First I will try to exclude root= and rootflags= parameters from the
>> cmdline and include the fstab via mkinitcpio and see if it finds the root.
>> Do I want to mask remount-fs in this case?
>
>
> That won't work. You'll have to create a hook for mkinitcpio that implements
> a custom mount_handler.
> In the install hook part, read the fstab data, write the necessary stuff to
> the image and add a runtime hook with add_runscript
> In the runtime hook, you change the mount_handler
>
> my_mount_handler() {
> mount ...
> }
> mount_handler="my_mount_handler"
Re: [arch-general] Unknown Trust and Corrupted Package
On 01/25/2016 10:27 AM, Damjan Georgievski wrote: > huh, now what? > [...] > gpg: keyserver refresh failed: Permission denied As the error message indicates, you need to do that as root. It's also possible to grab the new archlinux-keyring package from [testing]. cheers, Levente signature.asc Description: OpenPGP digital signature
Re: [arch-general] archlinux-keyring 20160123-1 is needed, but unavailable without testing
My apologies, after taking a look at the archive, I noticed that this issue already was reported. I couldn't notice it, since there's an issue with my account: "Note: your list delivery is currently disabled; it was disabled due to excessive bounces. The last bounce was received on 12-Jan-2016." :D
[arch-general] Clarification on pacman signature verification
Hi, This is regarding package verification performed by pacman. Does pacman download the .sig file of a package while installing one? All I could find are the local cached copies of packages only but not their signatures. If thats the case, how does pacman verify the integrity of the downloaded package? It could be that .sig file could have been downloaded into /tmp during installation or to another location that I'm not aware yet. This brings me to my next point. I've manually downloaded just the package file (of some random package) from a mirror and disconnected from the Internet. I used both 'pacman -U ' and 'pacman -S ' to install the package and the installation went just fine. I was expecting Pacman to emit an error stating that signature was missing but nothing happened. Could someone care to explain this. BTW, I have SigLevel = Required DatabaseOptional in my pacman.conf. - Solomon
[arch-general] archlinux-keyring 20160123-1 is needed, but unavailable without testing
Hi, archlinux-keyring 20160123-1 is needed, but not available, if testing isn't used. Packages (11) boost-1.60.0-2 boost-libs-1.60.0-2 cmake-3.4.2-1 confuse-2.8-1 dhcpcd-6.10.1-1 libvpx-1.5.0-4 ntp-4.2.8.p6-1 openmpi-1.10.2-1 pacman-mirrorlist-20160124-1 python-setuptools-1:19.6-1 python2-setuptools-1:19.6-1 error: confuse: signature from "Thorsten Töpper " is unknown trust :: File /var/cache/pacman/pkg/confuse-2.8-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). # pacman-key --refresh-keys --updatedb This fixed the issue with the signature. However, the current keyring package isn't available. "archlinux-keyring 20160123-1" - https://www.archlinux.org/packages/testing/any/archlinux-keyring/ "archlinux-keyring 20151220-1" - https://www.archlinux.org/packages/core/any/archlinux-keyring/ # pacman -Q archlinux-keyring archlinux-keyring 20151220-1 # pacman -Si archlinux-keyring | grep Ver Version: 20151220-1 Regards, Ralf
Re: [arch-general] Unknown Trust and Corrupted Package
> Looks like people tend to forget about updating pacman keyring. > > pacman-key --refresh-keys huh, now what? # pacman-key --refresh-keys gpg: refreshing 85 keys from hkp://keys.gnupg.net gpg: keyserver refresh failed: Permission denied ==> ERROR: A specified local key could not be updated from a keyserver. -- damjan
Re: [arch-general] Unknown Trust and Corrupted Package
> > > Looks like people tend to forget about updating pacman keyring. > > > > pacman-key --refresh-keys > > is'n this done automatically? should it? > I personally can't see how it (an upgrade hook in a package) could. The pacman-keyring package can (and does) do some maintenance operations on upgrades, but things like OP's issue (I noticed the same thing as well) is more likely to occur due to a completely unrelated package coming with signatures from a new key without the pacman-key package being touched. What could be done would be to make pacman automatically download any and all needed keys without user intervention. This shouldn't be a security issue since the web of trust should still be enforced (i.e. this wouldn't mean you'd just blindly trust random keys, just that pacman would do the equivalent of `pacman-key --refresh` when necessary). I don't know if this has already been considered and rejected by the pacman devs. >
Re: [arch-general] Unknown Trust and Corrupted Package
It is in testing; updating the keyring pkg from testing fixed the issue on my box. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [arch-general] Yahoo mail problems (was [aur-general] No notification for out-of-date package)
Hey, > Also as for rejecting invalid DKIM mails: People should really not do > that unless DMARC tells them to. That _is_ a problem already and will get worse this year. Yahoo has already published a "reject invalid" policy nearly two years ago[1]. See: [0 mosu@sweet-chili ~] host -t txt _dmarc.yahoo.com _dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_...@yahoo.com;"; It's known that Google will switch from "report" to "reject" this year, too[2]. At the moment they're only at "quarantine" which is bad enough already: [0 mosu@sweet-chili ~] host -t txt _dmarc.googlemail.com _dmarc.googlemail.com descriptive text "v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:mailauth-repo...@google.com"; Mailing list administrators have to act _now_ and make their lists DKIM compliant; otherwise more and more list mails will not reach their intended destinations. I already had to change my own DMARC policy from "reject" to "report" because I'm subscribed to too many mailing lists that break DKIM. Yes, this may not be the reason Yahoo currently rejects our mails, but it _is_ a problem on our side that the Arch lists haven't addressed yet. As long as there's such a known problem on our side speculating about _other_ potential reasons why Yahoo is rejecting mails is moot. Please, dear Arch list maintainers, change the mailman settings accordingly. Please. See [3] for how mailman can deal with DMARC. Kind regards, mosu [1] http://sendgrid.com/blog/update-yahoos-dmarc-policy/ [2] https://dmarc.org/2015/10/global-mailbox-providers-deploying-dmarc-to-protect-users/ [3] http://wiki.list.org/DEV/DMARC signature.asc Description: PGP signature
Re: [arch-general] Unknown Trust and Corrupted Package
>> I'm receiving message about unknown trust while trying to install the confuse >> package. >> > > Looks like people tend to forget about updating pacman keyring. > > pacman-key --refresh-keys is'n this done automatically? should it? -- damjan
Re: [arch-general] Unknown Trust and Corrupted Package
On Monday, 25 January 2016 09:00:43 IST Bruno Pagani wrote: > Is there somewhere on the wiki, especially beginner guide or install one > where it’s advised to do this on a regular basis? (I’m on mobile right now, > not easy to check) I found this [1], which suggests that the changes should be updated in the archlinux-keyring package, but that may not be enough if the keyring package is not recent enough. -- Cheers Jayesh Badwaik [1] https://wiki.archlinux.org/index.php/Pacman/ Package_signing#Adding_developer_keys
Re: [arch-general] Unknown Trust and Corrupted Package
Le 25 janvier 2016 03:23:25 GMT+01:00, Levente Polyak a écrit : >On 01/25/2016 03:17 AM, Jayesh Badwaik wrote: >> Hi, >> >> I'm receiving message about unknown trust while trying to install the >confuse >> package. >> > > >Looks like people tend to forget about updating pacman keyring. > >pacman-key --refresh-keys > > >cheers, >anthraxx Definitely, just ran into the same issue and had more than thousand new sigs… Is there somewhere on the wiki, especially beginner guide or install one where it’s advised to do this on a regular basis? (I’m on mobile right now, not easy to check) Bruno
