An opensource OpenWrt variant for mainland China users.

Go to file

John Audia f8f56aa8c2 openssl: bump to 1.1.1t Removed upstreamed patch: 010-padlock.patch Changes between 1.1.1s and 1.1.1t [7 Feb 2023] ) Fixed X.400 address type confusion in X.509 GeneralName. There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but subsequently interpreted by GENERAL_NAME_cmp as an ASN1_TYPE. This vulnerability may allow an attacker who can provide a certificate chain and CRL (neither of which need have a valid signature) to pass arbitrary pointers to a memcmp call, creating a possible read primitive, subject to some constraints. Refer to the advisory for more information. Thanks to David Benjamin for discovering this issue. (CVE-2023-0286) This issue has been fixed by changing the public header file definition of GENERAL_NAME so that x400Address reflects the implementation. It was not possible for any existing application to successfully use the existing definition; however, if any application references the x400Address field (e.g. in dead code), note that the type of this field has changed. There is no ABI change. [Hugo Landau] ) Fixed Use-after-free following BIO_new_NDEF. The public API function BIO_new_NDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by end user applications. The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the caller. Under certain conditions, for example if a CMS recipient public key is invalid, the new filter BIO is freed and the function returns a NULL result indicating a failure. However, in this case, the BIO chain is not properly cleaned up and the BIO passed by the caller still retains internal pointers to the previously freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO then a use-after-free will occur. This will most likely result in a crash. (CVE-2023-0215) [Viktor Dukhovni, Matt Caswell] ) Fixed Double free after calling PEM_read_bio_ex. The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload data. If the function succeeds then the "name_out", "header" and "data" arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case PEM_read_bio_ex() will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. The functions PEM_read_bio() and PEM_read() are simple wrappers around PEM_read_bio_ex() and therefore these functions are also directly affected. These functions are also called indirectly by a number of other OpenSSL functions including PEM_X509_INFO_read_bio_ex() and SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL internal uses of these functions are not vulnerable because the caller does not free the header argument if PEM_read_bio_ex() returns a failure code. (CVE-2022-4450) [Kurt Roeckx, Matt Caswell] ) Fixed Timing Oracle in RSA Decryption. A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. (CVE-2022-4304) [Dmitry Belyavsky, Hubert Kario] Signed-off-by: John Audia <therealgraysky@proton.me> Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>		2023-02-12 04:55:07 +08:00
.github/ISSUE_TEMPLATE	github: add command for device	2023-01-07 16:43:48 +08:00
config	Merge Official Source	2022-12-08 01:34:49 +08:00
include	kernel: bump 5.4 to 5.4.230	2023-01-28 19:26:47 +01:00
LICENSES	LICENSES: sync with upstream OpenWrt	2023-01-10 15:47:21 +08:00
package	openssl: bump to 1.1.1t	2023-02-12 04:55:07 +08:00
scripts	Merge Official Source	2023-01-14 13:49:55 +08:00
target	Merge Official Source	2023-02-08 23:15:24 +08:00
toolchain	toolchain: Include ./include/fortify for external musl toolchain	2022-12-04 16:07:33 +01:00
tools	Merge Official Source	2022-12-24 09:55:33 +08:00
.gitattributes	add .gitattributes to prevent the git autocrlf option from messing with CRLF/LF in files	2012-05-08 13:30:49 +00:00
.gitignore	gitignore: add .vscode for VS Code users	2021-03-29 22:26:27 +02:00
BSDmakefile	build: use SPDX license tags	2021-02-05 14:54:47 +01:00
Config.in	build: use SPDX license tags	2021-02-05 14:54:47 +01:00
COPYING	license: re-license Project ImmortalWrt under GPL-2.0-only	2022-12-24 10:44:52 +08:00
feeds.conf.default	ImmortalWrt v21.02.2: revert to branch defaults	2022-10-18 13:54:17 +08:00
Makefile	build: don't remove BUILD_LOG_DIR in _clean	2022-12-30 14:33:32 +08:00
README.md	Merge Official Source	2023-01-14 13:49:55 +08:00
rules.mk	Merge Official Source	2022-12-06 03:04:32 +08:00

README.md

Project ImmortalWrt

ImmortalWrt is a fork of OpenWrt, with more packages ported, more devices supported, better performance, and special optimizations for mainland China users.
Compared the official one, we allow to use hacks or non-upstreamable patches / modifications to achieve our purpose. Source from anywhere.

Default login address: http://192.168.1.1 or http://immortalwrt.lan, username: root, password: none.

Download

Built firmware images are available for many architectures and come with a package selection to be used as WiFi home router. To quickly find a factory image usable to migrate from a vendor stock firmware to ImmortalWrt, try the Firmware Selector.

ImmortalWrt Firmware Selector

If your device is supported, please follow the Info link to see install instructions or consult the support resources listed below.

Development

To build your own firmware you need a GNU/Linux, BSD or MacOSX system (case sensitive filesystem required). Cygwin is unsupported because of the lack of a case sensitive file system.

Requirements

To build with this project, Ubuntu 20.04 LTS is preferred. And you need use the CPU based on AMD64 architecture, with at least 4GB RAM and 25 GB available disk space. Make sure the Internet is accessible.

The following tools are needed to compile ImmortalWrt, the package names vary between distributions.

Here is an example for Ubuntu users:

Method 1:

Setup dependencies via APT

sudo apt update -y
sudo apt full-upgrade -y
sudo apt install -y ack antlr3 asciidoc autoconf automake autopoint binutils bison build-essential \
  bzip2 ccache clang clangd cmake cpio curl device-tree-compiler ecj fastjar flex gawk gettext gcc-multilib \
  g++-multilib git gperf haveged help2man intltool lib32gcc-s1 libc6-dev-i386 libelf-dev libglib2.0-dev \
  libgmp3-dev libltdl-dev libmpc-dev libmpfr-dev libncurses5-dev libncursesw5 libncursesw5-dev libreadline-dev \
  libssl-dev libtool lld lldb lrzsz mkisofs msmtp nano ninja-build p7zip p7zip-full patch pkgconf python2.7 \
  python3 python3-pip python3-ply python-docutils qemu-utils re2c rsync scons squashfs-tools subversion swig \
  texinfo uglifyjs upx-ucl unzip vim wget xmlto xxd zlib1g-dev

Method 2:

sudo bash -c 'bash <(curl -s https://build-scripts.immortalwrt.eu.org/init_build_environment.sh)'

Note:

For the for love of god please do not use ROOT user to build your image.
Using CPUs based on other architectures should be fine to compile ImmortalWrt, but more hacks are needed - No warranty at all.
You must not have spaces in PATH or in the work folders on the drive.
If you're using Windows Subsystem for Linux (or WSL), removing Windows folders from PATH is required, please see Build system setup WSL documentation.
Using macOS as the host build OS is not recommended. No warranty at all. You can get tips from Build system setup macOS documentation.
For more details, please see Build system setup documentation.

Quickstart

Run git clone -b <branch> --single-branch https://github.com/immortalwrt/immortalwrt to clone the source code.
Run cd immortalwrt to enter source directory.
Run ./scripts/feeds update -a to obtain all the latest package definitions defined in feeds.conf / feeds.conf.default
Run ./scripts/feeds install -a to install symlinks for all obtained packages into package/feeds/
Run make menuconfig to select your preferred configuration for the toolchain, target system & firmware packages.
Run make to build your firmware. This will download all sources, build the cross-compile toolchain and then cross-compile the GNU/Linux kernel & all chosen applications for your target system.

The main repository uses multiple sub-repositories to manage packages of different categories. All packages are installed via the ImmortalWrt package manager called opkg. If you're looking to develop the web interface or port packages to ImmortalWrt, please find the fitting repository below.

LuCI Web Interface: Modern and modular interface to control the device via a web browser.
ImmortalWrt Packages: Community repository of ported packages.
OpenWrt Routing: Packages specifically focused on (mesh) routing.

Support Information

For a list of supported devices see the OpenWrt Hardware Database

Documentation

Support Community

Support Chat: group @ctcgfw_openwrt_discuss on Telegram.
Support Chat: group #immortalwrt on Matrix.

License

ImmortalWrt is licensed under GPL-2.0-only.