| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 01/09/2014 07:17 PM, Ryan Hill wrote: |
| 5 |
> On Thu, 9 Jan 2014 17:30:46 -0600 Ryan Hill <dirtyepic@g.o> |
| 6 |
> wrote: |
| 7 |
> |
| 8 |
>> On Thu, 09 Jan 2014 17:29:26 -0500 "Rick \"Zero_Chaos\" Farina" |
| 9 |
>> <zerochaos@g.o> wrote: |
| 10 |
>> |
| 11 |
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 |
| 12 |
>>> |
| 13 |
>>> On 01/09/2014 05:21 PM, Michał Górny wrote: |
| 14 |
>>>> Dnia 2014-01-09, o godz. 17:06:52 "Anthony G. Basile" |
| 15 |
>>>> <blueness@g.o> napisał(a): |
| 16 |
>>>> |
| 17 |
>>>>> On 01/09/2014 04:57 PM, Pacho Ramos wrote: |
| 18 |
>>>>>> What are the advantages of disabling SSP to deserve that |
| 19 |
>>>>>> "special" handling via USE flag or easily disabling it |
| 20 |
>>>>>> appending the flag? |
| 21 |
>>>>> |
| 22 |
>>>>> There are some cases where ssp could break things. I know |
| 23 |
>>>>> of once case right now, but its somewhat exotic. Also, |
| 24 |
>>>>> sometimes we *want* to break things for testing. I'm |
| 25 |
>>>>> thinking here of instance where we want to test a pax |
| 26 |
>>>>> hardened kernel to see if it catches abuses of memory which |
| 27 |
>>>>> would otherwise be caught by executables emitted from a |
| 28 |
>>>>> hardened toolchain. Take a look at the app-admin/paxtest |
| 29 |
>>>>> suite. |
| 30 |
>>>> |
| 31 |
>>>> Just to be clear, are we talking about potential system-wide |
| 32 |
>>>> breakage or single, specific packages being broken by SSP? In |
| 33 |
>>>> other words, are there cases when people will really want to |
| 34 |
>>>> disable SSP completely? |
| 35 |
>>>> |
| 36 |
>>>> Unless I'm misunderstanding something, your examples sound |
| 37 |
>>>> like you just want -fno-stack-protector per-package. I don't |
| 38 |
>>>> really think you actually want to rebuild whole gcc just to |
| 39 |
>>>> do some testing on a single package... |
| 40 |
>>>> |
| 41 |
>>> Or just as easily set -fno-stack-protector in CFLAGS in |
| 42 |
>>> make.conf. |
| 43 |
>>> |
| 44 |
>>> I never felt manipulating cflags with use flags was a great |
| 45 |
>>> idea, but in this case is does feel extra pointless. |
| 46 |
>>> |
| 47 |
>>> Personally I don't feel this is needed, and the added benefit |
| 48 |
>>> of clearing up a bogus "noblah" use flag makes me smile. |
| 49 |
>>> |
| 50 |
>>> Zorry, do we really need this flag? |
| 51 |
>> |
| 52 |
>> Yes, we do. I want a way to disable it at a toolchain level. |
| 53 |
> |
| 54 |
> Let me clarify. I would like to be able to disable it without |
| 55 |
> relying on CFLAGS or anything the user could fiddle with. I need a |
| 56 |
> big red off switch, at least for now. |
| 57 |
> |
| 58 |
> |
| 59 |
I think if you clarify this last statement a lot of the arguments will |
| 60 |
vanish. I believe most of us are happy to hear your thoughts in a |
| 61 |
little more detail, and will be swayed by them. |
| 62 |
|
| 63 |
- -Zero |
| 64 |
-----BEGIN PGP SIGNATURE----- |
| 65 |
Version: GnuPG v2.0.22 (GNU/Linux) |
| 66 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 67 |
|
| 68 |
iQIcBAEBAgAGBQJSz5W+AAoJEKXdFCfdEflKle4P/3pwjbSDuPy56TXvyH43/Ucg |
| 69 |
LvTtyycvGF5pw4UzNBPoao+E7F4E84MFIrfLGE3XpkH1J4v4SLXwh+CuHJHaSxJg |
| 70 |
Zx1C6zhk0HnAS2LZHDCuS14+zyOpF/VELOZAimr8V1UBTot3gyZUVvBIsXoJwKx6 |
| 71 |
3nb+abTHHIFDcSGJz6KM36dy67MMW2kpcKTx5Wu7W91232K8WY3v1KuNRtLBQkd/ |
| 72 |
/YNcpkW3fkA5Plk7sMTFb8iL6k2oajNw/3PKvX9L/MSBf+PmGKB7yA3Yt5Qu2Grw |
| 73 |
gUdUel/fCtXyhv1Had3pjeqZCgK7mFUuw6pAieQen2cYmAypLTC8D7JpaIBkJ9G0 |
| 74 |
cAz4lBB4EXc+l5mh2SS9D4LqL/4bWu3f7xFdeSuGcoxU1aL8/pgAvz0LpP7/o8ib |
| 75 |
BMdvwPcy5zn9W5+jkx5IZXidIpEBHzJKEnSR5+Mf39xn9z0nOrEvzGWxEHIerlWc |
| 76 |
hlHNU8x5wsZdnfJsY9tOfb5/hCOZW6uTtdvSR7eDFC6+xx2kBuiS+lC9Dtg76t1q |
| 77 |
VAiDOQIb1qgM9D6IUA+Q6WG2sWj3aTmZxfRYYQZ0DBGG266Rr2HaQaVDmWjU8W2u |
| 78 |
etxretxm0emYr8vHBPJD1XKwOCs577u4W5sVrQbZl+VutEVH+pqJTg0NOYxTeSTW |
| 79 |
CWAZGdV093+dQAa58/M4 |
| 80 |
=YP+O |
| 81 |
-----END PGP SIGNATURE----- |
Archives