I started exactly such a project, for org syntax, a while ago. Didn't get very far though because it seems to me that things in org cannot be parsed and understood in one go. For example the TODO keywords can be specified at the top of an org file and then would influence how headings in the document are understood. This cannot be done with merely a PEG.
Another tricky point is nested inline markup. Bold inside italic? Verbatim inside bold, inside italic? And so on. Would be great to support all meaningful combinations via recursive rules. Org has many inline markup things. Even programming language specific inline markup elements.
Another issue is, that Guile's PEG library, when using the non-string form of grammar rules, does not allow mutually recursive grammar rules, due to being buggy (in that way it is not excellent, but in other ways it is!). One has to use the string form or rules, which makes it a lot less nice to use, unfortunately. I hope that will be fixed at some point, because I like the library except for that. And it is in the standard lib, no need to install any dependencies. Like to use it for AoC puzzle inputs for example.
Will be interesting to read how far they got.
EDIT: Also it's going to be great to have an actual grammar based parser for org. This will ease creating one for other tools, like for example parsers of readmes in repos on git hosters.
I had done some work in this direction in my org parser for racket [0]. That work is stalled at the moment (though I still intend to come back to it), but many of the interactions between org and traditional formal grammars have been explored there.
Aha! Interesting to hear you were going in the same direction. There are indeed quite some tricky situations to handle since Org (and Markdown) are complex in many ways.
the approach I am taking is to combine the PEG with a step of AST processing in order to then produce a correct and descriptive tree structure (for later rendering).
I do agree the Guile library has some spots to improve but honestly, I am already enjoying it so much, and it's far better for the Lisper in me than other things I've tried. I also find S-expressions much more comprehensible and self-documenting.
Looking forward to seeing what you do with it :)
I am indeed hoping that this library is useful for more people and that perhaps things like Haunt blog generator can use it (and other interesting uses)
As for nested markup, and nested lists it has been tricky, but so far I've really promising results:
(assert-equal
#:got (inline-org->html (inline-org->ast "*bold with /italic/*"))
#:expect "<strong>bold with <em>italic</em></strong>")
I am sure instead of more bombs, missiles and other military stuff, they will invest it into the public good, education for citizens, and infrastructure. No one will line their pockets. Not in the US. No, no, they will use that money to make things better. for all the people abused by tech giants. I am so sure of it.
I would like to throw in one 3D example, which I found to be excellently executed: Metroid Prime (1) on GameCube.
Looks beautiful, beautiful soundtrack, very much has you puzzled when solving the puzzles for the first time, tons of secrets, and maybe we can call it an adventure.
Probably a lot of those that have remained open will also stay that way, because they are (1) fake job ads, or (2) job ads of companies, where you don't even reach a human soul during the application process, and the companies don't realize how broken their hiring process really is, or (3) job ads of companies, who have so unrealistic idea about what they are looking for and what they themselves are actually offering to attract whomever they are looking for, that almost no one applying meets the criteria.
Probably I also forgot some more categories of crazy hiring processes in my enumeration.
The idea of covering irrigation canals has been around probably for thousands of years. Only recently I have seen this being done in Xinjiang in towns right next to the desert. The canals which have river water often flow under streets and through little caves and such, enabling them to grow grapes and such. The grapes are then also providing shade on paths and roads.
No, I am talking about both. If too much water evaporated, they wouldn't have enough to water all the plants. Both ideas, preventing evaporation, and guiding the water, are very old.
CA is already at 40% electric from green sources. I don't know their plans, but in general I would expect by 2035 they will be at 95%. However that last 5% will be the long tail of weird/hard things.
These are the reason, why every easily reachable web server will be spammed with /something/something.php?somearg=someval. If I had to guess, which software on the web has been the most exploitable over all of the web's history, WP would surely be among the top candidates. Maybe right after MS Teams or Sharepoint or some stuff like that.
TBF, some of it is structural: if you're the most popular anything on the internet, you'll be the most attacked and the most exploited, and hence the most exploitable.
Most attacked, sure. Most exploited? You get out of it what you put into it. If you work to make it more secure, it will stay more secure, popular or not.
WordPress is a software design from the early 2000's - and not a particularly good example. Even back then there were more secure designs.
Take QMail for example. A simple design, it had security baked in from the start, and remains one of the most secure software packages in history. This exploit would have been prevented if WordPress had followed QMail's security designs. Enforced data flow, avoidance of parsing, eliminating untrusted code, and eliminating bugs by choosing code paths with fewer variables, would've all prevented this bug.
DJB wrote a paper on QMail[1] to try to explain what worked and what was unnecessary. Anyone implementing new software (and wants it to be secure) should consider these [and other] design points. Popular software doesn't have to be bad software. [1] https://cr.yp.to/qmail/qmailsec-20071101.pdf
That's bad designs for you. Assume that just because it's widely visible, must mean it has exploits. (this is the only point on that list I'll call "that's bad logic" on).
The point of engineering is measuring and confirming errors, and designing to mitigate them. Exploits are errors.
Complexity does not lead directly to exploits, letting errors be ignored does. At what level an error can be ignored - that's quality control. And one can tell poor quality software by how exploitable it is.
Indirectly then? More complexity means more interacting parts, more complex interaction might hide flaws in ways it's hard to predict without looking at the big picture, which might be too big for a single person to picture (he).
I don't advocate for oversimplified systems, the same way I don't advocate for overcomplicated systems. I advocate for finding an equilibrium.
Well, one can design in ways to reduce attack surfaces. But then it also helps if your tools and infrastructure support that. PHP for instance, is famously unhelpful and often hostile to this, though.
True, but then again WP is a very simple system, in comparison to the Linux kernel, and WP operates on a very different level, at which it should be much easier to get right. Also WP is not written in C. Granted, PHP is not all that great either, but probably still miles ahead, when comparing it to having to write bug-free C code, as one doesn't have to deal with all the manual memory management stuff, which people, even experienced engineers _will_ get wrong at least sometimes (remember the Chromium statistics about vulnerabilities).
In the sense that it and its ecosystem is high maintenance. When I call something names I do not do that lightly, but Wordpress is probably the single piece of software that has caused me the most problems over my 20 year IT career. You simply cannot put Wordpress into a customers hands, let it run for 5 years and expect it not to blow up in one way or another.
Just today I spent three hours to manually fix a page where a customers site was defaced after they installed and then uninstalled a translation plugin. I had to write a script that manually check every single instance of translatable text there is on the website.
Yes, and most of them are low or medium impact and typically only apply to relatively niche modules or configurations. I can't recall any RCEs from this decade that were widely exploitable. The most recent one could be CVE-2026-42945 ("nginx rift"), but even that requires a really specific and kind of strange configuration.
You could've included a little more nuance. An interpretation of your response is "being the most popular remotely accessible software" != "the most attacked", which would need defending.
If I had to guess, which software on the web has been the most exploitable over all of the web's history, WP would surely be among the top candidates.
People on HN love to talk smack about WordPress. After all these years, it's as much a reflex as shouting "walled garden!" every time there's an Apple story.
Yet some of the biggest web sites on the internet run WordPress, and more importantly, some of the biggest hacking targets on the internet run WordPress.
Prime example: whitehouse.gov.
If you know what you're doing, WordPress fine. The same is true with every other piece of technology out there.
But people on HN like to lump the good in with the bad because everything is binary.
WordPress’s security model is distilled insanity, concentrated vulnerability. You’re supposed to give your site write access to its code, which turns almost any vulnerability into complete and persistent site takeover. Not to mention how many things will store code in the database and execute it from there, and how much of its design is fragile as anything, and how many plugins, often popular ones, do obviously dumb things that would not have been possible in most ecosystems.
Drupal (also popular in governments and such), by contrast, will check that it can’t write to anything but its designated file uploads directory, and complain if it can, and has careful guidance around avoiding letting uploads be accidentally executable too. The blast radius of the typical vulnerability, and the possibility of persistent takeover, is drastically reduced.
It’s possible to use C correctly, but in practice using it invites security problems, because it’s frightfully easy to make subtle but disastrous mistakes, even for experts, so there are reasons why people are moving to safe languages.
WordPress is that kind of bad. It has always been bad, though it’s somewhat less bad than it used to be. Some of its badness is a part of how it got popular.
> You’re supposed to give your site write access to its code
You do not need to. Its to help people who cannot manage an ssh login update. You can use the cli to update if you can. I am pretty sure big sites will not be doing their updates from the big site.
The problem with plugins is lack of a proper framework. Its very easy to do things like pass user inputs into a query by strong concatenation because you have to make in extra effort to not do so.
That said, its no guarantee. I have seen people do things like call exec on user inputs in Django.
> has careful guidance around avoiding letting uploads be accidentally executable too.
That should be the default, not something you need to take extra care over.
> That should be the default, not something you need to take extra care over.
I agree. That’s one of the problems of PHP’s file-based execution model, and how the likes of Apache and nginx work. Drupal is no paragon of security, but it’s far closer than WordPress. For all its faults, even Node.js avoids this class of problem.
Yeah, I agree that with the right expertise you can keep WordPress safe, and the White House is a good example of that. But the problem is the WP ecosystem and defaults push people without that expertise to install plugins and themes, and "if you know what you're doing" is the exception, not the rule for its user base
Anecdote: we contracted a web page, and the guy started saying "it would be a Wordpress. It has very bad press, but it's because it is widely used". Ok, we start developing in the latest version of php, and soon he say "we have to go down a couple phpversions, because x pluging don't work in the latest". Requested version had a dozen critical CVEs. Plugin in question did something really basic, like a preview card with OpenGraph data, or something like that. Something a junior could code in a day.
And that is insecure Wordpress: people lego-mounting sites without touching code, only with plugins.
People who _don't_ know what they are doing are using WP for every project, that they touch, because it is all they know. Given WPs database design, the assumptions baked into that, and the complications resulting from that, make anything other than a posts and pages website a PITA.
This in turn requires one to install shitty plugins, or spend time developing a minimalistic solution to each new challenge. With every plugin the attack surface grows, and the vast majority of larger WP sites is this cobbled together mess of WP plugins, having some WP expert trying to make them all work together without stepping on each other's toes, while hopelessly falling behind on updates, because updates could, and _will_ break things.
People only knowing PHP and WP, try to use WP as a sledgehammer, not realizing that hammer actually being made out of glass. Very few plugins are actually minimalistic, no-bloat, safe, well-developed. Lots of those plugins are 80% marketing fluff and wanting to make a business out of worse than mediocre code bases. That's also due to many people in that community being exactly those, who don't know anything but WP.
Even normal core WP updates can break the legality of ones site. I have had that at some point, where after some WP update it started loading emojis from a friggin third party, to replace the unicode symbol I had used. I was furious, because this needs to be part of the data protection policies/statements. One does not simply load a third party shit, replacing what the dev actually put there, which was just a unicode symbol. That's an idiotic thing to do. If I wanted third-party emojis, I would have included them myself.
Finally, some big pages run on WP says not much, given the catastrophic state of many websites. whitehouse.gov is laughably badly made. Another complete failure. The first thing I see that it loads Google tags manager. A government site loading shit.
lol. From nav directly to some mp4 video?? Not a URL of a page, which then would display the video, but a URL directly to a video? Good that my noscript blocked media on that domain!
If it is a prime example, then it is a prime example of a very shitty made website, by people, who don't know what they should be doing.
So all this shows is one can make a shitty site using WP. Great. I am sure one can also make a not shitty site using WP. Like you say, _"If you know what you are doing ..."_. Just that most WP people don't. They don't know how to not make a mess, or choose the short-term easy way out, and install tons of shitty plugins. Many of them just have to put things up once initially and are paid, or hold the hand open for some maintenance fee they extract, required only due to how badly made these WP sites are.
Manual safety or not is a real debate among people who carry pistols for self defense and law enforcement, and no manual safety is the majority position. The reasoning is that an extra step when the user needs the pistol in an emergency is problematic, a properly designed pistol can only fire if the trigger is pulled, and a properly designed holster makes pulling the trigger impossible until the pistol is drawn. Nobody seriously advocates carrying an unloaded pistol for those purposes, and only lunatics advocate having people who don't know what they're doing carry pistols.
It's not a great analogy to Wordpress, which attempts to provide as much capability as possible in a CMS while requiring as little expertise from the user as possible. Vanilla Wordpress, kept up to date is pretty safe. Plugins are just a click away though, and using plugins safely requires evaluating each plugin's risk profile and track record individually, which is real sysadmin work.
The access log of public http servers is truly interesting to watch.
You know that the scripts doing it are optimized for success rate, so the types of requests they send give you an impression of what's actually out there.
It's clear to me that once we finally achieve rogue AGI, it is going to propagate through unpatched WordPress WooCommerce instances.
I think that is very likely to be common. It is an easy mistake to make if your code is in a directory the web server can read, which is common, and is usual with PHP.
Yep I see this at work pretty regularly - a SpringBoot log file full of requests for all sorts of things (mostly WordPress but I think some IIS as well).
It has its share of vulnerabilities but flaws in core are rarer, more (a lot more) (i swear to god a LLM would be better) in the modules ecosystem. Also like most CMSes they are still vulnerable to what i call the "webapp bug" (you install this blob on a hosting that should not be aware of what you dump on there and allows you to run a php file on any subdir, while with a CMS, whatever you use, only a very limited number of files should be allowed to be reached, executed or even included in any php call).
All I remember with Joomla! is that it was really, really susceptible to the “plugin we use is abandoned and not updated and the new version of core is completely incompatible” causing everyone to run various out of date packages with stupid security layered on top. Web application firewalls are an abomination.
Every so often I switch on the nginx endpoint that serves a 10TB zipbomb to clients that request anything `wp-*` that 404s (which is everything on my sites, I don't run WordPress).
Sometimes the same IP address hits two or three URLs before going dead.
And there we get to the word both or all, where interestingly Mandarin has an (over)insistence on using it, even in places, where it seems unnecessary.
I started exactly such a project, for org syntax, a while ago. Didn't get very far though because it seems to me that things in org cannot be parsed and understood in one go. For example the TODO keywords can be specified at the top of an org file and then would influence how headings in the document are understood. This cannot be done with merely a PEG.
Another tricky point is nested inline markup. Bold inside italic? Verbatim inside bold, inside italic? And so on. Would be great to support all meaningful combinations via recursive rules. Org has many inline markup things. Even programming language specific inline markup elements.
Another issue is, that Guile's PEG library, when using the non-string form of grammar rules, does not allow mutually recursive grammar rules, due to being buggy (in that way it is not excellent, but in other ways it is!). One has to use the string form or rules, which makes it a lot less nice to use, unfortunately. I hope that will be fixed at some point, because I like the library except for that. And it is in the standard lib, no need to install any dependencies. Like to use it for AoC puzzle inputs for example.
Will be interesting to read how far they got.
EDIT: Also it's going to be great to have an actual grammar based parser for org. This will ease creating one for other tools, like for example parsers of readmes in repos on git hosters.
reply