𞋴𝛂𝛋𝛆

I think the distributed model used is in the venv under google/ai/. There appear to be json files in the googleapiclient repo that may contain the instructions used by the distributed model. I thought this was odd but likely just google crap in the json files related to telemetry. When I put this google repo on another drive entirely and disconnected it, there was a long list of warnings in ComfyUI that popped up about these when starting the server. Some of them are different than the rest. Some appear to be related only to the google online API, but some pages are more locally oriented.

If you search the sqlite3 database for ComfyUI using sqlite3 comfyui.db ".dump" and look at the entries at the bottom, these fields are what I searched for elsewhere. They somehow lead me to the google packaged stuff IIRC. These in turn lead to the locations mentioned previously and others within ComfyUI. I do not have an overview perspective to fully connect these dots. IIRC, there was a chain of obfuscation related to writing content to these entries in the database.

I also locked down Python, and boltctl in /usr/bin, and locked down /usr/libexec/uresourced to root. That seems to have altered behavior.

It appears that my modeling of a road bicycle shifter is a shape close enough to a gun to also trigger the same mechanism from FreeCAD where there was a similar x-pypi package sent with archive.

In the google api repo, there are tools for gcode and pretty much every other language or system.

I still have three processes on my system with no labels that appear to be related to the three archives, but I have no idea how to kill them. Nothing I have tried has worked. They appear to be connected to systemd-userdbd, but I have no way to know this is true. They are just three processes without labels that appear to only show up because of the SELinux context. Every other command claims they do not exist at the pid. They only show up with ps -eZ.

Lol. Good luck buddy.

The safety_checker.py package under the venv/lib/python3.xx/site-packages/diffusers/pipelines/stable_diffusion/ directory is where the actual image check for content is made.

The distributed model running in the background is setup in venv/…/accelerate/utils/fsdp_utils.py.

The ghost tty is in …/cachetools/func.py

Start searching for these same connecting packages in home, and watch how stuff starts lighting up in flatpaks…

I wish it was. ComfyUI is shit. My external firewall and dns logs picked up some dubious shit. Tracking it down, there are parts and pieces in many places.

I do not know the full scope.

I do not want to talk about what I have been able to figure out in models because it may have broader implications and I am honestly not sure of all the factors involved yet, like the vae, what exactly is on the second layer that is not in the vocab, and the role of Bert in the transformers package. That is what I am working on in the stable diffusion side. While testing the rewards system, I triggered some background system to package and try to send a sqlite3 database. I am tracking down the components of that system. The processes are unlabeled. The tty is manually created in Python. The agent is this weird distributed model. It is following instructions like an agent where the prompts are in a google package in the Python venv. The actual prompts are in json files. The parts of this system are intermixed with other packages and code. There is also a bunch of functionality that appears to be embedded into the ComfyUI JavaScript. There are also parts of this system that are not activated yet but will check UV hashes. The way the database is sent over the network appears to use the same systemd module for the collective user profile system… The same system that will be doing age verification.

Much of my searching for packages and names has been done from my home directory. So I was surprised to see the same reporting type database pop up with FreeCAD, and many packages also in flatpak containers. When I see the mechanisms used, it seems stupid obvious how many vectors involved should not be open by default on the host. Like why in the fuck should the kernel default pass no label packets and have access to namespaces outside of any reporting or logs. I was only able to find several components by looking at SELinux contexts. Anyone without SELinux enabled will never see the stuff.

BTW, why the fucking attitude and disrespect?

If I see it again today I will try to reply again but use separate devices for here and ws. I’m air gapped on WS, tracking down the malware that is ComfyUI. See other comment for a few more basics. Don’t trust pip or especially UV. Read the source for everything you have from Python. Look for host OS escalation and obfuscation of stuff like namespaces, processes, and additional tty’s. The dictionaries for Python under collections.abc are hashed for nefarious reasons. That is one way they determine if your stuff is bad think.

From what I have seen, I want to be on a European Gentoo at this point, maybe even LFS.

Looks like AI stuff is also maybe creeping into age/id stuff.

I’m super concerned because there is a bunch of Python fedora uses throughout.

FreeCAD also has it now. Rather, has it in the flatpak.

I am air gapped at the moment tracking down the garbage dump I stupidly failed to verify. As I grep find and locate those packages, I keep seeing problems crossing over into flatpak containers. Things like the default kernel setting passing no label packets, the level of access for host installed Python, noaccount, changing /proc, and allowing a process to escape namespaces is sus to me. This garbage allows Python to create a hidden tty, and hidden connections to TOR. That is straight up malware IMO.

The hashing of Collections.abc and how UV works is death to open source.

Meanwhile Fedora shipping face recognition.

Anyone else noticing python is a problem?

The main problem is when following instructions for command line tools. They might figure out how to use dnf instead of apt, but the extra layers required for ostree are not very friendly. There are a ton of potential frustrations in this area, especially with GPU stuff or hobbyist hardware like Arduino where kernel stuff is needed in userland. At least as of nearly 3 years ago, the documentation in this area sucks. I was on Silverblue for a few years and managed to get through the frustrations due to intermediate experience level. I found toolbox useless compared to distrobox. But using this with something like Arduino was annoying at best. The needed dependencies expected by whatever stuff I wanted to install was usually a big mystery with near useless error failure messages and names of packages and libraries totally unrelated to the package naming in DNF. When updating the base OS, stuff built in these containers is totally useless because I could not update the containers to the new OS image. Playing around with Flash Forth on a microcontroller was even worse. I ended up layering a bunch of stuff on the host because the containers were just not working. When I got an Nvidia machine, I went to Fedora Workstation and have had far fewer issues and frustrations. SB wasn’t bad, but it is a pain to use these if you need kernel level access. Just my $0.02. I was actually on SB for ~2-3 years.