ptrace isn’t a vulnerability; we can confine the discussion to reasonable interfaces, which are what’s implicated in this vulnerability.
-
-
The POV of the GPG project is clearly: callers might _want_ the unauth’d plaintext, so we’ll provide it with a warning. The POV of modern cryptography is: fuck what you want, unauth’d plaintext is hazmat.
1 reply 1 retweet 6 likes -
Replying to @tqbf @CiPHPerCoder
Again: we're obviously on the same page for the unauth'd issue. We differ here because I think the status api is effectively an internal low-level api, and it is unreasonable to hold that to the same bar as a documented and supported high-level api.
1 reply 0 retweets 1 like -
Tavis Ormandy Retweeted Tavis Ormandy
See this tweet.https://twitter.com/taviso/status/996136722546081793 …
Tavis Ormandy added,
Tavis OrmandyVerified account @tavisoReplying to @taviso @tqbfGpgme has user docs, whereas the status api has some org mode README in the source distribution. I'm not convinced it's fair to say "it's a vuln if it's hard to use the low-level internal apis", is there any library that can't be misused if you access private/internal apis? 2/21 reply 0 retweets 0 likes -
Replying to @taviso @CiPHPerCoder
We may be in distinction-without-a-difference land here. If you’re arguing that nothing in the GPG stack should be using the interfaces they’re using, I don’t have a strong POV on that. Sorry if I’m being obstinate.
1 reply 0 retweets 2 likes -
Replying to @tqbf @CiPHPerCoder
Yes, I'm saying clients should be using gpgme, it wraps all of this internal crazy stuff in a high-level, documented and supported api. If clients use the internal stuff directly anyway and then screw it up, I'm saying I don't see how that's a gpg vulnerability.
2 replies 2 retweets 9 likes -
Replying to @taviso @CiPHPerCoder
The GPG project itself is vouching for the interface we’re talking about, which is why it’s an issue.
2 replies 0 retweets 1 like -
Replying to @tqbf @CiPHPerCoder
I don't speak for them, but I think they vouch for it in the same way that openssl vouches for the bn library: they use it and rely on it. They're pretty upfront that status api is complex and clients should use gpgme, read this blurb: https://www.gnupg.org/software/gpgme/index.html …
1 reply 0 retweets 1 like -
Replying to @taviso @CiPHPerCoder
I’m reading message after message talking about exit codes and warnings, and that’s what I have a problem with.
1 reply 0 retweets 1 like -
If I understanding correctly, I think
@tqbf’s argument is OpenPGP should require you to pass a `--danger-ignore-authentication` errors flag before decrypting at all. Doing so explicitly forces the user to downgrade to a vulnerable state, so naive implementations aren’t hurt.3 replies 1 retweet 1 like
Yes, but this is a low-level api that *has* to expose a lot of legacy design decisions. Naive implementations should use the high-level api, and complaints about confusing api's there are valid - here you're just saying "this complex undocumented thing is complicated".
-
-
If it's true that it *has* to expose legacy design decisions, then we're better off replacing it rather than trying to fix it.
1 reply 0 retweets 0 likes -
I think you missed the point.
1 reply 0 retweets 1 like - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.