FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

implement std.sha256 by mikedanese · Pull Request #607 · google/jsonnet · GitHub

/ jsonnet Public

implement std.sha256 - #607

Open
mikedanese wants to merge 2 commits into
google:masterfrom
mikedanese:sha256
Open

implement std.sha256#607
mikedanese wants to merge 2 commits into
google:masterfrom
mikedanese:sha256

Conversation

Copy link
Copy Markdown
Contributor

Adds a dep on openssl and absl. I'm not sure how problematic that is.

* explicitly load git_repository rule
* load googletest as a git_repository
* stop using bind (see bazelbuild/bazel#1952)
Comment thread core/vm.cpp
builtins["primitiveEquals"] = &Interpreter::builtinPrimitiveEquals;
builtins["native"] = &Interpreter::builtinNative;
#ifndef DISABLE_INSECURE_HASH
builtins["md5"] = &Interpreter::builtinMd5;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Any reason to leave the old one at all? Why not just always use OpenSSL version if we depend on it anyway?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Backwards compatibility. We don't want to force people to redeploy their entire infrastructure because they were using md5 to generate unique names for things.

sbarzowski commented Feb 26, 2019
edited
Loading

Copy link
Copy Markdown
Contributor

Thanks, adding more standard hash functions is a good thing.

Unfortunately, going from 0 external dependencies to one (two with absl) is a pretty inconvenient. We need to support the users who don't use Bazel.

Are there any good header-only hash function libs? That would be much more convenient here. However, OpenSSL is going to be available on pretty much any system anyway and it provides us with all the crypto we may need. I'm not aware of any other reasonable option, so we probably should use it. But then we need to make it work with a regular Makefile, add dependency information to README and make the new requirement very clear during the release.

I don't think that absl::BytesToHexString is worth getting absl. It sounds like quite a pain to get working with Make and it's much less likely that the users have it already in their system.

I wonder what @sparkprime thinks about this.

Copy link
Copy Markdown
Contributor

The only reason Mike did this is that someone internally wanted us to provide an alternative to MD5 in case anyone felt tempted to use MD5 in a context where crytographic hashing was needed. Personally I'm not really convinced it's worthwhile since this is a config language.

As for absl dependency, I'm sure we can write our own absl::BytesToHexString :)

There are already build problems on windows and mac and stuff like this will probably exacerbate them.

Maybe we should pull off the bandaid and start adding stuff to go that's not in C++?

Copy link
Copy Markdown
Contributor

If we will go forward with parseYaml we will probably want to add shared library dependencies anyway, so adding openSSL should't change that much.

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants


Back | FazBrowse Home | New Git URL