Programming: Mostly a hate story | Hacker News Reader

Programming: Mostly a hate story

gist.github.com

58 pointsmathnmusic26 comments

Well I don't fully follow what "digital signatures inside Postgres" really means, but if it means essentially the same thing as digital signatures in, say, a Java program or a Python program or any other Turing-complete programming language, what about... writing code? Ha! I said it! Roll your own crypto! The title is "Programming: mostly a hate story", but it should be "Managing dependencies and trying to live up to this ridiculous pipe dream of reusing code and never writing any of your own because somebody on the internet said 'never roll your own': Mostly a hate story"

The case against rolling your own crypto is that bugs can hide in crypto software without symptoms. Everything will seem to function perfectly. The verifier will o.k. valid signatures and reject invalid ones. The signatures themselves will look like gibberish to the eye.

But the bug will still be there, waiting for an actual attack.

Unless you do it right.

The issue with this is the same thing that happens with all sorts of data breaches, regardless of whether it was caused by negligence.

Of course there's no problem if you do it right. It's just that guaranteeing you did it right is never possible with 100% certainty if you wrote the code, evaluated the code, and published the code.

More eyes means less mistakes. More hands makes less work. If you roll your own templating system, and you mess up, then some text on a page is displayed wrong. If you roll your own crypto to protect customer data and you mess up, whoops, that customer data is out there.

I agree that people are often too zealous about "don't do it yourself", whether in the name of security or preventing duplicate work. md5 hashing unsalted passwords is bad, but so is critically misconfiguring an off-the-shelf password tool you didn't understand. Not Invented Here Syndrome is bad, but so is breaking the entire internet because you didn't want to write 20 lines of NPM left-pad yourself.

That said, I think there's still a major difference between roll-your-own-crypto and other "unless you do it right" topics. Securely storing passwords and preventing XSS are things that can look ok and be insecure unless you do it right, but I'm not (always) against people (carefully) handling those things themselves. Rolling your own signatures or encryption are infamous because a "best practices" list and good code review won't save you; even if you root out all the actual bugs, your process can still be cripplingly vulnerable. As Schneier said, anyone can create an alogorithm they can't compromise.

Did you ever typo a character in your code and didn't notice, causing a fast compile or runtime error, then promptly fixed it? If it had compiled and ran with no visible symptoms, would you ever catch that typo? That's the level of gotcha in rolling your own crypto.

Yeah, sort of like playing the lottery is a bad investment, unless you win.

Author here. This was an unusual setup. The database server is directly accessible to users but they were only given INSERT and SELECT privileges on the table. The users need flexible querying with SQL so that they can use existing BI tools like Metabase.

This system is minimal, is running almost perfectly and has > 100 happy users. There isn't sufficient justification to introduce custom code layer and break all the existing functionality.

pgcrypto already does support PGP encryption after all, just not ECDSA.

>Ha! I said it! Roll your own crypto!

Isn't this the #1 anti-pattern in cryptography?

I do appreciate the pain and frustration in this post: version discontinuity, no documentation, and doing something that shouldn't be difficult. However, I feel he went wrong right from the start:

> I wanted digital signatures validation, preferably ed25519, inside PostgreSQL.

There should be some front-end server in front of PostgreSQL that can handle verification.

See my comment here: https://news.ycombinator.com/item?id=18993599

To be fair, doing digital signatures inside a database is a really weird use case. I'm not sure why you'd want to generate them there, instead of doing it elsewhere.

I don't understand what the author is trying to do. It feels like a classic XY problem[1] where the author just decided at some point that "I need digital signatures in the database" rather than focusing on what the actual problem to be solved is.

[1]: https://en.wikipedia.org/wiki/XY_problem

See my comment here: https://news.ycombinator.com/item?id=18993599

It's not just a little frustrating that even after reading that, I still have no idea what the purpose is of this change.

Why does the database need to be encrypted? Is the database entries encrypted with different keys based on the user? Why does the encryption need to happen in the database?

The author comments that AWS has a new version of the v8 libraries available in their postgresql offering, but doesn't explicitly say that this solves his problem. I hope it did.

Because software is so easy to distribute, sometimes just waiting for a period of time will cause problems to go away. Why spend time to fix the issue when it might be fixed next month by someone else? This is kinda like deflation for the economy of money (why spend when your money may be worth more next month?).

On the other hand, the problem may need to be fixed right now, so it's a tradeoff between estimating (often guessing, if you don't have insight into upstream roadmaps) if someone upstream will fix the underlying issue and estimating (guessing, really) the effort to fix it locally.

> Why spend time to fix the issue when it might be fixed next month by someone else?

I spent this time to find out exactly what all things are broken. It's just a rant for wasting a few hours of effort. In the end, we ended up de-prioritizing this feature request. :-)

I personally would have gone the other way and spend the second half of the day figuring out how hard it is to implement ecdsa from scratch in any of the supported languages. I guess the results would have been the same.

That would have gone awry of “don’t implement your own crypto”.

There is a difference between implementing YOUR OWN crypto and YOUR OWN implementation of crypto.

While it is still quite risky to have your own implementation if the platform doesn't have one there must be a person that does it for the first time. Provided you do it correctly according to the paper and you don't have bugs and you do it in constant time and you know about a bunch of other stuff it might be ok.

On the other hand creating new cryptos and protocols is best left to guys with long beards and titles.

Man, "implement an elliptic curve cryptographic hash in SQL" sounds like the stuff of nightmares, not far behind "implement a relational database in APL." Someone may have done it, but I'm glad it wasn't me.

Author here. "implement" is too vague here. All I wanted was to use in my triggers ECDSA utility methods from pgcrypto, the way it already supports PGP. pgcrypto is written in C, not in SQL. I just wanted to use something like that in my triggers.

In the same spirit, this is worth a re-read even if you've seen it before: https://www.stilldrinking.org/programming-sucks

Edit for context: this was published right after Heartbleed went public.

> Oops, Docker doesn't let me just publish the modified Dockerfile. It wants me to build the image locally and THEN push to Hub.

Yes, but to create the image, you don't need to build it. Meet your new friend "docker commit".

Yep, sounds like beginning DevOps to me!

It gets worse. But you eventually learn that it is just software and to not let it get to you.

Should really be called "Devops: Mostly a hate story".

That aside, man! this is relatable!

Reply on news.ycombinator.com