For a F1 drive axle the critical resonance frequency is around 2400 rpm. That's why you need to turn it up fast at start over the safe 4000 rpm, and never go down.
Without the ECU you can easily break it by starting too slow
They presented critical parser flaws in all major PGP implementations, not just GNU PGP, also sequoia, minisign and age. But gpg made the worst impression to us. wontfix
Sequoia is mentioned in only one vulnerability for supporting lines much longer than gpg. gpg silently truncates and discards long base64 lines and sequoia does not. So the vulnerability is in ability to feed more data to sequoia which doesn't have the silent data loss of gpg.
In all other cases they only used sequoia as a tool to build data for demonstrating gpg vulnerabilities.
The vulnerability that opens the talk, where they walk through verifying a Linux ISO's signature and hash and then boot into a malicious image, impacts both GnuPG and Sequoia.
They're not, but the flaws they found are independent of PGP. Mainly invalid handling of strings in C and allowing untrusted ANSI codes in terminal output.
Nope. Not yet enabled. It was submitted to HN right after the talk where they promised to make it public "really soon" after the talk. We all saw the talk live or on the stream
I’m not sure I completely agree here. For private use, this seems fine. However, this isn’t how email encryption is typically implemented in an enterprise environment. It’s usually handled at the mail gateway rather than on a per-user basis. Enterprises also ensure that the receiving side supports email encryption as well.
There's like one or two use cases where encrypting email could work. The best case I've come across--Bugzilla has the ability to let the user upload a public key to encrypt emails for updates to non-public bugs. It's not a big use case--pretty much the intersection of "must use email" and "can establish identity out of band," which does not describe most communication that uses email. (As tptacek notes in a sibling comment, you pretty much have to limit this to one-and-done stuff too, not anything that's going to be in an ongoing discussion, because leaks via unencrypted replies are basically guaranteed).
Your mail either needs to be encrypted reliably against real adversaries or it doesn't. A private emailing circle doesn't change that. If the idea here is, a private group of friends can just agree never to put anything in their subjects, or to accidentally send unencrypted replies, I'll just say I ran just such a private circle at Matasano, where we used encrypted mail to communicate about security assessment projects, and unencrypted replies happened.
Even my doctor's office and local government agencies support PGP encrypted emails, and refuse to send personal data via unencrypted email, but tech nerds still claim no one can use it?
I'm yet to finish watching the talk, but it starts with them confirming the demo fraudulent .iso with sequoia also (they call it out by name), so this really makes me think. :)
Sequioa hasn't fixed the attack from the beginning of the talk, the one where they convert between cleartext and full signature formats and inject unsigned bytes into the output because of the confusion.
The latest version of a bad standard is still bad.
This page is a pretty direct indicator that GPG's foundation is fundamentally broken: you're not going to get to a good outcome trying to renovate the 2nd story.
There are people who use GPG for more than that. Those that are fine with just those two features, sure. Heck, you can encrypt with "openssh", no need for age. :D I have a bash function for encryption and decryption!
Why does Fedora / RPM still rely on GPG keys for verifying packages?
This is a staggering ecosystem failure. If GPG has been a known-lost cause for decades, then why haven't alternatives ^W replacements been produced for decades?
Nonsense. You get the simplification and faster development times of knowing some variable types statically, plus the performance improvements for the compiler which can move the type checks from runtime to compile-time. Plus all the new optimization possibilities.
Common Lisp showed you the way. But almost none looked at it. Only PHP did.
At least CPython and CRuby (MRI), the most common implementations of each language, ignore all type hints and they are not able to use them for anything during compile or runtime. So the performance argument is complete nonsense for at least these two languages.
Both Python and Ruby (the languages themselves) only specify the type hint syntax, but neither specifies anything about checking the actual types. That exercise is left for the implementations of third party type checkers.
reply