alist: reintroduce package

[okatu-loli]

AList was previously available in OpenWrt packages and was later replaced by
OpenList. However, AList is still actively maintained upstream.

AList and OpenList are now separately maintained projects. They have different
feature sets, release lines, and upstream maintainers. Therefore OpenList
should not be treated as a direct replacement for AList.

This PR restores AList as an independent package in OpenWrt packages.

I am the current maintainer of AList and am willing to help maintain this
package.

Tested:

• Built with OpenWrt SDK: snapshot, x86/64, gcc-14.3.0_musl
• Target: x86/64
• Command: make package/alist/{clean,compile} V=s
• Result: success
• Output: bin/packages/x86_64/packages/alist-3.60.0-r1.apk
• Runtime verification: package installed and started in OpenWrt VM; http://127.0.0.1:5244/ served AList frontend

[GeorgeSapkin]

Are the reasons for removal addressed?

• openlist: move from alist and update to 4.0.5 #26855

New contributors are expected to use a real name and not an alias as per the contributing guidelines.

[okatu-loli]

1. The removal reason from openlist: move from alist and update to 4.0.5 #26855 (openlist: move from alist and update to 4.0.5 #26855) has been addressed.

   That PR treated OpenList as a replacement for AList and added PROVIDES:=alist, but that assumption no longer holds. AList and OpenList are now maintained as separate projects. In addition, the previously private auth/API component has already been open-sourced as AlistGo/auth (https://github.com/AlistGo/auth), so it can be deployed independently.

   AList is also still actively maintained upstream, for example: v3.60.0 (https://github.com/AlistGo/alist/releases/tag/v3.60.0).

2. The formatting issue has also been fixed.

   I have updated both the commit author and the Signed-off-by line to use my real name and email:

   YUXIAO FAN <CN_QianShi@hotmail.com>

[efahl]

Seems to me that the package description itself should reference the reason that the alist package was dropped, namely the telemetry issues, so that people are warned up front about the controversy surrounding this package. If a package is in the OpenWrt feeds, it is implicitly approved by OpenWrt and anything with a history of privacy concerns should make note of that directly in the package, not through a deep dive into the commit history.

[okatu-loli]

Seems to me that the package description itself should reference the reason that the alist package was dropped, namely the telemetry issues, so that people are warned up front about the controversy surrounding this package. If a package is in the OpenWrt feeds, it is implicitly approved by OpenWrt and anything with a history of privacy concerns should make note of that directly in the package, not through a deep dive into the commit history.

I understand the concern, and I agree that the previous change was related to trust and governance concerns around the upstream project at that time.

However, I would prefer not to describe AList itself in the package description as having “telemetry issues,” unless there is a concrete and current reference to a specific release, issue, commit, or code path. A general warning may unintentionally damage the reputation of the project, especially now that AList and OpenList are maintained separately and the auth/API component has been open-sourced as AlistGo/auth.

I think it is better to keep the package description neutral and focused on what the package does. If there are still specific privacy or telemetry concerns, I am happy to address them separately with factual references.

[okatu-loli]

I would like to add one more clarification regarding the “telemetry” concern.

As far as I understand, AList itself did not have telemetry code merged into the main tree. Even the previous removal PR stated that the AList code up to v3.45.0 had been reviewed as “clean”, and that the attempted runtime-information collection code was not merged:

• openlist: move from alist and update to 4.0.5 #26855

The main concern mentioned there was the private API used for connecting to some cloud drives. My understanding is that this was not general telemetry in the AList package itself, but an API/token helper required by some storage providers where developer credentials or OAuth/token exchange are needed.

AList currently provides such token tools here:

• https://alistgo.com/tool/

The related auth/API implementation has also been open-sourced:

• https://github.com/AlistGo/auth

OpenList has a similar token/API helper as well:

• https://api.oplist.org/
• https://github.com/OpenListTeam/OpenList-APIPages

The OpenList API pages are described as a token generator / API pages for obtaining cloud-drive API access for OpenList, and they also support using OpenList-provided parameters.

So if the package description for AList needs to include a warning about this kind of token/auth API helper, I think the same standard should also apply to OpenList. Otherwise it would be unfair to describe only AList in that way, especially when both projects now have open-sourced their corresponding API/token helper implementations.

I do not want to hide any real privacy or security concern. If there is a concrete, current telemetry/privacy issue in a specific AList release, I am happy to address it with a factual reference to the relevant upstream issue, commit, or code path. But without such a current reference, I think adding a general “telemetry issues” warning only to the AList package description would be misleading and may unfairly damage the reputation of the project.

[SheltonZhu]

Seems to me that the package description itself should reference the reason that the alist package was dropped, namely the telemetry issues, so that people are warned up front about the controversy surrounding this package. If a package is in the OpenWrt feeds, it is implicitly approved by OpenWrt and anything with a history of privacy concerns should make note of that directly in the package, not through a deep dive into the commit history.

⚠️ USER PRIVACY RISK WARNING ⚠️

I strongly oppose reintroducing AList into OpenWrt packages without a very explicit warning to users.

This is not just a technical packaging issue. It is fundamentally a trust, governance, and transparency issue.

The upstream project has already discussed community-edition hardware information collection in public planning documents:
AlistGo/alist#9142

That issue explicitly mentions collecting hardware-related information such as CPU, GPU, memory, operating system, storage type/capacity, etc. Even if upstream claims anonymization or consent mechanisms, this is highly relevant for OpenWrt users because routers and NAS systems operate in sensitive environments.

In addition, the upstream governance model appears highly centralized:

• merge authority is concentrated in a very small group
• recent development activity is dominated by the same maintainer(s)
• the visible “code review” process mostly consists of approvals from closely affiliated contributors rather than clearly independent review

The linked discussions also contain a large number of removed/deleted comments, which makes it difficult for downstream users and packagers to audit the actual community concerns and historical discussions around privacy and governance issues.

For transparency, I also want to disclose that I was previously a contributor to the AList project.

I raised concerns and strongly objected to the direction around privacy/trust issues. After that, I was blocked/banned from the community communication channels by the project owner.

I understand maintainers have the right to moderate communities. However, from a downstream packaging and trust perspective, this further reinforces concerns about governance transparency and how dissenting opinions are handled within the project.

Open source licensing alone does not automatically provide meaningful community governance or independent oversight.

For OpenWrt specifically, upstream self-review should not be treated as a sufficient trust signal for a package that:

• runs continuously on routers/NAS devices
• may access local storage and cloud credentials
• has existing privacy controversy/history
• operates under concentrated project governance

At minimum, the package description should contain a very clear warning about:

• prior privacy/telemetry concerns
• the upstream hardware information collection discussion
• the lack of clearly independent governance/review

Without that, including this package in official feeds risks creating an implicit trust endorsement that many users may not fully understand.

[okatu-loli]

@SheltonZhu Thanks for raising this in detail.

I agree that privacy and trust concerns are especially important for OpenWrt users, because this type of package may run continuously on routers or NAS devices and may handle local files or cloud-drive credentials.

However, I think we need to separate three different things here:

1. historical concerns around the upstream project;
2. upstream planning/discussion documents, such as Alist 网盘商业计划书 AlistGo/alist#9142;
3. the actual code and default behavior of the specific AList release being packaged here.

AlistGo/alist#9142 is clearly relevant background, and it does mention possible hardware information collection for the community edition. But from what I can see, that is a planning/discussion issue, not by itself evidence that the current OpenWrt package contains telemetry code or sends hardware information by default.

I do not object to documenting the history or adding a neutral note for users. What I object to is putting a strong “privacy risk warning” in the package description unless it is tied to a concrete current code path, commit, release, or default runtime behavior in the packaged version.

For example, I would be open to adding neutral wording such as:

“Users should be aware that the upstream AList project has had prior privacy/trust discussions, including discussion of possible hardware information collection. Please review upstream privacy and security discussions before deploying in sensitive environments.”

That would inform users without making an unsupported claim that the current package itself contains active telemetry.

If there is current telemetry or hardware-information collection code in the release packaged by this PR, please point me to the specific commit, source file, or runtime behavior. I will either patch it, disable it, or add a stronger warning based on that factual reference.

[SheltonZhu]

Thanks for the clarification.

I agree that planning/discussion documents are different from proven active telemetry code in a specific release. My concern is broader than only “does the current binary send telemetry by default”.

For OpenWrt users, especially router/NAS users, trust and governance posture are themselves highly relevant risk factors.

I appreciate that you are open to adding neutral wording. Personally, I think that is the minimum necessary compromise here.

What I want to avoid is a situation where inclusion in official OpenWrt feeds is interpreted by users as a full implicit trust endorsement, while the project has:

• prior privacy/trust controversy,
• documented discussion of hardware information collection,
• centralized governance/review structure,
• and ongoing debate around transparency.

A neutral but explicit note in the package description would allow users to make informed decisions without asserting unsupported claims about the current release.

Given that packages in the official OpenWrt feeds carry an implicit level of downstream trust, I think OpenWrt should require this disclosure before accepting the package.

[okatu-loli]

@SheltonZhu Thanks for the clarification.

I understand that your concern is broader than whether the currently packaged release sends telemetry by default. It also includes the broader trust, governance, moderation, and transparency context around deploying this kind of software on routers, NAS devices, and other sensitive environments.

I have added a user-facing disclosure to the package description to make these concerns visible before inclusion. The added text asks users to review upstream privacy, security, and governance discussions, including prior discussion of possible hardware information collection, centralized governance or moderation concerns, and ongoing transparency debates. It also clarifies that inclusion in the OpenWrt package feeds should not be interpreted as a full endorsement of the upstream project's trust or governance posture.

At the same time, the wording intentionally avoids asserting that the currently packaged AList release contains active telemetry or performs hardware-information collection by default, since no specific current code path, commit, source file, or runtime behavior has been identified in this PR.

I hope this addresses the disclosure concern while keeping the package description factual and fair to the current packaged release.

[efahl]

That sounds good to me. Probably should all be squashed into a single commit.

[okatu-loli]

@efahl You’re right, thanks. I squashed the PR into a single commit and force-pushed the branch.

Current commit:

fa0d7b6 alist: reintroduce package