5 ms·

Programming: Mostly a hate story

58 points by mathnmusic 8y ago

mooreds 8y ago
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.
- nileshtrivedi 8y ago
  > 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. :-)
sly010 8y ago
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.
- bluejekyll 8y ago
  That would have gone awry of “don’t implement your own crypto”.
  - lmilcin 8y ago
    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.
- username223 8y ago
  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.
  - nileshtrivedi 8y ago
    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.
juliangoldsmith 8y ago
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.
- hnarn 8y ago
  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 https://en.wikipedia.org/wiki/XY_problem
  - nileshtrivedi 8y ago
    See my comment here: https://news.ycombinator.com/item?id=18993599 https://news.ycombinator.com/item?id=18993599
    - hnarn 8y ago
      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?
commandlinefan 8y ago
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"
- emiliobumachar 8y ago
  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.
  - commandlinefan 8y ago
    Unless you do it right.
    - Djvacto 8y ago
      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.
    - Bartweiss 8y ago
      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.
norswap 8y ago
Should really be called "Devops: Mostly a hate story". That aside, man! this is relatable!
cpburns2009 8y ago
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.
- nileshtrivedi 8y ago
  See my comment here: https://news.ycombinator.com/item?id=18993599 https://news.ycombinator.com/item?id=18993599
andrewflnr 8y ago
In the same spirit, this is worth a re-read even if you've seen it before: https://www.stilldrinking.org/programming-sucks https://www.stilldrinking.org/programming-sucks Edit for context: this was published right after Heartbleed went public.
agnivade 8y ago
> 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".
honkycat 8y ago
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.

58 points by mathnmusic 8y ago

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.

nileshtrivedi 8y ago
> 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. :-)

sly010 8y ago

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.

bluejekyll 8y ago
That would have gone awry of “don’t implement your own crypto”.
- lmilcin 8y ago
  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.
username223 8y ago
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.
- nileshtrivedi 8y ago
  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.

juliangoldsmith 8y ago

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.

hnarn 8y ago
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 https://en.wikipedia.org/wiki/XY_problem
- nileshtrivedi 8y ago
  See my comment here: https://news.ycombinator.com/item?id=18993599 https://news.ycombinator.com/item?id=18993599
  - hnarn 8y ago
    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?

commandlinefan 8y ago

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"

emiliobumachar 8y ago
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.
- commandlinefan 8y ago
  Unless you do it right.
  - Djvacto 8y ago
    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.
  - Bartweiss 8y ago
    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.

norswap 8y ago

Should really be called "Devops: Mostly a hate story". That aside, man! this is relatable!

cpburns2009 8y ago

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.

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

andrewflnr 8y ago

In the same spirit, this is worth a re-read even if you've seen it before: https://www.stilldrinking.org/programming-sucks https://www.stilldrinking.org/programming-sucks Edit for context: this was published right after Heartbleed went public.

agnivade 8y ago

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

honkycat 8y ago

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.