> So I think it would be a good idea to flip the default to -z,now in
> the
> linker if we're going to use -fno-plt. I think they'd take a patch for
> that upstream. Clang issue could be avoided with a 1 line patch adding
> another no-op flag and they'd take that upstream. It's harmless to use
> th
On Wed, 2017-07-05 at 21:06 +0300, Evangelos Foutras wrote:
> On 5 July 2017 at 19:51, Daniel Micay wrote:
> > On Wed, 2017-07-05 at 12:36 +0300, Evangelos Foutras wrote:
> > > On 2 July 2017 at 19:19, Daniel Micay via arch-dev-public
> > > wrote:
> > > &
On Wed, 2017-07-05 at 12:36 +0300, Evangelos Foutras wrote:
> On 2 July 2017 at 19:19, Daniel Micay via arch-dev-public
> wrote:
> > Using -fno-plt would be a nice tiny little performance boost at
> > runtime
> > but then it's important to make sure everything is comp
Anyway, I think -Wl,-z,now, --enable-default-pie and --enable-default-
ssp are a good starting point.
Could enable -fstack-check=specific now, but it's not going to save a
mass rebuild by doing it now (if the goal is to rebuild everything
important with it) because they'll be improving it.
Using
On Sun, 2017-07-02 at 08:32 +1000, Allan McRae wrote:
> On 02/07/17 06:51, Bartłomiej Piotrowski wrote:
> > On 2017-06-30 23:44, Allan McRae wrote:
> > > On 30/06/17 19:07, Bartłomiej Piotrowski wrote:
> > > > On 2016-10-24 05:56, Allan McRae wrote:
> > > > > 1) building gcc to enable PIE by defaul
On Fri, 2017-06-30 at 11:07 +0200, Bartłomiej Piotrowski wrote:
> On 2016-10-24 05:56, Allan McRae wrote:
> > 1) building gcc to enable PIE by default
>
> I am in the middle of rebuilding gcc with --enable-default-pie. When
> it
> finishes, I will start a todo for rebuilding packages with static
>
> I need time to fix this. It is probably just test suite assumptions
> rather than errors.
Could we start with the changes other than PIE? Those won't need any
immediate rebuilds.
signature.asc
Description: This is a digitally signed message part
On Wed, 2016-09-28 at 21:12 +0200, Bartłomiej Piotrowski wrote:
> On 2016-09-28 05:10, Allan McRae wrote:
> >
> > The most pressing issue is #1. So lets get back to the issue of the
> > increasing amount of software requiring SSE2. How do we solve this?
>
> I thought about it, and I lean toward
On Fri, 2016-09-16 at 21:44 +0200, Bartłomiej Piotrowski wrote:
> Actually, why don't raise the bar higher? SSE2 has been introduced in
> 2001 – that's 15 years to upgrade one's hardware and given my sad
> experiences with computers, I find it hard to believe anyone has that
> old PC that happens t
On Tue, 2016-07-19 at 03:39 +0200, Balló György via arch-dev-public
wrote:
> I agree with this, and the same apply for vlc I think, which recently
> lost
> its qt4 dependency:
> https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packag
> es/vlc&id=b1a56bb8d107ebb51a6f2e32c67f866e2693517
On Fri, 2016-07-01 at 21:24 +0200, Florian Pritz via arch-dev-public
wrote:
> Am 2016-06-30 09:41, schrieb Johannes Löthberg via arch-dev-public:
> > That has actually come up on IRC a lot of times over the last
> > couple
> > years, users asking how to sign-off packages / if they can help
> > sign
> So linux-grsec supports no out-of-tree module? No requirement on dkms
> for it, then. Fine by me.
NVIDIA is the one of the few that would make sense because the PaX
upstream actually maintains a patch for it:
https://www.grsecurity.net/~paxguy1/nvidia-drivers-361.28-pax.patch
If I was going to
> To me the issue is people pushing new kernels to the repos but not
> being
> able to provide the same level of support that we have for mainline.
> Offloading out-of-tree module rebuilds to end users instead of doing
> it
> ourselves is clearly not the right solution.
>
> So I say: remove each n
On 15/09/15 08:26 AM, Jan Alexander Steffens wrote:
> Hi,
>
> I was quite surprised today that gcc suddenly started defaulting to
> -fstack-check. After some confusion and a bit of exploration, it turned out
> that hardening-wrapper, which came as a makedep with python, was
> responsible.
>
> It
-fstack-check works very well on x86 and x86_64 but is quite buggy on
other architectures like ARM. I'm not quite sure if that was the point
being made though.
signature.asc
Description: OpenPGP digital signature
On 20/07/15 12:03 AM, Gaetan Bisson wrote:
> [2015-07-19 16:37:42 +0200] Jan Alexander Steffens:
>> I recently noticed we have community/linux-grsec. Do we have a stance
>> on additional kernels? I vaguely remember some stigma against it but
>> not the details. Maybe I'm completely wrong.
>
> For
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 us
On 19/01/15 06:29 PM, Lukas Fleischer wrote:
> I would like to move lirc from [testing] to [extra] soon. Here is a
> draft news item ("Packaging changes in lirc 0.9.2"):
>
> For consistency with upstream naming, the lirc-utils package was
> renamed to lirc. The wpc8769l kernel drivers were
On 31/12/14 04:47 AM, Pierre Schmitz wrote:
> Am 26.12.2014 01:56, schrieb Allan McRae:
>> I am not in favour of using the hardening script because I don't find it
>> adheres to what we consider KISS. Our build system is supposed to be
>> simple and entirely transparent when looking at the PKGBUIL
On 25/12/14 07:56 PM, Allan McRae wrote:
>
> I'd guess it has a good change to be included in gcc-5.0. If it gets
> committed I can backport immediately.
>
> I am not in favour of using the hardening script because I don't find it
> adheres to what we consider KISS.
I can understand that. It wo
> The problem is that it's important for anything doing networking, any
> executable with setuid/setcap/setgid and anything run by users on
> untrusted input like image viewers, text editors and tools like file and
> strings. If `python` or `ruby` isn't PIE, then it's trivial to exploit
> heap buff
On 21/12/14 06:44 PM, Allan McRae wrote:
> On 22/12/14 06:53, Daniel Micay wrote:
>
> Yet we have already rebuilt ALL packages since adding this default.The
> static libraries left have no shared coutnerpart.
Ah, I forgot that there was a rebuild for that already. They'd just n
One more thing to note about this is that we'd need to do a rebuild of
the remaining 186 packages with static libraries. In many cases, those
libraries will probably just vanish thanks to the !staticlibs default.
Static libraries aren't currently built as position independent unless
they're meant
On 21/12/14 04:51 AM, Lukas Jirkovsky wrote:
> Hello Daniel,
> thank you for the detailed explanation.
>
>> The address of dynamic libraries, the stack and the heap (both sbrk and
>> the mmap base) is already randomized today so the backtrace is already
>> going to include randomized addresses for
On 19/12/14 03:50 AM, Lukas Jirkovsky wrote:
>
> No matter how much I like the idea of making Arch more secure, there
> is one thing that makes compiling the whole system with ASLR one big
> no-go for me (please correct me if I'm wrong). As far as I know, the
> ASLR makes core dumps completely usel
Arch's single biggest security weakness is that it's not benefiting from
address space layout randomization (ASLR). Fixing this issue would be a
major step towards being a leader in this area. Many distributions enable
ASLR, stack protector, etc. for a chosen set of "security critical" stuff
but ve
On 11/12/14 10:48 AM, Bartłomiej Piotrowski wrote:
>
> I couldn't manage to utilize any of criu features back when
> CONFIG_CHECKPOINT_RESTORE was enabled, for reasons I don't remember and
> have no log files about. Unless it's proven to be working, I see no
> reason why we should consider re-enab
On 26/08/14 03:47 PM, Jan Alexander Steffens wrote:
> On Wed, May 7, 2014 at 4:11 PM, Daniel Micay wrote:
>> RBAC also allows quite a bit of auditing with the grsecurity audit
>> infrastructure. You can audit attempts to make use of a certain path,
>> capability, IP protocol,
On 24/08/14 04:54 PM, Sébastien Luttringer wrote:
> On 20/08/2014 20:25, Dave Reisner wrote:
>> For packagers:
>> - systemd-sysusers is now a reasonable thing as it now reads and writes
>> to /etc/shadow and /etc/gshadow. This means that we can simplify the
>> filesystem package immensely, and
On 09/08/14 01:07 AM, Allan McRae wrote:
> On 09/08/14 14:53, Daniel Micay wrote:
>> The current strategy for handling this involves reserving ids for every
>> package needing users / groups and tracking it on the wiki. The wiki
>> doesn't actually correspond well to th
The current strategy for handling this involves reserving ids for every
package needing users / groups and tracking it on the wiki. The wiki
doesn't actually correspond well to the state of packages in the
repositories, as it's missing quite a few users / groups and has plenty
that are not used by
On 25/05/14 10:33 AM, Bartłomiej Piotrowski wrote:
> On Sat, 17 May 2014 22:57:46 +1000
> Allan McRae wrote:
>> On 17/05/14 22:40, Bartłomiej Piotrowski wrote:
>>> It's temporarily
>>> built using Clang, mainly because new gcc snapshot hasn't fixed
>>> segfaults for everyone.
>>
>> Please file bug
On 07/05/14 05:28 AM, Connor Behan wrote:
> On 07/05/14 01:07 AM, Daniel Micay wrote:
>> Sadly, the `perf trace` command has a dependency on libaudit for a few
>> convenience functions. I'm curious about what people feel the best
>> approach would be here... adding ba
On 07/05/14 05:28 AM, Connor Behan wrote:
> On 07/05/14 01:07 AM, Daniel Micay wrote:
>> Sadly, the `perf trace` command has a dependency on libaudit for a few
>> convenience functions. I'm curious about what people feel the best
>> approach would be here... adding ba
Sadly, the `perf trace` command has a dependency on libaudit for a few
convenience functions. I'm curious about what people feel the best
approach would be here... adding back audit to [community] is ugly since
it's not going to work, but building it and statically linking it in the
linux-tools pac
On 24/04/14 07:27 AM, Tom Gundersen wrote:
> Hi guys,
>
> It was recently brought to my attention (see below) that we still ship
> net-tools in Arch. Should we perhaps start working on dropping that? I
> regularly run into users who use it without knowing that it is dead
> and broken. Moving it to
On 22/04/14 03:21 PM, Connor Behan wrote:
>
> It's not just a matter of asking "what kernel are you using". You'll
> probably have to ask the bug submitter to install linux from [core],
> wait a day, and start comparing two sets of output.
Yeah, that's fine. If I'm already looking at them I might
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 add
On 21/04/14 01:54 AM, Gaetan Bisson wrote:
> 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] Da
On 21/04/14 12:40 AM, Gaetan Bisson wrote:
> [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
On 19/04/14 03:28 AM, Bartłomiej Piotrowski wrote:
> On Wed, 16 Apr 2014 00:09:55 -0400
> 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 a
On 20/04/14 05:12 AM, Sébastien Luttringer wrote:
> On 19/04/2014 01:21, Connor Behan wrote:
>> On 18/04/14 04:09 AM, S?bastien Luttringer wrote:
>>> On 16/04/2014 06:09, Daniel Micay wrote:
>>>> I don't think it makes sense to bother with the
>>>> n
On 20/04/14 04:32 AM, Florian Pritz wrote:
> 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,
On 19/04/14 06:23 PM, Tom Gundersen wrote:
> 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 pe
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
> It has taken over a decade for a few sysctl flags to enable some of the
> miscellaneous features from grsecurity.
(as in this stuff gets rejected time and time again until it was finally
accepted in a reversal of the previous decisions, so by now few people
other than Kees Cook are interested i
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.archli
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
On 19/04/14 02:11 PM, Connor Behan wrote:
> On 19/04/14 12:28 AM, Daniel Micay wrote:
>> 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
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 star
On 18/04/14 08:02 AM, Sébastien Luttringer wrote:
> On 18/04/2014 13:07, Daniel Micay wrote:
>> On 18/04/14 05:34 AM, Sébastien Luttringer wrote:
>>> On 18/04/2014 10:44, Daniel Micay wrote:
>>>> On 18/04/14 04:09 AM, Sébastien Luttringer wrote:
>>>>
On 18/04/14 05:34 AM, Sébastien Luttringer 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:
>> I could build these myself when I push a new version, because there
>>
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 sys
ary
> grsecurity packages [2]. Although I like the idea of further
> integrating grsecurity into Arch Linux, I have some points to
> criticize on the planning proposals of Daniel Micay.
>
>> It also includes the PaX project to provide a much stronger
>> implementation of AS
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 s
On 16/04/14 06:00 AM, 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 ins
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 avoid
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 fe
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:S
On 09/04/14 11:12 PM, Allan McRae wrote:
> On 10/04/14 12:58, Thomas Dziedzic wrote:
>> On Wed, Apr 9, 2014 at 12:07 AM, Magnus Therning wrote:
I'm guessing this means cabal-install now is the only package outside
of [community] that uses ghc to build. Is that right?
>> That wo
> So, in conclusion:
>
> 0 for removing kdelibs3
> -1 for removing gtk1
I think if we ship either qt3 or gtk1, that makes us upstream and we
become responsible for backporting any security fixes made in qt4/qt5
and gtk2/gtk3.
We usually hand wave away this kind of responsibility because we
prom
On 01/04/14 03:30 PM, Andrea Scarpino wrote:
> On Tue 01, April 20:48:16 Florian Pritz wrote:
>> Moving to extra sounds good.
>
> +1
>
>> Move it to extra and make it a dep of everything that logs to /var/log
>> by default, optdep for stuff that can be configured to log there. (both
>> assume tha
On 28/03/14 08:52 PM, Daniel Micay wrote:
> It's not currently enabled by default, and will have a narrow use case when
> the existing cron jobs on are.
are gone*.
signature.asc
Description: OpenPGP digital signature
On 28/03/14 06:01 PM, Tom Gundersen wrote:
> On Fri, Mar 28, 2014 at 3:01 AM, 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 (alth
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 an
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.
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 tim
On 26/03/14 02:56 PM, Thomas Bächler wrote:
> Hello all,
>
> it won't be too long until 3.14 is out and I want to address a topic
> that has been bugging me for a while. Our kernel includes everything and
> the kitchensink. I have no problem with delivering drivers that can be
> built modular, but
On 26/03/14 03:08 PM, Dave Reisner wrote:
> On Wed, Mar 26, 2014 at 07:56:26PM +0100, Thomas Bächler wrote:
>> Hello all,
>>
>> it won't be too long until 3.14 is out and I want to address a topic
>> that has been bugging me for a while. Our kernel includes everything and
>> the kitchensink. I have
On Sat, Jul 13, 2013 at 1:21 AM, Andreas Radke wrote:
> I've built libdrm now with CLANG compiler and so far also no problems.
> Clean dmesg, no hangs and no glitches over Firefox tabs.
>
> I suggest to push a "fixed" package built with clang to testing and
> report this one to gcc people.
>
> Opi
On Mon, May 20, 2013 at 5:57 AM, Jelle van der Waa wrote:
> I'm thinking about dropping uml_utilities, I have used it in the past in
> uni courses. But now I don't use it anymore and I think there are better
> alternatives atm ( latest release was in 2007 ).
>
> I'm dropping it unless someone want
71 matches
Mail list logo
