Re: [arch-dev-public] [extra] Dropping usermin and webmin
Am 13.01.2015 um 17:59 schrieb Tobias Powalowski: > Hi guys, > I don't use it on any of my machines anymore, anyone who wants to step up? > Else those are candidates for AUR. > > greetings > tpowa > Done removed from [extra] repository. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: OpenPGP digital signature
[arch-dev-public] [extra] Dropping ocaml packages
Hi guys, I don't use it on any of my machines anymore, anyone who wants to step up? Else those are candidates for AUR/community. ocaml ocaml-compiler-libs facile lablgtk2 unison greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: OpenPGP digital signature
[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 3 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 4 fully signed off packages * 57 packages missing signoffs * 2 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (3 total) == * hwids-20150129-1 (any) * refind-efi-0.8.5-1 (i686) * refind-efi-0.8.5-1 (x86_64) == Incomplete signoffs for [core] (18 total) == * hwids-20150129-1 (any) 0/2 signoffs * btrfs-progs-3.18.2-1 (i686) 0/1 signoffs * dhcpcd-6.7.1-1 (i686) 0/1 signoffs * gummiboot-48-1 (i686) 0/1 signoffs * libgpg-error-1.18-1 (i686) 0/1 signoffs * linux-lts-3.14.31-1 (i686) 0/1 signoffs * nfs-utils-1.3.2-1 (i686) 0/1 signoffs * patch-2.7.4-1 (i686) 0/1 signoffs * rpcbind-0.2.2-1 (i686) 0/1 signoffs * sqlite-3.8.8.2-1 (i686) 0/1 signoffs * btrfs-progs-3.18.2-1 (x86_64) 0/2 signoffs * dhcpcd-6.7.1-1 (x86_64) 0/2 signoffs * gummiboot-48-1 (x86_64) 0/2 signoffs * libgpg-error-1.18-1 (x86_64) 0/2 signoffs * linux-lts-3.14.31-1 (x86_64) 0/2 signoffs * nfs-utils-1.3.2-1 (x86_64) 0/2 signoffs * patch-2.7.4-1 (x86_64) 0/2 signoffs * sqlite-3.8.8.2-1 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (39 total) == * libreoffice-fresh-i18n-4.4.0-1 (any) 0/2 signoffs * libreoffice-still-i18n-4.3.5-1 (any) 0/2 signoffs * wicd-1.7.3-1 (any) 0/2 signoffs * apache-2.4.12-2 (i686) 0/1 signoffs * brltty-5.2-1 (i686) 0/1 signoffs * bzflag-2.4.2-6 (i686) 0/1 signoffs * calligra-2.8.7-4 (i686) 0/1 signoffs * cups-filters-1.0.62-2 (i686) 0/1 signoffs * enblend-enfuse-4.1.3-2 (i686) 0/1 signoffs * evas_generic_loaders-1.12.0-4 (i686) 0/1 signoffs * glew-1.12.0-1 (i686) 0/1 signoffs * hugin-2014.0.0-4 (i686) 0/1 signoffs * inkscape-0.91-2 (i686) 0/1 signoffs * libgit2-1:0.21.5-1 (i686) 0/1 signoffs * libreoffice-fresh-4.4.0-1 (i686) 0/1 signoffs * libreoffice-still-4.3.5-1 (i686) 0/1 signoffs * mesa-demos-8.2.0-4 (i686) 0/1 signoffs * poppler-0.30.0-1 (i686) 0/1 signoffs * pulseaudio-5.99.3-1 (i686) 0/1 signoffs * refind-efi-0.8.5-1 (i686) 0/1 signoffs * texlive-bin-2014.34260-5 (i686) 0/1 signoffs * apache-2.4.12-2 (x86_64) 0/2 signoffs * brltty-5.2-1 (x86_64) 0/2 signoffs * bzflag-2.4.2-6 (x86_64) 0/2 signoffs * calligra-2.8.7-4 (x86_64) 0/2 signoffs * cups-filters-1.0.62-2 (x86_64) 0/2 signoffs * enblend-enfuse-4.1.3-2 (x86_64) 0/2 signoffs * evas_generic_loaders-1.12.0-4 (x86_64) 0/2 signoffs * glew-1.12.0-1 (x86_64) 0/2 signoffs * hugin-2014.0.0-4 (x86_64) 0/2 signoffs * inkscape-0.91-2 (x86_64) 0/2 signoffs * libgit2-1:0.21.5-1 (x86_64) 0/2 signoffs * libreoffice-fresh-4.4.0-1 (x86_64) 0/2 signoffs * libreoffice-still-4.3.5-1 (x86_64) 0/2 signoffs * mesa-demos-8.2.0-4 (x86_64) 0/2 signoffs * poppler-0.30.0-1 (x86_64) 0/2 signoffs * pulseaudio-5.99.3-1 (x86_64) 0/2 signoffs * refind-efi-0.8.5-1 (x86_64) 0/2 signoffs * texlive-bin-2014.34260-5 (x86_64) 0/2 signoffs == Completed signoffs (4 total) == * tzdata-2015a-1 (any) * dialog-1:1.2_20150125-1 (i686) * dialog-1:1.2_20150125-1 (x86_64) * rpcbind-0.2.2-1 (x86_64) == All packages in [testing] for more than 14 days (2 total) == * rpcbind-0.2.2-1 (i686), since 2015-01-13 * rpcbind-0.2.2-1 (x86_64), since 2015-01-13 == Top five in signoffs in last 24 hours ==
[arch-dev-public] user/group management in packages
Hi all, While looking into how best handle those directory permission warnings with pacman-4.2, I have noticed a couple of things about user/group management in our packages. 1) We should not remove users/groups when packages are uninstalled. This is a potential security issue if any files are left owned by the non-existent user/group. 2) Most packages that chown files in the install file could do it use the user/group number in the PKGBUILD. This works on any package with a reserved user/group ID. The advantage of doing this is that pacman can track the permissions. (A solution is being worked on for dynamically created user/groups whose id number can vary.) Should I create a rebuild list? Cheers, Allan
Re: [arch-dev-public] user/group management in packages
2015-02-03 12:46 GMT+01:00 Allan McRae : > > 1) We should not remove users/groups when packages are uninstalled. This > is a potential security issue if any files are left owned by the > non-existent user/group. When should the cleanup be done? Installing and immediately uninstalling a package should really not do permanent changes to the system; iow, ideally, users shouldn't have to do regular cleanups on their system like that. J. Leclanche
Re: [arch-dev-public] user/group management in packages
On 03/02/15 13:46, Allan McRae wrote: > Hi all, > > While looking into how best handle those directory permission warnings > with pacman-4.2, I have noticed a couple of things about user/group > management in our packages. > > 1) We should not remove users/groups when packages are uninstalled. This > is a potential security issue if any files are left owned by the > non-existent user/group. > > 2) Most packages that chown files in the install file could do it use > the user/group number in the PKGBUILD. This works on any package with a > reserved user/group ID. The advantage of doing this is that pacman can > track the permissions. (A solution is being worked on for dynamically > created user/groups whose id number can vary.) > > Should I create a rebuild list? I'd say yes and I agree on both points. This is also a perfect opportunity to mention systemd-sysusers(8) which, along with sysusers.d(5) entries, can greatly simplify the creation of system users. For an example, check out the openldap package: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/slapd.sysusers?h=packages/openldap https://projects.archlinux.org/svntogit/packages.git/tree/trunk/openldap.install?h=packages/openldap
Re: [arch-dev-public] user/group management in packages
On Tue, Feb 3, 2015 at 1:27 PM, Evangelos Foutras wrote: > I'd say yes and I agree on both points. > > This is also a perfect opportunity to mention systemd-sysusers(8) which, > along with sysusers.d(5) entries, can greatly simplify the creation of > system users. > +1 for doing this. -- Andrea
Re: [arch-dev-public] user/group management in packages
On 02/03/15 at 02:27pm, Evangelos Foutras wrote: > On 03/02/15 13:46, Allan McRae wrote: > > Hi all, > > > > While looking into how best handle those directory permission warnings > > with pacman-4.2, I have noticed a couple of things about user/group > > management in our packages. > > > > 1) We should not remove users/groups when packages are uninstalled. This > > is a potential security issue if any files are left owned by the > > non-existent user/group. > > > > 2) Most packages that chown files in the install file could do it use > > the user/group number in the PKGBUILD. This works on any package with a > > reserved user/group ID. The advantage of doing this is that pacman can > > track the permissions. (A solution is being worked on for dynamically > > created user/groups whose id number can vary.) > > > > Should I create a rebuild list? > > I'd say yes and I agree on both points. > > This is also a perfect opportunity to mention systemd-sysusers(8) which, > along with sysusers.d(5) entries, can greatly simplify the creation of > system users. > > For an example, check out the openldap package: > > https://projects.archlinux.org/svntogit/packages.git/tree/trunk/slapd.sysusers?h=packages/openldap > > https://projects.archlinux.org/svntogit/packages.git/tree/trunk/openldap.install?h=packages/openldap -1 for systemd-sysusers unless you can figure out a way to use it in pre_install. In order for the dynamic user creation Allan mentioned to work, pacman will have to be changed to use symbolic user names for file ownership which requires the user to exist *before* the package is extracted. apg
Re: [arch-dev-public] user/group management in packages
On 03/02/15 17:58, Andrew Gregory wrote: > -1 for systemd-sysusers unless you can figure out a way to use it in > pre_install. In order for the dynamic user creation Allan mentioned > to work, pacman will have to be changed to use symbolic user names for > file ownership which requires the user to exist *before* the package > is extracted. Yeah, it doesn't seem like systemd-sysusers can be used for that, since the user and group information is stored in a sysusers.d file. But for packages that use static (reserved) user/group IDs, it should work a treat. :)
Re: [arch-dev-public] [extra] Dropping ocaml packages
Hi Tobias On Tue, Feb 3, 2015 at 12:33 AM, Tobias Powalowski wrote: > Hi guys, > I don't use it on any of my machines anymore, anyone who wants to step up? > Else those are candidates for AUR/community. > > ocaml > ocaml-compiler-libs I'll take care of ocaml.
Re: [arch-dev-public] [extra] Dropping ocaml packages
Hi Tobias, [2015-02-03 09:33:12 +0100] Tobias Powalowski: > I don't use it on any of my machines anymore, anyone who wants to step up? I'll take unison. Cheers. -- Gaetan pgpedt5So0eTz.pgp Description: PGP signature
Re: [arch-dev-public] user/group management in packages
On 03/02/15 22:01, Jerome Leclanche wrote: > 2015-02-03 12:46 GMT+01:00 Allan McRae : >> >> 1) We should not remove users/groups when packages are uninstalled. This >> is a potential security issue if any files are left owned by the >> non-existent user/group. > > When should the cleanup be done? Installing and immediately > uninstalling a package should really not do permanent changes to the > system; iow, ideally, users shouldn't have to do regular cleanups on > their system like that. > Never - what does on extra line in a file matter?
Re: [arch-dev-public] user/group management in packages
On 03/02/15 06:05 PM, Allan McRae wrote: > On 03/02/15 22:01, Jerome Leclanche wrote: >> 2015-02-03 12:46 GMT+01:00 Allan McRae : >>> >>> 1) We should not remove users/groups when packages are uninstalled. This >>> is a potential security issue if any files are left owned by the >>> non-existent user/group. >> >> When should the cleanup be done? Installing and immediately >> uninstalling a package should really not do permanent changes to the >> system; iow, ideally, users shouldn't have to do regular cleanups on >> their system like that. >> > > Never - what does on extra line in a file matter? There are a few cases where the user/group isn't actually used for any files, like these ones: https://projects.archlinux.org/svntogit/community.git/tree/trunk/grsec-common.install?h=packages/grsec-common I wouldn't mind leaving them around, but deleting them isn't really problematic. It's definitely a security issue when it comes to the dynamically assigned range (500..999) since files may be left behind and the user/group could be reused. It doesn't seem like it could be an issue with the reserved static ids though. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] user/group management in packages
On 03/02/2015 17:16, Evangelos Foutras wrote: > On 03/02/15 17:58, Andrew Gregory wrote: >> -1 for systemd-sysusers unless you can figure out a way to use it in >> pre_install. In order for the dynamic user creation Allan mentioned >> to work, pacman will have to be changed to use symbolic user names for >> file ownership which requires the user to exist *before* the package >> is extracted. > > Yeah, it doesn't seem like systemd-sysusers can be used for that, since > the user and group information is stored in a sysusers.d file. > > But for packages that use static (reserved) user/group IDs, it should > work a treat. :) > Allan, could you clarify your rebuild consign regarding static user/group to move to systemd-sysusers ? Cheers, -- Sébastien "Seblu" Luttringer Archlinux Developer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
Re: [arch-dev-public] user/group management in packages
On 04/02/15 13:21, Sébastien Luttringer wrote: > On 03/02/2015 17:16, Evangelos Foutras wrote: >> On 03/02/15 17:58, Andrew Gregory wrote: >>> -1 for systemd-sysusers unless you can figure out a way to use it in >>> pre_install. In order for the dynamic user creation Allan mentioned >>> to work, pacman will have to be changed to use symbolic user names for >>> file ownership which requires the user to exist *before* the package >>> is extracted. >> >> Yeah, it doesn't seem like systemd-sysusers can be used for that, since >> the user and group information is stored in a sysusers.d file. >> >> But for packages that use static (reserved) user/group IDs, it should >> work a treat. :) >> > Allan, could you clarify your rebuild consign regarding static > user/group to move to systemd-sysusers ? > I don't care...
Re: [arch-dev-public] user/group management in packages
[2015-02-03 22:10:26 -0500] Daniel Micay: > It's definitely a security issue when it comes to the dynamically > assigned range (500..999) since files may be left behind and the > user/group could be reused. It doesn't seem like it could be an issue > with the reserved static ids though. I concur. Besides, if we're not going to remove users/groups in post_remove, we might as well ship a default /etc/passwd in the filesystem package with every single user/group in it. There's also the issue of packages like postfix that use an upstream script to set permissions right after the package is installed. Well... I'll wait to see all this issues addressed before looking at the new todo list. Cheers. -- Gaetan signature.asc Description: PGP signature
