[C-safe-secure-studygroup] Chat from 04_01_17

[Chris Polin]

Hi all,

Please find the chat logs from today's meeting attached.

Thanks,

Chris


On 04/01/17 17:46, Martin, Robert A. via C-safe-secure-studygroup wrote:
> While it worked last week during our test - I can not get things to 
> work today either.
>
> Bob
>
> On 1/4/17 12:13 PM, Roberto Bagnara via C-safe-secure-studygroup wrote:
>> On 01/04/2017 06:09 PM, Joe Jarzombek via C-safe-secure-studygroup 
>> wrote:
>>> Is there a phone number that I could use?  The Domain is being 
>>> blocked by my Network Admin.
>>
>> Unfortunately not.
>> I do not understand why the domain of the University of Parma
>> would be blocked by by anyone.  Are you sure there are no other
>> problems?
>>
>
> _______________________________________________
> C-safe-secure-studygroup mailing list
> C-safe-secure-studygroup at lists.trustable.io
> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup 
>

-------------- next part --------------

Andrew Banks: +1 DMK

Gavin: start at 90

David A. Wheeler: This is a good start time for me..

Clive Pygott: This time is OK for me

Aaron Ballman: This time works well enough for me

Roberto BAGNARA: +1

Andrew Banks: Where are the other participants? What is the local times?

Martin Sebbor: I can't make Tue.

Chris Polin: Sorry Roberto, that was my slipup that time.

David A. Wheeler: We worked hard to find this day

Bart Miller/Elisa Heymann: Monday is best for us.

Andrew Banks: Monday is probably OK... I tend to be home with the youngest!

Kostya Serebryany: Mon doesn't work for me....

Bart Miller/Elisa Heymann: Can't make it once/month.

Roberto BAGNARA: Monday is a problem for me too

Bart Miller/Elisa Heymann: (for Weds)

Bart Miller/Elisa Heymann: (I can't make it the 3rd Weds of the month).  So 2nd and 4th Weds are ok.

Andrew Banks: Most weeks have different committments... cannot answer generally!

David A. Wheeler: Thur problematic

Bart Miller/Elisa Heymann: Thurs is OK for 1 hour.

Laurence Urhegyi: I can't do Thursdays. 

Andrew Banks: My guess is there is no correct answer :(

Gavin: fri is the weekend

Kostya Serebryany: do we really need meetings? why not E-mail?

Andrew Banks: Vary days for each meeting to spread unavailability

David Keaton: E-mail is great for exploring issues, not for coming to consensus.

Chris Polin: Andrew Banks +1

Bart Miller/Elisa Heymann: Thank you.

Bart Miller/Elisa Heymann: I'll miss that one next week.

Andrew Banks: 4th Wed of each month is bad for me... :-)

Gavin: +1

Gavin: on Andrews comments

Martin Sebbor: Does this group have access to the MISRA spec?

Roberto BAGNARA: :-D

Chris Polin: Rub it in, Robert.

David Keaton: I had no idea the price was so reasonable.

Andrew Banks: Sorry... £18 for PDF...

Andrew Banks: https://www.misra.org.uk/shop/buy_now.php

David Keaton: Still reasonable.

Clive Pygott: Just to clarify - there are several MISRA documents.  The one relevant to this study group is MISRA C

Andrew Banks: Still cheaper than CERT-C :-)

Aaron Ballman: Does ISO allow us to admit the existence of older standards like C99?

David Keaton: Earlier standards are withdrawn.

Aaron Ballman: I was under the impression we could only track against the latest version of a standard.

Andrew Banks: Aaron... the deltas betweenC99 and C11 are mostly additions

Aaron Ballman: WG21 ran into this for the standard library stuff.

Aaron Ballman: Andrew Banks: true,, I was speaking more towards what reference documents we're "allowed" to reference in the formal document we submit to ISO

David A. Wheeler: The resulting document should apply to previous versions of C as well.  Many safety-critical and security-critical systems are already developed and move slowly.

Andrew Banks: +1 David

Andrew Banks: Many embedded compilers are still C90+

Aaron Ballman: Andrew Banks: aka, we may struggle to talk about gets() because it doesn't exist in C11.

David A. Wheeler: It should be easy to support multiple versions of C.  For the most part, the later C specs are additions.

Aaron Ballman: (I agree, I would like to support older versions of C as well.)

David A. Wheeler: There's no "struggle" talking about gets().  All *real* C compilers have a gets(), possibly with a warning.  We need to focus on reality.

Andrew Banks: Even better would be that C2x has no *new* issues requir5ing our action!

David A. Wheeler: Robert: Do *NOT* target *ONLY* C11.  Cover previous versions!

Aaron Ballman: David: ISO doesn't always focus on reality. As I said, we ran into issues with this in WG21 where ISO was claiming they were going to reject the C++ standard because it was referencing C99.

Bart Miller/Elisa Heymann: Will there be an intermediary points of standard release before C2x?

Murali Somanchy: i agree to David's comment

David A. Wheeler: You can always say "you're risking having people die".  ISO often relents for that.

Aaron Ballman: David: or we target C90 but reference C11 officially in the document and leave things that aren't in C11 as nonnormative text.

David A. Wheeler: Does that mean that tools that can't work with the C in use are okay?

Aaron Ballman: David: For some definition of "okay", perhaps. Obviously, we don't want them to give unsafe/insecure guidance. This is more a technical thing about what we reference in the formal document, not what we intend to cover with its contents.

Aaron Ballman: aka, the References section should only mention C11 and not C99, but we can certainly cover everything we want to from C99 and C90 in terms of the content.

Andrew Banks: If a feature of the language can lead to unsafe (or unpredictable) behaviour, even if existing code, we shoudl flag it!

Andrew Banks: "Don't break existing code" is a flawed strategy!

David A. Wheeler: BIPM only wants *one* unit for each measure, but they made an exception for radiation measures because there were human safety concerns.

David A. Wheeler: It's not "don't break existing code".  It's "don't make me throw away my compiler which only supports the older C spec"

David A. Wheeler: Changing compilers is a big deal, and carries its own risks.

Andrew Banks: Fully agree, David

Aaron Ballman: Also agreed.

Andrew Banks: Probaby the biggest change you can make!

Bart Miller/Elisa Heymann: As a side note, Elisa and I are participating in a project to help define software assessment procedures for avionics.

David A. Wheeler: Developers should know about the rules.  That said, it's reasonable to write a document *primarily* for tool makers.

David A. Wheeler: In practice, most developers don't read the rules ahead of time.  They write the code, and then run a tool to see what rules they missed.

David A. Wheeler: If the tools are repeatedly applied on each change, the developers learn the rules organically over time.

Bart Miller/Elisa Heymann: And developers need feedback when they inadvertinently violate the rules.

Bart Miller/Elisa Heymann: The tools are part of that learning process.

Gavin: in part, one of the most useful aspects of MISRA was it trains coders to write better language

Andrew Banks: +1 Gavin

David A. Wheeler: If we focus only on things tools can find, then that will help narrow scope to something easier to apply.

Gavin: still have no sound

Bart Miller/Elisa Heymann: Tools are an evoloving technology.  We should describe the right coding practices and use that to pull tools along.

Gavin: from misra c2 onwards, we started to determine what rules could be analysed, rather than justbloose ideas

David Keaton: Analyzer rules can be more rigorous than coding standards if desire

Gavin: a key difference we found when we started the Ford coding standard - are we limited to existing syntax, or are we adding anatation, i.e. like Spake Ada

Gavin: agree - not style

Andrew Banks: +1 Clive - plus Data flow analysis.... 

David A. Wheeler: There are some "style" things that make sense, though.  E.G., misleading indentation led to Apple's "goto fail;  goto fail;" disastrous security vulnerability.

Andrew Banks: Goto fail was a result of not encapsulating if/else with braces !

David A. Wheeler: There are many indentation styles - we shouldn't mandate one.

Andrew Banks: Nor not detecting unreachabe code

Andrew Banks: Sorry peeps... I'm going to have to leave.

David A. Wheeler: Encapsulating braces is *also* a "style" thing - and something many projects *will* reject.

Robert Seacord: ok, see you Andrew.

Andrew Banks: Speak soon...

Roberto BAGNARA: bye Andrew

David A. Wheeler: I think the "San Francisco" rule is fine as long as this dependency is *documented* .

David Keaton: +1 David

David A. Wheeler: "Analyzer vendors" probably includes gcc and clang...!

Gavin: documented with deviation triggering #error

David A. Wheeler: Most C compilers include many warning flags.

David A. Wheeler: I doubt ISO likes sharing :-)

Bart Miller/Elisa Heymann: Unreachable code is an interesting challenge because it can mean detecting when a functdion is no returning.

Bart Miller/Elisa Heymann: (no -> not)

Bart Miller/Elisa Heymann: An interesting question about indentation is whether we can come up with a rule that captures most "good" indenting styles?

David A. Wheeler: The GCC folks already have a warning for indentation.  They only trigger on "clearly misleading" case, e.g., a closing brace at end of previous line, but no outdent of next line.  I don't recall the details, but they're online.

Gavin: indentation is a style issue ;)

David A. Wheeler: Misleading indentation that disables cert validation is not a style issue.  Misleading indentation produces *different* code..

Gavin: poor style can lead to human error

David A. Wheeler: I like fuzzing for C programs - but is this out-of-scope?  I thought these would be more "rules for code" not "rules for test process".

Aaron Ballman: David: I don't think it's out of scope; this is a document telling analyzer vendors how to analyze code, so it seems reasonable to discuss whether fuzzing belongs in there or not.

Robert Seacord: Various types of programs (such as compilers or specialized analyzers) can be used to check if a program contains any violations of the coding rules specified in this Technical Specification. In this Technical Specification, all such checking programs are called analyzers. An analyzer can claim conformity with this Technical Specification. Programs that do not yield any diagnostic when analyzed by a conforming analyzer cannot claim conformity to this Technical Specification.

Robert Seacord: A conforming analyzer shall produce a diagnostic for each distinct rule in this Technical Specification upon detecting a violation of that rule, except in the case that the same program text violates multiple rules simultaneously, where a conforming analyzer may aggregate diagnostics but shall produce at least one diagnostic.

Robert Seacord: Conformance is defined only with respect to source code that is visible to the analyzer. Binary-only libraries, and calls to them, are outside the scope of these rules.For each rule, the analyzer shall report a diagnostic for at least one program that contains a violation of that rule.For each rule, the analyzer shall document whether its analysis is guaranteed to report all violations of that rule and shall document its accuracy with respect to avoiding false positives and false negatives.

David A. Wheeler: Fuzzing *requires* that you be able to run the program.  In many cases this is tricky, esp. for embedded processors with specialized components.

Aaron Ballman: David: fair point

Roberto BAGNARA: Most interesting properties of programs are undecidable.

Roberto BAGNARA: So it is not possible to ask tools to diagnose all and only the violations of a rule involving undecidable properties.

Aaron Ballman: Since we are going to start caring about safety critical code, I think it makes sense to revisit the conformance statement.

Aaron Ballman: whether we alter it or not is another thing. :-P

Bart Miller/Elisa Heymann: Stating whether an analyzer misses anything is starting to get into the realm of soundness.

David A. Wheeler: Dynamic & static analysis have different properties.  It might make more sense to separate those as separate documents.

David A. Wheeler: Bart: Agree, that goes into soundness.  *Some* rules can be completely analyzed in a sound way easily.. but many others cannot.

Gavin: can we get access to the C11 standard for reference?

Bart Miller/Elisa Heymann: Definitely separate static and dynamic analyses.

Gavin: other standard reference documents that we should have?

Aaron Ballman: Thank you!