Here's some stuff where it would bite me in my work:
- I sometimes use random 64 bit integers in my data (usually as cheaper synthetic guid-like keys).
- I sometimes use CRC-64 hashes.
- I sometimes use 2^63 as a sentinel.
517 karma · joined April 28, 2016
- I sometimes use random 64 bit integers in my data (usually as cheaper synthetic guid-like keys).
- I sometimes use CRC-64 hashes.
- I sometimes use 2^63 as a sentinel.
Consider this JSON: {"key": 9223372036854775807}. With most parsers it never fails.
But... some JSON parsers (include JS.eval) parse it to 9223372036854776000 and continue on their merry way.
The problem isn't user-provided JSON here. The problem is user-provided data (or computer-provided data) that's inside the JSON.
rachelbythebay's take (http://rachelbythebay.com/w/2019/07/21/reliability/):
On the other hand, if you only need 53 bits of your 64 bit numbers, and enjoy blowing CPU on ridiculously inefficient marshaling and unmarshaling steps, hey, it's your funeral.
I had to write my own JSON parser/formatter a year ago (to support Java 1.2 - don't ask) and this article and its supporting github repo (https://github.com/nst/JSONTestSuite) was an unexpected gift from the heavens.
Just kidding, but I suspect it would be a lot faster.
{
"original":"json",
"goes":"here"
}
{
"original_json_contents_base64":"ewogICJvcmlnaW5hbCI6Impzb24iLAogICJnb2VzIjoiaGVyZSIKfQo=",
"hmac_sha256_of_base64":"bf1f4cb95ce8633aff46888e1717873e32bb2a770b3d4b5b74a59e5e9adefeda"
}
I guess the problem here is if intermediate systems want to do stuff based on the payload (but without validating it), they won't like this.
But if the problem is just intermediate systems barfing on non-json, this might work!
p.s. enjoyable blog post - as they always are! ;-)
> Many of you are thinking, "Jesus, I would never fall for the "the check's in the mail, we had trouble with the wire transfer, the money is coming in from our affiliate in New York, I'll get you the tracking number" routine day after day. But sociopaths are very, very good at this. You don't want to believe you've been conned, you don't want to believe you have to go hire a lawyer and file a lawsuit, you don't want to believe someone can do this to you, you want the income that this transaction promises, and often you don't want to go tell your superiors — so you keep hoping that the money is coming any day now. It can happen to you. It's happened to very smart lawyers I know. It's happened to me. And I used to put these people in jail. So don't judge the victims too harshly. When you find yourself in such a situation, you've got to focus — to convince yourself to bail out and cancel the contract, stop providing services, and file suit if necessary.
(You're probably looking at 1.5 to 3 years before you obtain any final orders - and then there's the issue of enforcing any orders you might obtain!)
In Canada there are important federal tax credits (e.g., SR&ED) that work best if staff and contractors track hours in at least 4-hour chunks.
But if a client hopes to get tax credits back for your hours, that's another good reason to raise your rates!
Last I checked expedited D&B was around $40 USD (10 business days) and same-day D&B around $500 USD.
Free D&B said it would take 30 business days, but it actually only took them 5 business days when I applied for it.
$61/yr (USD) will get you an OV cert - there are 10% discount codes that are easy to find for these guys, and their list price is $67/yr:
https://codesigning.ksoftware.net/
But the Notepad++ guy will need a business registered with that name before he can obtain CN=Notepad++, no matter how much he's willing to pay.
Also, the validation requirements to obtain a code-signing certificate, while certainly not bulletproof, are not nothing: you need to send in articles of incorporation and your business needs a listing with a physical address and phone number in a public directory (e.g., bbb.org), and someone representing your business needs to pick up that phone when the cert validator calls it.
Your business name and physical address are injected into the certificate. Basically code-signing certificates make it easier for people to find you and sue you if they truly want to. I suspect that's the whole point.
The problem here is that the Notepad++ developer wants his certificate to say CN=Notepad++, but he won't be able to obtain that until he has some kind of business or organization registered in his jurisdiction with that name. Whereas CN=FIRSTNAME LASTNAME he could probably obtain immediately (just send in his driver's license during validation).
It often takes more time to assess whether your system is truly vulnerable to a given public exploit than it takes to just grab a newer version of the component.
Also worth considering: getting pwned because of a 0day is no fun, but getting pwned because of an unpatched CVE in your system - priceless.
When I took out a payday loan they made me sign a PAD authorization (pre-authorized debit) that was timed to hit my account the same day as my next payroll.
They also needed my last bank statement so they could 1.) verify my payroll was through direct deposit, and 2.) help them estimate the right date for their PAD.
In other words: yup! You must be banked!
I think it strikes a good balance between founder-friendly and investor-friendly.
Edited to add: Seems there's a 5-year window from year 35-40 after the initial license or grant where the license or grant can be terminated, either by the original author or their heirs, but honestly I have no idea if I'm reading this correctly. This whole statutory terminations thing goes way over my head. I cannot parse this document: https://akbllp.com/introduction-and-copyright-overview/statu...
It seems VirusTotal is a tool for running 70 anti-virus products at once against the same file. How can VirusTotal catch freshly developed malwares? How would VirusTotal even suspect that an uploaded file was fresh malware? That doesn't make sense to me.