Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Saturday December 02 2017, @01:48PM   Printer-friendly
from the see-what-we-did-there? dept.

https://www.cossacklabs.com/blog/macros-in-crypto-c-code.html

Like death and taxes, one thing that you can be sure of is that using C macros in a modern software project will cause a debate. While for some macros remain a convenient and efficient way of achieving particular programming goals, for others they are opaque, introduce the unnecessary risk of coding errors, and reduce readability.

The criticism of macros is particularly acute in the wider security community. Among Cossack Labs' engineers and the core Themis crypto library contributors there are people who previously worked on auditing cryptographic implementations of critical code. Their typical knee-jerk reaction to macros was always "kill it with fire and never use it again". Taking no sides, we would like to assess both pros and cons of using such dangerous things as macros in security code (as we faced the issue when developing Themis) and suggest some techniques for lowering the accompanying risks.

We'll also discuss a custom "for-audit" build target for Themis designed specifically to generate source code that exposes the macros to inspection because we appreciate the need for security software to be subject to detailed source code scrutiny.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Insightful) by fyngyrz on Saturday December 02 2017, @10:59PM (5 children)

    by fyngyrz (6567) on Saturday December 02 2017, @10:59PM (#604445) Journal

    C macros are fine. Poor programmers aren't.

    This, as with many other things, strikes me as blaming the language for the weakness of the practitioner. Which, in the case of operations that employ programmers, also means someone's been hiring people for the wrong reasons (like degrees / age / sex / court records / location / health / instead of skill, for example.)

    There's good code and poor code; and macros are code. If people are writing poor macros, then fix your people problem. Either train them more, or stop hiring incompetents.

    If your organization is not keeping track of the quality of code your employees / members are writing and getting blindsided by this sort of thing, why then you have another problem.

    And if it's you that's unable to deal with macros... time for some self-improvement. The macro code capabilities in c aren't broken. Guess what that leaves to fix?

    Starting Score:    1  point
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by Pino P on Saturday December 02 2017, @11:40PM (3 children)

    by Pino P (4721) on Saturday December 02 2017, @11:40PM (#604463) Journal

    stop hiring incompetents

    Easier said than done. Or would you please explain an efficient way to sort out dozens of applications by incompetent candidates to a particular position en masse?

    The macro code capabilities in c aren't broken.

    They're not type-safe. Some people include not type-safe in broken.

    • (Score: 3, Insightful) by fyngyrz on Saturday December 02 2017, @11:59PM (2 children)

      by fyngyrz (6567) on Saturday December 02 2017, @11:59PM (#604470) Journal

      would you please explain an efficient way to sort out dozens of applications by incompetent candidates to a particular position en masse?

      After you've determined that they say they're really good at the language you plan to have them use (demand/specify that info in the job app), then you test them. If you're hiring programmers without testing them, we've found (at least one of) your problems.

      Tests should be progressive; not stupid puzzles, or dips into realms that have to relevance to the job at hand, either. You can get newbies in and out of a test sequence in just minutes; they'll never survive the most simple questions about language details. Better programmers will take longer to check out. But competent testing is an absolute requirement to fill programming positions – if you don't want to be saddled with people who will do damage to the task(s) at hand.

      Also, don't ask for X years of experience in X. Ask for high competence in X. The former doesn't imply the latter, though one might (naively) think so.

      They're not type-safe. Some people include not type-safe in broken.

      Yes, well, you shouldn't hire people with that kind of skills deficit. Problem solved! Anything else I can help you with? :)

      c'mon, smile. Not kidding, though. A fundamental (not basic) programmer skill is managing types. If the language doesn't do it, it's your job (and if the language does do it, there's still no excuse for you to be bad at it.)

      • (Score: 0) by Anonymous Coward on Sunday December 03 2017, @01:09AM

        by Anonymous Coward on Sunday December 03 2017, @01:09AM (#604493)

        What you're suggesting sounds too hard. Wouldn't it be better to just keep turning away introverts, since they fail our shallow personality tests by not being social enough? Wouldn't it be easier to just throw out the applications of anyone who doesn't have a degree? Look how much time we're saving!

        Ugh, why is there a shortage of talented individuals!? We need foreigners to fill the gaps!

      • (Score: 2) by Pino P on Sunday December 03 2017, @03:29AM

        by Pino P (4721) on Sunday December 03 2017, @03:29AM (#604551) Journal

        You can get newbies in and out of a test sequence in just minutes; they'll never survive the most simple questions about language details. Better programmers will take longer to check out.

        It still costs quite a bit of money to administer the tests, especially when it involves flying in candidates from a thousand miles away. This competent testing had better provide improvement in quality that is measurable and substantial, or the shareholders won't stand for it.

        A fundamental (not basic) programmer skill is managing types. If the language doesn't do it, it's your job

        Then why not just write all programs in assembly language and make the programmer do everything?

  • (Score: 2) by DutchUncle on Sunday December 03 2017, @05:22AM

    by DutchUncle (5370) on Sunday December 03 2017, @05:22AM (#604578)

    Actually, C macros sort of suck, compared with IBM assembler macros from the 1970s, or Motorola's macro assembler for the 68000. IBM macros had capabilities close to templates in C++. That said, within the limits of what C macros can do, I agree with your premise that it's not the tool's fault if the programmer uses it badly.