Remote

Derick Rethans' Blog

@blog@social.derickrethans.nl

This is the ActivityPub version of Derick Rethans' blog. The original is at https://derickrethans.nl

34 Followers

0 Following

3 Posts

Joined April 17, 2024

Derick Rethans' Blog @blog@social.derickrethans.nl

· 28mo ago

Xdebug Update: May 2024
Original Post

In this monthly update I explain what happened with Xdebug development in the past month. These are normally published on the first Tuesday on or after the 5th of each month.

GitHub and Pro/Business supporters will get it earlier, around the first of each month.

On GitHub sponsors, I am currently 44% towards my $2,500 per month goal, which is set to allow continued of Xdebug.

If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In the last month, I spend around 23 hours on Xdebug, with 22 hours funded.

Xdebug 3.4

I created the first alpha release of Xdebug 3.4 — with some preliminary PHP 8.4 support. The main reason for this was to test out the PIE tool, that @asgrim@phpc.social is working on as part of his work for the PHP Foundation.

This new tool uses composer-style definition files. It also means that extensions like Xdebug can now be found on Packagist.

PIE is still in early development, but I shall be continuing to test out while it matures.

The 3.4.0alpha1 release itself adds a new XDEBUG_IGNORE HTTP variable to prevent Xdebug from initiating a debugging session for this request only. This feature was requested by the Symfony project, to prevent debugging sessions for the debugging toolbar.

Native Xdebug Path Mapping

In the previous update I wrote about Xdebug's new projects section, and the first project that I am hoping to fund through this: Native Xdebug Path Mapping.

After my announcement, several companies and individuals reached out. The funding is now nearly there, with good hopes that it will conclude soon.

You could be part of this too!

Once we cross the line, I will start with the implementation, which I intend to include into Xdebug 3.4.

Xdebug Videos

I have created no new videos since last month, but you can see all the previous ones on my channel.

If you have any suggestions, feel free to reach out to @derickr@phpc.social or via email.

Business Supporter Scheme and Funding

In the last month, no new business supporters signed up.

Besides business support, I also maintain a Patreon page, a profile on GitHub sponsors, as well as an OpenCollective organisation.

If you want to contribute to specific projects, you can find those on the Projects page.

Xdebug Cloud

Xdebug Cloud is the Proxy As A Service platform to allow for debugging in more scenarios, where it is hard, or impossible, to have Xdebug make a connection to the IDE. It is continuing to operate as Beta release.

Packages start at £49/month, and I have recently introduced a package for larger companies. This has a larger initial set of tokens, and discounted extra tokens.

If you want to be kept up to date with Xdebug Cloud, please sign up to the mailinglist, which I will use to send out an update not more than once a month.

youtube.com

Derick Rethans' Blog @blog@social.derickrethans.nl

· 6mo ago

Human Creations
Original Post

Last year I wrote about how you can use ActivityPub, through the Fediverse to publish your own content, and being in control of it.

As part of a recent keynote that I gave at the Dutch PHP Conference I returned to this subject, but also reflected on what happens with the content you publish, and your rights over it.

Because in the last year, it has become clear, that lots of large and wealthy companies, don't really care about the latter.

What I mean by this becomes clear with the following examples.

When Gary Gale one day went to visit his Vaguely Rude Places Map site, he found that (AI) bots had eaten through his map tile allowance. He now hosts his site behind Cloudflare, being beholded to a Big Tech™ company again.

When I look at the web server logs for the php.net sites, I see that most of the uncached requests come from bots.

This also happens to other large sites, such as OpenStreetMap, which got hit by AI DDos Scraper Bots requesting an extreme amount of content from 100,000+ IP addresses; or Fediverse instances, such as infosec.exchange, which had to deal with more load.

All this scraping comes at a cost, but to the scrapers, nor the users of these tools.

Although the content is freely available, the services hosting content still need to be funded. Instead of you giving up your privacy, you will need to pay for those with actual money for them to thrive, and exist.

But AI impacts content in other ways as well.

I need to be clear of what I mean with AI. I don't mean the visual recognition models to detect cancer faster, sifting through loads of data to find patterns, fraud detection, speech recognition, translation services, or deciphering my terrible handwriting.

I specifically mean Generative AI through LLMs — for articles, source code, and "art".

I have no beef with the actual technology either, only the exploitative nature of how these currently are created and hyped up.

Just like the Luddites weren't against new technology, but how this technology was used to exploit them.

I have written two books in my life, many years ago. The material in them has been slurped up into the LLMs, and one of them was originally part of the Anthropic law suit where they settled for using pirated copies of the books.

Mind you, not for using the book as training material.

Although the settlement was for 1.5 billion dollars, I still ended up getting nothing, as only American authors were compensated.

There are similarities with the code that I, and many others, have written.

Code, published under an open license. But these licenses often require attribution. How much attribution is now given when one of your chat bots produces parts of my code?

Nothing.

Which means that these tools are in breach of the licences under which the original code was published, and hence shouldn't exist.

Unfortunately, some governments, like mine in the UK, are less concerned about AI companies stealing content, although there are some indications that they've changed their tune.

I never gave permission for any of my content, be it books, code, nor photos, to be used by these tools, but they're still making money of it.

As a matter of fact, they are not only making money of it, but also making it a lot harder to host things ourselves by driving up costs for CPUs, GPUs, memory, and storage.

They are literally stealing things to sell back to us, whilst at the same time making sure we have to use their services as it is becoming too costly to have a decent set up in our homes and offices.

But lets get back to content. I like writing. I am not great at it, but I find it pleasing to show others what I have worked on, and the adventures I have had.

I write for humans, and therefore, I also expect that when I read something, it is also written by humans. I prefer to be able to see the writing style of specific authors, as that is part of the experience. They own their voice.

In my case, that has always been including em-dashes wherever I can.

What I do not like to read is generic and bland text. Text that has no weird grammarisms, flair, or emotions.

That is text that comes out of LLMs: Generic slop.

I feel the same about AI "Art".

Over-polished generic images and logos, that you see more and more on signs in front of shops, the Web, and in presentations at conferences.

Not only do I find them boring, it is also taking work away from actual artists. I thought that computers were around to do the boring monotonous work?

This cartoon, by Tjeerd Royaards, nails it on the head.

Unlike AI companies slurping up all content on the Internet, I asked the author for permission to include this into my presentation.

He said . — "I don't allow the free use of my work, as I depend on my drawing to make a living"

So I went and purchased a digital license.

And this makes perfect sense.

Quality content created by artists, authors, and software professionals is worth something important. And these creators need to be rewarded for their creative work.

Unlike the AI slop generators, I value : Writing, photos, images, and source code.

derickrethans.nl

Derick Rethans' Blog @blog@social.derickrethans.nl

· 4mo ago

Humans in the LLM Loop Original Post In the last few weeks, I have been working through some bug reports for Xdebug, that resulted in the Xdebug 3.5.3 release. These bug reports did not come solely from humans, but rather from a mix of humans using LLM assistant tools, focussing on security related problems, from two different sources and methodologies. Although all of these issues where indeed bugs that I now have fixed, I don't think any of them can be classified even as having a low security impact. But there was a whole host of other issues with these reports. The reports themselves can be unnaturally verbose — and also fairly alarmist using terms like "victim" and "attacker". The tests that were present in the reports were often minimal, and sometimes incomplete, and so were some of their suggested fixes. The humans forwarding the reports took care not to flood the issue tracker with reports out of the blue, and reached out to me first. They've also been helpful discussing the reported issues. The first four cases were reported by Ilia Alshanetsky, a long time, and recently returned, contributor to PHP. The first report, #2421, deals with sending wrong option characters with commands through the DBGp protocol, that an IDE and Xdebug use to communicate. Xdebug would allocate an array for 27 of these, representing the 26 lower case letters of the Latin alphabet, and the - character. What Xdebug did not do is to make sure the option letters were indeed in the range [a-z-], and would happily accept -@ or -\x00. This makes it possible to overwrite locations in memory. The suggested patch was fine, but the test that went with it was very hard to read. It didn't use already exiting framework for testing the step debugger either — I had to add my own. I also believe that this issue could as easily have been found by a fuzzer, which I added now as well. The fuzzer found the same problem in about five seconds, and luckily, nothing else either. The second issue, #2422 complained that there was no limit in the debugger's code that reads commands from the network. The patch was mostly fine, but the test was wholly cumbersome again — it didn't use the already existing testing framework either. It also picked a funnily large (arbitrary) limit of 64MB for DBGp commands, where 64KB would easily suffice — in most cases, 256 bytes would have been fine. The third issue, #2423, argues that Xdebug shouldn't follow symlinks when creating profiling or trace files. The patch was OK and trivial, but the test was again very hard to read making it hard to figure out what it as trying to do. It also did not make use of some existing helpers to skip tests. It came up with: --SKIPIF-- <?php if (PHP_OS_FAMILY === 'Windows') die('skip: Linux-only symlink semantics'); ?> Instead of what is used everywhere else: --SKIPIF-- <?php require __DIR__ . '/../utils.inc'; check_reqs('!win'); ?> The fourth and last issue through Ilia, #2424, deals with Xdebug's Control Socket functionality, where its parser would not handle empty or large command packets correctly. The LLM proposed patch fixed the symptoms, but not the actual cause of this issue. The second set of reports were shared with me in a private gist by Volker, as part of the PHP Foundation's Ecosystem Security Team effort. The first one was a duplicate of bug #2421. The test focussed on the Control Socket functionality instead of the Step Debugger, but the underlying issue and fix were the same. The second issue I added as bug #2433. When you enable xdebug.collect_assignments with tracing, Xdebug needs to re-create the variable name from several opcodes in order to show this name in a readable way. But the issue is not a real time problem, insofar this can only happen if you run PHP code on the command line through the -r option, xdebug.start_with_request is yes. For some reason, when PHP runs code through -r, the CLI binary does not generate EXT_STMT opcodes (Xdebug uses these for breaking during step-debugging), which would otherwise prevent the out-of-bound memory read from happening. The LLM tool also hadn't realised that the third argument to the function responsible for reassembling the variable name was always NULL, and hence superfluous. I addressed these both through the same commit, and added a test, which would not exhibit the problem in most situations either. It is still good to have the expected outcome documented. Another report resulted in two issues in Xdebug's tracker. #2427 addresses an incorrect memory read if the xdebug.file_link_format setting ends with a lone %, and #2429, a similar report, but then for xdebug.trace_output_name. Although the report mentioned three locations, the accompanying test only covered one of three situations where this was a problem: for trace file names, but not formatting link files through xdebug.file_link_format, nor profiling files. The patch it suggested was also wrong, as it would remove the trailing % instead of keeping it. One of three locations where the trailing % was not handled, was internal only, and hence couldn't be triggered by making configuration errors. The test that came with this report did not help me trying to show the problem. It relied on AddressSanitizer to show any problems, but I could not get that to happen. All the tests through this tool also provided tests that tested that the was present, and not what the correct result ought to be. Luckily, using the Xdebug test suite with the valgrind tool showed the problem. A further report, #2430 showed a problem if either an IDE through the step debugging protocol, or a developer directly, would request the contents of a "variable" named :::. The step debugger uses :: to indicate "all the static variables for this class", and following that up with a : isn't valid. The fix was good, but I couldn't directly use the test case, as it tested for the broken behaviour. The test was fairly trivial to write as the reproduce case in the reported test case was correct. And the last issue from the second list, #2431, again reinvented its own way for doing DBGp tests, and also tested that the behaviour was wrong, instead of a test to show that it now works. Even with the code fixed, the new correct test would also surface another issue, as it would have resulted in Xdebug to open a directory as it was a file, and then fail. : Although the LLM tools did find bugs, they were not particularly groundbreaking. Some of the bugs would also have been found by fuzzing, and used a lot less resources in that process. Most of the crashes and potential security issues would only be a problem if an attacker didn't already have access to the machine that the code runs on itself, or have an IDE talking to Xdebug already. If you have access to the machine, you can do worse without these bugs present. If you have client access to Xdebug through DBGp, you would have all the functionality that PHP provides, including reading all files on the file system and running code. The generated test cases were generally hard to read, or incomplete. The patches that the models came up with were not always comprehensive, or correct. I also spent too much time getting AddressSanitizer to do anything, unsuccessfully. I think I would have been as quick writing these patches and actual test cases myself, when provided with the issues' causes and the reasoning that was provided. I don't think I'll be spending time trying to get these tools to work myself, but in the right hands with people that know what they're doing, they can find issues that needs to be addressed. But the value comes from the humans interpreting their results.