It is the latter. If you are certain your theorem is stated correctly, and you believe that the Lean kernel against which you validate is correct, your proof is correct.
This is how the theorem for FLT looks in the particular proof we discuss here:
theorem fermat_last_theorem (n : ℕ) (hn : 3 ≤ n) (a b c : ℕ)
(ha : 0 < a) (hb : 0 < b) (hc : 0 < c) : a ^ n + b ^ n ≠ c ^ n
As long as this statement is correct, and the kernel is correct, the proof could be trillion lines of code, and if the kernel says it is correct, it is correct.
This proof was checked against TWO independently built kernels. So you would need TWO kernels to have the same bug to mistakenly accept an incorrect proof.
(Not impossible: such a bug indeed was recently discovered (and patched))
The most important aspect of blockchain that is relevant here is that your counterparty half a world away and you both agree that you trust the state of this blockchain, and thus can transact on it.
For business running the same code on their 1 node instead of N is not a replacement, because their counterparty has no reason to trust whatever is running on that 1 node.
Your reasoning re: N nodes are expensive is also flawed. Executing a single payment transaction takes a fraction of a second of compute. Even if it is replicated 10,000X, it's still extremely cheap compute-wise. The low cost of transactions has nothing to do with subsidizing.
> For business running the same code on their 1 node instead of N is not a replacement, because their counterparty has no reason to trust whatever is running on that 1 node
I mean, why are you doing this kind of business with someone where you can't even trust that?
Aside from that, block chains only provide trust if they're meaningfully decentralized. These hyper specific b2b ones seem unlikely to pass that test. Exactly who all is running verifier nodes?
This is the main value of a blockchain. You can do business with someone you don't specifically trust without requiring a third party in the middle to mediate the financial transaction.
The only people that need to run a verifier node are those that don't trust the other verifier nodes to do it properly. It's opt in, most will not run one, but a business that has enough money at stake can if they want to.
Then the blockchain client software provides the framework for cryptographic assurance that the two copies of the ledger are in sync.
You don't need verifiers. I interviewed at R3 (now Onyx) in JP Morgan and my take on the business was that it's more of a distributed ledger than a blockchain
While I believe that the city should share the schema, and that the city is effectively argues for security through obscurity, I disagree with the main premise of the article: that knowing SQL schema doesn't help the attacker.
If I understand the argument of the author here:
> Attackers like me use SQL injection attacks to recover SQL schemas. The schema is the product of an attack, not one of its predicates
The author appears to imply that once the vulnerability is found, the schema can be recovered anyway. It is not always the case. It is perfectly viable to find a SQL injection that would allow to fetch some data from the table that is being queried, but not from any other table, including `information_schema` or similar. If all the signal you get from the vunlerability is also "query failed" or "query succeeded, here's the data", knowing the schema makes it much easier to exploit.
> the problem is that every computer system connected to the Internet is being attacked every minute of every day
If you specifically log failed DB queries, than for all the possible injections that such 24/7 attacks would find you have already patched them. The log would then be not deafening until someone stumbles on the actual injection (that, for example, only exists for logged in users, and thus is not found by bots), in which case you have time to see it and patch before the attacker finds a way to actually utilize it.
Knowing schema both expedites their ability to take advantage of the vulnerability, but also increases their chances of probing the injection without triggering the query failure to begin with.
> that knowing SQL schema doesn't help the attacker.
Knowing the name of the service helps the attacker, knowing the name of government officials working at city hall helps attackers, knowing the legal description of what a parking ticket is helps attackers. If you are sued and decide you want to hack the government knowing the details of the suit against you helps you in your attack.
The barrier is not “any helpful information must be censored” the barrier is “don’t disclose passwords or code that would divulge backdoors” a schema cannot be that.
I'm not an attacker, just a boring old software dev. If there's an SQL Injection I'd say all bets are off re: schema.
That said I've definitely worked on applications where knowing the schema could help you exfill data in the absence of a full injection. The most obvious being a query that's constructed based on url parameters, where the parameters aren't whitelisted.
So I actually do agree that the schema could potentially be of marginal benefit to the attacker.
I can't imagine how the schema would reveal SQL injection holes. Maybe other holes, though. Any poor choices for PKs, dumb use of MD5 computed fields, insecure random, misuse of NULL, weird uniqueness constraints (this also ties back to NULLs), vulnerable extensions, wrong timestamp type, too-small integer type, varchar limits, predictable index speed...
> I can't imagine how the schema would reveal SQL injection holes.
It wouldn't. I'm just assuming that the thrust of the hypothetical negligence accusation was "The schema is useless unless you have SQL injection holes. So give us the schema or admit you are negligent!" But you're correct that there are other justifications one could make to keep the schema secret.
The schema can provide an insight into what the application developer was thinking when writing the code, which in turn can direct an attacker towards tricky corners where mistakes might have been made.
This is the city government here. The people arguing the case didnt write the code and dont have time to look through all their code but one thing they do know is that it was written by monkeys. They probably have some level of reason to believe their are SQL injections available in the code.
However his comment assumes monetisation is selling the bug; (tptacek deeply understands the market for bugs). However I would have thought monetisation could be by scanning as many YouTube users as possible for their email addresses: and then selling that limited database to a threat actor. You'd start the scan with estimated high value anonymous users. Only Google can guess how many emails would have been captured before some telemetry kicked off a successful security audit. The value of that list could possibly well exceed $10000. Kinda depends on who is doxxed and who wants to pay for the dox.
It's hard to know what the reputational cost to Google would be for doxxing popular anonymous accounts. I'm guessing video is not so often anonymous so influencers are generally not unknown?
I'm guessing trying to blackmail Google wouldn't work (once you show Google an account that is doxxed, they would look at telemetry logs or perhaps increase telemetry). I wonder if you could introduce enough noise and time delay to avoid Google reverse-engineering the vulnerability? Or how long before a security audit of code would find the vulnerability?
Certainly I can see some governments paying good money to dox anonymous videos that those governments dislike. The Saudis have money! You could likely get different government security departments to bid against each other... Thousands seems doable per dox? The value would likely decrease as you dox more.
If you specifically log failed database queries, where "failure" means "indicative of SQL injection", then nothing you can do with the schema is going to reduce the signal in that feed --- even a single SQL syntax error would be worth following up on. No, I don't think your logic holds.
I don't understand your logic. Knowledge of the schema can give an attacker an edge because they now know the exact column names to probe. Whether these probes get logged is irrelevant; even if it makes the system more vulnerable for an instant, it's still more vulnerable.
Even if logging failed queries is your metric, then knowledge of column names would make it more likely for an attacker to craft correct queries, which would not get logged, thus making your logs less useful than if the attacker had to guess at column names and, in so doing, incur failed queries.
To probe for what? How does knowledge of a column name make it easier for me to discern whether a SQL injection vulnerability exists? I've spent a lot of time in my career probing for SQL injection, and I can't remember an instance where my stimulus/response setup involved the table names.
SQL injection is a property of a SQL query, not of the schema itself. To have a meaningful chance of blind-one-shotting a query, getting a TRUE/FALSE answer about susceptibility without ever generating a SQL syntax error, I would need to see the queries themselves.
Knowledge of the column names doesn't give you insight into whether a vulnerability exists. It gives you insight into what you can do with a vulnerability, should it exist. For example, if you want to set your account balance to $1 million, you'd need to know the column name in order to generate a valid query. Without advance knowledge of the column name, your job becomes harder.
SQL injection will give you the entire schema anyway. It doesn't help if someone tells you the col names beforehand. I'm more wondering about non-SQL-injection vulns.
SQL injection isnt just an ssh tunnel to the database. If the line you've injected isnt a select and the backend never fetches it how does the injection give you the column names?
Wait, this is known as a blind SQLi, and it's not so blind. You can still use timing to get the info you need one bit at a time. This may be slow, but it's doable without triggering any DB errors, so you have time.
Yeah, it's a cool trick and not obvious. I think when I said SQL injection gets you the schema, I was recalling some faint old memory from a security course without remembering why this is doable.
> How does knowledge of a column name make it easier for me to discern whether a SQL injection vulnerability exists?
It doesn't. It just means that as soon as you find one, you can immediately begin crafting valid queries instead of randomly guessing table names and columns, therefore not setting off the "DB query failed" alert.
EDIT: I guess this is the part I missed:
> To have a meaningful chance of blind-one-shotting a query, getting a TRUE/FALSE answer about susceptibility without ever generating a SQL syntax error, I would need to see the queries themselves.
Really? I guess I have to take your word for it because I've never attempted it, but I would have thought that in some (horribly broken) systems `bobby tables' or 1=1 --` would have a very reasonable chance of detecting SQL injection without alerting anyone.
Right, and that's what you use to find the vulnerability. But imagine you've found the vulnerability and now you want to use it to update all of your parking tickets as paid. Without the schema, this is going to be quite tricky and will generate a lot of failed SQL. With the schema, you might be able to do it on your first try.
Is there not any SQLi vulnerability in practice that doesn't allow such an information recovery? That is, is the schema-recovery step so foolproof that it can always be performed on any target form? GP is suggesting that this may be difficult, depending on the kind of signal that gets returned from the form.
In my entire experience as a software security practitioner, which at the time of my testimony encompassed some hundreds of assessments of SQL-backed websites, the availability of a schema has never impacted my ability to exploit a SQL injection. It's not my job as an expert witness, nor Matt's job as a plaintiff, to invent improbable scenarios where security could hinge on schema availability. The court (all of them, in fact) found that testimony dispositive, so I'm happy to leave the issue there.
"Blind" SQLi is a thing, but even in the real-life example I could find, it wasn't exactly blind. They could still use the timing to get one bit of info at a time and discern the email addresses. https://www.invokesec.com/2025/01/13/a-real-world-example-of...
It's hard to imagine a case where you can't even get info based on timing. But it requires more effort and knowledge to exploit this.
I don’t think that’s a very common setup but perhaps I’m just exposing my own ignorance. Just consider the popularity of ORMs. They explicitly load the schema into the application in many cases.
Not just that, but perhaps the app is smart enough to lock you out the second it detects an attempt to gather the schema, e.g. by logging and automatically responding to a query that displays the schema. Then you have to look for other ways in (another IP, etc.). But if you know the schema in advance, you have a better chance of a one-shot injection that accomplishes your malicious goal.
In other words, advance knowledge of the schema may make it easier to act maliciously.
> nothing you can do with the schema is going to reduce the signal in that feed --- even a single SQL syntax error would be worth following up on
Syntax errors coming from your web application mean there is a page somewhere with a bugged feature, or perhaps the whole page is broken. Of course that's worth following up on?
Edit: maybe I should add a concrete example. I semi-regularly look at the apache error logs for some of my hobby projects (mainly I check when I'm working on it anyway and notice another preexisting bug). I've found broken pages based on that and either fixed them or at least silenced the issue if it was an outdated script or page anyway. Professionals might handle this more professionally, or less because it's about money and not just making good software, idk
> Syntax errors coming from your web application mean there is a page somewhere with a bugged feature, or perhaps the whole page is broken. Of course that's worth following up on?
This is a government system, with apps probably built by lowest-bid contractors.
I imagine most of us would be horrified by the volume of everyday failed queries from deployed apps.
Can be, but I'm not sure it's worth investigating whether a particular deployment has such a specific monitoring system before being able to do a FOIA. The schema is marginally relevant for attacks at best (with heavy emphasis on just how marginal it is) and that's no barrier to releasing it
> "query failed" or "query succeeded, here's the data"
Blind SQL injection is a type where no error is produced, but some subtle signal can indicate success or failure. The most interesting one that I know about is where the presence of a successful injection was a normal looking response that was one byte longer than an unsuccessful injection. This was used to not only figure out the schema, but to fully exfiltrate the entire database.
There is nothing in the log on the server that indicates an error.
Most of the relatively introductory SQL injection exercises that I taught proceed without any knowledge of the schema.
Not just with SQLi, but I've managed to statistically proof "information" with timing attacks.
Where if you join another table (by e.g. requesting extra info in a graphql query) the response goes from ms to s or even m. Indicating the size of the joined table.
Or where I could change a "?sort[updated_at]=desc" to a "?sort[password_hash]" through trial-and-error and suddenly see the response time drop from ms to seconds (in this case finding columns that exist but aren't indexed).
Even if the response content is exactly the same, we know things exist, are big, not indexed, or simply present, by timing the attack.
A famous one is obviously the timing trick to find out that an email is in the system because "user = user.find(email) && user.password_matches(password)" short cirquits if the email does not exist but spends significant time on hashing the password for matching it. A big lot of backends and apps make this mistake.
That's where the court's technical distinction between the words: "could" and "would", is important. It appears they have reduced the distinction to a risk assessment which is more objective than opining wildly!
For example: I've just re-wired a three gang light switch. I verified power on with my multimeter (test the meter), cut the power and then retested all the circuits to make sure I had got it right.
It turns out that switch three is on a separate ring main. Cool I didn't get to test my body's ability to take a whopper of a shock. In the UK it is common to have upstairs and downstairs rings for light circuits. Our kitchen has quite a few lights in it so it got a separate ring as well. Anyway there are quite a lot of wires in there because all of them are two way switches. Oh and I am allowed to work on them because of the switch location - not kitchen and not bathroom, ie a low risk location
I noted down the connections, and took them all out. I put Wagos over the flying ends to make them safe, turned the power back on and got on with the job in hand.
I then cut the power (both circuits) checked again with my Fluke. Oh bollocks ... enable power, test the Fluke and then cut power again and recheck the circuits.
Now I re-terminated all the connections. There was plenty of additional wire so I decided to cut and re-strip the conductors, to make sure that I avoided potential failures due to "work hardening" from the inevitable pushing and pulling and "gentle" forcing into position. Once all the conductors were screwed down I pulled on them fairly forcefully to make sure they wont fall out.
I screwed down the switch face plate and restored power. Its a brushed metal finish switch so I did test it was not live, because I'm careful. I tested the functionality ie all three switch circuits (three) from all the switches (six).
So, given that description is it possible that the connectors might fall out in the future and short on say, the metal back box. Of course it is possible. It could happen but would it happen?
You could postulate all sorts of scenarios. Perhaps I may be careful but I might be cack handed and forgetful and got something wrong anyway and a wire might still drop out. Now we are at the point of whataboutery! and that wont wash.
The would/could distinction is a powerful one and it is analogous to how we do risk assessments.
I'm certainly not saying you are wrong in your assessment but I think you are fiddling with details to conjure up a "could" and not a "would". I agree that knowing the schema would assist a hacking attempt but would it make a successful crack more likely - no I don't think so. It is a classic case of obscurity despite security but a rather more complicated one than putting the ssh daemon on port 2222.
Would help a lot if somewhere at the very top it explained what tree calculus is (may be extend the animation of the addition example to first show what the t is)
It took me a while on the website to understand what it was all about. As it is it looks more like a website for a functional programming language.
...but if it's no longer restricted to the visual cortex and they can extract the kind of horrific imagery as in the movie, I don't really want to see it.
I really like this film, especially with my photography hat on. A lot of the imagery taken from the mind of the serial killer is actually based on surrealist art, and some of the cinematography is superb, e.g. the sequences filmed in the Namibian desert
Tarsem Singh's next movie The Fall is visually similar (though in another genre), so watch it too if you didn't already: https://www.imdb.com/title/tt0460791/
From the aesthetic/cinematography side of things, it did stick with me for a long time; I haven't re-watched it since the early naughties and I do remember lots of scenes. It is just hard to take in that some people might experience a similar internal imagery and the very slight possibility exists that they also act upon it.
I saw that episode and I hated it precisely because it didn't really explore the idea. There was this profound, interesting, thought provoking premise which it completely relegated to the background in favor of an unchallenging police procedural.
This is how the theorem for FLT looks in the particular proof we discuss here:
theorem fermat_last_theorem (n : ℕ) (hn : 3 ≤ n) (a b c : ℕ) (ha : 0 < a) (hb : 0 < b) (hc : 0 < c) : a ^ n + b ^ n ≠ c ^ n
As long as this statement is correct, and the kernel is correct, the proof could be trillion lines of code, and if the kernel says it is correct, it is correct.
This proof was checked against TWO independently built kernels. So you would need TWO kernels to have the same bug to mistakenly accept an incorrect proof.
(Not impossible: such a bug indeed was recently discovered (and patched))