@BlayTation, you are doing fantastic work here. Thanks for all of this information, it’s helping me keep my expectations in check for when I get my A06, and it’ll help me to know what to look out for.
I am still having problems with firefox, and now am having the same problems with palemoon. These things just fail to open. Other things work, these browsers don’t. What caused this I do not know. Sometimes they open, other times they don’t. If anyone could direct me to figuring out how to fix it, or look over this thread to tell me if it’s something I may have done, I would be appreciative. Using lynx is fine, but not nesesarily a daily-driver.
Firefox is hit-or-miss. Working again… I have also discovered that Armbian proper does not offer support for the system (The Armbian-based Clockwork OS) because it is a custom, in-house build of Armbian. I did not realize this, and thought it might be prudent to anlalyze these custom system images as they originate from China. If you have been reading this thread, you will see I already ran rkhunter and did a clamscan on the binary directories. Nothing was found, but since a custom-kernel is being run, this is prudent to check as well.
Checking the /etc/apt/sources.list*/* I see that it is fetching from ClockworkPi’s Github. However, looking at its resource it appears to be firmware. This is easily audited and can be inspected for CCP creeperware. The only other (default) entry was apt.armbian.org.
The kernel is in a prepackaged .deb as expected
But where is the source for this deb file? There is no deb-src directory. I find a Kernel entry in the larger list of repositories by the ClockworkPi team:
All I find in this directory are pre-compiled binaries and a few patchfiles. The directory is labled (per the Readme) “clockworkPI (CPI3) Linux Kernel 4.14.2 Patch”. So this repo is not the kernel, but a patchfile for the kernel it is using. It also has not been comitted to in three years. Dead end. I look through other repos and find no code. In fact, a few of the repos are blank with only a README and a LICENSE file.
I decide to check what the kernel the system is running. uname -srm produces “Linux 5.10.75-sunx164 arch64”. I don’t know what the sunx164 is supposed to mean, so I check the patchfiles to see if it’s labled. I don’t see it. I download the .deb for the latest kernel and run clamscan on it (from my main computer). No infection.
The only web-reference I can find to sunx164 is a userpost from 2014 on the Chinese website Badiu
https://zhidao.baidu.com/question/689126902998431764.html
Searching the entire Github account for ClockworkPi shows nothing.
Finally, I decide to websearch “armbian sunx164” and see it is a custom build from armbian. False-alarm, no problem there. It appears that sunx### is some kind of custom-built kernel for a specialty serial-driver, and there are numerous entries returned (though none by the exact name).
So now, the only issue really is to check the firmware patch files and confirm that these patches are valid hanges and not installing CCP creeperware. Then, for a fuller-audit, confirm that the .debs being fetched do what they appear to do and patch the Armbian-provided kernel. I plan to do this later, as this is time and resource-intensive. I was previously told that this project is in no way affiliated with the Chinese Communist Party, but considering the international troubles it is not overzealous or paranoid to confirm that a custom-repo for a portable computer does not have malicious intent.
SUGGESTION: Provide a deb-src tree.
regarding your browser-trouble: Did you try another sdcard? Those are technically cheap and as far as I know don‘t do the same data cleanup as ssds do… we are essentially running the OS on a storage for cameras 
I do not know the read-speed for the provided mciroSD card. I did not try any other microSD card for the system as I have no spares to try. I am currently seeking help on a few different help-forums for this web-browser issue as I now believe this stems from SystemDickery.
I did not think about the speed but the data reliance of sdcards, this can be abysmal… many small systems running of sdcards use a readonly system that is written to RAM instead of the card for that reason…
Still trying to seek information. As for the board itself, I am having some confusion about what exactly is running on this. Is this a custom-board based off of the CM3, or is this a rebranded RaspberryPi? The GPU is different than the RaspberryPi, and the spec page has no real specs listed.
Speaking to other people, the error on shutdown is a kernel-related bug which is unrelated to systemd. So I need to file a bug-report. There is also updates on the kernel in the DevTerm repo from days ago, but it has not yet made it to the DevTerm apt.
If you have an A04, you can build the kernel by checking out the DevTerm repo and an Armbian build tree and following the instructions in DevTerm/Code/patch/armbian_build_a04/README. The kernel you have installed was produced by taking the linux-sunxi package that that produced and renaming it (both in the package’s internal metadata as well as the filename.) It is Armbian’s 5.10 tree from a few months ago plus some patches (also in the armbian_build_a04 directory).
i.e. the source is easily available, just not super well documented. I posted about this a week or two ago and @guu put the patches and README up.
I am trying this now on the device. I will report back once I have completed this upgrade. It appears that this directory was last upgraded 8 days ago. This would then be newer than the 15 day old .deb in the apt repo. Also, you should know that Private key isn’t private is a completely valid and extremely concerning issue. apt is completely compromised because it appears @guu doesn’t understand PGP signatures. The entire repo can not be used safely or securely until a new private key is generated, actually kept private, and the packages are resigned.
extremely concerning issue
I said similar to ClockworkPi in my communications with them about including my patched Xorg in future images. I agree that this is a very serious issue.
I don’t think the patches in patches are newer than the kernel .deb, they just hadn’t been put up yet. They’re against an Armbian version from October anyway.
I am confused as to the proper compilation method. I have followed the readme, and am prompted with a kernel compiling window (as expected). I choose “U-Boot and kernel packages” followed by “Do not change the kernel configuration” as I do not believe I need to change the flags from the existing system. However the next window is asking to select which board I am running. The truth is I do not know what the A04 is running. I have been confused since I purchased the device. I therefore do not know the proper compiling enviornment, and the readme here does not say.
It’ll be the only board with “clockworkpi” in the name if you’ve followed the DevTerm README.
I see. I forgot to add the wildcard per the readme. I followd and got a bunch of gawk errors from /home/cpi/build/lib/general.sh. It now appears to be running apt to “install build dependencies”. They are installing, all of which are being fetched from ports.ubuntu.com. One of the packages installed is gawk. Another is cpp-10-arm-linux-gnu.... There are over 70 build dependencies it appears. For some ungodly reason qemu is also being installed. I guess it’s needed for Armbian compilation since it’s hard to compile on pure-hardware on a SBC? I don’t know. Other packages I see including nfs-kernel-server. It finishes and enters the next step.
It now appears to be running a git clone on u-boot after “syncing clock”. It finishes and is now “Checking out”. It seems to take a long while at this step. I double-check to confirm that the system is not frozen. It is not.
After a while, it now is getting the git for “linux-mainline orange-pi-5.10”. Why? Is this what I am running? How can I know? Everything is branded ClockworkPi. I still don’t know if ClockworkPi made this SBC or not. It’s all very vague. It finishes and is checking out again. I’m tempted to end the program and start from the beginning again to ensure that I’ve done everything correctly. I am certain that I selected “clockworkpi-a04” after seeing it in the menu. It was alphabetical. Why would it skip to “O”? It probably wouldn’t. I trust that it’s doing what it’s supposed to do so I don’t close the program. This takes significantly longer to checkout than the u-boot. There is no status bar for this, nor verbose output of any kind.
After a while, I convince myself it is hung so I try again. Now, instead of gawk errors I get an error saying uuidgen: command not found. Interesting it did not install it with its download of dependencies. The script skips back to where it was, checking out “linux-mainline orange-pi-5.10”. At least I now know this is expected behavior.
I guess I just play the waiting game now…
The SoC in the A04 is an Allwinner H6, a SoC in the same family as the one that is in the Orange Pi, which is why the kernel tree used for it is that.
While I was gone a lot happened. I left it unattended for a long while. It is well into make now. Slowly and surely it continues. It finishesm and begins building a .deb rather than installing the compiled headers to the system directly. Then it runs make clean. After this, it begins compiling select drivers. Apparently it needs the rtl8192eu chipset driver? I did not know that the embeded board was Realtek. Quite honestly, that doesn’t make a lot of sense. Still, with a Mystery-Board who can say? (UPDATE: Thank you @annathyst for telling me it is an Allwinner H6, which is not in doumentation anywhere I can find). However, it then compiles another realtek driver, for the rtl8188eu. Then the rtl88x2bu. And it continues with many more realtek chipset drivers.
After a while, it spits out a lot about patching in incemental patch files, then named patchfiles for the drivers it has compiled. After this, more makefile lines, all referencing the scripts/ directory. It then begins “compressing sources for the linux-source package”. This does have a status bar which pops up after a period of time, but does not say how big the final file is expected to be. At time of typing 7%, 106MB @ 959Kib/s. A lot of fluxuation in speed. Later on, it appears to peak at 5+MiB/s. 67% is ~922MiB compressed. 76%, ~1.02 GiB at ~415Kib/s. At 86% it cocurently began running a dpkg-deb on linix-source-5.10.75. Or perhaps 1.16GiB is complete and the status bar was incorrect at 86%? The fan is running harder, and it’s hot to the touch.
“Make the linux source package compeled 1992 seconds”
Now it’s running make on the arch/ folder. Later, the other folders are being compiled too. Just boring gcc/makefile output to report.
I make sure to give the device proper ventilation too and also check that the room is cool enough for it. The compilation continues to make it hotter. How hot? I don’t want to try to check because this is so resource-intensive opening a new terminal may be detrimental to the entire thing.
For some readson it generated an RSA keypair. Perhaps this is part of the script for pubishing compiled kernels?
After that, more gcc output.
After a while the fan is moving so fast it’s making the device hum. I decide to unplug the device from AC (as it appears to be fully charged) hoping this cools down the unit. Almost immediately after I do that the fan stops making noise. I touch the back and it still feels hot, but less so. I still feel airflow from the fan. A minute later, the fan is makingnoise again. I move the device to a different corner of the room in hopes it will cool down.
Over the next hour the fan continued to cycle, and it continued to compile. I went back after about an hour and saw that the battery died before finishing the compile. Since there is now the major issue of apt being completely compromised, and @guu not understanding what that means, I think I’m going to stop posting my audit until this is fixed. I am considering demanding a refund for this product if the security has been long-term compromised like this and the devpool is inept to this degree.
[Apt] [Keysigning] [Security] Entire Apt Repositiory compromised
I am still in the process of self-compilation of the Kernel in an attempt to rectify the framebuffer issues. This has taken several hours of my day. I hope to be able to provide extended report soon and see if this fixes the previously-mentioned errors. Hopfully I come-accross nothing as extreme as I have already found, and censorship of my forum posts ends. I hope to see this thread relisted in the near future. It has been an incredible 26 hours since I had initially discovered the problems with the apt repo, and I hope that this is the only security problem I find going forward.
The only other things to add to this Audit so-far are included in my previous FTC complaint, which are that the screen in advertisment is simulated without notice that it is simulated, and the machine reports to only have 2 cores instead of the advertised 4. This issue regarding cores appears to have been previously reported seven days prior. The thread shows that this is a userspace issue, and changing the CPU mode using devterm-a04-gearbox -s 5 fixes the issue. Doing so made the fan kick on again. I am unsure if I may have problems as I changed the setting during the Kernel compile.
It also would do well to state the board provided on the advertisment page, which I have since learned is an Allwinner H6. There is no documentation or notice in advertisment that this is the board being recieved.