nietaki / hoplon Goto Github PK

Example: if your project depends on ecto and ecto depends on :decimal, verify them both.

This info is in mix.lock, but we're currently discarding it

The code as of 0.3.2 is a little rushed. The purpose of this task is to bring the code to a good place before moving forward with more features.

General checklist:

• Add some integration tests, increase code coverage
• Clean up interfaces/function names
• Move as much of the business logic away from mix tasks and into hoplon's modules
• Fill in the TODOs from README
• Consider developing moduledocs and function specs a bit more

...and there's probably more, just needs a fresh look

bisect doesn't work because even the initial commit is 0.1.0, it will point to the second commit in the repo

The purpose of this task is to add another heuristic to the "find commit for the version using git bisect" functionality.

The idea is that if the commit found by bisect doesn't align with the dependency, we could check some of its children and grandchildren, up to a defined depth. It should reduce the number of false positives a lot

• ok: 0
• unresolved: 11
• corrupt: 12

• fetch github urls from mix hex.info
• clone repos
• try to check out corresponding git tag
• diff files
• print output

Both to iron it out in my head and have something I can get some feedback on.

Things to pay attention to:

• What is the developer/project setup process?
• What is the audit creation/submission process?
• What is the process of checking the project dependencies?
• Are we introducing any concepts/terminology (audit? revocation? verification?)? What do they mean exactly?
• Are we changing any existing terminology?
  • There might be some terminology around the diff-based tasks and functionality that we might want to move around: hoplon.check, hoplon.verify, absolutions, ...
• How does the audit-based functionality fit in with the local lockfile absolutions? Are they rendered obsolete?

...or another modern open source license.

Currently the project goes through mix.lock to find the project's dependencies. While this works pretty well, there's a chance mix.lock is going to contain a package the project no longer depends on - the old entries don't get cleaned up.

The system should be slightly more sophisticated here.

• add an integration test to travis
• document that in the readme
• update suffixer

Currently all hex packages pulled from mix.lock which have something other than just [:mix] as their build tools get silently skipped. Investigate what work is required to support mix+rebar3 and rebar3 dependencies.

Probably using a flag in the mix tasks. However sensible the default location might be, there might be good reasons for users to override it.

I'm not crazy about the aspis stuff anymore ;)

Wishlist:

• always compile .asn1 files to erlang files as a pre-compilation hook, if possible.
  • otherwise alias the compile and test mix tasks?
• compile the generated erlang files as part of normal compilation
• provide a convenient way of parsing the generated records
• token encode/decode test for some simple record
  • make sure the encoded stuff is proper DER format

• see if you can push a tag that doesn't point under any branch (you probably can)
• decide the requirements for tags (under master? under any branch?)
• do the verification on mix aspis.check

/tmp is bad, mainly because it can be cleaned up in an arbitrary fashion by the operating system. That means some files might be deleted while others are left behind, leading to broken repositories.

The repositories should probably be under ~/.hoplon/repos/ and named after their github locations (nietaki/hoplon), not package names

We probably still want to print them as results come in, so we might have to do something vaguely smart about figuring out the column widths in advance

Add the ability to absolve a version (hex checksum) of a library. Optional message

%{
  absolved: %{
    hackney: %{
      "1.3.4 (or the hash)" => "readme and format changes - Jacek"
    }
  }
}

green for checked items, red for unchecked, default for instructions.

Make sure to share the code with mix aspis.check

Currently we only find the right commit in the dep's repository if it's correctly tagged. It would be possible to find it (or a good approximation of it) using git bisect run and a script that checks for the version in mix.exs.

Git internally is just a Merkle-tree so there is no need for diff as you can just compute Git-compatible tree and compare it with the one stored in repo. In theory it can end with differences (as SHA-1 is broken), but it would allow to speedup first check and reject obvious invalid repos.

...and pass them straight to diff. Otherwise choose sensible defaults

creating releases with tags, verifying you have the github url in your hex description, ...