3 ms·

I worked on a provenance system which would be so completely the wrong solution to this problem that I only bring it up because the 100,000 foot view is still r

I worked on a provenance system which would be so completely the wrong solution to this problem that I only bring it up because the 100,000 foot view is still relevant. I think we are eventually going to end up with some sort of tagged memory with what this is for (such as credentials) and rules about who is allowed to touch it and where it's allowed to go. Instead of writing yet another tool that won't let fields called "password" or "token" or "key" be printed into the logs, but misses "pk", it's going to be no printing any memory block in this arena, period. I also think we aren't doing enough basic things with backend systems like keeping just a user ID in the main database schema and putting all of the PII in a completely different cluster of machines, that has 1/10 to 1/100th of the sudoer entries on it of any other service in the company. I know these systems are out there, my complaint is we should be talking about them all the time, to push the Recency Effect and/or Primacy Effect hard.

Etheryte 2y ago
While I agree with you as a matter of an ideal, the step from one database to two is infinitely larger than from two to more. Given budget, time and engineering constraints, sticking everything in one database is by far the sanest solution for the vast majority of code out there.
- hinkley 2y ago
  I think microservices kind of break that wall with a herd of stampeding elephants being chased by even angrier bees. If you're still using one database in 2025, even if you wouldn't touch microservices with a ten foot pole, then you've got some problems. OLAP, KV, cache heirarchies, you aren't running a singular database, except maybe for a standalone app.
perlgeek 2y ago
Perl has had a limited data tagging system for decades now, called "taint checking". If enabled (through a command line switch), all data coming in from the outside (sockets, STDIN etc.) are "tainted", and if you e.g. concatenate a non-tainted and a tainted string, it becomes tainted. Certain sensitive operations, like system() calls or open(), raise an error when used with tainted data. If you match tainted data with a regex, the match groups are automatically untainted. It's not perfect, but it demonstrates that such data tagging is possible, and quite feasible if integrated early enough in the language.
- hinkley 2y ago
  Rails has a “safe” attribute that only works for html output, and doesn’t work right for urls (a bug that somehow became my responsibility to fix many times). It’s a limited version of the same thing and I believe Elixir has the same design, and I’ve already seen a reproduction of the Rails flaw in Elixir. But they are Boolean values and they need to be an enumeration or likely a bitfield. Even just for web I’ve already identified four in this thread. HTML unsafe, url unsafe, PII unsafe, credentials unsafe. I hesitate to add SQL unsafe because the only solution to sql injection is NO STRING CONCATENATION. But so many SQL libraries use concatenation even for prepared statements that maybe it should be. Only allow string constants for sql queries.
pjmlp 2y ago
Solaris SPARC ADI has had tagged memory for quite some time now.

Etheryte 2y ago

While I agree with you as a matter of an ideal, the step from one database to two is infinitely larger than from two to more. Given budget, time and engineering constraints, sticking everything in one database is by far the sanest solution for the vast majority of code out there.

hinkley 2y ago
I think microservices kind of break that wall with a herd of stampeding elephants being chased by even angrier bees. If you're still using one database in 2025, even if you wouldn't touch microservices with a ten foot pole, then you've got some problems. OLAP, KV, cache heirarchies, you aren't running a singular database, except maybe for a standalone app.

perlgeek 2y ago

Perl has had a limited data tagging system for decades now, called "taint checking". If enabled (through a command line switch), all data coming in from the outside (sockets, STDIN etc.) are "tainted", and if you e.g. concatenate a non-tainted and a tainted string, it becomes tainted. Certain sensitive operations, like system() calls or open(), raise an error when used with tainted data. If you match tainted data with a regex, the match groups are automatically untainted. It's not perfect, but it demonstrates that such data tagging is possible, and quite feasible if integrated early enough in the language.

hinkley 2y ago
Rails has a “safe” attribute that only works for html output, and doesn’t work right for urls (a bug that somehow became my responsibility to fix many times). It’s a limited version of the same thing and I believe Elixir has the same design, and I’ve already seen a reproduction of the Rails flaw in Elixir. But they are Boolean values and they need to be an enumeration or likely a bitfield. Even just for web I’ve already identified four in this thread. HTML unsafe, url unsafe, PII unsafe, credentials unsafe. I hesitate to add SQL unsafe because the only solution to sql injection is NO STRING CONCATENATION. But so many SQL libraries use concatenation even for prepared statements that maybe it should be. Only allow string constants for sql queries.

pjmlp 2y ago

Solaris SPARC ADI has had tagged memory for quite some time now.