a loved one, gun to the head: "please pay the ransom, i don't want to die!"
what's your play now? save loved one, and go to prison? or worse, bank blocks transfer, and they die?
go ahead and tax ransom payments (0 tax if human life at risk, 10x otherwise) if you have to, but making it illegal feels disconnected from the messiness of the real world. then, go after the attackers.
ex: main.db + fts.db. reading and writing to main.db is always available; updating the fts index can be done without blocking the main database — it only needs to read, the reads can be chunked, and delayed. fts.db keeps the index + a cursor table — an id or last change ts
could also use a shard to handle tables for metrics, or simply move old data out of main.db
* some examples:
conn = sqlite3.connect("data.db")
conn.execute("PRAGMA journal_mode=WAL") # concurrent reads (see above)
conn.execute("PRAGMA synchronous=NORMAL") # fsync at checkpoint, not every commit
conn.execute("PRAGMA cache_size=-62500") # ~61 MB page cache (negative = KB)
conn.execute("PRAGMA temp_store=MEMORY") # temp tables and indexes in RAM
conn.execute("PRAGMA busy_timeout=5000") # wait 5s on lock instead of failing
edit: orms will obliterate your performance — use raw queries instead. just make sure to run static analysis on your code base to catch sqli bugs.
my replies are being ratelimited, so let me add this
the heavy duty server other databases have is doing that load bearing work that folks tend to complain about sqlite can't do
the real dmbs's are doing mostly the same work that sqlite does, you just don't have to think about it once they're set up. behind that chunky server process the database is still dealing with writing your data to a filesystem, handling transaction locks, etc.
by default sqlite gives you a stable database file, that when you see the transaction complete, it means the changes have been committed to storage, and cannot be lost if the machine were to crash exactly after that.
you can decide to wave some, or all of those guaranties in exchange for performance, and this doesn't even have to be an all or nothing situation.
Kind-of. But there are worse things than outages when it's PKIs we're talking about. DNSSEC is also extremely opaque and unmonitored. Any compromise will not be noticed. Nor will anyone have any recourse against misbehaving roots.
Fun fact, CloudFlare has used the same KSK for zones it serves more than a decade now.
Which is fine. Not because KSK rollover is supposedly complicated, but if you can't manage to keep your private keys and PKI safe in the first place then key rotation is just a security circus trick. But if you do know how to keep them safe, then...
It is not fine. Keeping key material safe is not a boolean between "permanently safe" and "leaks immediately".
Keeping key material secure for more than a decade while it's in active use is vastly more complex than keeping it secure for a month, until it rotates.
For all we know, some ex-employee might be walking around with that KSK, theoretically being able to use it for god knows what for an another decade.
Yeah, theoretically. They "only" need continued access to CF's internal systems. Surely you're aware that the ZSK is confined to your zone and can be rotated as much as you want without having to involve the root/registrar, and with none of the risks or consequences of not knowing how to perform a KSK rollover?
What's your take on the conundrum of Amazon Trust's 20+ year root cert, with which they sign a 5+ year intermediate, with which they sign a 2-month leaf?
> Keeping key material secure for more than a decade while it's in active use is vastly more complex than keeping it secure for a month, until it rotates.
Nope. Key material rotation is just circus when it's done for the sake of rotation.
> For all we know, some ex-employee might be walking around with that KSK, theoretically being able to use it for god knows what for an another decade.
Or maybe an employee has compromised the new key that is going to be rotated in, while the old key is securely rooted in an HSM?
The point of rotation for these kinds of keys is that it limits the blast radius of what happens if an employee compromises such a key. This is sort of like how there are one or two die-hard PGP advocates who have come up with a whole Cinematic Universe where authenticated encryption is problematic ("it breaks error recovery! it's usually not what you want!") because mainstream PGP doesn't do it. Except here, it's that key rotation is bad, because of how often DNSSEC has failed to successfully pull off coordinated key rotations.
I can see the periodic rotations used as a way to keep up the operational experience. This is indeed a valid reason, although it needs to be weighted against the increased risk of compromise due to the rotation procedure itself.
I'm just saying that rotating the key just in case someone compromised it is not a great idea. Doubly so if it's done infrequently enough for the operational experience to atrophy between rotations.
And yeah, I fully agree that anything surrounding the DNSSEC operations is a burning trash fire. It doesn't have to be this way, but it is.
I'm glad we agree about DNSSEC, but the rationale I'm giving you for key rotation is the same reason we use short-lived secrets everywhere in modern cryptosystems. It's not controversial (except among Unix systems administrators).
Oh, I never disagreed about the state of DNSSEC. It's horrible. Along with the rest of the DNS infrastructure (I just had the reason to remember the DNS haiku again today, unrelated to .de). My disagreement is that I believe that DNSSEC should be fixed, rather than abandoned. And I believe that this does not actually require all that much work.
And I just don't fully buy this rationale for asymmetric key rotation. It makes total sense for symmetric secrets (except for passwords).
> Nope. Key material rotation is just circus when it's done for the sake of rotation.
I'm a mere sysadmin and not a cybersecurity expert. But this is always something that leaves me torn.
On the one hand, yes, rotation periods for many/most credentials are long enough that you're not really de-risking yourself all that much.
On the other hand, doing regular rotations allows you to tighten up your threat model. A regularly-rotated credential allows you to say "I implicitly trust that this credential has not been compromised prior to the previous rotation."[0] Whereas, without credential rotation, you're saying "I implicitly trust that this credential has not been compromised ever."
The latter to me seems clearly like the inferior model. The question is just whether the cost-benefit pencils out. And that is obviously very situationally dependent. That calculus doesn't pencil out when dealing with user-owned passwords for instance (i.e. the costs of regular password rotation dominate the benefits of the improved threat model). Human limitations with memory and such are the main issue there. However, that doesn't apply to e.g. hypothetical sufficiently developed DNSSEC infrastructure. Does that calculus pencil out there? I don't know. But it seems plausible at least.
[0] Modulo attackers having been able to pivot into a persistent threat with a previously-compromised credential.
Let's Encrypt going down isn't equivalent to a rant about how encryption was a terrible idea from the very beginning and we should all just use unencrypted traffic.
I host my blog on HTTP/1.1 only. But I also have an amateur radio station and I listen occasionally to (unencrypted!) air traffic frequencies around nearby airport.
i don't know a lot about the subject, but the little i know tells me this is not the way to look at this
your password (plain text) is secret because only you are supposed to a have it. in the digital realm, sharing the contents of the password (plain-text) is be akin to making a copy of it — undesirable
now, the algorithm that hashes the plain-text for comparison with the stored hash, that can be know by anyone, and typically is
a loved one, gun to the head: "please pay the ransom, i don't want to die!"
what's your play now? save loved one, and go to prison? or worse, bank blocks transfer, and they die?
go ahead and tax ransom payments (0 tax if human life at risk, 10x otherwise) if you have to, but making it illegal feels disconnected from the messiness of the real world. then, go after the attackers.
reply