You're right, PDFs are horrible scary monsters who you should never trust.
[1] https://fil-c.org/Same thing applies here. Even Rust has a crate for dealing with binary data, despite its memory promises: https://crates.io/crates/untrusted
It's a fucking minefield, and this is one area where the Rust zealots are undeniably correct. It doesn't have to be Rust, any memory safe language will do, but Rust also happens to be performance competitive and that's usually also desirable.
Rust is a general purpose programming language, which is great if your problem might be something never imagined before, but this literally isn't our first rodeo, we have wrangled lots of file formats before, we should use a language purpose-built to do that safely.
I don't understand how I hit the anti-Rust tripwire here:
> My comment: any memory safe language will do
I like 4th edition D&D but if you're trying to make a story about nuanced inter-personal conflict in which there's no actual violence it's just not the right roleplaying system and so I'm not going to agree with your choice to recommend 4eD&D as the system for the story "Love and Jealousy in the Elven Forest"
I've written a whole bunch of Rust, and hardly any WUFFS - but, I wasn't writing code for Wrangling Untrusted File Formats and that's very much what you're doing in a PDF parser.
You're confusing just assuming by default its enough for purpose rather than not caring at all.
You can downvote anything not interesting.
If he have list some alternative or give example, it might be interesting.
Up until 2022, they had PDF interpreter written in Postscript, the current version is in C.
If you have a hammer, everything seems like a nail I guess.
Rule #2? Please don’t.
btw... im sure there's some legacy rng in windows or some shit that isnt good. read the docs but if it's the blessed system rng, you're probably fine!
although... i suppose if this is news to you (the person reading this), then you probably shouldn't be implementing whatever you are that really requires prng. ask a friend for help. im not trying to be a jerk, i just want to make sure you dont hurt yourself!
And if you're a sysadmin, be extremely careful when generating keys in VMs or embedded devices. They tend to overestimate their entropy sources - it's possible that every clone of a VM generates the same keys. In some cases (cough ECDSA) generating the same key and nonce to sign two different messages is catastrophic - it immediately leaks the private key.
-object rng-random,id=objrng0,filename=/dev/null
or maybe just a file that contains 4 :O
Rule 3b: Failing rule 3, disclose motivations and full list of employers and / or customers
man encrypt works. info /encrypt works too.
Another pet peeve is when people use the rand() when they want hash() but I will leave that rant for another day.
They are so close that people can and often do build rand() as "internal state s = hash(s) return s" (or similar). then other people, wanting that deterministic hash() behavior thus accidentally exposed, build entire worlds(literally) out of rand().
Another problem with this is that the rand() internals are opaque and unknown and can change without violating the spec. hash(), because it is supposed to be deterministic, usually has an exposed stable algorithm.
A specific example. At one job I found they were storing long term customer order archives encrypted where the key was a hash of the date, this in itself is a little suspicious but the archives were offline and physically locked up on site, so not too bad. The real wtf was that the encryption was done on a win98 machine with a perl script that was basically "seed(date); key = rand(); encrypt(data, key)". expecting to regenerate the key if they ever wanted to look at the data. When I saw that I went "I don't know much about perl, but that does not feel stable" and did a few checks. Sure enough the behavior of rand() could change depending on the operating system or even version. making the keys highly dependent on that exact win98 machine with that exact version of perl, I think they ended up using that machine to generate and store all used keys in a database so other machines could decrypt the archives.
The human bar is not that high.
I would much rather have rigorous testing than a filter based on the origin of the code.
For AI this will be impossible, however.
If you're talking about testing of code, well "tests can only prove the presence of bugs, not their absence"
It's basically a browser, but a PDF instead of HTML. It even has JavaScript support.
Each with varying degrees of trust. The outcome is never perfect, but that’s not their purpose.
Every hiring manager worth their salt has caught at least one completely incompetent applicant with a CV full of certifications.
Would the new LLM model owners like to strike this down, or use it to demonstrate how dangerous unrestricted models can be?
It makes me wonder: Coincidence, really? There's enough there to think that there might be some invisible hand behind it.
Also, I get that a lot of sensitive information is exchanged with PDFs these days, but why should PDFs have encryption built-in to the file format? Sensitive information is also exchanged in image files, word documents, zip files, html, etc etc etc etc. If you take all the work that goes into making the crypto UX decent for one kind of file and apply that to "all files", then each ecosystem doesn't have to invent their own.
This is just like "high-end" car manufacturers insisting on making their own software, and not integrating apple carplay. They're either going to make a truly shitty podcast app, or they're not even going to bother and instead tell people to use bluetooth to listen to podcasts like it's 2006.
Since the kind of data people want available may differ for each file format, here we are.
Because very few 'end user' people know how to use en/decryption. So it's much easier to send them a familiar file and say 'enter this password' than to have them searching the web to work out which arguments to pass to openssl. In a command line? What's that?
I received an AES-encrypted file recently but neither gnupg nor openssl could determine what mode and keysettings the sender had used, so it was just a useless lump of data. Very secure though...
That's the point, rather than PDF viewers implementing this, it should be an OS-wide UX, so that you could click any encrypted file and have a unified password prompt, regardless of whether it's a PDF, PNG, DOCX, etc.
And the same goes the other way, rather than having your PDF viewer implement the encryption UX, you should just have an "Encrypt with password" entry in your file manager's context menu.
So you could open encrypted documents on iOS and Android.
always Base64Encode/Decode!
What drives developers to reinvent these wheels? It's both more effort and worse.