[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 12 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 8 fully signed off packages * 128 packages missing signoffs * 0 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 (12 total) == * curl-7.36.0-1 (i686) * file-5.18-1 (i686) * flex-2.5.39-1 (i686) * curl-7.36.0-1 (x86_64) * file-5.18-1 (x86_64) * flex-2.5.39-1 (x86_64) * libevdev-1.1-1 (i686) * nvidia-334.21-3 (i686) * nvidia-lts-334.21-4 (i686) * libevdev-1.1-1 (x86_64) * nvidia-334.21-3 (x86_64) * nvidia-lts-334.21-4 (x86_64) == Incomplete signoffs for [core] (7 total) == * curl-7.36.0-1 (i686) 0/1 signoffs * file-5.18-1 (i686) 0/1 signoffs * flex-2.5.39-1 (i686) 0/1 signoffs * gmp-6.0.0-1 (i686) 0/1 signoffs * curl-7.36.0-1 (x86_64) 1/2 signoffs * file-5.18-1 (x86_64) 1/2 signoffs * flex-2.5.39-1 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (121 total) == * accerciser-3.8.2-2 (any) 0/2 signoffs * django-1.6.2-2 (any) 0/2 signoffs * eric-5.4.2-2 (any) 0/2 signoffs * namcap-3.2.5-2 (any) 0/2 signoffs * orca-3.10.2-2 (any) 0/2 signoffs * pyatspi-2.10.0-2 (any) 0/2 signoffs * pylint-1.1.0-3 (any) 0/2 signoffs * pyopengl-3.0.2-6 (any) 0/2 signoffs * pyopenssl-0.14-3 (any) 0/2 signoffs * python-astroid-1.0.1-3 (any) 0/2 signoffs * python-beaker-1.6.4-2 (any) 0/2 signoffs * python-chardet-2.2.1-2 (any) 0/2 signoffs * python-cssselect-0.9.1-2 (any) 0/2 signoffs * python-feedparser-5.1.3-3 (any) 0/2 signoffs * python-logilab-common-0.61.0-2 (any) 0/2 signoffs * python-mako-0.9.1-2 (any) 0/2 signoffs * python-nose-1.3.1-2 (any) 0/2 signoffs * python-pip-1.5.4-2 (any) 0/2 signoffs * python-ply-3.4-4 (any) 0/2 signoffs * python-pyasn1-0.1.7-2 (any) 0/2 signoffs * python-pycparser-2.10-4 (any) 0/2 signoffs * python-pyelftools-0.21-2 (any) 0/2 signoffs * python-setuptools-3.3-3 (any) 0/2 signoffs * python-virtualenv-1.11.4-2 (any) 0/2 signoffs * python2-rdflib-4.1.0-2 (any) 0/2 signoffs * pyxdg-0.25-2 (any) 0/2 signoffs * xcb-proto-1.10-2 (any) 0/2 signoffs * apr-util-1.5.3-4 (i686) 0/1 signoffs * avidemux-2.5.6-9 (i686) 0/1 signoffs * brltty-4.5-7 (i686) 0/1 signoffs * dbus-python-1.2.0-3 (i686) 0/1 signoffs * ffmpeg-1:2.2-2 (i686) 0/1 signoffs * ffmpeg-compat-1:0.10.12-2 (i686) 0/1 signoffs * fontconfig-2.11.1-1 (i686) 0/1 signoffs * gedit-3.10.4-2 (i686) 0/1 signoffs * gnome-music-3.10.3-2 (i686) 0/1 signoffs * gst-plugins-ugly-1.2.3-2 (i686) 0/1 signoffs * gstreamer0.10-ugly-0.10.19-10 (i686) 0/1 signoffs * ibus-1.5.6-2 (i686) 0/1 signoffs * kdebindings-python-4.12.3-2 (i686) 0/1 signoffs * kdesdk-kate-4.12.3-2 (i686) 0/1 signoffs * kdevelop-python-1.6.1-1 (i686) 0/1 signoffs * libevdev-1.1-1 (i686) 0/1 signoffs * liblouis-2.5.2-3 (i686) 0/1 signoffs * libpeas-1.9.0-2 (i686) 0/1 signoffs * libreoffice-4.2.2-5 (i686) 0/1 signoffs * mplayer-37051-1 (i686) 0/1 signoffs * nss-3.15.5-2 (i686) 0/1 signoffs * nvidia-334.21-3 (i686) 0/1 signoffs * nvidia-lts-334.21-4 (i686) 0/1 signoffs * opal-3.10.11-3 (i686) 0/1 signoffs * pyalpm-0.6.2-2 (i686) 0/1 signoffs * pycrypto-2.6.1-2 (i686) 0/1 signoffs * pygobject-3.10.2-2 (i686) 0/1 signoffs * pygobject2-2.28.6-10 (i686) 0/1 signoffs * pyqt4-4.10.4-1 (i686) 0/1 signoffs * pyqt5-5.2.1-1 (i686) 0/1 signoffs * python-3.4.0-2 (i686) 0/1 signoffs * python-cairo-1.10.0-4 (i686) 0/1 signoffs * python-cffi-0.8.2-4 (i686) 0/1 signoffs * python-cryptography-0.2.2-2 (i686) 0/1 signoffs * python-lxml-3.3.3-2 (i686) 0/1 signoffs * python-markupsafe-0.19-2 (i686) 0/1 signoffs * python-numpy-1.8.0-3 (i686) 0/1 signoffs * python-pycurl-7.19.3.1-2 (i686) 0/1 signoffs * python-urwid-1.2.0-2 (i686) 0/1 signoffs * python-zope-interface-4.1.0-2 (i686) 0/1 signoffs * qscintilla-2.8.1-1 (i686) 0/1 signoffs * sip-4.15.5-2 (i686) 0/1 signoffs * speech-dispatcher-0.8-3 (i686) 0/1 signoffs * vde2-2.3.2-6 (i686) 0/1 signoffs * vim-7.4.214-1 (i686) 0/1 signoffs * vlc-2.1.4-2 (i686) 0/1 signoffs * x264-20140311-1 (i686) 0/1 signoffs * apr-util-1.5.3-4 (x86_64) 0/2 signoffs * avidemux-2.5.6-9 (x86_64) 0/2 signoffs * brltty-4.5-7 (x86_64) 0/2 signoffs * dbus-python-1.2.0-3 (x86_64) 0/2 signoffs * ffmpeg-1:2.2-2 (x86_64) 0/2 signoffs * ffmpeg-compat-1:0.10.12-2 (x86_64) 0/2 signoffs * fontconfig-2.11.1-1 (x86_64) 0/2 signoffs * gedit-3.10.4-2 (x86_64) 0/2 signoffs * gnome-music-3.10.3-2 (x86_64) 0/2 signoffs *
Re: [arch-dev-public] Trimming down our default kernel configuration
On 27/03/14 01:07 AM, tho...@archlinux.org wrote: Am 26.03.2014 20:08, schrieb Dave Reisner: Looks like audit is still built into our kernel. Wasn't this meant to be reverted as well? Forgot about that. That was pulled in by AppArmor or so. Wasn't it pulled in by http://bugs.archlinux.org/task/12584 and the fact that community/audit came out shortly after? signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Trimming down our default kernel configuration
On Thu, Mar 27, 2014 at 9:52 AM, Connor Behan connor.be...@gmail.comwrote: On 27/03/14 01:07 AM, tho...@archlinux.org wrote: Am 26.03.2014 20:08, schrieb Dave Reisner: Looks like audit is still built into our kernel. Wasn't this meant to be reverted as well? Forgot about that. That was pulled in by AppArmor or so. Wasn't it pulled in by http://bugs.archlinux.org/task/12584 and the fact that community/audit came out shortly after? I didn't know when it was added in the kernel or why, but I find it useful and would appreciate it being kept in (that's why I maintain community/audit).
Re: [arch-dev-public] Trimming down our default kernel configuration
Am 27.03.2014 09:52, schrieb Connor Behan: On 27/03/14 01:07 AM, tho...@archlinux.org wrote: Am 26.03.2014 20:08, schrieb Dave Reisner: Looks like audit is still built into our kernel. Wasn't this meant to be reverted as well? Forgot about that. That was pulled in by AppArmor or so. Wasn't it pulled in by http://bugs.archlinux.org/task/12584 and the fact that community/audit came out shortly after? No, it was pulled in accidentally as a dependency of AppArmor. If we actually want audit, we should support it as well. Our systemd package is compiled with -AUDIT for example. Since audit is one of those enabled unless the user intervenes option that also does annoying things, I would like to get rid of it in our kernel. signature.asc Description: OpenPGP digital signature
[arch-dev-public] nvidia 334.21-3 / nvidia-lts 334.21-4 pulled from [testing]
Hi all, The nvidia-modprobe binary was provided in the nvidia / nvidia-lts packages, but this doesn't work well because the two packages should not be prevented from installing together. To fix this, I've pulled the two packages from [testing], and will upload a new nvidia-utils package containing the binary to [testing]. FS#39203 and FS#39636 will be closed if the new package fixed everything. (A setuid binary is not good, but no trivial workaround was found) If you still have one of the packages installed, please revert them to the corresponding version in [extra]. If you failed to do so, a file conflict error is expected after the new nvidia-utils get pushed. Sorry for the inconvenience! Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] nvidia 334.21-3 / nvidia-lts 334.21-4 pulled from [testing]
Am 27.03.2014 16:02, schrieb Felix Yan: Hi all, The nvidia-modprobe binary was provided in the nvidia / nvidia-lts packages, but this doesn't work well because the two packages should not be prevented from installing together. To fix this, I've pulled the two packages from [testing], and will upload a new nvidia-utils package containing the binary to [testing]. FS#39203 and FS#39636 will be closed if the new package fixed everything. (A setuid binary is not good, but no trivial workaround was found) Seriously, that is a crappy solution. If nvidia would properly register its devices with linux, these devices could be created dynamically. It's really up to nvidia to fix their kernel module. (By the way, the /dev/nvidia* devices do not even generate proper uevents and thus cannot be caught by udev or systemd. I wish they would stop relying on a closed-source kernel driver with debatable quality.) signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] nvidia 334.21-3 / nvidia-lts 334.21-4 pulled from [testing]
On Thu, Mar 27, 2014 at 04:15:21PM +0100, Thomas Bächler wrote: Am 27.03.2014 16:02, schrieb Felix Yan: Hi all, The nvidia-modprobe binary was provided in the nvidia / nvidia-lts packages, but this doesn't work well because the two packages should not be prevented from installing together. To fix this, I've pulled the two packages from [testing], and will upload a new nvidia-utils package containing the binary to [testing]. FS#39203 and FS#39636 will be closed if the new package fixed everything. (A setuid binary is not good, but no trivial workaround was found) Seriously, that is a crappy solution. If nvidia would properly register its devices with linux, these devices could be created dynamically. It's really up to nvidia to fix their kernel module. (By the way, the /dev/nvidia* devices do not even generate proper uevents and thus cannot be caught by udev or systemd. I wish they would stop relying on a closed-source kernel driver with debatable quality.) Heh. Now they have *2* modules of debatable quality.
Re: [arch-dev-public] nvidia 334.21-3 / nvidia-lts 334.21-4 pulled from [testing]
On Thursday, March 27, 2014 16:15:21 Thomas Bächler wrote: Am 27.03.2014 16:02, schrieb Felix Yan: Hi all, The nvidia-modprobe binary was provided in the nvidia / nvidia-lts packages, but this doesn't work well because the two packages should not be prevented from installing together. To fix this, I've pulled the two packages from [testing], and will upload a new nvidia-utils package containing the binary to [testing]. FS#39203 and FS#39636 will be closed if the new package fixed everything. (A setuid binary is not good, but no trivial workaround was found) Seriously, that is a crappy solution. If nvidia would properly register its devices with linux, these devices could be created dynamically. It's really up to nvidia to fix their kernel module. (By the way, the /dev/nvidia* devices do not even generate proper uevents and thus cannot be caught by udev or systemd. I wish they would stop relying on a closed-source kernel driver with debatable quality.) Yeah, I totally agree with you. I played a lot with udev but only produced a hacky (and certainly wrong except works) udev rule. I don't think that one better than the upstream-provided crappy binary. I've also asked upstream for help, but still didn't get a reply. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
[arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
Since systemd 212, systemd timers support the Persistent=true option for OnCalendar timers. This is functionality similar to anacron: Persistent= Takes a boolean argument. If true the service unit is immediately triggered when the timer unit is activated and the timer elapsed at least once since the last time the service unit has been triggered by the timer unit. The time when the service unit was last triggered is stored on disk. This is useful to catch up for missed timers when a machine is shutdown temporarily and then is powered up again. Note that this setting only has an effect on timers configured with OnCalendar=. This means that we could replace the cron.* dropin scripts with systemd services and timers. Pros: * enabled by default (in contrast to cronie) * systems without need for crontabs can disable/uninstall cron * service will be simpler than the rather long dropin scripts Cons: * services are run in parallel instead of sequentially (is this even a con? timer start will be randomized, and we can increase accuracy to an hour to randomize even more) * no holdoff time after boot as it seems Affected packages: community/awstats 7.2-1 /etc/cron.hourly/awstats community/snapper 0.2.1-1 /etc/cron.hourly/snapper community/sysstat 10.3.1-1 /etc/cron.hourly/sysstat core/logrotate 3.8.7-1 /etc/cron.daily/logrotate core/man-db 2.6.6-1 /etc/cron.daily/man-db core/mlocate 0.26-1 /etc/cron.daily/updatedb core/shadow 4.1.5.1-7 /etc/cron.daily/shadow extra/hylafax 6.0.6-4 /etc/cron.daily/hylafax community/atop 2.0.2-1 /etc/cron.daily/atop community/dspam 3.10.2-8/etc/cron.daily/dspam_maintenance community/logwatch 7.4.0-3 /etc/cron.daily/0logwatch community/snapper 0.2.1-1 /etc/cron.daily/snapper community/sysstat 10.3.1-1 /etc/cron.daily/sysstat extra/pkgstats 2.3-3/etc/cron.weekly/pkgstats community/squid 3.4.4-1 /etc/cron.weekly/squid I'd be willing to convert all the core packages and put them to testing if people agree that this is the right course. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
On Fri 28, March 01:01:22 Thomas Bächler wrote: Since systemd 212, systemd timers support the Persistent=true option for OnCalendar timers. This is functionality similar to anacron: Cool! I'd be willing to convert all the core packages and put them to testing if people agree that this is the right course. +1 from me -- Andrea Arch Linux Developer signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
On Mon 24, March 15:02:53 Gaetan Bisson wrote: Personally, although I think the AUR is a valuable service and that you shouldn't be assuming its costs and maintenance alone, I'm not sure if making it official would be a good thing (TM) in terms of encouraging users to downgrade packages rather than reporting bugs and upgrading cleanly when things break. I want to quote Gaetan and Dave here. I fear that making ARM official or semi-official we unconsciously boost single packages downgrade. -- Andrea Arch Linux Developer signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
On 03/27/2014 09:01 PM, Thomas Bächler wrote: Since systemd 212, systemd timers support the Persistent=true option for OnCalendar timers. This is functionality similar to anacron: Persistent= Takes a boolean argument. If true the service unit is immediately triggered when the timer unit is activated and the timer elapsed at least once since the last time the service unit has been triggered by the timer unit. The time when the service unit was last triggered is stored on disk. This is useful to catch up for missed timers when a machine is shutdown temporarily and then is powered up again. Note that this setting only has an effect on timers configured with OnCalendar=. This means that we could replace the cron.* dropin scripts with systemd services and timers. Pros: * enabled by default (in contrast to cronie) * systems without need for crontabs can disable/uninstall cron * service will be simpler than the rather long dropin scripts Cons: * services are run in parallel instead of sequentially (is this even a con? timer start will be randomized, and we can increase accuracy to an hour to randomize even more) * no holdoff time after boot as it seems Affected packages: community/awstats 7.2-1 /etc/cron.hourly/awstats community/snapper 0.2.1-1 /etc/cron.hourly/snapper community/sysstat 10.3.1-1 /etc/cron.hourly/sysstat core/logrotate 3.8.7-1 /etc/cron.daily/logrotate core/man-db 2.6.6-1 /etc/cron.daily/man-db core/mlocate 0.26-1 /etc/cron.daily/updatedb core/shadow 4.1.5.1-7 /etc/cron.daily/shadow extra/hylafax 6.0.6-4 /etc/cron.daily/hylafax community/atop 2.0.2-1 /etc/cron.daily/atop community/dspam 3.10.2-8/etc/cron.daily/dspam_maintenance community/logwatch 7.4.0-3 /etc/cron.daily/0logwatch community/snapper 0.2.1-1 /etc/cron.daily/snapper community/sysstat 10.3.1-1 /etc/cron.daily/sysstat extra/pkgstats 2.3-3/etc/cron.weekly/pkgstats community/squid 3.4.4-1 /etc/cron.weekly/squid I'd be willing to convert all the core packages and put them to testing if people agree that this is the right course. Finally! Yes I agree with this, I like the flexibility that it provides. Thanks. :) -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1 signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
On 27/03/14 08:01 PM, Thomas Bächler wrote: Since systemd 212, systemd timers support the Persistent=true option for OnCalendar timers. This is functionality similar to anacron: Persistent= Takes a boolean argument. If true the service unit is immediately triggered when the timer unit is activated and the timer elapsed at least once since the last time the service unit has been triggered by the timer unit. The time when the service unit was last triggered is stored on disk. This is useful to catch up for missed timers when a machine is shutdown temporarily and then is powered up again. Note that this setting only has an effect on timers configured with OnCalendar=. This means that we could replace the cron.* dropin scripts with systemd services and timers. Pros: * enabled by default (in contrast to cronie) * systems without need for crontabs can disable/uninstall cron * service will be simpler than the rather long dropin scripts Cons: * services are run in parallel instead of sequentially (is this even a con? timer start will be randomized, and we can increase accuracy to an hour to randomize even more) * no holdoff time after boot as it seems Affected packages: community/awstats 7.2-1 /etc/cron.hourly/awstats community/snapper 0.2.1-1 /etc/cron.hourly/snapper community/sysstat 10.3.1-1 /etc/cron.hourly/sysstat core/logrotate 3.8.7-1 /etc/cron.daily/logrotate core/man-db 2.6.6-1 /etc/cron.daily/man-db core/mlocate 0.26-1 /etc/cron.daily/updatedb core/shadow 4.1.5.1-7 /etc/cron.daily/shadow extra/hylafax 6.0.6-4 /etc/cron.daily/hylafax community/atop 2.0.2-1 /etc/cron.daily/atop community/dspam 3.10.2-8/etc/cron.daily/dspam_maintenance community/logwatch 7.4.0-3 /etc/cron.daily/0logwatch community/snapper 0.2.1-1 /etc/cron.daily/snapper community/sysstat 10.3.1-1 /etc/cron.daily/sysstat extra/pkgstats 2.3-3/etc/cron.weekly/pkgstats community/squid 3.4.4-1 /etc/cron.weekly/squid I'd be willing to convert all the core packages and put them to testing if people agree that this is the right course. I think it would make sense to remove cronie from base when these are migrated to timer units. It's not enabled by default, and ships with a setuid binary (crontab) so it opens up a vulnerability in the base install. Among others (although one requires cron to be enabled): * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0424 * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6097 signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
On 28/03/14 10:05, Andrea Scarpino wrote: On Fri 28, March 01:01:22 Thomas Bächler wrote: Since systemd 212, systemd timers support the Persistent=true option for OnCalendar timers. This is functionality similar to anacron: Cool! I'd be willing to convert all the core packages and put them to testing if people agree that this is the right course. +1 from me Agreed. +1
Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
[2014-03-27 21:01:17 -0400] Daniel Micay: setuid binary (crontab) so it opens up a vulnerability in the base install. Among others (although one requires cron to be enabled): * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0424 * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6097 There were bugs that have been fixed a while ago; what's your point? I support switching to systemd timers in order to streamline our base install, as well as regroup daemons and periodic commands configuration in just one place. But I do not believe that replacing a small setuid binary by a larger one addresses any potential security issue. -- Gaetan pgpJR1aMV7z1A.pgp Description: PGP signature
Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
On 27/03/14 10:01 PM, Gaetan Bisson wrote: [2014-03-27 21:01:17 -0400] Daniel Micay: setuid binary (crontab) so it opens up a vulnerability in the base install. Among others (although one requires cron to be enabled): * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0424 * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6097 There were bugs that have been fixed a while ago; what's your point? My point was only that the security risk is not theoretical. The only other arguments I have against including packages in base are disk and bandwidth usage and I don't think those are important when we're talking about such small numbers. Reducing the attack surface of most Arch installs is a stronger reason to keep base small. I think cutting down the number of setuid binaries shipped in base (and overall) would be great, and crontab is one of the few that we can't eventually switch to a significantly less scary capability like CAP_NET_RAW. I support switching to systemd timers in order to streamline our base install, as well as regroup daemons and periodic commands configuration in just one place. Removing a daemon that's not enabled by default would help to streamline the base install too. But I do not believe that replacing a small setuid binary by a larger one addresses any potential security issue. I don't think systemd timers allow non-root users to run timer units outside of their session and the systemd session binary runs as non-root. AFAIK avoiding setuid binaries is one of the reasons for tools like hostnamectl using a client-server model. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
[2014-03-27 22:59:36 -0400] Daniel Micay: On 27/03/14 10:01 PM, Gaetan Bisson wrote: [2014-03-27 21:01:17 -0400] Daniel Micay: setuid binary (crontab) so it opens up a vulnerability in the base install. Among others (although one requires cron to be enabled): * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0424 * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6097 There were bugs that have been fixed a while ago; what's your point? My point was only that the security risk is not theoretical. Of course it isn't: we all know every piece of software has bugs, which is a potential security issue when run as root. Now the above cronie bugs were fixed long ago. Do you have any evidence suggesting systemd should be less bug-prone than cronie? AFAIK avoiding setuid binaries is one of the reasons for tools like hostnamectl using a client-server model. Forgive me if I'm not convinced a user client giving commands to a root daemon is much better than a setuid binary implementing said commands. -- Gaetan pgpp97IcG67tu.pgp Description: PGP signature
Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
On 27/03/14 11:26 PM, Gaetan Bisson wrote: My point was only that the security risk is not theoretical. Of course it isn't: we all know every piece of software has bugs, which is a potential security issue when run as root. Now the above cronie bugs were fixed long ago. Do you have any evidence suggesting systemd should be less bug-prone than cronie? Arch Linux is going to be shipping systemd in base, whether or not cronie is included. Including more setuid binaries increases the attack surface. I do think it can be assumed that including cronie (with the crontab setuid binary) and systemd will be more prone to exploitation than systemd alone. The importance of this is open to debate, but I think it's worth consideration, especially since cronie is not enabled by default. Perfect security is an unobtainable goal but we can do what we can to harden the base install. It means cron users will need to issue another pacman command, similar to how Arch leaving ptrace_scope enabled by default requires users of commands like `strace -p $PID`, `perf trace -p $PID`, `gdb -p $PID` or `reptyr $PID` to either turn it off or work around it. They're very minor inconveniences for a subset of Arch users and the security benefit is real, even if it's small. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Trimming down our default kernel configuration
On 27/03/14 08:24 AM, tho...@archlinux.org wrote: Am 27.03.2014 09:52, schrieb Connor Behan: On 27/03/14 01:07 AM, tho...@archlinux.org wrote: Am 26.03.2014 20:08, schrieb Dave Reisner: Looks like audit is still built into our kernel. Wasn't this meant to be reverted as well? Forgot about that. That was pulled in by AppArmor or so. Wasn't it pulled in by http://bugs.archlinux.org/task/12584 and the fact that community/audit came out shortly after? No, it was pulled in accidentally as a dependency of AppArmor. I doubt that. AppArmor was enabled a year and a half after audit was. https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kernel26id=e46bc1d41848b258a138df26590967dc1e0a3417 https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kernel26id=688e0f7508fa943868470e9d6c0dcb12823b06f0 If we actually want audit, we should support it as well. Our systemd package is compiled with -AUDIT for example. Since audit is one of those enabled unless the user intervenes option that also does annoying things, I would like to get rid of it in our kernel. It is supported if you count [community] packages. I'll ask on the LKML if anything can be done about the logging. signature.asc Description: OpenPGP digital signature
