By default I’m skeptical of hand-written parsers, especially if they’re implemented in a language lacking memory safety features. I have seen too many parsers fall victim to (domain specific) fuzzing, and the consequences are serious security vulnerabilities.
Parser combinators are great, but they’re still hand-written in excessively powerful languages. That’s error-prone if the goal is to end up with a trustworthy, portable parser. The most frequently used parser combinator tools I know of are embedded DSLs, which means porting such a parser to another language requires manually converting to another parser combinator’s syntax and semantics and potentially implementing a new DSL which hasn’t yet been battle tested.
Parser generators which are in a position to get battle tested by supporting many parser implementations and integrations seem like the safest and most scalable way to go. I’m not familiar with Semantic Designs’ GLR implementation; thanks for mentioning it. Another worth knowing is tree-sitter (https://tree-sitter.github.io/tree-sitter/). As a GLR-based parser generator it supports ambiguous context-free grammars. At first ambiguity may sound like a downside, but without a computer-verified proof that your grammar doesn’t admit multiple valid parses for any inputs it’s safest to assume ambiguity and proceed accordingly. For example, if at parse-time multiple parses are found you have the option to warn the user or even reject their input with a diff of the ASTs so they can try to patch the input so it’s no longer ambiguous.
Tree-sitter is young, but it has reach. Atom editor packages for languages are encouraged to implement tree-sitter parsers. It’s particularly well-suited for editors because it supports incremental parsing. Parsing the same file from scratch after every edit isn’t necessary.
Recently I implemented a tree-sitter grammar for ABNF (https://github.com/jmitchell/tree-sitter-abnf) and an Atom package (https://atom.io/packages/language-abnf) for it. Now I’m exploring how to generate tree-sitter parsers for grammars specified using ABNF, such as Dhall’s (https://github.com/dhall-lang/dhall-lang/blob/master/standar...). My plan is to automatically generate and fuzz C-friendly parser libraries for many languages to make them more accessible. I also want to help address any tree-sitter bugs discovered along the way that could translate into security vulnerabilities in generated parsers. For now this is a labor of love, and I am not affiliated with the tree-sitter project.
There was an incident with similar consequences on April 10, 2014. The cause was a programmed threshold being breached and the impact was 6h of downtime.
> Operated by a systems provider named Intrado, the server kept a running counter of how many calls it had routed to 911 dispatchers around the country. Intrado programmers had set a threshold for how high the counter could go. They picked a number in the millions.
I'm really curious if there's some explanation that makes this sound less catastrophically stupid, particularly the part where they picked a threshold less than INT_MAX.
Thank you and the Keybase team for this. Unlike other services, I think KB has solved the online identity authentication issue.
There's one hurdle I need to work through to get going on chat. Thus far I've avoided uploading my private GPG key to my Keybase profile, or even copying it to other devices (call me paranoid). Unfortunately this apparently means I can't authorize any other devices (see error message: http://imgur.com/a/UOftN). I assumed device keys were meant to solve this problem, but maybe not. Is there a supported way to make a subkey (GPG or otherwise) of my primary private GPG keypair, so other devices can securely authenticate against my KB profile?
EDIT: I haven't yet started using device keys. Maybe they would work?
This is answered in the FAQ at the bottom of the post.
You'll see this policy in action when you install Keybase on a 2nd computer. It'll make you either (a) type something on your first computer, or (b) enter a paper key. This isn't just two-factor auth with server trust. The old key is signing a statement about the new key, and the new key is countersigning.
It could be formatted better: it's telling you you have three different options, one of which is,
Install Keybase on a different machine that has your PGP key
I was in the same boat as you, I didn't want to import my private key onto this mac laptop because I don't know how the "Keychain.app" works and don't trust apple to not do something super helpful like store my GPG private key forever and always. I did the login flow on the machine I do trust, and was then able to use that machine to authorize the mac laptop, without moving any GPG keys anywhere.
I interpreted that option as Keybase needing a local copy of the PGP key. Thanks for helping me understand that's not the case.
I've set up Keybase on my trusted machine with my GPG keypair, and now have a device key on that machine. When I go to Devices -> Add new... -> New Computer in the GUI I'm told to "Type in text code" (along with the note "In the Keybase app on your computer, go to Devices > Add a new device"). I find this confusing because I'm already there. I tried using the only paper key I have, the one corresponding to my first device key, but there's no response when I click Continue. This is the Linux client, by the way. I'm guessing this is a bug, but I'm not sure. Can you confirm this is the same process you went through to generate your second device key?
When I try to log in on the secondary computer, which doesn't have the GPG keypair or a device key, I'm brought to the same error shown in the screenshot.
on my trusted computer with my GPG key, I ran 'keybase device add', selected option 1 ("desktop or laptop") and it asked me to enter the "verification code" from the other device. It also said, "to get a verification code, run 'keybase login' on your other device", but I'm certain that I just clicked some buttons in the GUI instead of running that command.
This is true and good to keep in mind, but it's also an inescapable risk of any network involving autonomous agents. We're also susceptible to downloading content that's different than advertised (e.g. Rickrolling).
And in all honesty, the whole "but child porn OMG" is a non-sequitor.
Child porn already exists on the web directly. And Tor Hidden Sites. And Freenet. And other places.
The real problem with CP is that fact there's no mens-rea requirement. A script can download it to your browser cache under blank images. It's in your cache, and you have no clue.
In the current situation, you are illegal. With mens-rea, you aren't - there was no willingness to get it, therefore you aren't at fault. Think of this as shoplifter compared to something that fell in your cart you missed. Same idea.
(In all honesty, I hold to Stallman's idea of CP shouldn't be illegal, period. It's a proof of a crime. Snuff videos of people being murdered isn't illegal, although the murdering part very much is. Child abuse is illegal, as well it should be, but proof of child abuse shouldn't.)
You still have to convince others there was no willingness. And it's much easier to convince them of that if you're not also sending the copies to other people.
Exactly. Stay away from anything that could even be believed to be hosting felony content. I always tell people that, if they do run it, run it through some hosted server at a reputable place so the police just grab that box. They might still hit a residence but they might not if they find nothing on the box they grab while it's active.
