On 16/04/14 02:46 AM, Allan McRae wrote:

Which packages? We need the details.

For just the basics (most of PaX disabled), there's no external work required. It would be useful with just the kernel and userland tools in [community] and no extra work done on other packages. Enabling the PaX features requires marking a fairly long list of binaries with exceptions to the rules via the PaX extended attributes in the install scripts. For example, web browsers require memory that's both executable + writable (requiring an mprotect exception) and many programs are broken by stuff like the ASLR improvements due to depending on all kinds of undefined behaviour. The `paxctl` command for this is a 0.06MiB package with a single binary and man page, so the drawback would be the work required rather than any form of dependency bloat. It wouldn't be reasonable to report every case via the issue tracker, someone would actually have to be interested in systematically adding to to [core] and [extra] packages. If you want a nearly full list of the packages, you can look in the linux-pax-flags AUR package, which is a total hack adding the PaX xattrs when the user runs a command. Doing it that way means any upgrades are going to break everything until the user runs the script, so I'm just planning on leaving the features disabled at first. Pacman hooks would be a nicer solution than editing all the install scripts, but we don't have those :).

On 16/04/14 17:25, Daniel Micay wrote:

On 16/04/14 03:15 AM, Daniel Micay wrote:

...

Pacman hooks would be a nicer solution than editing all the install scripts, but we don't have those :).

It also wouldn't be nearly as bad if packages could store extended attributes, since the ugly install scripts could be avoided and paxctl would only be a make dependency. Packages like iputils already run into this issue due to using capabilities as a replacement for setuid.

Just submitted a patch to pacman that will allow setting capabilites in the package() function. Allan

On 16/04/14 20:00, Thomas Bächler wrote:

Am 16.04.2014 11:52, schrieb Allan McRae:

...

On 16/04/14 17:25, Daniel Micay wrote:

...

On 16/04/14 03:15 AM, Daniel Micay wrote:

...

Pacman hooks would be a nicer solution than editing all the install scripts, but we don't have those :).

It also wouldn't be nearly as bad if packages could store extended attributes, since the ugly install scripts could be avoided and paxctl would only be a make dependency. Packages like iputils already run into this issue due to using capabilities as a replacement for setuid.

Just submitted a patch to pacman that will allow setting capabilites in the package() function.

Since we want PAX support to remain optional, we'd still need hooks so that after each upgrade, a script can adjust the flags appropriately.

Sure... I really don't care about PAX (and think it should just be packaged in a separate repo...). I just wanted pacman to support setting capabilities during packaging. A

On 16/04/14 21:36, Thomas Bächler wrote:

Am 16.04.2014 12:21, schrieb Allan McRae:

...

...

...

Just submitted a patch to pacman that will allow setting capabilites in the package() function.

Since we want PAX support to remain optional, we'd still need hooks so that after each upgrade, a script can adjust the flags appropriately.

Sure... I really don't care about PAX (and think it should just be packaged in a separate repo...). I just wanted pacman to support setting capabilities during packaging.

I am not sure that your patch will work at all due to limitations of fakeroot. I just tested this shortly, and fakeroot supports setting file capabilities using setcap, but not setting ACLs using setfacl.

So, support for extended attributes in fakeroot is incomplete at best.

A further look indicates that this may simply be stupidity on the side of fakeroot: it explicitly hardcodes ENOTSUP for acl_{s,g}et_f{ile,d}, while the now implemented f{s,g}etxattr support should be sufficient in order to support ACLs entirely. I guess these acl overrides are remnants of the days when xattr support was missing.

Anyway, we need to fix fakeroot before this makepkg feature can be useful.

Getting off-topic... but only one package in our repos uses setfacl (systemd on the journal directory) in its install script, and seven use setcap. Getting the majority case fixed is still worth including this in my opinion. We can deal with get/setfacl when fakeroot does properly. Any chance you can take that upstream? Also, I really thought setcap would be used in more install scripts! A

In data giovedì 17 aprile 2014 02:44:37, Daniel Micay ha scritto:

Of course, I'm imagining a future utopia where a critical mass of developers / trusted users are interested in maintaining this kind of thing. For the near future, users would just keep using the scary linux-pax-flags package if they wanted to enable PaX via sysctl.

FWIW I'm very interested in linux-grsec and would gladly maintaing PAX flags on my packages if I had to. I'm still mourning over the abrupt drop of audit support from the kernel with lame reasons. -- Massimiliano "mtorromeo" Torromeo Arch Linux TU GPG: 0xDA2EE423

On 18/04/14 04:09 AM, Sébastien Luttringer wrote:

On 16/04/2014 06:09, Daniel Micay wrote:

...

To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system.

How do you/we will handle off stream kernel modules rebuild? Each modules maintainer will have to create a new version for this kernel and update it when you push a new version, right?

I could build these myself when I push a new version, because there aren't many of them. I don't think it makes sense to bother with the nvidia module because it would be a bit silly to mix it with grsecurity. grsecurity almost always follows the point releases of the previous kernel version longer than Arch keeps them around, so any real work to migrate to the new kernel version would already be done and easily copied over.

In data venerdì 18 aprile 2014 11:34:14, Sébastien Luttringer ha scritto:

On 18/04/2014 10:44, Daniel Micay wrote:

...

On 18/04/14 04:09 AM, Sébastien Luttringer wrote:

...

On 16/04/2014 06:09, Daniel Micay wrote: I could build these myself when I push a new version, because there aren't many of them.

When I will push a new version of Virtualbox, which currently provides modules for linux and linux-lts. I will have to build a third external package for linux-grsec, like every modules maintainer.

How about only using dkms for third-party modules for kernels outside of [core]? -- Massimiliano "mtorromeo" Torromeo Arch Linux TU GPG: 0xDA2EE423

On 18/04/14 05:34 AM, Sébastien Luttringer wrote:

...

On 18/04/14 04:09 AM, Sébastien Luttringer wrote:

...

On 16/04/2014 06:09, Daniel Micay wrote: I could build these myself when I push a new version, because there aren't many of them. When I will push a new version of Virtualbox, which currently provides modules for linux and linux-lts. I will have to build a third external

On 18/04/2014 10:44, Daniel Micay wrote: package for linux-grsec, like every modules maintainer.

There's no problem with simply not building a VirtualBox module for the linux-grsec kernel. You're not building one now, so there would be nothing gained or lost. Supporting out-of-tree modules wasn't something I planned on considering at all right away. Other modules without userspace components wouldn't present the same problems as VirtualBox, since they would be an entirely separate package.

...

I don't think it makes sense to bother with the nvidia module because it would be a bit silly to mix it with grsecurity.

Why user with nvidia cards should be deprived of grsec security enhancement?

It will work fine with Nouveau. The nvidia driver is a larger pile of code than the Linux kernel itself and no hardening can be applied to it. The grsecurity kernel randomization features are rendered useless since it has info leaks all over. It might have an impact on the RBAC policies, which would otherwise be able to assume that X will be running as non-root post 1.16. If someone is interested in building an nvidia module for a grsecurity kernel and fixing any RBAC issues then I won't object, but I'm not going to do it myself.

On 18/04/14 08:02 AM, Sébastien Luttringer wrote:

On 18/04/2014 13:07, Daniel Micay wrote:

...

...

On 18/04/2014 10:44, Daniel Micay wrote:

...

On 18/04/14 04:09 AM, Sébastien Luttringer wrote:

...

On 16/04/2014 06:09, Daniel Micay wrote: There's no problem with simply not building a VirtualBox module for the

On 18/04/14 05:34 AM, Sébastien Luttringer wrote: linux-grsec kernel. Being not consistent is a problem to me. But nothing which I can overcome.

...

You're not building one now, so there would be nothing gained or lost. I build 2 modules for each release[1]. Could be 3 tomorrow. I miss your point.

I mean that users are currently compiling these modules on their own for grsec, so if there were no packaged out-of-tree modules for it at all then it wouldn't be a step backwards. The most painful part for users is compiling the kernel, especially when most of the AUR kernel packages are based on older versions of the [core] package rather than following the current configuration.

...

Supporting out-of-tree modules wasn't something I planned on considering at all right away. Suggestion of Massimiliano is fine to me. If we all agree to get ride of compiled modules, there is no burden to me to grsec kernel addition. This even open the door to talk about versioned kernel :)

I agree that DKMS is the best way of dealing with this.

On 18/04/14 05:09 AM, Gaetan Bisson wrote:

[2014-04-16 00:09:55 -0400] Daniel Micay:

...

To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system.

It sounds fairly intrusive to me to introduce and support a new kernel in our repositories.

I don't expect anyone but myself to put any work into supporting it. A few other developers and trusted users may be interested in helping, but I can certainly take care of it myself if there isn't interest. It's far less invasive than asking for features like SELinux to be enabled in all of our packages. I think most people who would be asking for the [core] kernel to support TOMOYO/AppArmor/SELinux/Smack/Audit will be more than happy to use grsecurity instead.

And I feel quite uneasy about this set of patches not having been accepted upstream.

It makes changes like adding (mostly) redundant checks to reference counting and bounds checks on copies to/from userspace with a measurable performance cost. These changes prevent many of the discovered kernel vulnerabilities from working on a grsecurity kernel. These features don't prevent bugs, but rather stop them from becoming exploitable vulnerabilities. Linus doesn't see security issues as meriting special treatment over other bugs, and trying to sell a 1-5% performance loss upstream is just not going to happen. ASLR was invented by the PaX team, along with other mitigation techniques that are now upstream. Many of the non-PaX grsecurity features have also made their way into the Linux kernel (ptrace_scope, hidepid, fs.protected_symlinks, fs.protected_hardlinks, dmesg_restrict, kptr_restrict, etc.) and other operating systems. The mainline kernel still hasn't caught up to where it was ten years ago, and there has been a significant amount of new research and feature development since then.

Is there a particular reason why the current state (packages in the AUR, built on-demand by those users that are interested) is dissatisfying?

You might as well ask why I want to maintain any packages at all. :P I think I can offer a good out-of-the-box experience with this package in the repositories. The userspace support is relevant whether someone uses a grsecurity package from the repositories or builds their own.

In your view, should we also package other patchsets, such as Con Kolivas' (by far the most popular linux-* package on the AUR)?

I'm fine with other people packaging any FOSS under the sun if it has an active upstream and isn't going to put a burden on other developers / trusted users. I don't think we should bring more dead projects or proprietary software into the repositories but this is neither. I'm not familiar with what the CK patches do, so I can't really voice an opinion on whether they are worth including in the repositories. I don't think votes are a good measure of interest in a package, since it's tied to age and automatic voting by some AUR helpers. For all we know, someone used a script to create a bunch of accounts to vote for it. If someone writes an explanation of what it is and why it would be valuable to include in the repositories then I can give an answer.

On 18/04/14 05:11 PM, Tom Gundersen wrote:

On Wed, Apr 16, 2014 at 6:09 AM, Daniel Micay wrote:

...

There has been a recent surge of interest in securing Arch by paying closer attention to CVEs and addressing many security issues in our packages. I also started some initial work/documenting on securing the services shipped in various packages:

https://wiki.archlinux.org/index.php/DeveloperWiki:Service_isolation

I'm very happy that more people are now looking at security related things in Arch. Nice work!

...

To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system. This would be the first case of an alternative kernel in the repositories, so I'm open to discussion about whether it's appropriate to do this. There are also some issues relevant to other packages in the repositories.

Hmm, grsec seems like a dead-end to me. It will never land upstream, and hence will never be in our standard kernel and our default packages will therefore never be integrated with it. So whatever work you do will have to live independently in perpetuity. At worst it would split our (very limited) development and QA resources.

There's nothing else hardening the kernel itself against exploitation, so containers (namespaces, seccomp-bpf) aren't going to benefit from any other work. I don't see much point in spending my time integrating an LSM when they're just layering on more complexity without fixing the lowest hanging fruit. The work that's done in grsecurity trickles into the kernel years later, so it's not really a dead end. I understand if touching any other packages is viewed as unacceptable and can work around that issue. The RBAC policies will be entirely centralized in the gradm package, and I can try to take the quirky approach of doing all of the PaX exceptions there. No other packages will be aware of anything going on, unless people feel like taking the completely optional step of making DKMS versions of modules. The only time spent on this is going to be my own. I've already spent far more time writing these mailing list responses than any amount of work I've put into improving security-related issues... speaking of development resources.

Would it not make more sense to focus on some other security features that are actually upstream and which can then at least potentially be merged into our default packages eventually?

We do have ptrace_scope, protected_symlinks and protected_hardlinks enabled, which are bits of grsecurity that made it into the kernel after many years. The upstream kernel only has ASLR at all because PaX invented it in the early 2000s. We could enable dmesg_restrict / kptr_restrict but there's not much value until KASLR can be turned on. Even then, there's little value in KASLR (or ASLR) when many upstream maintainers simply don't care about breaking it by leaking addresses. Flipping on PIE for some executables would be an improvement, but it's a lot more valuable with the improved PaX ASLR.

Maybe another option, if you really think grsec is the way to go, would be to simply create a new unofficial repository and put the packages there instead?

I do really think it's the way to go. If it has to be walled off outside of the repositories, there's a lot less value in it. I'm unlikely to waste any more time trying to improve this aspect of the distribution if it's just shot down. To be perfectly honest, I didn't feel I had to ask for permission to maintain a 13 year old open-source project with 43 votes in [community] and had no idea there would be such a negative response. We have plenty of forks like graphicsmagick and even two entire desktop environments forked from GNOME (Mate and Cinnamon). There's at least one proprietary driver that's never going to be open-source let alone integrated upstream, and plenty of *truly* dead-end projects with no upstream (metacity!).

On 18/04/14 08:15 PM, Allan McRae wrote:

On 19/04/14 07:11, Tom Gundersen wrote:

...

On Wed, Apr 16, 2014 at 6:09 AM, Daniel Micay wrote:

...

There has been a recent surge of interest in securing Arch by paying closer attention to CVEs and addressing many security issues in our packages. I also started some initial work/documenting on securing the services shipped in various packages:

https://wiki.archlinux.org/index.php/DeveloperWiki:Service_isolation

I'm very happy that more people are now looking at security related things in Arch. Nice work!

...

To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system. This would be the first case of an alternative kernel in the repositories, so I'm open to discussion about whether it's appropriate to do this. There are also some issues relevant to other packages in the repositories.

Hmm, grsec seems like a dead-end to me. It will never land upstream, and hence will never be in our standard kernel and our default packages will therefore never be integrated with it. So whatever work you do will have to live independently in perpetuity. At worst it would split our (very limited) development and QA resources.

Would it not make more sense to focus on some other security features that are actually upstream and which can then at least potentially be merged into our default packages eventually?

Maybe another option, if you really think grsec is the way to go, would be to simply create a new unofficial repository and put the packages there instead?

I'd say an unofficial repo is the way to go for the time being. linux-grsec in the AUR only has 44 votes, so it is not screaming out for inclusion in the repos.

Allan

Users have been asking for MAC to be provided in the repositories for a long time. At the moment, two bugs are open about it: https://bugs.archlinux.org/task/37578 https://bugs.archlinux.org/task/39852 Any of these reported bugs could simply be closed with the response that the grsecurity RBAC is provided in the repositories and there's no one interested in maintaining another. I think that's a response most people would be satisfied with, but users aren't going to be very happy with an a WONTFIX simply saying Arch has no official support for any of this.

On 19/04/14 05:25 PM, Tom Gundersen wrote:

On Sat, Apr 19, 2014 at 9:59 PM, Daniel Micay wrote:

...

Users have been asking for MAC to be provided in the repositories for a long time. At the moment, two bugs are open about it:

https://bugs.archlinux.org/task/37578 https://bugs.archlinux.org/task/39852

Any of these reported bugs could simply be closed with the response that the grsecurity RBAC is provided in the repositories and there's no one interested in maintaining another. I think that's a response most people would be satisfied with, but users aren't going to be very happy with an a WONTFIX simply saying Arch has no official support for any of this.

I would see this the other way around (which is one of the reasons I don't think adding forks of the kernel is such a great idea). It would be very nice if we could manage to support some more security features in the main kernel, but asking people to use an alternative kernel if they want security features seems wrong. Especially if it is used as an excuse not to get things that are already upstream working with the main kernel we provide.

These features aren't in the regular kernel though. There's no way to have anything but the weak ASLR implementation with missing pieces. It has no configuration option to flip on similar hardening options. All of the MAC implementations in the kernel are limited to what's offered by the LSM framework, so even writing an equivalent to the RBAC implementation isn't possible without going through the political work of convincing many maintainers to add many more hooks, etc. The LSM support (beyond ptrace_scope from Yama) was disabled in core/linux seeing as it wasn't receiving any userspace report in the repositories and many people don't like the auditing.

If you were providing an alternative kernel temporarily as a testing-ground for things that would eventually get integrated in our main kernel, I'd be all for it. But the way I see it, everyone agrees that grsec is never going upstream and that this is not something we could ever integrate in the main kernel, so I think we should be very careful about splitting efforts which could have otherwise benefited the whole distro (such as support for AppArmor, TOMOYO, SELinux, whatever).

In short, work on grsec if you want, but please let's not use that as an excuse to discourage people from working on similar features for the main kernel.

I have no problem with someone else working on it, but as far as I know there are no other developers or trusted users interested in doing this kind of work. Anyway, there is simply no similar support upstream. It has taken over a decade for a few sysctl flags to enable some of the miscellaneous features from grsecurity. You'll encounter a *lot* of resistance trying to upstream work as Kees Cook has been doing. Yama exists because the kernel developers refused to support ptrace_scope in the core kernel... and it's a tiny feature.

On Sat, Apr 19, 2014 at 11:47 PM, Daniel Micay wrote:

On 19/04/14 05:25 PM, Tom Gundersen wrote:

...

On Sat, Apr 19, 2014 at 9:59 PM, Daniel Micay wrote:

...

Users have been asking for MAC to be provided in the repositories for a long time. At the moment, two bugs are open about it:

https://bugs.archlinux.org/task/37578 https://bugs.archlinux.org/task/39852

Any of these reported bugs could simply be closed with the response that the grsecurity RBAC is provided in the repositories and there's no one interested in maintaining another. I think that's a response most people would be satisfied with, but users aren't going to be very happy with an a WONTFIX simply saying Arch has no official support for any of this.

I would see this the other way around (which is one of the reasons I don't think adding forks of the kernel is such a great idea). It would be very nice if we could manage to support some more security features in the main kernel, but asking people to use an alternative kernel if they want security features seems wrong. Especially if it is used as an excuse not to get things that are already upstream working with the main kernel we provide.

These features aren't in the regular kernel though.

I was referring to SELinux and TOMOYO. Cheers, Tom

On Sat, Apr 19, 2014 at 11:58 PM, Daniel Micay wrote:

On 19/04/14 05:25 PM, Tom Gundersen wrote:

...

In short, work on grsec if you want, but please let's not use that as an excuse to discourage people from working on similar features for the main kernel.

For example, if someone opens a bug asking to enable CONFIG_AUDIT again, will it really be accepted? The workaround for containers landed in systemd.

http://cgit.freedesktop.org/systemd/systemd/commit/?id=24fb111

That is clearly not an acceptable long-term solution. As far as I know audit is being fixed upstream to make this temporary work-around unnecessary. -t

On 19.04.2014 23:58, Daniel Micay wrote:

For example, if someone opens a bug asking to enable CONFIG_AUDIT again, will it really be accepted? The workaround for containers landed in systemd.

Going slightly off topic here, but you only seem to connect audit with the systemd bug so might be valuable: I don't care about audit so I don't use it. Sadly that doesn't work because it defaults to being enabled which means I get tons of audit spam in dmesg. As long as that's the case I'm against enabling it and the same thing applies to all other features that change the kernel behaviour even if I don't use them.

[2014-04-20 20:22:59 -0400] Daniel Micay:

I don't really see any problem with moving a FOSS package with 52 votes to [community]. Whether or not people like the project isn't really relevant.

So you initially inquired about this on arch-dev-public because you knew it was a controversial issue, but when it turns out most answers are not what you hoped for you go ahead against them? Is that the logic here? What part of "do it in a separate repo for the time being" didn't you understand and/or like? That solution seemed to make everyone happy... By the way, "Packager: Unknown Packager" looks bad. -- Gaetan

Hi again, As you might have noticed, I do not care too much about grsecurity, however I do care very much about doing things the right way. That's why I'll only respond to this: [2014-04-21 01:21:16 -0400] Daniel Micay:

The mailing list wasn't the only place where I've discussed this. It has been a topic of conversation on various IRC channels, where numerous trusted users and developers voiced support for it. I don't think a vocal minority on the mailing list represents a consensus against it.

The arch-dev-public mailing list is *the* medium of discussion between developers and trusted users. That's why all of us have access to it, and that's why all of us are expected to read it. And it really is the *only* one: not all of us have access to #archlinux-dev or #archlinux-tu and not all of us follow arch-general or aur-general. And when I say "medium of discussion", the "discussion" bit is extremely important! It's not just a poll you or someone else conducts by asking people privately on different channels, it really is: a discussion where everyone is free to raise arguments for or against, then if a consensus emerges we follow it, otherwise we vote. I believe we are all reasonable people, and just as my opinion might have evolved after reading the arguments of that mysterious developer you mention, the opposite may also happen. That's why discussing is so critical. Now I'm sorry to say this but it seems to me you have handled this issue in the worst possible way: ignoring community feedback as you saw fit. -- Gaetan

In data domenica 20 aprile 2014 18:40:15, Gaetan Bisson ha scritto:

What part of "do it in a separate repo for the time being" didn't you understand and/or like? That solution seemed to make everyone happy...

Actually it only made happy the developers/tu that didn't care one bit about grsecurity. I surely am not happy about that solution and others have expressed concerns about this (Bartłomiej Piotrowski and Connor Behan come to mind) so I am not sure who is here that is ignoring feedback... -- Massimiliano "mtorromeo" Torromeo Arch Linux TU GPG: 0xDA2EE423

In data lunedì 21 aprile 2014 22:24:26, Gaetan Bisson ha scritto:

Here on earth, Bartłomiej (who said nothing against separate repos) and the guy who breaks every thread he replies to are just two people out of ten in this discussion. And why didn't you chime in and gave us your arguments against separate repos? How relevant is it whether you are happy or not if you said nothing of it in the discussion?!?

Because I simply agreed with points already expressed by others and I didn't think "+1s" would help the discussion. In data sabato 19 aprile 2014 11:11:18, Connor Behan ha scritto:

Hah. I would just like to add that unofficial repositories are usually a dead end.

1. Maintainer adds kernel to his own repository and tries to advertise it in the forums. 2. Only 10 people install it. 3. Maintainer decides it's not worth the work and takes down the repo.

With [community] there is a much higher probability that packages will be popular and maintained for awhile.

This is the quote I remembered agreeing with. And looking back at the discussion I have to admit that Bartłomiej didn't really argument against separate repo but expressed his desire for grsec in [community] instead.

You can pull all the excuses you want, but no consensus was reached. Pressing ahead with something so controversial while the discussion is still going on is a plain and simple lack of respect for the opinion and advice of fellow developers and TUs.

I am not saying that consensus was reached because it definetely was not, but at the same time I also don't feel like there is any need for consensus here as it seems to me that this is a package just like any other. Feedback was requested and taken into consideration, concerns were addressed and, as explained, this ended up being a self-contained package. If this results in problems that have not been considered it can be easily removed. -- Massimiliano "mtorromeo" Torromeo Arch Linux TU GPG: 0xDA2EE423

Lets not draw this out too much further. I don't want to have to unsubscribe from another mailing list... But I am still going to have my say! 1) This was different than every other package in [community]. I know this because packages get added to [community] all the time without an email here. And saying discussion about adding PaX extensions was makes it different is naive as anyone who has been around here a short time could tell you that was never going to happen. 2) A few years back we specifically reduced the number of kernels in our repos to one. Then the LTS kernel appeared. Now this. The problem with adding a non-vanilla kernel to the repos is now for kernel bug reports we have to verify which kernel is running. If it is linux-grsec, we then need to figure out if the issue a generic linux one, or with the other patchset. This is a burden to all our the kernel maintainers and not just the packager and is part of the reason the variety of kernels was reduced. 3) Now this is in [community] there will be an expectation of providing all the extras that are supposed to come with this. As decided, this will not be happening, but it will be expected and the question will need to be answered repeatedly. 4) A separate repo would have given actual number for interest in this. We all know the number of votes in the AUR is a crap metric and could have accumulated a long time ago. It would also have allowed us to see how important the above issues are. Despite assertions, many binary repos are well used by the Arch community. 5) There were objections to it being included in our binary repos. This does not happen often, but we usually discuss further and come to a consensus about inclusion. Ignoring those objections is not how our team works. Given the relatively few people who responded to the thread, we have no real idea what the support was (and I can provide unsupported anecdotes for support against or for inclusion of the package as well as the next person can...) In conclusion, this should have waited before being put in the repo. It might have ended up there anyway, it might not have. And I can not be bothered figuring it out as it will not affect me in any way. Allan

On 22/04/14 06:03 AM, Allan McRae wrote:

Lets not draw this out too much further. I don't want to have to unsubscribe from another mailing list... But I am still going to have my say!

1) This was different than every other package in [community]. I know this because packages get added to [community] all the time without an email here. And saying discussion about adding PaX extensions was makes it different is naive as anyone who has been around here a short time could tell you that was never going to happen.

I didn't expect much from that proposal but it was worth trying. It's now clear to me that it's never going to happen. It was less of a pipe dream than enabling SELinux support in many packages + shipping complex policies via labels on files/directories :).

2) A few years back we specifically reduced the number of kernels in our repos to one. Then the LTS kernel appeared. Now this. The problem with adding a non-vanilla kernel to the repos is now for kernel bug reports we have to verify which kernel is running. If it is linux-grsec, we then need to figure out if the issue a generic linux one, or with the other patchset. This is a burden to all our the kernel maintainers and not just the packager and is part of the reason the variety of kernels was reduced.

Output from `uname -a` or `dmesg` is a pretty basic requirement for a kernel issue, especially since problems like /boot not being mounted and new upgrades installed to the wrong place often happen. I don't mind being the one who asks for this on any [linux] issues missing it. I'll have to dig up the old discussion because I wasn't around for it.

3) Now this is in [community] there will be an expectation of providing all the extras that are supposed to come with this. As decided, this will not be happening, but it will be expected and the question will need to be answered repeatedly.

Whether or not the kernel is in the repositories, I'm going to be maintaining the userspace components in [community] so there is going to an expectation of support (from me). Rather than providing the PaX exceptions via file attributes, it can be done via an RBAC policy. If I didn't think I could provide all of the extras, I wouldn't be taking on the responsibility. https://bugs.archlinux.org/task/39983 The downside of this solution from a user perspective is that it won't work for the PaX subset alone (linux-pax, which I have no interest in) so the hacks in the AUR will stay around. It also means extra pain for me since it's not yet written, but no one else has to worry about that.

4) A separate repo would have given actual number for interest in this. We all know the number of votes in the AUR is a crap metric and could have accumulated a long time ago. It would also have allowed us to see how important the above issues are. Despite assertions, many binary repos are well used by the Arch community.

If what ends up happening is that it sees little use and/or causes work for other people, it can be dropped again. I don't think we're ever going to find that out from an unofficial repository. At the very least moving it to [community] is going to make a bunch of people angry about it and we can get to a resolution faster.

5) There were objections to it being included in our binary repos. This does not happen often, but we usually discuss further and come to a consensus about inclusion. Ignoring those objections is not how our team works. Given the relatively few people who responded to the thread, we have no real idea what the support was (and I can provide unsupported anecdotes for support against or for inclusion of the package as well as the next person can...)

I know there were objections, but as you said few people felt like voicing their opinion here. A real vote would make sense but I don't see value in arguing in circles with the same few people. I'm not ignoring real issues that are raised, like the added work of distinguishing between which kernel users are using. I'm willing to put in whatever time is required to prevent this from increasing the workload of people who aren't interested in it. If that means stepping up and beginning to help with [linux] bug triage, I can do that.

In conclusion, this should have waited before being put in the repo. It might have ended up there anyway, it might not have. And I can not be bothered figuring it out as it will not affect me in any way.

If the end result is that it ends up back in the AUR, that's fine. I moved it because I didn't feel this was a productive discussion anymore. Arguing about this on the mailing list for weeks is going to cause much more pain than it simply being in [community].