There is nothing about stopping/killing rsyslog in thst virustotal output. `kill -s HUP` sends SIGHUP to a process (read rsyslogd(8) to know how it interprets HUP).

It seems like virustotal also records unrelated processes running on that host, logrotation is a normal thing.

Can you produce some evidence, even a screenshot? It would be helpful.

When did it do that? yt-dlp uses .onion addresses for some of the sites.

That's not described in the documentation. Does it do that automatically or does it ask for a user action first?

Did you open an issues on their GitHub page?

FWIW, It appears one of the people who saw this post asked in a comment in an issue on GitHub [1]:

  > @seproDev unrelated, but what you think about https://news.ycombinator.com/item?id=42040600

.. and one of the main maintainers (ranked #14th by #commits, but a recently active maintainer) replied the following:

  > False positive in virus total. Calling yt-dlp without any arguments makes no web requests.
  > To expand a bit more. Our releases are built with github runners and they report back the sha hash during build. https://github.com/yt-dlp/yt-dlp/actions/runs/11656153929 for the release from yesterday
  > You can see the commit that was built, what we merged in the last couple days, and the hash of the resulting files to check against the files in the release section.
  > Those network requests are likely just other processes on the machine. I remember windows executable would regularly show microsoft servers in the "connections made" list due to windows update and telemetry still running.

[1] https://github.com/yt-dlp/yt-dlp/issues/11451#issuecomment-2...

Can you link to the issue?

Sure: https://github.com/yt-dlp/yt-dlp/issues/11451#issuecomment-2...

I edited my reply too.

Edit: I'd caution against spamming the maintainers though (not caution you specifically), the possibility of that happening is what swayed me to not post the link originally.

Ah yeah that makes sense. I just wanted to confirm it because I couldn't really find anything when I was searching.

Is it using Tor to download content?

(The second part of your comment was just normal log rotation as it turns out)

If all you have is results from VirusTotal, this is a nothingburger. Dig into what those calls actually are before you cry wolf.

It's not crying wolf to ask the question (yes, leading questions can be used that way, but they are clearly asking here, not trying to imply), they presented the thing that concerned them to get eyes on it and find out if it was a problem, that seems reasonable.

That would make it our job to teach OP critical thinking.

This is a news aggregator, not a help desk. It's perfectly fair to characterize submitting such entry as "crying wolf", even when it's formulated as a question. When I browse my RSS feed from HN, I expect the items to have at least some minimal substance.

VirusTotal seems to be generating more false positives lately. Seems like they’re adding some poorly written heuristics. We’ve seen problems with false reports of things being infected like our own products.

VirusTotal said it is ok?

https://www.virustotal.com/gui/file/3f6ab524d899f39ef46004a9...

The only thing VirusTotal would tell you about, is already known patterns of virus/malware. If there is a novel/different way of doing something, and/or it hasn't been noticed by the AVs they're collaborating with, you'll end up with everything green.

PoC Rust program that takes the contents of .npmrc and uploads it to a random IP (DONT RUN THIS! It'll steal your npm authentication token): https://gist.github.com/victorb/adf0ac8b7ada8d5a4982462e24e8...

"No security vendors flagged this file as malicious" = https://www.virustotal.com/gui/file/b99b86a5ce3aa24b39ec53dd...

But clearly, it is malicious :)

I don't understand, the op claims the alert came from Virustotal.

I think he might be talking about the "relations" tab. You can see the "Contacted IP addresses" section that claims to be "contacted IPs by the file uploaded to virus total". If you click the IP some will have detections and flagged as bad or criminal.

https://www.virustotal.com/gui/file/dcca6afb6ac9770d4d3425c3...

Says it contacted 45.66.35.11 and you can see its a tor relay https://metrics.torproject.org/rs.html#details/7EA6EAD6FD830...

Though haven't looked at how yt-dlp works, I'd guess yt-dlp might attempt to use tor network in case some IP or network is blocked and can't reach a server.

Its not just a tor relay, it is one of the directory servers: https://metrics.torproject.org/rs.html#search/flag:authority

Look at other tabs https://www.virustotal.com/gui/file/3f6ab524d899f39ef46004a9... at the bottom you can see the commands that looks like the program trying to delete down syslogs. Look also in the relations tab that shows some tor nodes.

This is not "shutting down" rsyslog. The kill command sends a SIGHUP to rsyslog, which causes it to reopen its log files - what you are seeing is a normal logrotation, not an attempt to terminate the process.

I suspect virustotal did the check in a container with a logrotation job still running, and it happened to run right in the moment when yt-dlp was being tested.

You mean this `systemctl kill -s HUP rsyslog.service` ? This just tells syslog to reload itself

Why would yt-dlp tell syslog to reload?

It seems VirusTotal spins up a virtual machine/container to run the program, and monitors what happens inside that environment. And it further seems that during that time syslog (or something else, probably the distribution) reloaded itself. And some other process tried to connect to the TOR IPs.

And since we're all amateurs here who don't understand what VirusTotal is doing, some of us think "ZOMG yt-dlp compromised?!?".

If you look at the process tree, the process that reloaded rsyslog wasn't spawned from the yt-dlp_linux process.

I don't see anything trying to delete syslogs. There's a line for reloading new configuration (kill -HUP ...) - is that what you meant?

Source?