You are not logged in.
in general,
if everyone thinks these should questions be silently ignored (even if false positives), then ... i give up, maybe i shouldn't use the forums either.. community toxicity seems to be an issue not solvable... (not sure, what i expected in the 1st place, from a nazi friendly environment.)
i read all sorts of BS, like trying to blame me or Clamav or LMD for not being responsible or spending devuan devs precious time, while they are doing their fine job and not need to hear this..
well, that's how communities work. communicate issues, no matter how stupid they might seem to you (...elitists)..
so someone(...) who checked this, is going to communicate this false positive to another foss (clamav) to help make it better, and not just whine about it in whatever forums.
---
anyway, some moderator, please lock this thread...
not solved imho, got no help/assurances from pkgmaster admin, so lock it up anyway.
tired of all the spam and bs on this thread.
Ideally if you had a rsync of a mirror locally you could update systems through a lan connection much more securely without having to go through internet hoops.
to clear something : this is not a local mirror, it's a mirror in Devuan RR, rsynced directly from pkgmaster - which changed ip once again recently without any official notification...
mirror is used daily by many people.
Is LMD still alerting on those package digest files? I downloaded those files today, and then installed clamav and LMD. I ran maldet manually and had it analyze those files. It didn't find anything.
did you install clamav-unofficial-sigs as well? that's what's giving the false positive. not default clamav signatures. and that's why virustotal doesn't report it either (they don't use unofficial sigs).
in my case, i put those files on ignore list, after examining them. don't know if lmd would report those again.
Why is it needed if after years of use this is its first message and it’s false? Or am I missing something?
yes, you're missing something, "1st message on devuan mirror files" is more accurate.
The paths
/path/to/mirror/devuan/merged/dists/chimaera-backports/main/by-hash/SHA256/e8b658bc0b30120109470ac5b20c8be088f56b9024a49285c76d41d8694e2ce2
et al are all compressed Packages files, i.e. so called "digests", and evidently that "tool" can't handle them.
that tool (clamav really) was running for years scanning all server files. this is the 1st time i got notifications and though i immediately thought of it as false positives, i guessed it'd be better to get official confirmation...
and not all "digests" give false positives notifications.
i mean, php is not great but calling it malware isn't a bit too much?
where did you read that php is malware? maybe in another post, there was no such reference here. (?)
If you haven't done so already, try the mailing list:
dng is just a users general list, and toxic. unsubscribed years ago.
but there was another list for mirror operators. not currently working for reasons unknown.
anyway, put them on ignore list, didn't see anything alarming while examining packages.
---
would be nice to get feedback though. but "mirror master" seems absent. :
pkgmaster ip changes once again - no notification to mirror operators,
mirror mailing list doesn't work (no messages get through..),
a simple question about reported malware in contents, doesn't get any official feedback
what's up?
Is this a troll, or are we really asking if gzipped package digests are malware?
The mind boggles.
question was about gzip package reported as malware, not digests.
and btw, do you check every gzip package content you use? how do you know its only digests?
Only two of those have been submitted to VirusTotal. I searched VirusTotal for all of them, and only found these two:
By the way, thanks for posting about this. I had never read about Linux Malware Detect (LMD) until I read your post.
personally submitted those to VT. clean there, only clamav unofficial sigs reports malware.
possible for gzip to provide a different hash depending on gzip version?
nice catch, but no. hash is not similar to any other malware (if i understand correctly what you said).
earlier today, got an lmd (linux malware detect) notification from the devuan packages mirror, that some file were infected and quarantined.
re-downloaded those files from a couple of other mirrors, still the same results with clamav+clamav-unofficial-sigs.
virustotal doesn't report any malware, but i'm not sure, they're using unofficial ruleset for clamav checks. strange that no other antivirus finds it though.
can some repository admin (or project member), verify these files (in reality these are gzipped Contents-$arch) ?
are those false positives perhaps?
thx in advance,
FILE HIT LIST:
{YARA}r57shell_php_php : /path/to/mirror/devuan/merged/dists/chimaera-backports/main/by-hash/SHA256/e8b658bc0b30120109470ac5b20c8be088f56b9024a49285c76d41d8694e2ce2
{YARA}r57shell_php_php : /path/to/mirror/devuan/merged/dists/chimaera-backports/main/by-hash/SHA256/fe1a7fca9e67d2677bbe17c44db8bd283dd382d76552f4bc40e67eb8fb0f7375
{YARA}r57shell_php_php : /path/to/mirror/devuan/merged/dists/chimaera-backports/main/by-hash/SHA256/e71a5fb0e45c4eecd8d884b9340eed1309e0f549ee58a0a781b6d001437d3649
{YARA}r57shell_php_php : /path/to/mirror/devuan/merged/dists/chimaera-backports/main/by-hash/SHA256/937166aadc617d54976267ff9269c38a3ccfe65b2b08e961756682c95f7b5b52
{YARA}r57shell_php_php : /path/to/mirror/devuan/merged/dists/chimaera-backports/main/by-hash/SHA256/29e3bede56b3b753c04f7afbb1eba55ee9f8ab994a20e6ee6d88b4f5dacb539a
{YARA}r57shell_php_php : /path/to/mirror/devuan/merged/dists/chimaera-backports/main/by-hash/SHA256/2832da4d5d778be5ef448f6ab32506ac5d39be77e77938d63ca64a445e1c5059
add testing repo along with ceres.
then :
apt policy libgudev-1.0-0
should show both version, and :
apt install libgudev-1.0-0/testing
to rollback to a working version.
tails does that, iirc whonix just forwards traffic to 2nd vm used as gateway.
you can set global wide proxy in system to tor socks5 address, but it still won't be like tails. some apps might use hardcoded address and/or bypass system proxy. you have to use some network sniffer to make sure, all traffic goes through tor.. and adjust/remove those that don't .
or just use tails which is already build especially for this purpose.
if you're using ceres, rollback libgudev-1.0-0 to testing version. (237-2). latest debian version causes this for all systems using eudev (like devuan, antiX, etc).
https://dev1galaxy.org/viewtopic.php?id=5807
had a similar error, with dhclient+runit, and @Lorenzo (debian runit maintainer) fixed it in a runit-services 0.6.0 version in debian experimental.. maybe you should try that package, see if it helps.
removing service isn't a fix, you're just removing service so it doesn't run..
about a year ago, i've uploaded a runscript for libvirtd if you want to try/use with runit : https://git.devuan.org/xinomilo/runscri … bvirtd/run
involves some steps to add to runit, better look Debian runit documentation.
Lorenzo, the Debian runit maintainer (who's also around here), also accepts wishlist bugs for new services/runscripts to add to runit-services package...
nor sure i understand. so you want to resize luks partition? other partition? there's only one partition?
you can't disable luks temporarily. there are ways to disable completely (under certain circumstances) but not temporarily.
but you can resize luks partition like any other one. involves a few extra steps, but not impossible.
btw, you can use nbd mount for qcow2 image, and gparted on that afterwards.
what does `file xyz.db` say?
creation date?
could be a db backup, or something else. do you have a database server running on that system?
reportbug
ωραιο φαινεται το community, καλή αρχή..
απλά πολύ google ρε παιδιά, google translate, analytics, γιατι;
δυστυχώς με το -χειροτερο και απο systemd- μονοπωλιο της γκουγκλ δε τα παω καλα, οποτε δεν μπορω να κάνω εγγραφή να πω ενα γεια και απο εκει..
2c
looks like network issue. http/https ports are filtered, not accessible from outside.
could be router/ISP or firewall issue. ping seems to work ok, but ports 22,80,443,631 look filtered.
so, resolve network issues first... then look at web server for possible issues... (might be fine just as is).
self-signed wont work on most browsers... you could get a free ssl cert from Lets Encrypt (or other providers). there's a python3-certbot-nginx package to facilitate certificate issue and installation...
as for ssl configuration for nginx, this is probably better : https://ssl-config.mozilla.org/
choose nginx + openssl versions, security level, and copy output to a ssl-params.conf file (customizing to your needs ofcourse...)
just tested, after installing evince, atril is using evince-previewer for print preview. and that works. not atril-previewer as it should(?) ...
so probably atril-previewer is buggy/fails/whatever...
edit] running standalone `atril-previewer $file` works.
atril is a document viewer app
evince is another document viewer app.
one is not needed to run the other.. no relation/dependency between those 2.
that's why i'm saying atril's problem is not fixed. by installing evince, you just use evince for viewing/printing documents..