source tree includes vulnerable libexpat 2.7.1 (does not affect binary distributions)

I should update it, and it's a bug that I haven't. I would totally welcome pull requests to update any dependencies. The best way to do it is:

1. Commit the unmodified package in projects/xyz-1.2.3 with a commit that says "Initial commit of xyz 1.2.3".
2. Commit any changes needed for the package to work in Fil-C in subsequent commits.

Since I used this approach for all of the projects, it should be easy to extract the Fil-C patch to expat by diffing the directory against the initial commit, and then using that patch for step (2).

I would also welcome any patches or suggestions for how to automate rebasing these packages.

As an aside, I think that all of the bugs fixed in expat since 2.7.1 are just DoS in Fil-C - except maybe the deprecation of XML_SetHashSalt (but it's not obvious that taking a new version to bring in a deprecation is super valuable). Correct me if I'm wrong though!

Oh I just realized: /opt/fil doesn't bundle expat at all!

So, this is an issue in Pizlix (which is an experimental demo) and if you build the full pizfix from source (which is not fully supported; it's mostly a way to test that Fil-C works).

Changing the title accordingly.

Oh I just realized: /opt/fil doesn't bundle expat at all!

So, this is an issue in Pizlix (which is an experimental demo) and if you build the full pizfix from source (which is not fully supported; it's mostly a way to test that Fil-C works).

Changing the title accordingly.

OK I got T800 to start rebasing packages in a loop.

I'm focusing on the packages used in /opt/fil since that's an actual distribution that I want to support.

Hi @pizlonator, thannks for your replies!

Oh I just realized: /opt/fil doesn't bundle expat at all!

Where can I find the sources going into optfil-0.684-linux-x86_64.tar.xz?

OK I got T800 to start rebasing packages in a loop.

Where can I learn more about about T800, what it is, how the new loop is working?

So, this is an issue in Pizlix (which is an experimental demo) and if you build the full pizfix from source (which is not fully supported; it's mostly a way to test that Fil-C works).

There seem to be two copies of Expat here:

• 2.6.4 at pizlix/expat-2.6.2.tar.xz
• 2.7.1 at projects/expat-2.7.1

If the first is Pizlix, what is the second one used for?

I would also welcome any patches or suggestions for how to automate rebasing these packages.

One idea worth sharing is use of GitHub Action peter-evans/create-pull-request to detect that something is outdated in a "cron action" and then make it create a pull request, e.g. caddy-detect-outdated.yml keeps the Docker image of Caddy up to date for me.

As an aside, I think that all of the bugs fixed in expat since 2.7.1 are just DoS in Fil-C [..]. Correct me if I'm wrong though!

Many are degraded to DoS, yes, but it would take a closer look at all of them (which takes time) and DoS would still be critical with e.g. a live car on the road. The 2022 stuff could still be more than DoS dependening on environment.

Where can I find the sources going into optfil-0.684-linux-x86_64.tar.xz?

Look at the optfil/ directory and trace what the build.sh script in that directory does.

Where can I learn more about about T800, what it is, how the new loop is working?

It's my own personal agent harness. I haven't written much about it.

For all I know, it's not any better than claude code/codex/pi/etc. I just made my own for fun, and it works well, so I use it. It's especially good at self-review.

There seem to be two copies of Expat here

One is for the bootstrap of Pizlix, which involves building with a yolo C compiler (just gcc) and the other is for Pizlix post-bootstrap.

One idea worth sharing is use of GitHub Action peter-evans/create-pull-request to detect that something is outdated in a "cron action" and then make it create a pull request, e.g. caddy-detect-outdated.yml keeps the Docker image of Caddy up to date for me.

Interesting. Is that an AI workflow, or something else?

My T800 loop does the rebasing of patches, sometimes fixes interesting merge conflicts, and runs a battery of tests. It's very flexible and thorough.

Many are degraded to DoS, yes, but it would take a closer look at all of them (which takes time) and DoS would still be critical with e.g. a live car on the road. The 2022 stuff could still be more than DoS dependening on environment.

Gotcha. That's fascinating!

I don't think that expat is used on security-exposed paths in Pizlix, from what I can tell. I might be wrong of course. But my understanding is that it's there to support XML parsing in Perl, and that's needed because of how Perl is used in the build systems of some packages. So unless you're in a position to smuggle invalid XML into the Pizlix build system, it's not super interesting. (And if you are in that position, then game over anyway.)

Still! Of course we should update expat! :-) I appreciate you bringing this up

@pizlonator thanks for elaborating!

One idea worth sharing is use of GitHub Action peter-evans/create-pull-request to detect that something is outdated in a "cron action" and then make it create a pull request, e.g. caddy-detect-outdated.yml keeps the Docker image of Caddy up to date for me.

Interesting. Is that an AI workflow, or something else?

There is no AI in there that I'd be aware of, and I started using that GitHub Action in March 2022 before ChatGPT was released and AI took off.