Please try again, I changed something about how files are served...
1 Like
Behaves as expected now, downloads nicely.
Thank you
1 Like
Is there a confidence that it was not a supply chain attack/other security incident where attackers would incorporate malicious code in compiler or the packages themselves?
They deal with that everyday.
Occasionally there are posts showing what they are doing and how how much negative traffic they are affecting.
If they were being attacked they would, simply, tell us.
Feel free to read every line yourself.
Yes there is. If it was a security issue it would've been taken offline.
This project take user security seriously.
1 Like
This is not a good response to the genuine question. Not professional at least.
Checksum mismatches is quite a good flag that something might be hacked and replaced. That's why I'm asking if proper analysis for this has been done. OpenWRT is very good target for attackers to plug backdoors/etc, and that's why it is important.
@psherman could you advise if there is a chance this has been a result of malicious activity?
I saw it could read snarky but how else to say it is open source without insulting you?
Every file package has a checksum.
You cannot, just, edit your post after it has been replied to, to reply back.
It is not malicious activity. This is purely an issue with the demands placed on the image builder in light of resource limitations (i.e. CPU, RAM, disk), caching, and things getting out of sync. See this earlier post about it by the author/maintiner of the sysupgrade system.
For what its worth, there was a recent advisory about a security issue with the ASU server (disclosed and discussed here). In that case, the system was immediately taken offline when the problem was discovered, and it was not returned to service until it was corrected.
The OpenWrt project and its developers are transparent about security issues because they take security seriously and they want everyone to be properly informed and protected. When security vulnerabilities are discovered in general, those that might affect OpenWrt are raised in the "Release and security announcements" section of the forum. There are four typical recommendations, depending on the specifics of any CVE:
- Does not affect OpenWrt because < insert specific reasons >; do not worry about it
- The vulnerability has been (or will be) addressed in the next maintenance release of OpenWrt, please upgrade accordingly.
- An update is not immediately available, but you can mitigate the risks by < insert specific procedure >
- Please upgrade this specific package (or set of packages) to obtain the latest security patches.
When you mention supply chain attacks in OpenSource software, there are obviously lots of potential entry points for this, but OpenWrt is not unique here -- basically all Linux based operating systems/firmware would potentially be vulnerable to these attacks. So, it is not really possible to guarantee that there isn't some random upstream supply chain attack that has yet to be discovered by the open source community.... if/when such a vulnerability is detected, it will likely affect a whole swath of operating systems (think Ubuntu, Debian, RedHat, etc....) and/or service providers. Such issues may or may not actually affect OpenWrt, but upon discovery, they would be addressed rapidly.
What we can guarantee is that the recent image generation issues (Feb 2025) is not related to a supply chain attack.
4 Likes
Seems much snappier with new squid conf. 
Lets wait another 24h to draw conclusions.
2 Likes
Thank you very much for your extremely clear and professional answer to my question/concern, I really appreciate it!
And I'm also infinitely grateful for all the work you are doing not only on the OpenWRT itself, but on the security of the related systems.
Thank you!
You're welcome. But most of the thanks really should be credited towards the amazing developer team -- a group of volunteers who devote an unbelievable amount of time and energy to the project!
3 Likes
Coming here via: https://github.com/openwrt/asu/issues/1232
I'm getting Server response: Unsupported target: ipq807x/generic when requesting a new image via attended sysupgrade. This is the Request Data:
{
"url": "https://sysupgrade.openwrt.org",
"revision": "r24106-10cc5fcd00",
"advanced_mode": "1",
"sha256_unsigned": "",
"branch": "23.05",
"efi": null,
"profile": "xiaomi,ax3600",
"target": "ipq807x/generic",
"version": "24.10.0",
"packages": [
"ath10k-firmware-qca9887-ct",
"ath11k-firmware-ipq8074",
"auc",
"base-files",
"busybox",
"ca-bundle",
"dnsmasq",
"dropbear",
"e2fsprogs",
"firewall4",
"fstools",
"ipq-wifi-xiaomi_ax3600",
"kernel",
"kmod-ath10k-ct-smallbuffers",
"kmod-ath11k-ahb",
"kmod-fs-ext4",
"kmod-gpio-button-hotplug",
"kmod-leds-gpio",
"kmod-nft-offload",
"kmod-phy-aquantia",
"kmod-qca-nss-dp",
"kmod-usb-dwc3",
"kmod-usb-dwc3-qcom",
"kmod-usb3",
"libc",
"libgcc",
"libustream-mbedtls",
"logd",
"losetup",
"luci",
"luci-app-attendedsysupgrade",
"luci-ssl",
"mtd",
"netifd",
"nftables-json",
"odhcp6c",
"odhcpd-ipv6only",
"opkg",
"ppp",
"ppp-mod-pppoe",
"procd",
"procd-seccomp",
"procd-ujail",
"uboot-envtools",
"uci",
"uclient-fetch",
"urandom-seed",
"urngd",
"wpad-basic-mbedtls"
],
"diff_packages": true,
"filesystem": "squashfs",
"client": "luci/git-23.339.51123-138595a"
}
hi im trying to update a gl.inet mt6000 via asu, but it reports no firmware upgrade available, is it ok to post here or should post elsewhere ?
The target was renamed to qualcommax/ipq807x, so the ASU clients won't work on that device. Your best bet is to use https://firmware-selector.openwrt.org/?version=24.10.0&target=qualcommax%2Fipq807x&id=xiaomi_ax3600 and build a new image there. Subsequent upgrades will work with the ASU clients, once you've made the jump.
Do you have "Advanced Mode" enabled in ASU's configuration tab? If not, that's usually the issue.
thanks so much !! that was it 
2 Likes
Oh, so I need to go the full manual upgrade procedure as described here?
https://openwrt.org/docs/guide-user/installation/generic.sysupgrade
edit: sysupgrade via luci worked just fine, thanks for the kind info! 
1 Like
I'm using auc to upgrade my R7800 (currently OpenWrt 23.05.5 r24106) with the command auc -b 24.10
But I get the message: Bad message (74)
How do I fix this?
Try web version in advanced mode?