search

ethpm / py-ethpm

This library is deprecated. ethPM python tooling is now located in web3.py
MIT License
24 stars 13 forks source link

Http backend #61

Closed njgheorghita closed 5 years ago

njgheorghita commented 6 years ago

What was wrong?

URI backend needed to serve content-addressed github URIs

How was it fixed?

Wrote backend that serves github URIs conforming to

https://raw.githubusercontent.com/user/repo/commit_hash/path/to/manifest.json

Cute Animal Picture

image

njgheorghita commented 5 years ago

@pipermerriam ping for review. The scheme i'm using here isn't quite exactly, what's discussed in the ERC 1319](https://github.com/ethereum/EIPs/issues/1319), I'm not sure if that's a problem or not. IMO just using the raw.githubusercontent.com authority is simpler than creating/fetching blobs as suggested in the spec. Any thoughts? Obvs, i'd like to conform to the spec wherever possible, but this is also an area that imo doesn't require strict conformity.

I also thought about requiring a content hash fragment suffixing the github uri . . . i.e. https://raw.githubusercontent.com/ethpm/ethpm-spec/481739f6138907db88602558711e9d3c1301c269/examples/owned/contracts/Owned.sol#bfdea1fa5f33c30fee8443c5ffa1020027f8813e0007bb6f82aaa2843a7fdd60 for an added layer of security, but I recently removed that since the commit-hash is already in the uri, didn't seem necessary to have two content hashes

pipermerriam commented 5 years ago

@njgheorghita on not including the hash in the URL: I don't think this is ok. While I agree that it doesn't allow for arbitrary modification of the resouce by the user, it doesn't provide protection against github serving up incorrect content. I acknowledge this probably isn't a concern we're likely to see realized, but I'd prefer we do it correctly and both require the hash as well as verifying the payload we receive matches said hash.

Which makes me realize that we should be doing the same with the IPFS gateway backends (and probably generically via any of the IPFS backends) just to be doubly sure that the content we receive is indeed the content that should have been at the address.

njgheorghita commented 5 years ago

@pipermerriam Makes sense, added the requirement for a valid content hash to the end of github uris. And added a validation to IPFS backend that the hash of the retrieved contents matches the content hash in the uri