[DELETED]

[Dont-Copy-That-Floppy]

[DELETED]

[github-actions]

Thank you for contributing to PyTube. Please remember to reference Contributing.md

[a-czyrny]

Can you explain more. Can't find any evidence.

[Dont-Copy-That-Floppy]

[DELETED]

[a-czyrny]

I need evidence in the code.

[Dont-Copy-That-Floppy]

[DELETED]

[GrautDevelopes]

Do you know what burden of proof is? To HeLp yOU loGiCAllY, that's a huge claim with no backing. It sounds like it might be related to some other 3rd party tool instead. Do you use NSSM?

[tfdahlin]

@pusalieth your understanding of that error message is a bit flawed

To begin with, those mentions of failing to grab the key are merely warnings, likely due to a debug mode being enabled somewhere in your system, and I really don't think those are even coming from pytube. The bracketed numbers in front of the message make it seem like the messages are coming from other processes that are running, and I suspect those numbers are process IDs. The error from pytube is unrelated to those messages.

Secondly, those messages are about accessing registry keys from your windows machine. Registry keys are primarily used for saving configurations in a centralized location on Windows, and those are simply stating that the length of the registry keys could not be determined. If you use regedit.exe on your machine, and navigate to HKEY_CURRENT_USER\Software\Google\DriveFS\Share, you should see that the information there is pretty useless -- there are probably some flags for enabled settings on your Drive FileStream installation, as well as a value for the drive letter to use, but not much else. Google isn't storing your account password or anything in there, because it would be really insecure to do so, and Google spends a lot of money making sure that their software is secure.

@RONNCC can this issue be closed so as not to mislead potential users?

[Dont-Copy-That-Floppy]

[DELETED]

[tfdahlin]

1. You're correct, pytube != pytube3, and both repos aren't updated super regularly, but there is overlap. For a period of time, when this repo seemed to be stale (Around October 2019), hbmartin took it upon themself to fork the repo and maintain that fork. Hbmartin updated that repo for a while, until around February of this year, at which point nficano merged all of those updates into this repo, bringing the original pytube up-to-date with pytube3. Since then, pytube has been strictly ahead of pytube3.

2. Let's assume that those are from compiled C object files from pytube for a moment. Running pip uninstall pytube and pip uninstall pytube3 after a fresh install will show us where all the relevant files are that come from pytube and pytube3 respectively, which we can use Select-String to search for a substring of the error that you're seeing. In my case, these are the relevant directories:
   
   We aren't really interested in the dist-info directory, because it simply lists information about the package, which really only leaves us with C:\Users<username>\AppData\Local\Programs\Python\Python\lib\site-packages\pytube*, as well as pytube.exe and pytube3.exe in C:\Users<username>\AppData\Local\Program\Python\Python\scripts\pytube3.exe.
   We can use Dependency Walker to see what gets imported into pytube.exe and pytube3.exe.
   Pytube.exe is dependent on kernel32.dll and shlwapi.dll. Sorting by function name, GetProtoFromRegistryValue does not show up in either of these DLLs:
   
   
   Pytube3.exe is dependent on the same DLL files, and we see this function doesn't exist in those:
   
   
   So we can effectively rule out those executables. On to the rest of ...\site-packages\pytube\*. If we look at the contents of that directory...
   
   We see that it's just the files from the pytube folder here, plus the pycache.
   We can use Select-String to search through files for substrings pretty quickly. For example, here's how you can find out what files import logging:
   
   Let's try a few strings related to the warnings you're seeing:
   
   To prove I'm actually using the command, you can see that cancelling it produces the escape character. There seem to be no substrings in any of these files that actually mention a registry.
   There genuinely is nothing in these files that seems to reflect the behavior you're seeing. If I had to guess what is causing it, I could see it stemming from the way that DriveFS functions behind the scenes when uploading files. Are you attempting to save a file to a Drive folder? Perhaps there's something going on with the way that the files are getting saved at a much lower level while it is uploading to drive.

3. Believe me, I know that throwing money at software doesn't always fix security issues! I work in cybersecurity myself. My point is that Google has exceptionally talented security engineers, and a robust bug bounty system in order to identify and fix issues like this quickly. I just genuinely do not see any evidence that the warnings you're seeing are stemming from pytube, especially after looking at the registry keys on a machine with drive fileshare installed. The only non-boolean values I see are filepaths for things like the cache location, the drive name, and a base-64 key called "SyncTargets" which I can't find documentation about anywhere, but which I assume is related to the location files are stored in Google's cloud, as it looks nothing like an auth hash.

[Dont-Copy-That-Floppy]

[DELETED]

[tfdahlin]

You're absolutely right -- it is theoretically possible that pytube could fetch a binary from somewhere online and execute it, but in order to do so, you'd have to go through a builtin python library like subprocess, os.popen, or os.system. You can search the repo yourself, but os.popen and os.system calls aren't made, and the only use of subprocess is to call ffmpeg.

Pytube has its own implementation of requests, as it does not rely on the python requests library, and so you can easily find instances where the request implementation is used in the library. The classes that make use of the request implementation are the Caption class, the Stream class, the Playlist class, and the Youtube class. There is a reference to the request module of python's urllib, but it's only used for setting up a proxy which is only done when you explicitly tell pytube to do so, so we can safely ignore that.

In the Caption class, a GET request is made to the class' self.url variable, but there are no Caption class instantiations in the rest of the codebase, so we can confirm no malicious requests are made by this class.

In the Stream class, request.stream is used, which is a wrapper around a GET request to split the request into reasonably sized chunks. request.filesize is also used, which makes a HEAD request and returns a dictionary of the response headers. Both of these operate on the class' self.url variable, and a Stream class is only ever instantiated by the YouTube class in its initialize_stream_objects method. YouTube classes are only instantiated by Playlist classes or from the CLI, and Playlist classes are only instantiated by the CLI. You can search the code yourself to see this. This covers all of the classes that make use of the request implementation, which means that none of the code in the repository attempts to download anything that isn't explicitly specified by the user.

Unless you've customized your PATH to do something non-standard, python will only attempt to import pip libraries from the standard installation location, which in my case is %APPDATA%\Local\Python\Python36\Lib\site-packages. Pip will tell you exactly where it has the files that it's importing. Alternatively, you can use python's built-in functionality to see where the files are getting imported from like so:

I understand the concern you have, but I assure you this isn't pytube that's trying to read registry keys on your computer, or clandestinely installing a trojan to do so. Have you tried using procmon to confirm that it's actually a python (sub)process attempting to access the registry key?

[Dont-Copy-That-Floppy]

[DELETED]

[GrautDevelopes]

Hmm. My first experience of trolls on GitHub.
@tfdahlin This person is just trying to get a reaction. No amount of proof is going to satiate them.

[tfdahlin]

@GrautDevelopes yeah, I'm realizing that based on their last response. Would be great if @RONNCC could close this issue so people don't get the wrong idea

[Dont-Copy-That-Floppy]

[DELETED]

[RONNCC]

Closing issue -- let's please keep things civil please
We all believe in open-source 😄

https://docs.scipy.org/doc/scipy/reference/dev/conduct/code_of_conduct.html

Thanks @tfdahlin