while i found this bug:
https://issues.guix.gnu.org/67839
i was reading the discussion under its probable root cause:
https://github.com/wingo/fibers/issues/29
and it suggests that Guile before 3.0.5 had important bugs WRT fluids, which
are relied upon in shepherd. maybe Guile 2.2 can not be u
Hello!
Attila Lendvai skribis:
> the codebase seems to use catch/throw, and at some places with comments like
> "for Guile 2.2". what is the minimum guile version that the shepherd codebase
> wants to support? the README says "GNU Guile 3.0.x or 2.2.x". is this still
> intended? or can i assu
dear Guix,
i'm working on hardening shepherd's error handling and logging to debug an
issue that i'm facing. these changes escalated quickly, so i'm writing to
clarify a few things before i shape the codebase into a direction that the
maintainers will not accept.
the c
Let's keep this thread as the thread to discuss possible solutions and work
in that field.
Yesterday Marius wrote on IRC
(https://gnunet.org/bot/log/guix/2018-03-21#T1657250):
[] This is a pretty good article about build flags
(mainly hardening related):
ng0 writes:
>> > The flags I use (suggested by Debian Wiki[0]) are:
>> >
>> > CPPFLAGS=-D_FORTIFY_SOURCE=2
>>
>> How does this differ from "-O2 -D_FORTIFY_SOURCE" in CFLAGS?
>> I know O2 is optimization and that FORTIFY_SOURCE requires optimization
>> to be specified.
>
> Okay, I've read some
n CFLAGS?
> >> I know O2 is optimization and that FORTIFY_SOURCE requires optimization
> >> to be specified.
> >
> > Okay, I've read some related commits and bug tickets, I understand
> > the difference now.
>
> Please share. Otherwise this commen
ng0 transcribed 1.6K bytes:
> Alex Vong transcribed 1.3K bytes:
> > Hello,
> >
> > n...@n0.is writes:
> >
> > > Hi,
> > >
> > > as we've long talked and not really taken action on hardening builds
> > > I've started work
Alex Vong transcribed 1.3K bytes:
> Hello,
>
> n...@n0.is writes:
>
> > Hi,
> >
> > as we've long talked and not really taken action on hardening builds
> > I've started working on an opt-in way as last discussed in
> > september 2016, modifyi
Hello,
n...@n0.is writes:
> Hi,
>
> as we've long talked and not really taken action on hardening builds
> I've started working on an opt-in way as last discussed in
> september 2016, modifying the gnu-build-system with a
> #:hardening-flags keyword.
>
>
and testing. I'll send
patches as soon as I have something to go with, today I only had
breakage on the bootstrap level ;)
> On Mon, Jan 29, 2018, at 4:44 AM, n...@n0.is wrote:
>> Hi,
>>
>> as we've long talked and not really taken action on hardening builds
>&g
Is this something anyone can start using now? Like I can modify my config.scm
file somehow and start enjoying a hardened guix?
On Mon, Jan 29, 2018, at 4:44 AM, n...@n0.is wrote:
> Hi,
>
> as we've long talked and not really taken action on hardening builds
> I've starte
Hi,
as we've long talked and not really taken action on hardening builds
I've started working on an opt-in way as last discussed in
september 2016, modifying the gnu-build-system with a
#:hardening-flags keyword.
For my testing purposes I will use
> CFLAGS="-fPIE -fs
shepherd
> > 26.7 MiB + 551.5 KiB = 27.3 MiB emacs-25.2
> > 131.1 MiB + 6.2 MiB = 137.3 MiB .guix-real
> > 732.7 MiB + 932.0 KiB = 733.6 MiB tor
> > …
> > uptime: 6:24h
> >
> > Now I wouldn't consider tor to be problematic when
to be problematic when this would be the
> default for tor. But it isn't, and --enable-expensive-hardening is an
> experimental function which is not enabled by default from upstream (as
> all our recently added config options for tor (not sure right now if all
> are experimental
= 27.3 MiB emacs-25.2
131.1 MiB + 6.2 MiB = 137.3 MiB .guix-real
732.7 MiB + 932.0 KiB = 733.6 MiB tor
…
uptime: 6:24h
Now I wouldn't consider tor to be problematic when this would be the
default for tor. But it isn't, and --enable-expensive-hardening is an
experimenta
contact@cryptolab.net skribis:
> From: ng0
>
> * gnu/packages/tor.scm (tor)[arguments]: Add '--enable-expensive-hardening',
> 'enable-gcc-hardening', '--enable-linker-hardening' to configure-flags.
Applied, thanks.
Ludo'.
On Wed, Jan 25, 2017 at 09:31:07AM +, contact@cryptolab.net wrote:
> From: ng0
>
> * gnu/packages/tor.scm (tor)[arguments]: Add '--enable-expensive-hardening',
> 'enable-gcc-hardening', '--enable-linker-hardening' to configure-flags.
LGTM. Does anyone else want to test before pushing?
now, look at Hardened-gentoo and other systems how
>>> they solve issues. Afterwards we need to address the toolchain
>>> level, which to our advantage can be an make and break by hydra
>>> and everyone who wants to contribute to fixing issues can run
>>> th
>> they solve issues. Afterwards we need to address the toolchain
>> level, which to our advantage can be an make and break by hydra
>> and everyone who wants to contribute to fixing issues can run
>> their system from the hardening-toolchain-wip branch to
>> contri
he toolchain
> level, which to our advantage can be an make and break by hydra
> and everyone who wants to contribute to fixing issues can run
> their system from the hardening-toolchain-wip branch to
> contribute to fixing all the breaking applications.
>
> Then we need to disc
Ricardo Wurmus writes:
> Leo Famulari writes:
>
>> On Tue, Jan 24, 2017 at 08:56:48PM +, ng0 wrote:
>>> Leo Famulari writes:
>>> > Should we build Tor with "--enable-expensive-hardening"?
>>>
>>> I will take a look later w
From: ng0
* gnu/packages/tor.scm (tor)[arguments]: Add '--enable-expensive-hardening',
'enable-gcc-hardening', '--enable-linker-hardening' to configure-flags.
---
gnu/packages/tor.scm | 4
1 file changed, 4 insertions(+)
diff --git a/gnu/packages/tor.sc
Leo Famulari writes:
> On Tue, Jan 24, 2017 at 08:56:48PM +, ng0 wrote:
>> Leo Famulari writes:
>> > Should we build Tor with "--enable-expensive-hardening"?
>>
>> I will take a look later what can be applied other than the
>> default config
n.
>>>
>>> No, I would say this needs an effort of more than one person. At
>>> best a team of people who either are willing to learn about
>>> system hardening or already know enough, maybe even a combination
>>> of both to share knowledge :)
>>
have as much
>> >>> experience with SELinux (and only basic experience with
>> >>> GrSecurity without a modular kernel like GuixSD uses).
>> >>
>> >> Yes, this effort needs a champion.
>>
>> No, I would say this needs an effort of
ience with SELinux (and only basic experience with
> >>> GrSecurity without a modular kernel like GuixSD uses).
> >>
> >> Yes, this effort needs a champion.
>
> No, I would say this needs an effort of more than one person. At
> best a team of people who either are w
ng0 writes:
> Leo Famulari writes:
>
>> On Tue, Jan 24, 2017 at 08:56:48PM +, ng0 wrote:
>>> Leo Famulari writes:
>>> > Should we build Tor with "--enable-expensive-hardening"?
>>>
>>> I will take a look later what can be app
Leo Famulari writes:
> On Tue, Jan 24, 2017 at 08:56:48PM +, ng0 wrote:
>> Leo Famulari writes:
>> > Should we build Tor with "--enable-expensive-hardening"?
>>
>> I will take a look later what can be applied other than the
>> default configu
On Tue, Jan 24, 2017 at 08:56:48PM +, ng0 wrote:
> Leo Famulari writes:
> > Should we build Tor with "--enable-expensive-hardening"?
>
> I will take a look later what can be applied other than the
> default configure flags.
>
> I'm all for hardening,
Leo Famulari writes:
> On Tue, Jan 24, 2017 at 11:19:33AM +, contact@cryptolab.net wrote:
>> Changes in version 0.2.9.9 - 2017-01-23
>> o Major bugfixes (security):
>> - Downgrade the "-ftrapv" option from "always on" to "only on
gt;>> packages will not get these flags, for instance because they pass their
>>> own #:configure-flags.
>>>
>>> IOW, it will take a whole rebuild to find out exactly what’s going on
>>> and to fix any issues.
>>>
>>> Would you lik
>>
>> IOW, it will take a whole rebuild to find out exactly what’s going on
>> and to fix any issues.
>>
>> Would you like to start working on it? Then we could create a branch,
>> have Hydra build it, and incrementally fix things.
>
> We should pick th
ild, and (2) another third of the
>>>>> packages will not get these flags, for instance because they pass their
>>>>> own #:configure-flags.
>>>>>
>>>>> IOW, it will take a whole rebuild to find out exactly what’s going on
>>>>
ild, and (2) another third of the
>>>>> packages will not get these flags, for instance because they pass their
>>>>> own #:configure-flags.
>>>>>
>>>>> IOW, it will take a whole rebuild to find out exactly what’s going on
>>>>
t;> own #:configure-flags.
>>>>
>>>> IOW, it will take a whole rebuild to find out exactly what’s going on
>>>> and to fix any issues.
>>>>
>>>> Would you like to start working on it? Then we could create a branch,
>>>> have H
to fix any issues.
>>>
>>> Would you like to start working on it? Then we could create a branch,
>>> have Hydra build it, and incrementally fix things.
>>
>> We should pick this project back up. I was suprised to find we haven't
>> done anything li
>>
>> IOW, it will take a whole rebuild to find out exactly what’s going on
>> and to fix any issues.
>>
>> Would you like to start working on it? Then we could create a branch,
>> have Hydra build it, and incrementally fix things.
>
> We should pick th
; Would you like to start working on it? Then we could create a branch,
> have Hydra build it, and incrementally fix things.
We should pick this project back up. I was suprised to find we haven't
done anything like this after reading this recent blog post about Nix's
hardening effort:
https://blog.mayflower.de/5800-Hardening-Compiler-Flags-for-NixOS.html?utm_source=twitterfeed&utm_medium=twitter
ages, something
> like `use this set of flags, please'. For example, in Debian, if you
> type
>
> $ dpkg-buildflags --get CFLAGS
>
> you get
>
> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security
>
> which are thr default flags to be exported during
39 matches
Mail list logo
