Quoting goli...@devuan.org (goli...@devuan.org):
> EvilGnome: A New Backdoor Implant Spies On Linux Desktop Users
> https://thehackernews.com/2019/07/linux-gnome-spyware.html
My view: The only _actually interesting question_ in any report about
malware is how the code gets executed. The cited
On Wed, 17 Jul 2019 21:28:25 -0500
goli...@devuan.org wrote:
> EvilGnome: A New Backdoor Implant Spies On Linux Desktop Users
>
> https://thehackernews.com/2019/07/linux-gnome-spyware.html
Using Openbox, I have the advantage of not depending on the actual
Gnome desktop, meaning I can prevent
EvilGnome: A New Backdoor Implant Spies On Linux Desktop Users
https://thehackernews.com/2019/07/linux-gnome-spyware.html
Some excerpts:
"Security researchers have discovered a rare piece of Linux spyware
that's currently fully undetected across all major antivirus security
software
On dc., jul. 17 2019, Bernard Rosset via Dng wrote:
Thx Evilham for your answer. Glad it was not sinkholed ;o)
Not at all :-).
But maybe it'll be interesting to add simple monitoring at a
connection
level same way you ran your tests.
I'll try to setup a thing in the next couple days.
I
On Tue, Jul 16, 2019 at 08:02:43PM -0500, hal wrote:
> Hello,
> Thank you. Here is the boot output from
> devuan_ascii_2.0.0_armel_raspi1.img.xz and setting emmc clock to 50Mhz in
> config.txt
>
> The same sdcard will boot my Raspi A+ fine so maybe it's hardware?
>
>
Thx Evilham for your answer. Glad it was not sinkholed ;o)
> FWIW: I've been running "while; curl; sleep 30" as a similar test for a
> good few minutes now and it's been solid.
Yup, as I stated before in my report, nothing wrong had been detected
since 1100Z, ie almost 6h ago.
I have been using
Hello,
On dc., jul. 17 2019, Bernard Rosset via Dng wrote:
After I stumbled, by chance, on mirror 141.84.43.19 (being part
of the
deb.devuan.org pool) being unavailable for a couple of minutes,
I set a
script up checking TCP/80 availability for all of mirrors in
said pool.
The conclusion
After I stumbled, by chance, on mirror 141.84.43.19 (being part of the
deb.devuan.org pool) being unavailable for a couple of minutes, I set a
script up checking TCP/80 availability for all of mirrors in said pool.
The conclusion is clear:
1°) 141.84.43.19 is the only mirror suffering from this
