71–80 of 116 posts
Earlier quoted context omitted.
You're just swapping one exposed service for another in that case. Ie, OpenSSH instead of MySQL. On other other hand, I'd trust OpenSSH more than MySQL.
Well, you're reducing the exposed services from two (mysql + ssh), to one (ssh). Which is always a good idea. Also agreed. I'd trust OpenSSH to do security better than MySQL.
Earlier quoted context omitted.
I would generally avoid building applications that assume clients are going to speak directly to the database. We see a couple of them every year (it's a common pattern in enterprise applications) and they tend to be horrorshows. In any case, the typical web app deployed by HN readers has no business having an exposed MySQL port.
Actually that's exactly what we do with LedgerSMB. The database is the final enforcer of security matters and the authoritative voice in authentication (the web app logs into the db with user-supplied credentials). A lot of traditional middleware functions are pushed into the db (as stored procedures) where these can be reasonably represented as set operations against the database. As an ERP application, this means t…
Earlier quoted context omitted.
You're just swapping one exposed service for another in that case. Ie, OpenSSH instead of MySQL. On other other hand, I'd trust OpenSSH more than MySQL.
Well, you're reducing the exposed services from two (mysql + ssh), to one (ssh). Which is always a good idea. Also agreed. I'd trust OpenSSH to do security better than MySQL.
This is a vulnerability in the authentication scheme used in the MySQL wire protocol, meaning attackers need to be able to connect to your MySQL database directly to exploit it. Attackers should never, ever be able to connect directly to your MySQL database directly . If you can connect to your MySQL instance directly from your Macbook in your living room, fix it right now .
What is the best way to enable replication without access to the database? ssh tunnel?
Cheapest? SSH tunnel or openvpn point to point link.
Earlier quoted context omitted.
I would imagine you have to try a different password each time.
Why would you imagine that? The bug is that what password you provide doesn't matter.
I'd love to see the code; quite how they are not comparing a memcmp to 0 would be interesting to see...
Earlier quoted context omitted.
Actually that's exactly what we do with LedgerSMB. The database is the final enforcer of security matters and the authoritative voice in authentication (the web app logs into the db with user-supplied credentials). A lot of traditional middleware functions are pushed into the db (as stored procedures) where these can be reasonably represented as set operations against the database. As an ERP application, this means t…
Oh god you poor man. We took a look at using SMB Ledger (the parent of LedgerSMB) years back and after peeling back the covers it just looked horrific both from a security and general code quality perspective. This was around the time of the fork, and I couldn't help feel that SMB Ledger had it's work cut out. Hopefully you guys have been able to get through to the other side.
1) Going to a db-centric security model has allowed us not to trust the SQL-Ledger code (good thing too).
2) We are refactoring/removing SQL-Ledger code as quickly as possible. As of 1.3 this means payment logic, reconciliation logic, contact management logic and more. 1.4 will hopefully rip out and replace all search and reporting functions. It will take us a few more years to get the codebase where we want it though.
3) The bad thing about bad code is that bad code is contagious. When you spend a lot of your time debugging bad code it is very hard to write good code. Most of what we wrote for 1.3 will need to be rewritten again. I am pretty happy with the code we are writing for 1.4.....
I think we have come through the worst of it. Pace of development is speeding up which is a good sign and much more of the application is subjected to unit tests.
As a side note, when we first added unit tests to the number rounding tests for the code we inherited from SQL-Ledger, there were failures. We replaced that logic very quickly.
Yeah, it was pretty bad... Now its getting better.
Edit: Also it seems to me the worst never seems so bad when you are in it. I don't think that I could see how many problems we had from this until I am here, half way from 1.3 to 1.4, asking why 1.3 took five years to release (we beat Perl 6 and HURD though, I guess Duke Nukem Forever in fact beat us date-wise by a couple months).
Looking back at the customers of mine who have had problems, or projects that went way over budget or took too long because of difficulties here, I can see how much that hurt us. At the time though, it was just one of those keep working on it kind of things.