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.
-
-
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".
1 reply 0 retweets 1 like -
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.
-
-
Replying to @taviso @CiPHPerCoder and
now question: do clients actually use gpgme? And of there is a safe api, gpg should not expose an insecure api at all. When it's exposed, you have to consider clients using it. At least the whole api could be marked depreciated or so and always empty a depreciation warning or so
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.