Policy on packages containing AI-powered features

Project Discussion
, ,
1

I recently reviewed the source code and page of a package that I have been using for a few years now, Atuin. Unsurprised, I saw a new feature that was not there before: “AI as part of your terminal”. Knows your shell history, has access to your data, ask it anything etc.

I currently am at version Atuin v18.12.1 and the AI feature seems to have been introduced in v18.13.0 - coming at the next version update. That got me thinking, had it not been for a coincidental check, I could have easily gotten LLMs or “AI-powered” features installed without even knowing it just by regular system updates.

For some individuals and cases that might be fine, but for others such AI feature creep running rampant everywhere opens an entire can of data privacy and security worms. Not referring specifically to the Atuin AI feature, speaking in general here, but were I to update to the latest version from the Fedora repository I certainly wouldn’t have given any conscious approval to an AI accessing my data, I possibly wouldn’t know which local or non-local model is used by default, whether it calls somewhere home, or even whether it has been trained in bypassing any firewalls or other networking restrictions that I may have configured. What permissions does it have, running a package as my user can it start deleting my data?

I found the policy on AI-assisted contributions. This is different, it’s about packages that contain AI features. Is there a policy on that? Similar to free versus unfree code/packages? Are there any checks by Fedora packagers when they introduce or update packages? I skimmed through the Package Guidelines and What can be packaged? pages and I didn’t see any relevant sections.

In this specific case, for example, how will the Atuin packager proceed when they update to the next version? Are they going to get into the trouble and compile Atuin with the AI feature disabled? Possible in this case, what if another program does not provide that capability - is it going to be flagged as unsupported and removed from the repository? If not, should users be notified if a package introduces “AI features” so that they can decide whether they want to continue using it, maybe with modifications in system settings or usage patterns, or uninstall it instead? What would this mean for non-technical users that wouldn’t have the capability to configure a more complex setup that defines rules on what “AI features” can access and do and what not?

If I were to find that unchecked “AI features” start popping all over the place in my Fedora systems (and containers as well) without any checks or notifications, that would certainly send me looking for a different Linux distribution.

2 Likes
Monitor Your Drive Health with Performance Co-Pilot on Fedora
4

From the docs Settings - Atuin Docs the default is disabled from the AI features.

As the AI features are optional and disable by default I do not think there is a issue.

5

Hi atuin packager here. That introduction did indeed require more review on the feature to make sure what exactly this does and if it is opt-in or opt-out. I did raise an issue with them on how can this be handled on the distribution side, as I would like to give the user the maximum flexibility for opting in or out of that with as much guard rails as we can. Right now the only proposed approach that they gave is to have the cli binaries for those be independent and installed as sub-packages.

At the very least the AI and hex features will be disabled initially because of the dependency requirement creep. How to enable those features for the users who expect it, I am still not sure, but additional discussion with upstream, and review of the rust code itself is definitely welcome. Atuin docs and discussion with upstream do indeed indicate that these features are opt-in, but to what extent, I am rather ill-equipped to actually review that. At most I could suggest some tests that would verify there is no unexpected external communications.

2 Likes
6

Thank you both.

I did a test installing Atuin via cargo in a container, the AI feature is installed by default (defined at this line) but disabled. It is therefore opt-in, as mentioned, and users can do so the first time they try to use the feature. Then you are asked to login to Atuin Hub i.e. it uses a remote LLM.

Screenshot_20260809_201209
Screenshot_20260809_201209746×224 21.9 KB

The fact that this was already on your radar as a packager gives me more confidence. However, the point of this post was not just the specific case, but in general. If there is no official guideline on this, what would another maintainer do with another package that has AI features enabled by default?

I looked around a bit on other forums as well, and I don’t think that Linux distributions are well-prepared for the AI feature creep. Most responses to people’s questions/concerns are “Linux does not come with any AI installed” meaning that OOTB they don’t install anything (as opposed to Windows, for example), and then “You have the freedom to install/uninstall anything that you want”. But that’s exposing a gap here, to be looking for the documentation or source code to know whether there’s AI features is quite beyond the ability of the non-technical or even technical users, for all packages and their dependencies.

Would it be a good idea to have a flag/label for packages that have AI features? Same way that Flatpaks on their web UI list features/risks. Then at least users are notified and they can review further.

Screenshot_20260809_210713
Screenshot_20260809_210713414×539 33 KB

Maybe that would be for a package manager like Discover, but then I do updates from the CLI so I’d love for dnf to let me know if a package all of the sudden introduces AI features.

Personally I could go as far as having AI-enabled packages on a separate repository that the user would have to enable.

7

I think that AI features should be disabled by default, and that the idea of having sub-packages / weak dependencies would be a good way to separate these properties reliably.

8

I found this topic, AI policy in Fedora - WIP but it seems like it has been stalled for almost a year now. As far as I can tell it is WIP policy for in general AI contributions. Maybe it worth reviving that topic. One of the suggestions in that topic is to make sure that AI features are disabled by default (although, it looks like it’s related to Fedora itself, not 3d party packages that users can install).

As a user I would be happy if someone can protect my operating system from AI creep-in but at the same time I imagine it’s practically impossible to enforce packagers to police every package or its update for AI features. It sounds more practical to me if users do it themselves and install/uninstall packages depending on their attitude towards a particular project.

1 Like
9

That works if the code is structured in a modular way that can be packaged accordingly. That may not be all programs.

It’s certainly tricky at best. Fedora does have policy for free vs unfree software that applies to all packages. The non-deterministic nature of the algorithms known as AI (that is, you can’t read the code and know what it is going to do), together with data access and internet access, is such an explosive combination that deserves special attention.

10

This should apply to ALL fedora (except summarys on the fourms as it’s useful). FOSS should stay free of “slop code”. Slop code as in “AI-generated apps”. But they should be still able to be on COPR for devs that need AI as they are a beginner.

Thanks!

11

You are conflating AI support in an app with vibe coding.
Please stay on topic.

1 Like