Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/30/2014 02:25 AM, Thierry Carrez wrote:
> Kurt Seifried wrote:
>> On 05/29/2014 12:47 AM, Clark, Robert Graham wrote:
>>> I certainly share your frustration, I think the idea with the 
>>> anti-patterns is to document the things that get done badly
>>> most often in OpenStack and format them in a way that¹s easily 
>>> consumable by core devs and PTLs. The list should be short
>>> enough that they can refer back to it while reviewing new
>>> features.
>> 
>>> It¹s not going to fix anything on it¹s own but anything we can
>>> do to help developers not make the same mistakes which, as you
>>> point out, have been made for the last 20 years - is a good
>>> thing.
>> 
>>> -Rob
>> 
>> So a concrete example, I wrote this in 2012? Nothing new, all
>> this goes back a few decades:
>> 
>> https://kurt.seifried.org/2012/03/14/creating-temporary-files-securely/
>>
>>
>> 
Then I checkout all the source code:
>> [...]
> 
> Yes, it's frustrating. We run those greps from time to time, fix
> stuff, but then some new are added, or some new component appears
> with its own share.
> 
> Ideally we would write a hacking-style test that we would gate
> against (to prevent reintroduction) and run those greps at
> incubation time (to prevent new components from inserting them).
> 
> The problem is, to make it part of gating we'd have to come with
> an automated detection that would be right most of the time (and
> that you can actively disable in remaining cases). However we
> receive a lot of automated reports at the VMT lately, and more than
> half of them are actually shallow and do not represent a real
> vulnerability -- automated detection is hard.
> 
> So this is not a simple problem.

If automated code analysis worked as well as people wanted ... yeah,
we'd have fixed a lot more bugs by now =).

One strategy to deal with the false positives is to simply add source
code comments before the offending line, e.g. with brakeman reports it
shows a few lines before/after the offending code, rather than build a
separate system to track false positives just fold that information
back into the code ("the following line triggers X, but don't worry
because Y"), the challenge of course is to keep these exceptions up to
date and correct in case the code changes in a way that does turn the
false positive into a real issue.

You can try to get code at check-in time but there may not be enough
context, another strategy is to integrate code checks (e.g. for Ruby
tying the brakeman scanner into Jenkins) at build time, and have a
strong feedback loop to ensure this stuff actually gets looked at and
fixed if needed (non trivial).

- -- 
Kurt Seifried - Red Hat - Product Security - Cloud stuff and such
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTiLBYAAoJEBYNRVNeJnmTNw8P/3NLTX6GavN5M4Kjub/1/qpL
n76+s0ycz/BVlKaisuEB2qDf3GWB29/PkdKwSo2WTyrWuo9LWh8QT9bjjS01qBmY
q8UwbOKsgdEs/zwpU+yWRr02oQm2GSTKi3QgvJAdcvgo7bkwXLQVsdoxASGgDbwI
3TsxuU6QOYmdEB9BVP8/RDLEjHdUM/32KlZdy6c8yCLl1Zbjf65ILfMuj0iNmmdq
TvUGGfO4GySLEvApzeuq5YOPR19JUKaAmcYfN/Fcixd3BEE/4Tl/7cYLoFkfTAnE
6hb3PSCPGSHVA8Z+M0R6NigZ9LSpeEw4lSqzu4ZipzbemMmTgwJEYCIj8LrSRW/H
L5AdrkUQbXrHnCfL3BCKnDOrY8VaEpy0xRjX6KWyxTchztNUFyZyjxN62TabveK2
0x6htFKat3d2jw0vMrFLaNLV2g3tzA6Rg93du2RcJPgfBJEzrua1nZTKnC1mX3gW
qgakG64NoDxHE23JqSmCoQzXWE/0C6hy2PjHaMSjR1sk8kKchZuO1qml2AeGKEzQ
iP5q/8972ny+SNF8/NGxXft1Vt1gW/JR1atwak+O9HRP0CorHH7WbaWwqnoe57Uj
a+0JZZ/spJtHTHh1acI/pBRbEtI4F1vwpreuNcMbRvjQXa/C/lNLf0flkxGzWwAY
VBiGFlXzzNXvuMmyVAd2
=ox8g
-----END PGP SIGNATURE-----