Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Upgrade sha2/sha3/digest from 0.9 to 0.10 #102

Open
webmaster128 opened this issue Jan 9, 2023 · 3 comments · May be fixed by #130
Open

Upgrade sha2/sha3/digest from 0.9 to 0.10 #102

webmaster128 opened this issue Jan 9, 2023 · 3 comments · May be fixed by #130

Comments

@webmaster128
Copy link

I'd like to upgrade sha2 in my codebase to 0.10, which is used for ExpandMsgXmd<H: Digest> here. It would be great if that could be upgraded when someone gets the chance.

I spent some time on an upgrade but then gave up since I am not at all familiar with the digest traits and how hash_to_curve is implemented here.
@str4d
Copy link
Member

str4d commented Feb 27, 2023

This conflicts with #90, and we've been blocked on reviewing #90 because of how large it is. I have a plan on how to tackle this, but it won't be done for the next release.

@fspreiss
Copy link

Is there maybe an update on this? We are running into sha2 version conflicts now in our codebase and would be happy if this was addressed. Thanks!

vmx added a commit to filecoin-project/ref-fvm that referenced this issue May 24, 2024
@vmx
fix: remove the pairing feature from fvm_shared
8a367f9 
The `pairing` feature from the `fvm_shared` crate isn't used. It causes
problems, as it forces the `subtle` dependency to v2.4.1, although the
rest is happy to have v2.5.0.

Here is a detailed dependency graph and issue outline:

`fvm_shared` depends on `bls-signatures`.
In `bls-signatures` we depend on an old version (v0.11) of `hkdf`.
That version depends on `hmac` v0.11, which depends on `crypto-mac` v0.11.
`crypto-mac` v0.11.0 depends on `subtle` v2. That is fine, it would
automatically select v2.5.0.
The problem is that `crypto-mac` v0.11.1 pins `subtle` to exactly v2.4,
therefore v2.5.0 won't be selected.

The obvious thing is to upgrade in`bls-signatures` the version of `hkdf`
to the latest v0.12.
That would make it possible to use `subtle` v2.5.0.
The problem is that such an upgrade is not easily possible.
`hkdf` v0.12 depends on a newer version v0.10 of the `sha2` crate.
Updating that breaks the `bls12_381` crate.
The reason is the current version v0.8.0 of `bls12_381` depends on an old
version v0.9 of the `digest` crate.

The obvious thing is to upgrade in `bls12_381` the version of `digest` to
v0.10.
That would make it possible to get `hkdf` v0.12 built.
But such an upgrade is and open issue at
zkcrypto/bls12_381#102, which mentions that it's
blocked on zkcrypto/bls12_381#90.
That pull request is about updating do the hash-to-curve draft v16, currently
it's using v12.
We use that code path in `bls-signatures`, else we wouldn't enable the
`experimental` feature of `bls12_381`.
So it's even not clear if we'd want such a change to v16.
@vmx vmx mentioned this issue May 24, 2024
Merged
vmx added a commit to filecoin-project/ref-fvm that referenced this issue May 24, 2024
@vmx
fix: remove the pairing feature from fvm_shared
fe2665c 
The `pairing` feature from the `fvm_shared` crate isn't used. It causes
problems, as it forces the `subtle` dependency to v2.4.1, although the
rest is happy to have v2.5.0.

Here is a detailed dependency graph and issue outline:

`fvm_shared` depends on `bls-signatures`.
In `bls-signatures` we depend on an old version (v0.11) of `hkdf`.
That version depends on `hmac` v0.11, which depends on `crypto-mac` v0.11.
`crypto-mac` v0.11.0 depends on `subtle` v2. That is fine, it would
automatically select v2.5.0.
The problem is that `crypto-mac` v0.11.1 pins `subtle` to exactly v2.4,
therefore v2.5.0 won't be selected.

The obvious thing is to upgrade in`bls-signatures` the version of `hkdf`
to the latest v0.12.
That would make it possible to use `subtle` v2.5.0.
The problem is that such an upgrade is not easily possible.
`hkdf` v0.12 depends on a newer version v0.10 of the `sha2` crate.
Updating that breaks the `bls12_381` crate.
The reason is the current version v0.8.0 of `bls12_381` depends on an old
version v0.9 of the `digest` crate.

The obvious thing is to upgrade in `bls12_381` the version of `digest` to
v0.10.
That would make it possible to get `hkdf` v0.12 built.
But such an upgrade is and open issue at
zkcrypto/bls12_381#102, which mentions that it's
blocked on zkcrypto/bls12_381#90.
That pull request is about updating do the hash-to-curve draft v16, currently
it's using v12.
We use that code path in `bls-signatures`, else we wouldn't enable the
`experimental` feature of `bls12_381`.
So it's even not clear if we'd want such a change to v16.
Stebalien pushed a commit to filecoin-project/ref-fvm that referenced this issue May 24, 2024
@vmx
fix: remove the pairing feature from fvm_shared (#2009)
206a772 
The `pairing` feature from the `fvm_shared` crate isn't used. It causes
problems, as it forces the `subtle` dependency to v2.4.1, although the
rest is happy to have v2.5.0.

Here is a detailed dependency graph and issue outline:

`fvm_shared` depends on `bls-signatures`.
In `bls-signatures` we depend on an old version (v0.11) of `hkdf`.
That version depends on `hmac` v0.11, which depends on `crypto-mac` v0.11.
`crypto-mac` v0.11.0 depends on `subtle` v2. That is fine, it would
automatically select v2.5.0.
The problem is that `crypto-mac` v0.11.1 pins `subtle` to exactly v2.4,
therefore v2.5.0 won't be selected.

The obvious thing is to upgrade in`bls-signatures` the version of `hkdf`
to the latest v0.12.
That would make it possible to use `subtle` v2.5.0.
The problem is that such an upgrade is not easily possible.
`hkdf` v0.12 depends on a newer version v0.10 of the `sha2` crate.
Updating that breaks the `bls12_381` crate.
The reason is the current version v0.8.0 of `bls12_381` depends on an old
version v0.9 of the `digest` crate.

The obvious thing is to upgrade in `bls12_381` the version of `digest` to
v0.10.
That would make it possible to get `hkdf` v0.12 built.
But such an upgrade is and open issue at
zkcrypto/bls12_381#102, which mentions that it's
blocked on zkcrypto/bls12_381#90.
That pull request is about updating do the hash-to-curve draft v16, currently
it's using v12.
We use that code path in `bls-signatures`, else we wouldn't enable the
`experimental` feature of `bls12_381`.
So it's even not clear if we'd want such a change to v16.
rjan90 pushed a commit to filecoin-project/ref-fvm that referenced this issue Jun 12, 2024
@vmx @rjan90
fix: remove the pairing feature from fvm_shared (#2009)
c5e6576 
The `pairing` feature from the `fvm_shared` crate isn't used. It causes
problems, as it forces the `subtle` dependency to v2.4.1, although the
rest is happy to have v2.5.0.

Here is a detailed dependency graph and issue outline:

`fvm_shared` depends on `bls-signatures`.
In `bls-signatures` we depend on an old version (v0.11) of `hkdf`.
That version depends on `hmac` v0.11, which depends on `crypto-mac` v0.11.
`crypto-mac` v0.11.0 depends on `subtle` v2. That is fine, it would
automatically select v2.5.0.
The problem is that `crypto-mac` v0.11.1 pins `subtle` to exactly v2.4,
therefore v2.5.0 won't be selected.

The obvious thing is to upgrade in`bls-signatures` the version of `hkdf`
to the latest v0.12.
That would make it possible to use `subtle` v2.5.0.
The problem is that such an upgrade is not easily possible.
`hkdf` v0.12 depends on a newer version v0.10 of the `sha2` crate.
Updating that breaks the `bls12_381` crate.
The reason is the current version v0.8.0 of `bls12_381` depends on an old
version v0.9 of the `digest` crate.

The obvious thing is to upgrade in `bls12_381` the version of `digest` to
v0.10.
That would make it possible to get `hkdf` v0.12 built.
But such an upgrade is and open issue at
zkcrypto/bls12_381#102, which mentions that it's
blocked on zkcrypto/bls12_381#90.
That pull request is about updating do the hash-to-curve draft v16, currently
it's using v12.
We use that code path in `bls-signatures`, else we wouldn't enable the
`experimental` feature of `bls12_381`.
So it's even not clear if we'd want such a change to v16.
rjan90 pushed a commit to filecoin-project/ref-fvm that referenced this issue Jun 12, 2024
@vmx @rjan90
fix: remove the pairing feature from fvm_shared (#2009)
cdadf15 
The `pairing` feature from the `fvm_shared` crate isn't used. It causes
problems, as it forces the `subtle` dependency to v2.4.1, although the
rest is happy to have v2.5.0.

Here is a detailed dependency graph and issue outline:

`fvm_shared` depends on `bls-signatures`.
In `bls-signatures` we depend on an old version (v0.11) of `hkdf`.
That version depends on `hmac` v0.11, which depends on `crypto-mac` v0.11.
`crypto-mac` v0.11.0 depends on `subtle` v2. That is fine, it would
automatically select v2.5.0.
The problem is that `crypto-mac` v0.11.1 pins `subtle` to exactly v2.4,
therefore v2.5.0 won't be selected.

The obvious thing is to upgrade in`bls-signatures` the version of `hkdf`
to the latest v0.12.
That would make it possible to use `subtle` v2.5.0.
The problem is that such an upgrade is not easily possible.
`hkdf` v0.12 depends on a newer version v0.10 of the `sha2` crate.
Updating that breaks the `bls12_381` crate.
The reason is the current version v0.8.0 of `bls12_381` depends on an old
version v0.9 of the `digest` crate.

The obvious thing is to upgrade in `bls12_381` the version of `digest` to
v0.10.
That would make it possible to get `hkdf` v0.12 built.
But such an upgrade is and open issue at
zkcrypto/bls12_381#102, which mentions that it's
blocked on zkcrypto/bls12_381#90.
That pull request is about updating do the hash-to-curve draft v16, currently
it's using v12.
We use that code path in `bls-signatures`, else we wouldn't enable the
`experimental` feature of `bls12_381`.
So it's even not clear if we'd want such a change to v16.
Stebalien pushed a commit to filecoin-project/ref-fvm that referenced this issue Jun 13, 2024
@rjan90 @vmx
chore: release fvm v3.10.0 (#2016)
3c5da7e 
* Update `filecoin-proofs-api` to v18

Update `filecoin-proofs-api` to v18

* Bump to 3.10.0

Bump to 3.10.0

* Update cargo.lock and changelog

Update cargo.lock and changelog

* fix: remove the pairing feature from fvm_shared (#2009)

The `pairing` feature from the `fvm_shared` crate isn't used. It causes
problems, as it forces the `subtle` dependency to v2.4.1, although the
rest is happy to have v2.5.0.

Here is a detailed dependency graph and issue outline:

`fvm_shared` depends on `bls-signatures`.
In `bls-signatures` we depend on an old version (v0.11) of `hkdf`.
That version depends on `hmac` v0.11, which depends on `crypto-mac` v0.11.
`crypto-mac` v0.11.0 depends on `subtle` v2. That is fine, it would
automatically select v2.5.0.
The problem is that `crypto-mac` v0.11.1 pins `subtle` to exactly v2.4,
therefore v2.5.0 won't be selected.

The obvious thing is to upgrade in`bls-signatures` the version of `hkdf`
to the latest v0.12.
That would make it possible to use `subtle` v2.5.0.
The problem is that such an upgrade is not easily possible.
`hkdf` v0.12 depends on a newer version v0.10 of the `sha2` crate.
Updating that breaks the `bls12_381` crate.
The reason is the current version v0.8.0 of `bls12_381` depends on an old
version v0.9 of the `digest` crate.

The obvious thing is to upgrade in `bls12_381` the version of `digest` to
v0.10.
That would make it possible to get `hkdf` v0.12 built.
But such an upgrade is and open issue at
zkcrypto/bls12_381#102, which mentions that it's
blocked on zkcrypto/bls12_381#90.
That pull request is about updating do the hash-to-curve draft v16, currently
it's using v12.
We use that code path in `bls-signatures`, else we wouldn't enable the
`experimental` feature of `bls12_381`.
So it's even not clear if we'd want such a change to v16.

* Update Changelog.md with #2009 backport

Update Changelog.md with #2009 backport

* Update fvm_shared to 3.10.0

Update fvm_shared to 3.10.0 in `testing/integration/Cargo.toml`

* Update fvm_shared to v3.10.0

Update fvm_shared to v3.10.0

* Update cargo.lock

Update cargo.lock by running `cargo check --all`

* Update `shared/CHANGELOG.md`

Update `shared/CHANGELOG.md`

---------

Co-authored-by: Volker Mische <volker.mische@gmail.com>
Stebalien pushed a commit to filecoin-project/ref-fvm that referenced this issue Jun 13, 2024
@rjan90 @vmx
chore: release fvm v2.8.0 (#2017)
cefb3d1 
* Update filecoin-proofs-api to v18

Update filecoin-proofs-api to v18

* Bump to 2.8.0

Bump to 2.8.0

* Update cargo.lock and changelog

Update cargo.lock and changelog

* fix: remove the pairing feature from fvm_shared (#2009)

The `pairing` feature from the `fvm_shared` crate isn't used. It causes
problems, as it forces the `subtle` dependency to v2.4.1, although the
rest is happy to have v2.5.0.

Here is a detailed dependency graph and issue outline:

`fvm_shared` depends on `bls-signatures`.
In `bls-signatures` we depend on an old version (v0.11) of `hkdf`.
That version depends on `hmac` v0.11, which depends on `crypto-mac` v0.11.
`crypto-mac` v0.11.0 depends on `subtle` v2. That is fine, it would
automatically select v2.5.0.
The problem is that `crypto-mac` v0.11.1 pins `subtle` to exactly v2.4,
therefore v2.5.0 won't be selected.

The obvious thing is to upgrade in`bls-signatures` the version of `hkdf`
to the latest v0.12.
That would make it possible to use `subtle` v2.5.0.
The problem is that such an upgrade is not easily possible.
`hkdf` v0.12 depends on a newer version v0.10 of the `sha2` crate.
Updating that breaks the `bls12_381` crate.
The reason is the current version v0.8.0 of `bls12_381` depends on an old
version v0.9 of the `digest` crate.

The obvious thing is to upgrade in `bls12_381` the version of `digest` to
v0.10.
That would make it possible to get `hkdf` v0.12 built.
But such an upgrade is and open issue at
zkcrypto/bls12_381#102, which mentions that it's
blocked on zkcrypto/bls12_381#90.
That pull request is about updating do the hash-to-curve draft v16, currently
it's using v12.
We use that code path in `bls-signatures`, else we wouldn't enable the
`experimental` feature of `bls12_381`.
So it's even not clear if we'd want such a change to v16.

* Update cargo.lock and Changelog.md

Update cargo.locl and Changelog.md

* Update fvm_shared, cargo.lock and changelog

Update fvm_shared, cargo.lock and changelog

---------

Co-authored-by: Volker Mische <volker.mische@gmail.com>
@fspreiss
Copy link

I made an attempt to upgrade sha2/sha3/digest to 0.10 in #130.

I'm aware that this conflicts with #90 (as stated above), but there was no activity for over a year on #90, so maybe #130 can be an acceptable intermediate step.

@fspreiss fspreiss linked a pull request Jun 17, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Upgrade sha2/sha3/digest from 0.9 to 0.10 fspreiss/bls12_381
3 participants
@webmaster128 @fspreiss @str4d