Hello, this email is a notification from the Auto Upgrade Helper that the automatic attempt to upgrade the recipe(s) *lrzsz* to *0.13.1* has Failed (devtool error).
Detailed error information: Running 'devtool upgrade' for recipe lrzsz failed. NOTE: Reconnecting to bitbake server... Loading cache...done. Loaded 0 entries from dependency cache. Parsing recipes...done. Parsing of 959 .bb files complete (0 cached, 959 parsed). 1994 targets, 43 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION = "2.20.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "x86_64-poky-linux" MACHINE = "qemux86-64" SDKMACHINE = "x86_64" DISTRO = "poky" DISTRO_VERSION = "6.1.99+snapshot-b904e11c8c33e2f44d6e36158dc201a84c00895e" TUNE_FEATURES = "m64 x86-64-v3" meta = "tmp-auh-upgrades:b904e11c8c33e2f44d6e36158dc201a84c00895e" meta-yocto-bsp meta-poky = "master:49a2b44583968d321b3195bfd0cb2232dff13950" workspace = "<unknown>:<unknown>" Initialising tasks...NOTE: The /proc/pressure files can't be read. Continuing build without monitoring pressure Sstate summary: Wanted 14 Local 14 Mirrors 0 Missed 0 Current 16 (100% match, 100% complete) done. NOTE: Executing Tasks NOTE: Tasks Summary: Attempted 103 tasks of which 100 didn't need to be rerun and all succeeded. NOTE: Writing buildhistory NOTE: Writing buildhistory took: 2 seconds Loading cache...done. Loaded 0 entries from dependency cache. Parsing recipes...done. Parsing of 960 .bb files complete (0 cached, 960 parsed). 1995 targets, 43 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION = "2.20.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "x86_64-poky-linux" MACHINE = "qemux86-64" SDKMACHINE = "x86_64" DISTRO = "poky" DISTRO_VERSION = "6.1.99+snapshot-b904e11c8c33e2f44d6e36158dc201a84c00895e" TUNE_FEATURES = "m64 x86-64-v3" meta = "tmp-auh-upgrades:b904e11c8c33e2f44d6e36158dc201a84c00895e" meta-yocto-bsp meta-poky = "master:49a2b44583968d321b3195bfd0cb2232dff13950" workspace = "<unknown>:<unknown>" Initialising tasks...NOTE: The /proc/pressure files can't be read. Continuing build without monitoring pressure Sstate summary: Wanted 1 Local 0 Mirrors 0 Missed 1 Current 0 (0% match, 0% complete) done. NOTE: Executing Tasks NOTE: Tasks Summary: Attempted 3 tasks of which 0 didn't need to be rerun and all succeeded. NOTE: Writing buildhistory NOTE: Writing buildhistory took: 2 seconds Adding changed files: 0% | | ETA: --:--:-- Adding changed files: 0% | | ETA: --:--:-- Adding changed files: 54% |################### | ETA: 0:00:00 Adding changed files: 100% |####################################| Time: 0:00:00 INFO: Extracting current version source... INFO: Extracting upgraded version source... INFO: Fetching https://www.ohse.de/uwe/releases/lrzsz-0.13.1.tar.gz... INFO: Rebasing devtool onto d6a3282387ec0dfe07189bce80db3916c1159125 WARNING: Command 'git rebase d6a3282387ec0dfe07189bce80db3916c1159125' failed: Auto-merging Makefile.am CONFLICT (content): Merge conflict in Makefile.am CONFLICT (modify/delete): configure.in deleted in HEAD and modified in 0eb996f (Update autotools infrastructure (including gettext) to modern versions.). Version 0eb996f (Update autotools infrastructure (including gettext) to modern versions.) of configure.in left in tree. CONFLICT (modify/delete): lib/Makefile.am deleted in HEAD and modified in 0eb996f (Update autotools infrastructure (including gettext) to modern versions.). Version 0eb996f (Update autotools infrastructure (including gettext) to modern versions.) of lib/Makefile.am left in tree. Auto-merging po/Makevars CONFLICT (add/add): Merge conflict in po/Makevars CONFLICT (modify/delete): po/de.po deleted in HEAD and modified in 0eb996f (Update autotools infrastructure (including gettext) to modern versions.). Version 0eb996f (Update autotools infrastructure (including gettext) to modern versions.) of po/de.po left in tree. Auto-merging po/lrzsz.pot CONFLICT (content): Merge conflict in po/lrzsz.pot Auto-merging src/Makefile.am CONFLICT (content): Merge conflict in src/Makefile.am Auto-merging src/zglobal.h CONFLICT (content): Merge conflict in src/zglobal.h You will need to resolve conflicts in order to complete the upgrade. INFO: Upgraded source extracted to /srv/pokybuild/yocto-worker/auh/build/build/workspace/sources/lrzsz INFO: New recipe is /srv/pokybuild/yocto-worker/auh/build/build/workspace/recipes/lrzsz/lrzsz_0.13.1.bb INFO: Changelog extracted to /srv/pokybuild/yocto-worker/auh/build/build/workspace/changelogs/lrzsz.txt INFO: Changelog metadata written to /srv/pokybuild/yocto-worker/auh/build/build/workspace/changelogs/lrzsz.json Please review the attached files for further information and build/update failures. Any problem please file a bug at https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Automated%20Update%20Handler Regards, The Upgrade Helper
Version 0.13.1 - October 2026, Uwe Ohse This release only removes the ZMODEM 8th-bit escaping capability, which was recently implemented, and not part of any announced release, after Stephen Hurd alerted me to the fact that the implementation was incompatible with the (proprietary and undocumented) Omen implementation. The incompatibility would have made the session mutually undecodable in both directions. The option's practical benefit (escaping bytes >= 0x80, which keeps bit 7 set and thus cannot cross 7-bit links) is negligible: the historically problematic bytes (XON/XOFF lookalikes) are escaped by default, and transports that act on the remaining high bytes are practically extinct. Thank you, Stephen. Version 0.13.0 - September 2026, Uwe Ohse This release fixes a large number of security issues. Two of the changes warrant an immediate update if you use lrz to receive files from not perfectly trustworthy senders. Security fixes: This was a security bug found by Tristan Madani (Talence Security). Likewise lsz did not correctly check paths in the restricted mode if PUBDIR support was not compiled in. This was a security bug found by Tristan Madani (Talence Security). Note: this stems from the original public domain rzsz suite (80s). This was a security bug found by Tristan Madani (Talence Security). Note: this stems from the original public domain rzsz suite (80s). Note: this stems from the original public domain rzsz suite (80s). Note: this stems from the original public domain rzsz suite (80s). Note: this stems from the original public domain rzsz suite (80s). Security related changes: Note: this stems from the original public domain rzsz suite (80s). Other changes: Note: lrzsz's 31-bit file-size limit stems from the original public domain rzsz suite (80s). The same limit existed in later published omen technology sources, and at least one independent implementation. Expect interoperability problems when transferring files of that size. I'm willing to work with translators, not only to include translations, but also to make your job easier - but I am not going to burden myself with doing translations. Fun fact: the same implementations leading the performance score on a 115200 bps line with a 20ms delay are the ones losing on the 1mbit line with 250ms delay line. The package refused to die. CVS-2018-10195 came, and i wondered for a while why nothing worse had been detected. But then i decided that lrzsz is not my problem anymore. It had to be the problem of someone else. Then Tristan contacted me on 2026-07-27, which was 8 days after i did a major screwup at https://naturfotografen-forum.de by updating the production system to a software version which should been tested and debugged for at least 2 or 3 additional weeks, and which contained one feature which made a rollback infeasible. I saw his mail, and thought 'Uh, uh… this is not a minor thing'. But i had no time, because the forum is more important to me. 14 days later i found the time, and the real fun started. I needed far less time to fix the three vulnerabilities Tristan reported than i needed to fix the autoconf stuff so i could compile the package. Updating the gettext stuff also took hours, and i wasted half an evening trying to update the dejagnu test suite (which i failed at). Then i sat back, looked at the code, decided what compatibility hacks to throw out, and started to clean up the mess. Then i asked qwen (coder next) to block my graphics card for a few days, i mean, i asked the LLM to review the code (the prompt was somewhat longer than that), which on my 4 GB graphics card took a long time. In the meantime i found the old recordxyz tool (a protocol tracer), and even the version 2 of it (a total rewrite which was much worse than the original, which wasn't very good to begin with), took some parts from them, and created zmodemsnif. When that was about ready, i gave up on the local qwen. It had produced some interesting findings, but my machine is too slow for that. I used a cloud kimi-k2.6 to do a review, and later used glm-5.2, kimi-k3, some qwen and glm-5.3-flash for the same. For all you LLM haters or sceptics: i get it. I hate these LLM companies with a passion. These people steal in the internet (and from my own server, too), and give nothing back, beyond nebulous claims and lies and server overloads. They spend billions to improve LLMs, which should be spend to improve people and society. The list of reasonable complaints is long. I get all that. But i've run out of people i can work with. The only programmer whom i could have relied on reviewing my code, and any changes, in time has died a few years ago (and i would have had to pay for by reviewing his code, which is something i tried to avoid, because his stuff was really complicated - lrzsz is quite simple compared to that). And i absolutely _needed_ some kind of review. I was out of practise with C and the toolchain, and given the sorry state of the C language (why, oh why, isn't '-Wturn-on-all -Werror' the default?) it would have been irresponsible to not use an LLM for that. This kind of review is something LLMs are good at, and they found more than a few security issues in the code (i also found some, but not that many), and quite a few bugs. The core code, any code in the installed programs, is 100% human written (i'm lazy and hate commenting, and copied some LLM generated comments, but no code). The code of the programs not installed by default (which are not very useful for anyone but the maintainer) is partially or mostly human written: - zmodemsniff.c is about 75% human written (maybe more, i don't care). - linesimulator.c is about 50% human written. [this tool is for the test suite, and simulates different line types with different error modes] - zmodemfuzz.c is about 15% human written, maybe a bit less. The reason the later has been written mostly by the LLMs is that i'm not feeling able to think as attacker and defender at the same time. Maybe i could - but i would never bet on it. I also would never bet on the fuzzer being able to detect all possible holes, but it did help me to fix many border cases. If you don't want to use lrzsz because of the LLM usage, you don't have to. I understand that. Maybe you can backport the security fixes to lrzsz-0.12.21rc - but i will not do that. This release did cost about 6 weeks of my spare time, including some extra time during my vacation. In addition i spent a few days rewriting the ZMODEM specification. If you feel that i should not have spent that much time on this old package: you are not alone. If you feel you should pay something for this: please consider donating to some international help organization, for example Amnesty International, International Red Cross and Red Crescent Movement, Médecins Sans Frontières (Doctors Without Borders) or UNICEF. Version 0.12.21rc - August 1999, Uwe Ohse
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#247208): https://lists.openembedded.org/g/openembedded-core/message/247208 Mute This Topic: https://lists.openembedded.org/mt/121586904/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
