> Do you know that ascan is very confident that ascan is malicious? Is it by > design?
I am not affiliated with Atomdrift, but from what I am understanding it may be comparable with how heuristics scanning in antivirus software looks like. It seems that the goal is to highlight capabilities and behavior that is either common for malware or untypical for normal software, through the approach that Atomdrift uses seems to differ in an attempt to get around the limitations of generic or rule-based heuristic scanning. As such, it would make sense for ascan to detect itself as suspicious since what ascan is doing is highly unlikely for regular software or common for malware... but the question is where we are drawing the line here. As for my first impression of ascan I must add that the results varied a lot from one day to another from updating the models when scanning active processes. For reference, as of today it does flag my Hyprland, XWayland, NetworkManager Applet and the entirety of Steam as "100% hostile". Sometimes reasons are provided, sometimes one is left with only the "MAL-ECULE" which probably contains everything one does need to know to acknowledge how it came to the conclusion that something is suspicious or hostile. But unlike the demonstration with the Atomdrift Lab that was posted earlier that meticulously discloses how every individual finding in the PKGBUILD was used to come to a conclusion, that type of transparency seems to be currently missing in ascan, or at least I am unaware on how to reproduce it. Not exactly optimal for evaluation if manual intervention is required. While I wasn't able to reproduce this inconsistencies with scanning actual AUR Git Clones that I happened to have laying around, it got me wondering whenever this situation only exists with false-positives or if we also have to keep false-negatives in mind. I wasn't going to risk to test with actual malware on my system, but all of that got me thinking that it could add a lot of additional work for the user when the target audience of the attack has likely been to go for people that are blindly installing AUR Packages without reading the PKGBUILD. So I am currently not sure if this is the answer to our problems, at least on on the user's side. The idea of integrating Atomdrift into the AUR does sound interesting but I honestly lack insight to evaluate that. Maybe ascan is a lot better at dealing with file scanning than with processes, or when using the `--interpret` option to ask another Local LLM, or doesn't struggle with false-negatives. But that requires more resourceful people to figure out. I am still figuring out myself how I wanna improve my own approach to building packages more reliably to catch missing dependencies or dodging weird quirks of my main system... I hope this contributes anything meaningful to the discussion, PureFallen P.S. I apologize Pasha for the duplicate E-Mail; I ended up sending it directly to you instead of the mailing list the first time.
