Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS

2020-05-14 Thread Levente Polyak via arch-dev-public
On 5/14/20 9:46 AM, Morten Linderud wrote:
> On Thu, May 14, 2020 at 09:39:58AM +0200, Levente Polyak via arch-dev-public 
> wrote:
>>> At the end of the month I'll make a todo with the remaining packages 
>>> depending
>>> on `go-pie`.
>>>
>>> The complete future Go PKGBUILD is attached to this email below.
>>>
>> PS: shouldn't we look into Go getting those flags as well? The Go
>> compiler itself doesn't have RELRO and fortified sources :)
> 
> Because everything, sadly, breaks. I'd much rather try look into 
> reproducibility
> before actually caring about binary hardening.
> 
> If we PIE compile the test suite upstream fails quite badly. Evidently 
> upstream
> doesn't test the go compiler with PIE/RELRO enabled. Unsure if they care at 
> all
> even. If we also try define `CGO_CFLAGS` we end up with errors like:
> 
> /usr/include/features.h:397:4: error: #warning _FORTIFY_SOURCE requires 
> compiling with optimization (-O) [-Werror=cpp]
> 
> `-buildmode=pie` is also going to land you in trouble with the race detection 
> in
> their test suite.
> 
> So not quite there yet for the compiler itself.
> 


/o\ @ upstream

not sure what else to say :P

If you wanna take an adventure in the future, feel invited to ping me
for the ultimate quest to explore the rabbit hole in detail and maybe at
least get RELRO or something.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature


Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS

2020-05-14 Thread Morten Linderud via arch-dev-public
On Thu, May 14, 2020 at 09:39:58AM +0200, Levente Polyak via arch-dev-public 
wrote:
> > At the end of the month I'll make a todo with the remaining packages 
> > depending
> > on `go-pie`.
> > 
> > The complete future Go PKGBUILD is attached to this email below.
> > 
> PS: shouldn't we look into Go getting those flags as well? The Go
> compiler itself doesn't have RELRO and fortified sources :)

Because everything, sadly, breaks. I'd much rather try look into reproducibility
before actually caring about binary hardening.

If we PIE compile the test suite upstream fails quite badly. Evidently upstream
doesn't test the go compiler with PIE/RELRO enabled. Unsure if they care at all
even. If we also try define `CGO_CFLAGS` we end up with errors like:

/usr/include/features.h:397:4: error: #warning _FORTIFY_SOURCE requires 
compiling with optimization (-O) [-Werror=cpp]

`-buildmode=pie` is also going to land you in trouble with the race detection in
their test suite.

So not quite there yet for the compiler itself.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature


Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS

2020-05-14 Thread Levente Polyak via arch-dev-public
On 5/13/20 10:16 PM, Morten Linderud via arch-dev-public wrote:
> 
> If there are no objections, I'll probably merge the guidelines this weekend
> section-by-section to make the wiki admins happy. The new package should land
> sometime nextweek.
> 

Awesome, thanks a lot this is a great step to improve the security of Go
applications on a binary level.


> At the end of the month I'll make a todo with the remaining packages depending
> on `go-pie`.
> 
> The complete future Go PKGBUILD is attached to this email below.
> 
PS: shouldn't we look into Go getting those flags as well? The Go
compiler itself doesn't have RELRO and fortified sources :)

cheers,
Levente



signature.asc
Description: OpenPGP digital signature