Am 29.07.2015 um 17:48 schrieb Jeffrey Walton: > > As VS 2015 is finally out, I wanted to point to a very interesting > feature of it's compiler: > > The /control flow guard/. > > https://msdn.microsoft.com/en-us/library/dn919635.aspx > > This feature should prevent some standard exploit attacks but is > only available to VS2015 so we'd have to add a solution file for > this one to enable this feature by default. > > > > > So my question: > > Should we make a set of solution files for every VS version to > support them to the best we can as there are certainly some nice > and interesting new features since VS 2005? > > > Four points come to mind.... First, this is generally referred to as > hardening or platform security integration. I'm a big fan of it. When > I audit software, I generate a finding if I see a missed opportunity. > (I'm fairly fanatical, and I'll generate a finding if I cannot easily > set a CFLAG used for testing, like -fsanitize=undefined). > > Second, Crypto++ does not really provide complete remediations. That's > a nice way of saying it misses some opportunities. I'm not sure what > to do with them in cryptest.exe because its just a test program. > Opportunities in the library are a different story, and they should be > taken. cryptest.exe is just the libraries self-validation tool right? I think it's ok if it isn't hardened as much as possible. The library on the other hand should be hardened as much as we can so it's never /our /fault if a program using Crypto++ gets successfully attacked. > > Third, I'm sure what to do about multiple solution and multiple > project files. I've done this in the past, an I found the following > scheme works well: > > cryptest.vs13.sln // Visual Studio 2005 > cryptest.vs16.sln // Visual Studio 2010 > cryptest.vs18.sln // Visual Studio 2015 > > You probably see where this is going: clutter. Yeah I've already expected that, but if the next point is applicable we don't need this (+ we really don't want this). > > Fourth, regarding CFG for VS2015, the project files are just XML > files. XML has conditional statements, so I'd be interested to know if > there's some way it can be added and guarded with something like (yep, > you write the '<' as <): > > <xsl:if test="@version < '1800'"> > <xsl:apply-templates select="//*[@class='special-cfg']"/> > </xsl:if> I've just posted a question on how we can do this on StackOverflow: http://stackoverflow.com/q/31734545/4733946. Let's see how it ends...
BR JPM > > Jeff > -- > -- > You received this message because you are subscribed to the "Crypto++ > Users" Google Group. > To unsubscribe, send an email to > [email protected]. > More information about Crypto++ and this group is available at > http://www.cryptopp.com. > --- > You received this message because you are subscribed to the Google > Groups "Crypto++ Users" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
