Metadata-Version: 2.4
Name: veripypi
Version: 0.1a0
Summary: TODO
Home-page: https://github.com/alichtman/veripypi
Author: alichtman
Author-email: aaronlichtman@gmail.com
Project-URL: Bug Reports, https://github.com/alichtman/veripypi/issues
Project-URL: Donations, https://www.patreon.com/alichtman
Keywords: backup documentation system dotfiles install list configuration
Classifier: Development Status :: 4 - Beta
Classifier: Intended Audience :: Developers
Classifier: Intended Audience :: End Users/Desktop
Classifier: Intended Audience :: System Administrators
Classifier: Topic :: System :: Installation/Setup
Classifier: Topic :: System :: Operating System
Classifier: Topic :: Utilities
Classifier: Operating System :: MacOS
Classifier: Operating System :: POSIX :: Linux
Classifier: Operating System :: Unix
Classifier: Natural Language :: English
Classifier: License :: OSI Approved :: MIT License
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.4
Classifier: Programming Language :: Python :: 3.5
Classifier: Programming Language :: Python :: 3.6
Classifier: Programming Language :: Python :: 3.7
Description-Content-Type: text/markdown
License-File: LICENSE
Dynamic: author
Dynamic: author-email
Dynamic: classifier
Dynamic: description
Dynamic: description-content-type
Dynamic: home-page
Dynamic: keywords
Dynamic: license-file
Dynamic: project-url
Dynamic: summary

### Veripypi

Ensure the package you're installing from `PyPi` is the same as the source code advertised on GitHub.

#### Installation and Usage

```bash
$ pip3 install veripypi
$ veripypi <PACKAGE_NAME>
```

#### Motivation

Open-sourced repositories provide a false sense of security. Since the code *is readable*, other developers *must have* read and audited it, right? Someone would surely say something if there were really an issue...

*(See [the Bystander Effect](https://en.wikipedia.org/wiki/Bystander_effect).)* 

But, even when the source code has been thoroughly audited, it's trivial to showcase a clean version of the project on GitHub and a distribute a trojaned package on `PyPi`.

This is a PoC to minimize this attack vector. (Although the real solution to this problem is probably more along the lines of enforcing PGP signed releases, but there's a whole lot of controversy surrounding this that I won't delve into here.)

#### How it works

First, a source distribution is created from the latest release of a GitHub repository of the package to be verified. This `sdist` is used as "ground truth." Then, the PyPi version of the package is installed. Both versions are compared, and if they're not identical, a flag is raised. 

#### Interpreting Results

A green flag from `veripypi` only tells you that the source code being distributed matches the source code that can be viewed on GitHub. It **does not** imply anything about the safety of the code being installed. 

Similarly, a red flag does not necessarily mean that the package is trojaned. One simple explanation for a rejection from this tool is a maintainer pushing an updated release to `PyPi` and forgetting to push to GitHub. 
