Hacker News Reader

Comment by mgaunard | Hacker News Reader

I disagree; dependencies are more of a liability than anything else.

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, 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.

> 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.

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.

In my world architects design, engineers provide feedback and implement stuff

First time I hear about technicians writing code.

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.... https://www.developerdotstar.com/mag/articles/reeves_origina... https://www.developerdotstar.com/mag/articles/reeves_13years..., and the discussion on wiki https://wiki.c2.com/?TheSourceCodeIsTheDesign=

That was a great read. Amazing how it can still be quoted to explain software design 32 years later.

glad you enjoyed it!

What industry are you from?

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.

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)

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. :)

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

Do you really want to implement http, ssl and tls; all by your self, what about security hash algorithms? Re inventing the wheel means you also get to go through all the bugs and s purity issue that these open source libraries went through. This is a type of opinion I would expect some one with no understanding about security saying.

Assuming you do have enough understanding of secure programming, you can actually forgo most dependencies if you really want. You can ignore most edge cases which have to be implemented if you exactly follow the standard (e.g. HTTP parsing rules), supporting only one ciphersuite that is known to be safe and widely used, and so on. Of course that still doesn't justify the use of assembly.

If you're building an application that depends heavily on networking for either its performance or reliability, then yes, you are better off rewriting those components and taking on ownership of hardening them to satisfy your requirements than you are relying on someone else that doesn't know your use case and has no incentive to making it work well making sure it works well for you.

HTTP is fairly trivial as well; if you're afraid of little things like that, you'll never deliver best-in-class software.

Reply on news.ycombinator.com