4 ms·

I can see this maybe being true in a high level language (depending on the dependency), though it's definitely not the case with assembly. OpenSSL, for example

• throwup238 3y ago
  > OpenSSL, for example, was hit with quite a few serious bugs over the years, and I'd still choose using it than my own SSL implementation. Especially in assembly. That's the difference between a programmer and a real engineer: an engineer doesn't need any help from dependencies to make his code totally insecure.
  • bee_rider 3y ago
    Engineers do design, implementation is the job of the technician or machinist or somebody like that. If the engineer’s code ends up shipped to customers, something very strange has happened.
    • hardware2win 3y ago
      In my world architects design, engineers provide feedback and implement stuff First time I hear about technicians writing code.
    • kragen 3y ago
      the source code is the design; it plays the same role that schematics or mechanical drawings play for products made by electronic technicians or machinists. the difference is that compilers take the place of technicians or machinists, and that confuses people, often for political/ideological reasons see jack w. reeves's 'code as design' series, beginning with 'what is software design?' from 01992, for a fuller explanation https://www.developerdotstar.com/mag/articles/reeves_design.html https://www.developerdotstar.com/mag/articles/reeves_design.... https://www.developerdotstar.com/mag/articles/reeves_originalletter.html https://www.developerdotstar.com/mag/articles/reeves_origina... https://www.developerdotstar.com/mag/articles/reeves_13yearslater.html https://www.developerdotstar.com/mag/articles/reeves_13years..., and the discussion on wiki https://wiki.c2.com/?TheSourceCodeIsTheDesign= https://wiki.c2.com/?TheSourceCodeIsTheDesign=
      • ozozozd 3y ago
        That was a great read. Amazing how it can still be quoted to explain software design 32 years later.
        • kragen 3y ago
          glad you enjoyed it!
    • resonious 3y ago
      What industry are you from?
    • ozozozd 3y ago
      No snark but this is the ultimate example of “tell me you never built software without telling me you never built software” Unless I totally missed the sarcasm.
• kragen 3y ago
  people who are not familiar with cryptography are often unaware of this, but cryptographic algorithms are among the kinds of code most commonly written in assembly not only are they almost never subject to the kinds of security problems we commonly associate with low-level languages like assembly or c (for example, buffer overflows and heap corruption) they also commonly need to run in constant time to prevent timing side-channel information leaks, and while that is not trivial to achieve in any language, it's more feasible in assembly than in c. also, they are commonly a performance bottleneck, and they commonly need kinds of bit manipulations that c is typically slow at, which rewards assembly implementations openssl in particular contains about 85000 lines of assembly language, mostly embedded in perl files. (it uses perl as a sort of alternative macro assembler)
  • tasn 3y ago
    I'm aware, and this is a good point to bring up about cryptography. I had the protocol code in mind when I was talking about the bugs. I should have used curl as example in retrospect. :)
    • kragen 3y ago
      i agree that probably assembly is an especially bug-prone language to implement things like protocol logic and asn.1 parsing; but high-level programming languages are pretty bad at things like that, too. it still mostly depends on your system design: assembly might be a perfectly fine language in which to implement a bytecode interpreter for a safe asn.1 parser in a non-turing-complete language you can formally verify. assembly's weak points don't matter much for bytecode interpreters incidentally those 85000 lines of assembly are about 12% of the total openssl codebase