Replace Digest-related blanket impls with methods - #16

Merged
tarcieri merged 1 commit into
masterfrom
replace-blanket-impls-with-trait-methods
Jun 6, 2019
Merged

Replace Digest-related blanket impls with methods#16
tarcieri merged 1 commit into
masterfrom
replace-blanket-impls-with-trait-methods

Conversation

@tarcieri

@tarcieritarcieri commented Jun 5, 2019

Copy link
Copy Markdown
Member

The current "clever" blanket impl (for which I'm entirely responsible!) seems to have bounds which prevent anything from implementing Signer or Verifier when the digest feature is enabled:

 = note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`

(I don't even understand the note: downstream crates... issue as I wasn't aware it was possible for a downstream crate to impl a trait in one upstream dependency for a type in another upstream dependency, however the note: upstream crates may add new impl of trait DigestSigner seems like a dealbreaker)

This commit, while a bit ugly, at least eliminates all of the complexity around bounds on the blanket impl by entirely removing the blanket impl, and adding an additional method to precompute the digest.

I'm not entirely happy with this and think the method names are a bit confusing and not descriptive enough, but it does have the following rather nice properties:

  • Easy to reason about: no blanket impls
  • Allows the same type to impl both the Digest and non-Digest forms
    of Signer and Verifier simultaneously.

There are a lot of potential directions this could go in order to improve the API, potentially splitting it into two traits rather than one (which gets us back to the Sha*Signer/Sha*Verifier traits which
Signatory used originally), however I think this is the MVP for actually using the signature crate in Signatory, so I'd like to start with this and then iterate towards a better API.

@tarcieri
Replace Digest-related blanket impls with methods
6c0c9e2
The current "clever" blanket impl (for which I'm entirely responsible!)
seems to have bounds which prevent anything from implementing `Signer`
or `Verifier` when the `digest` feature is enabled:
```
= note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`
```
This commit, while a bit ugly, at least eliminates all of the complexity
around bounds on the blanket impl by entirely removing the blanket impl,
and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit
confusing and not descriptive enough, but it does have the following
rather nice properties:
- Easy to reason about: no blanket impls
- Allows the same type to impl both the `Digest` and non-`Digest` forms
of `Signer` and `Verifier` simultaneously.
There are a lot of potential directions this could go in order to
improve the API, potentially splitting it into two traits rather than
one (which gets us back to the `Sha*Signer`/`Sha*Verifier` traits which
Signatory used originally), however I think this is the MVP for actually
using the `signature` crate in Signatory, so I'd like to start with this
and then iterate towards a better API.
@tarcieri

tarcieri commented Jun 5, 2019

Copy link
Copy Markdown
MemberAuthor

I am going to attempt to finish retrofitting signature into Signatory using this change, and if it works out, I'd like to merge this and cut another release, and then we can discuss paths forward which provide a nicer API. Perhaps we should revisit some of the approaches @newpavlov was originally proposing for layering an object-safe API on top of a concrete API.

@tarcieri

tarcieri commented Jun 5, 2019

Copy link
Copy Markdown
MemberAuthor

In other news, it seems our DigestSigner trait is incompatible with ed25519-dalek's sign_prehashed, since it takes a Digest instance as input:

https://docs.rs/ed25519-dalek/1.0.0-pre.1/ed25519_dalek/struct.Keypair.html#method.sign_prehashed

@tarcieri

tarcieri commented Jun 6, 2019

Copy link
Copy Markdown
MemberAuthor

It looks like this (and one additional PR) will be sufficient to get Signatory to compile against the signature crate.

Here is my tentative plan:

  • Merge this, PR the additional necessary changes (see DigestSigner comment above), merge that, and release v0.2.0-pre.1
  • Revisit the blanket impl. I think it will work if constrained to particular digests, which in practice for common signature algorithms is generally the case.

This API is bad and shouldn't go out in a final release, but Signatory is a great testbed for how this stuff actually works in practice, and I want to get it working with some released crate until we can discuss options for the blanket impl.

@tarcieri
tarcieri merged commit 566002e into masterJun 6, 2019
@tarcieri
tarcieri deleted the replace-blanket-impls-with-trait-methods branch June 6, 2019 16:32
tarcieri added a commit that referenced this pull request Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
ca76118
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
tarcieri added a commit that referenced this pull request Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
6edecb6
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
@tarcieritarcieri mentioned this pull request Jun 6, 2019
Merged
tarcieri added a commit that referenced this pull request Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
559fe47
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit that referenced this pull request Jun 7, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
338dbb1
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit that referenced this pull request Oct 9, 2019
@tarcieri
signature-crate: Remove DigestSignature
e7be249
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed. This commit removes it.
@tarcieritarcieri mentioned this pull request Oct 9, 2019
Merged
tarcieri added a commit that referenced this pull request Oct 9, 2019
@tarcieri
signature-crate: Replace DigestSignature with derive attr
48e33d8
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed.
This commit replaces it with a `#[digest(...)]` custom derive attribute
which can be used to specify the digest which should be used when
computing a signature.
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@tarcieri
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Replace Digest-related blanket impls with methods - #16
Merged
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Jun 6, 2019
Merged
Replace Digest-related blanket impls with methods#16
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Conversation
@tarcieri
@tarcieritarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

Member
The current "clever" blanket impl (for which I'm entirely responsible!) seems to have bounds which prevent anything from implementing Signer or Verifier when the digest feature is enabled:
 = note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`

(I don't even understand the note: downstream crates... issue as I wasn't aware it was possible for a downstream crate to impl a trait in one upstream dependency for a type in another upstream dependency, however the note: upstream crates may add new impl of trait DigestSigner seems like a dealbreaker)
This commit, while a bit ugly, at least eliminates all of the complexity around bounds on the blanket impl by entirely removing the blanket impl, and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit confusing and not descriptive enough, but it does have the following rather nice properties:
  • Easy to reason about: no blanket impls
  • Allows the same type to impl both the Digest and non-Digest forms
    
of Signer and Verifier simultaneously.
There are a lot of potential directions this could go in order to improve the API, potentially splitting it into two traits rather than one (which gets us back to the Sha*Signer/Sha*Verifier traits which

Signatory used originally), however I think this is the MVP for actually using the signature crate in Signatory, so I'd like to start with this and then iterate towards a better API.
@tarcieri
Replace Digest-related blanket impls with methods
6c0c9e2
The current "clever" blanket impl (for which I'm entirely responsible!)
seems to have bounds which prevent anything from implementing `Signer`
or `Verifier` when the `digest` feature is enabled:
```
= note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`
```
This commit, while a bit ugly, at least eliminates all of the complexity
around bounds on the blanket impl by entirely removing the blanket impl,
and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit
confusing and not descriptive enough, but it does have the following
rather nice properties:
- Easy to reason about: no blanket impls
- Allows the same type to impl both the `Digest` and non-`Digest` forms
of `Signer` and `Verifier` simultaneously.
There are a lot of potential directions this could go in order to
improve the API, potentially splitting it into two traits rather than
one (which gets us back to the `Sha*Signer`/`Sha*Verifier` traits which
Signatory used originally), however I think this is the MVP for actually
using the `signature` crate in Signatory, so I'd like to start with this
and then iterate towards a better API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
I am going to attempt to finish retrofitting signature into Signatory using this change, and if it works out, I'd like to merge this and cut another release, and then we can discuss paths forward which provide a nicer API. Perhaps we should revisit some of the approaches @newpavlov was originally proposing for layering an object-safe API on top of a concrete API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
In other news, it seems our DigestSigner trait is incompatible with ed25519-dalek's sign_prehashed, since it takes a Digest instance as input:
https://docs.rs/ed25519-dalek/1.0.0-pre.1/ed25519_dalek/struct.Keypair.html#method.sign_prehashed
@tarcieri
tarcieri
commented
Jun 6, 2019

Copy link


Copy Markdown

MemberAuthor
It looks like this (and one additional PR) will be sufficient to get Signatory to compile against the signature crate.
Here is my tentative plan:
  • Merge this, PR the additional necessary changes (see DigestSigner comment above), merge that, and release v0.2.0-pre.1
  • Revisit the blanket impl. I think it will work if constrained to particular digests, which in practice for common signature algorithms is generally the case.
This API is bad and shouldn't go out in a final release, but Signatory is a great testbed for how this stuff actually works in practice, and I want to get it working with some released crate until we can discuss options for the blanket impl.
@tarcieri
tarcieri
merged commit 566002e
into
masterJun 6, 2019
@tarcieri
tarcieri
deleted the

replace-blanket-impls-with-trait-methods

branch
June 6, 2019 16:32
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
ca76118
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
6edecb6
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
@tarcieritarcieri
mentioned this pull request
Jun 6, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
559fe47
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Jun 7, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
338dbb1
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Remove DigestSignature
e7be249
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed. This commit removes it.
@tarcieritarcieri
mentioned this pull request
Oct 9, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Replace DigestSignature with derive attr
48e33d8
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed.
This commit replaces it with a `#[digest(...)]` custom derive attribute
which can be used to specify the digest which should be used when
computing a signature.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@tarcieri

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Replace Digest-related blanket impls with methods - #16
Merged
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Jun 6, 2019
Merged
Replace Digest-related blanket impls with methods#16
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Conversation
@tarcieri
@tarcieritarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

Member
The current "clever" blanket impl (for which I'm entirely responsible!) seems to have bounds which prevent anything from implementing Signer or Verifier when the digest feature is enabled:
 = note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`

(I don't even understand the note: downstream crates... issue as I wasn't aware it was possible for a downstream crate to impl a trait in one upstream dependency for a type in another upstream dependency, however the note: upstream crates may add new impl of trait DigestSigner seems like a dealbreaker)
This commit, while a bit ugly, at least eliminates all of the complexity around bounds on the blanket impl by entirely removing the blanket impl, and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit confusing and not descriptive enough, but it does have the following rather nice properties:
  • Easy to reason about: no blanket impls
  • Allows the same type to impl both the Digest and non-Digest forms
    
of Signer and Verifier simultaneously.
There are a lot of potential directions this could go in order to improve the API, potentially splitting it into two traits rather than one (which gets us back to the Sha*Signer/Sha*Verifier traits which

Signatory used originally), however I think this is the MVP for actually using the signature crate in Signatory, so I'd like to start with this and then iterate towards a better API.
@tarcieri
Replace Digest-related blanket impls with methods
6c0c9e2
The current "clever" blanket impl (for which I'm entirely responsible!)
seems to have bounds which prevent anything from implementing `Signer`
or `Verifier` when the `digest` feature is enabled:
```
= note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`
```
This commit, while a bit ugly, at least eliminates all of the complexity
around bounds on the blanket impl by entirely removing the blanket impl,
and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit
confusing and not descriptive enough, but it does have the following
rather nice properties:
- Easy to reason about: no blanket impls
- Allows the same type to impl both the `Digest` and non-`Digest` forms
of `Signer` and `Verifier` simultaneously.
There are a lot of potential directions this could go in order to
improve the API, potentially splitting it into two traits rather than
one (which gets us back to the `Sha*Signer`/`Sha*Verifier` traits which
Signatory used originally), however I think this is the MVP for actually
using the `signature` crate in Signatory, so I'd like to start with this
and then iterate towards a better API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
I am going to attempt to finish retrofitting signature into Signatory using this change, and if it works out, I'd like to merge this and cut another release, and then we can discuss paths forward which provide a nicer API. Perhaps we should revisit some of the approaches @newpavlov was originally proposing for layering an object-safe API on top of a concrete API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
In other news, it seems our DigestSigner trait is incompatible with ed25519-dalek's sign_prehashed, since it takes a Digest instance as input:
https://docs.rs/ed25519-dalek/1.0.0-pre.1/ed25519_dalek/struct.Keypair.html#method.sign_prehashed
@tarcieri
tarcieri
commented
Jun 6, 2019

Copy link


Copy Markdown

MemberAuthor
It looks like this (and one additional PR) will be sufficient to get Signatory to compile against the signature crate.
Here is my tentative plan:
  • Merge this, PR the additional necessary changes (see DigestSigner comment above), merge that, and release v0.2.0-pre.1
  • Revisit the blanket impl. I think it will work if constrained to particular digests, which in practice for common signature algorithms is generally the case.
This API is bad and shouldn't go out in a final release, but Signatory is a great testbed for how this stuff actually works in practice, and I want to get it working with some released crate until we can discuss options for the blanket impl.
@tarcieri
tarcieri
merged commit 566002e
into
masterJun 6, 2019
@tarcieri
tarcieri
deleted the

replace-blanket-impls-with-trait-methods

branch
June 6, 2019 16:32
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
ca76118
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
6edecb6
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
@tarcieritarcieri
mentioned this pull request
Jun 6, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
559fe47
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Jun 7, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
338dbb1
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Remove DigestSignature
e7be249
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed. This commit removes it.
@tarcieritarcieri
mentioned this pull request
Oct 9, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Replace DigestSignature with derive attr
48e33d8
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed.
This commit replaces it with a `#[digest(...)]` custom derive attribute
which can be used to specify the digest which should be used when
computing a signature.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@tarcieri

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Replace Digest-related blanket impls with methods - #16
Merged
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Jun 6, 2019
Merged
Replace Digest-related blanket impls with methods#16
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Conversation
@tarcieri
@tarcieritarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

Member
The current "clever" blanket impl (for which I'm entirely responsible!) seems to have bounds which prevent anything from implementing Signer or Verifier when the digest feature is enabled:
 = note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`

(I don't even understand the note: downstream crates... issue as I wasn't aware it was possible for a downstream crate to impl a trait in one upstream dependency for a type in another upstream dependency, however the note: upstream crates may add new impl of trait DigestSigner seems like a dealbreaker)
This commit, while a bit ugly, at least eliminates all of the complexity around bounds on the blanket impl by entirely removing the blanket impl, and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit confusing and not descriptive enough, but it does have the following rather nice properties:
  • Easy to reason about: no blanket impls
  • Allows the same type to impl both the Digest and non-Digest forms
    
of Signer and Verifier simultaneously.
There are a lot of potential directions this could go in order to improve the API, potentially splitting it into two traits rather than one (which gets us back to the Sha*Signer/Sha*Verifier traits which

Signatory used originally), however I think this is the MVP for actually using the signature crate in Signatory, so I'd like to start with this and then iterate towards a better API.
@tarcieri
Replace Digest-related blanket impls with methods
6c0c9e2
The current "clever" blanket impl (for which I'm entirely responsible!)
seems to have bounds which prevent anything from implementing `Signer`
or `Verifier` when the `digest` feature is enabled:
```
= note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`
```
This commit, while a bit ugly, at least eliminates all of the complexity
around bounds on the blanket impl by entirely removing the blanket impl,
and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit
confusing and not descriptive enough, but it does have the following
rather nice properties:
- Easy to reason about: no blanket impls
- Allows the same type to impl both the `Digest` and non-`Digest` forms
of `Signer` and `Verifier` simultaneously.
There are a lot of potential directions this could go in order to
improve the API, potentially splitting it into two traits rather than
one (which gets us back to the `Sha*Signer`/`Sha*Verifier` traits which
Signatory used originally), however I think this is the MVP for actually
using the `signature` crate in Signatory, so I'd like to start with this
and then iterate towards a better API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
I am going to attempt to finish retrofitting signature into Signatory using this change, and if it works out, I'd like to merge this and cut another release, and then we can discuss paths forward which provide a nicer API. Perhaps we should revisit some of the approaches @newpavlov was originally proposing for layering an object-safe API on top of a concrete API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
In other news, it seems our DigestSigner trait is incompatible with ed25519-dalek's sign_prehashed, since it takes a Digest instance as input:
https://docs.rs/ed25519-dalek/1.0.0-pre.1/ed25519_dalek/struct.Keypair.html#method.sign_prehashed
@tarcieri
tarcieri
commented
Jun 6, 2019

Copy link


Copy Markdown

MemberAuthor
It looks like this (and one additional PR) will be sufficient to get Signatory to compile against the signature crate.
Here is my tentative plan:
  • Merge this, PR the additional necessary changes (see DigestSigner comment above), merge that, and release v0.2.0-pre.1
  • Revisit the blanket impl. I think it will work if constrained to particular digests, which in practice for common signature algorithms is generally the case.
This API is bad and shouldn't go out in a final release, but Signatory is a great testbed for how this stuff actually works in practice, and I want to get it working with some released crate until we can discuss options for the blanket impl.
@tarcieri
tarcieri
merged commit 566002e
into
masterJun 6, 2019
@tarcieri
tarcieri
deleted the

replace-blanket-impls-with-trait-methods

branch
June 6, 2019 16:32
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
ca76118
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
6edecb6
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
@tarcieritarcieri
mentioned this pull request
Jun 6, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
559fe47
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Jun 7, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
338dbb1
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Remove DigestSignature
e7be249
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed. This commit removes it.
@tarcieritarcieri
mentioned this pull request
Oct 9, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Replace DigestSignature with derive attr
48e33d8
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed.
This commit replaces it with a `#[digest(...)]` custom derive attribute
which can be used to specify the digest which should be used when
computing a signature.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@tarcieri

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Replace Digest-related blanket impls with methods - #16
Merged
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Jun 6, 2019
Merged
Replace Digest-related blanket impls with methods#16
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Conversation
@tarcieri
@tarcieritarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

Member
The current "clever" blanket impl (for which I'm entirely responsible!) seems to have bounds which prevent anything from implementing Signer or Verifier when the digest feature is enabled:
 = note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`

(I don't even understand the note: downstream crates... issue as I wasn't aware it was possible for a downstream crate to impl a trait in one upstream dependency for a type in another upstream dependency, however the note: upstream crates may add new impl of trait DigestSigner seems like a dealbreaker)
This commit, while a bit ugly, at least eliminates all of the complexity around bounds on the blanket impl by entirely removing the blanket impl, and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit confusing and not descriptive enough, but it does have the following rather nice properties:
  • Easy to reason about: no blanket impls
  • Allows the same type to impl both the Digest and non-Digest forms
    
of Signer and Verifier simultaneously.
There are a lot of potential directions this could go in order to improve the API, potentially splitting it into two traits rather than one (which gets us back to the Sha*Signer/Sha*Verifier traits which

Signatory used originally), however I think this is the MVP for actually using the signature crate in Signatory, so I'd like to start with this and then iterate towards a better API.
@tarcieri
Replace Digest-related blanket impls with methods
6c0c9e2
The current "clever" blanket impl (for which I'm entirely responsible!)
seems to have bounds which prevent anything from implementing `Signer`
or `Verifier` when the `digest` feature is enabled:
```
= note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`
```
This commit, while a bit ugly, at least eliminates all of the complexity
around bounds on the blanket impl by entirely removing the blanket impl,
and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit
confusing and not descriptive enough, but it does have the following
rather nice properties:
- Easy to reason about: no blanket impls
- Allows the same type to impl both the `Digest` and non-`Digest` forms
of `Signer` and `Verifier` simultaneously.
There are a lot of potential directions this could go in order to
improve the API, potentially splitting it into two traits rather than
one (which gets us back to the `Sha*Signer`/`Sha*Verifier` traits which
Signatory used originally), however I think this is the MVP for actually
using the `signature` crate in Signatory, so I'd like to start with this
and then iterate towards a better API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
I am going to attempt to finish retrofitting signature into Signatory using this change, and if it works out, I'd like to merge this and cut another release, and then we can discuss paths forward which provide a nicer API. Perhaps we should revisit some of the approaches @newpavlov was originally proposing for layering an object-safe API on top of a concrete API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
In other news, it seems our DigestSigner trait is incompatible with ed25519-dalek's sign_prehashed, since it takes a Digest instance as input:
https://docs.rs/ed25519-dalek/1.0.0-pre.1/ed25519_dalek/struct.Keypair.html#method.sign_prehashed
@tarcieri
tarcieri
commented
Jun 6, 2019

Copy link


Copy Markdown

MemberAuthor
It looks like this (and one additional PR) will be sufficient to get Signatory to compile against the signature crate.
Here is my tentative plan:
  • Merge this, PR the additional necessary changes (see DigestSigner comment above), merge that, and release v0.2.0-pre.1
  • Revisit the blanket impl. I think it will work if constrained to particular digests, which in practice for common signature algorithms is generally the case.
This API is bad and shouldn't go out in a final release, but Signatory is a great testbed for how this stuff actually works in practice, and I want to get it working with some released crate until we can discuss options for the blanket impl.
@tarcieri
tarcieri
merged commit 566002e
into
masterJun 6, 2019
@tarcieri
tarcieri
deleted the

replace-blanket-impls-with-trait-methods

branch
June 6, 2019 16:32
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
ca76118
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
6edecb6
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
@tarcieritarcieri
mentioned this pull request
Jun 6, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
559fe47
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Jun 7, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
338dbb1
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Remove DigestSignature
e7be249
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed. This commit removes it.
@tarcieritarcieri
mentioned this pull request
Oct 9, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Replace DigestSignature with derive attr
48e33d8
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed.
This commit replaces it with a `#[digest(...)]` custom derive attribute
which can be used to specify the digest which should be used when
computing a signature.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@tarcieri

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Replace Digest-related blanket impls with methods - #16
Merged
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Jun 6, 2019
Merged
Replace Digest-related blanket impls with methods#16
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Conversation
@tarcieri
@tarcieritarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

Member
The current "clever" blanket impl (for which I'm entirely responsible!) seems to have bounds which prevent anything from implementing Signer or Verifier when the digest feature is enabled:
 = note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`

(I don't even understand the note: downstream crates... issue as I wasn't aware it was possible for a downstream crate to impl a trait in one upstream dependency for a type in another upstream dependency, however the note: upstream crates may add new impl of trait DigestSigner seems like a dealbreaker)
This commit, while a bit ugly, at least eliminates all of the complexity around bounds on the blanket impl by entirely removing the blanket impl, and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit confusing and not descriptive enough, but it does have the following rather nice properties:
  • Easy to reason about: no blanket impls
  • Allows the same type to impl both the Digest and non-Digest forms
    
of Signer and Verifier simultaneously.
There are a lot of potential directions this could go in order to improve the API, potentially splitting it into two traits rather than one (which gets us back to the Sha*Signer/Sha*Verifier traits which

Signatory used originally), however I think this is the MVP for actually using the signature crate in Signatory, so I'd like to start with this and then iterate towards a better API.
@tarcieri
Replace Digest-related blanket impls with methods
6c0c9e2
The current "clever" blanket impl (for which I'm entirely responsible!)
seems to have bounds which prevent anything from implementing `Signer`
or `Verifier` when the `digest` feature is enabled:
```
= note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`
```
This commit, while a bit ugly, at least eliminates all of the complexity
around bounds on the blanket impl by entirely removing the blanket impl,
and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit
confusing and not descriptive enough, but it does have the following
rather nice properties:
- Easy to reason about: no blanket impls
- Allows the same type to impl both the `Digest` and non-`Digest` forms
of `Signer` and `Verifier` simultaneously.
There are a lot of potential directions this could go in order to
improve the API, potentially splitting it into two traits rather than
one (which gets us back to the `Sha*Signer`/`Sha*Verifier` traits which
Signatory used originally), however I think this is the MVP for actually
using the `signature` crate in Signatory, so I'd like to start with this
and then iterate towards a better API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
I am going to attempt to finish retrofitting signature into Signatory using this change, and if it works out, I'd like to merge this and cut another release, and then we can discuss paths forward which provide a nicer API. Perhaps we should revisit some of the approaches @newpavlov was originally proposing for layering an object-safe API on top of a concrete API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
In other news, it seems our DigestSigner trait is incompatible with ed25519-dalek's sign_prehashed, since it takes a Digest instance as input:
https://docs.rs/ed25519-dalek/1.0.0-pre.1/ed25519_dalek/struct.Keypair.html#method.sign_prehashed
@tarcieri
tarcieri
commented
Jun 6, 2019

Copy link


Copy Markdown

MemberAuthor
It looks like this (and one additional PR) will be sufficient to get Signatory to compile against the signature crate.
Here is my tentative plan:
  • Merge this, PR the additional necessary changes (see DigestSigner comment above), merge that, and release v0.2.0-pre.1
  • Revisit the blanket impl. I think it will work if constrained to particular digests, which in practice for common signature algorithms is generally the case.
This API is bad and shouldn't go out in a final release, but Signatory is a great testbed for how this stuff actually works in practice, and I want to get it working with some released crate until we can discuss options for the blanket impl.
@tarcieri
tarcieri
merged commit 566002e
into
masterJun 6, 2019
@tarcieri
tarcieri
deleted the

replace-blanket-impls-with-trait-methods

branch
June 6, 2019 16:32
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
ca76118
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
6edecb6
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
@tarcieritarcieri
mentioned this pull request
Jun 6, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
559fe47
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Jun 7, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
338dbb1
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Remove DigestSignature
e7be249
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed. This commit removes it.
@tarcieritarcieri
mentioned this pull request
Oct 9, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Replace DigestSignature with derive attr
48e33d8
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed.
This commit replaces it with a `#[digest(...)]` custom derive attribute
which can be used to specify the digest which should be used when
computing a signature.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@tarcieri

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Replace Digest-related blanket impls with methods - #16
Merged
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Jun 6, 2019
Merged
Replace Digest-related blanket impls with methods#16
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Conversation
@tarcieri
@tarcieritarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

Member
The current "clever" blanket impl (for which I'm entirely responsible!) seems to have bounds which prevent anything from implementing Signer or Verifier when the digest feature is enabled:
 = note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`

(I don't even understand the note: downstream crates... issue as I wasn't aware it was possible for a downstream crate to impl a trait in one upstream dependency for a type in another upstream dependency, however the note: upstream crates may add new impl of trait DigestSigner seems like a dealbreaker)
This commit, while a bit ugly, at least eliminates all of the complexity around bounds on the blanket impl by entirely removing the blanket impl, and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit confusing and not descriptive enough, but it does have the following rather nice properties:
  • Easy to reason about: no blanket impls
  • Allows the same type to impl both the Digest and non-Digest forms
    
of Signer and Verifier simultaneously.
There are a lot of potential directions this could go in order to improve the API, potentially splitting it into two traits rather than one (which gets us back to the Sha*Signer/Sha*Verifier traits which

Signatory used originally), however I think this is the MVP for actually using the signature crate in Signatory, so I'd like to start with this and then iterate towards a better API.
@tarcieri
Replace Digest-related blanket impls with methods
6c0c9e2
The current "clever" blanket impl (for which I'm entirely responsible!)
seems to have bounds which prevent anything from implementing `Signer`
or `Verifier` when the `digest` feature is enabled:
```
= note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`
```
This commit, while a bit ugly, at least eliminates all of the complexity
around bounds on the blanket impl by entirely removing the blanket impl,
and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit
confusing and not descriptive enough, but it does have the following
rather nice properties:
- Easy to reason about: no blanket impls
- Allows the same type to impl both the `Digest` and non-`Digest` forms
of `Signer` and `Verifier` simultaneously.
There are a lot of potential directions this could go in order to
improve the API, potentially splitting it into two traits rather than
one (which gets us back to the `Sha*Signer`/`Sha*Verifier` traits which
Signatory used originally), however I think this is the MVP for actually
using the `signature` crate in Signatory, so I'd like to start with this
and then iterate towards a better API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
I am going to attempt to finish retrofitting signature into Signatory using this change, and if it works out, I'd like to merge this and cut another release, and then we can discuss paths forward which provide a nicer API. Perhaps we should revisit some of the approaches @newpavlov was originally proposing for layering an object-safe API on top of a concrete API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
In other news, it seems our DigestSigner trait is incompatible with ed25519-dalek's sign_prehashed, since it takes a Digest instance as input:
https://docs.rs/ed25519-dalek/1.0.0-pre.1/ed25519_dalek/struct.Keypair.html#method.sign_prehashed
@tarcieri
tarcieri
commented
Jun 6, 2019

Copy link


Copy Markdown

MemberAuthor
It looks like this (and one additional PR) will be sufficient to get Signatory to compile against the signature crate.
Here is my tentative plan:
  • Merge this, PR the additional necessary changes (see DigestSigner comment above), merge that, and release v0.2.0-pre.1
  • Revisit the blanket impl. I think it will work if constrained to particular digests, which in practice for common signature algorithms is generally the case.
This API is bad and shouldn't go out in a final release, but Signatory is a great testbed for how this stuff actually works in practice, and I want to get it working with some released crate until we can discuss options for the blanket impl.
@tarcieri
tarcieri
merged commit 566002e
into
masterJun 6, 2019
@tarcieri
tarcieri
deleted the

replace-blanket-impls-with-trait-methods

branch
June 6, 2019 16:32
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
ca76118
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
6edecb6
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
@tarcieritarcieri
mentioned this pull request
Jun 6, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
559fe47
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Jun 7, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
338dbb1
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Remove DigestSignature
e7be249
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed. This commit removes it.
@tarcieritarcieri
mentioned this pull request
Oct 9, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Replace DigestSignature with derive attr
48e33d8
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed.
This commit replaces it with a `#[digest(...)]` custom derive attribute
which can be used to specify the digest which should be used when
computing a signature.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@tarcieri

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Replace Digest-related blanket impls with methods - #16
Merged
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Jun 6, 2019
Merged
Replace Digest-related blanket impls with methods#16
tarcieri merged 1 commit into
masterfrom 
replace-blanket-impls-with-trait-methods
Conversation
@tarcieri
@tarcieritarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

Member
The current "clever" blanket impl (for which I'm entirely responsible!) seems to have bounds which prevent anything from implementing Signer or Verifier when the digest feature is enabled:
 = note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`

(I don't even understand the note: downstream crates... issue as I wasn't aware it was possible for a downstream crate to impl a trait in one upstream dependency for a type in another upstream dependency, however the note: upstream crates may add new impl of trait DigestSigner seems like a dealbreaker)
This commit, while a bit ugly, at least eliminates all of the complexity around bounds on the blanket impl by entirely removing the blanket impl, and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit confusing and not descriptive enough, but it does have the following rather nice properties:
  • Easy to reason about: no blanket impls
  • Allows the same type to impl both the Digest and non-Digest forms
    
of Signer and Verifier simultaneously.
There are a lot of potential directions this could go in order to improve the API, potentially splitting it into two traits rather than one (which gets us back to the Sha*Signer/Sha*Verifier traits which

Signatory used originally), however I think this is the MVP for actually using the signature crate in Signatory, so I'd like to start with this and then iterate towards a better API.
@tarcieri
Replace Digest-related blanket impls with methods
6c0c9e2
The current "clever" blanket impl (for which I'm entirely responsible!)
seems to have bounds which prevent anything from implementing `Signer`
or `Verifier` when the `digest` feature is enabled:
```
= note: conflicting implementation in crate `signature`:
- impl<S, T> signature::signer::Signer<S> for T
where S: signature::signature::DigestSignature, T: signature::signer::DigestSigner<<S as signature::signature::DigestSignature>::Digest, S>;
= note: upstream crates may add new impl of trait `signature::signature::DigestSignature` for type `signatory::ed25519::signature::Signature` in future versions
= note: downstream crates may implement trait `signature::signer::DigestSigner<_, signatory::ed25519::signature::Signature>` for type `ed25519::Ed25519Signer`
```
This commit, while a bit ugly, at least eliminates all of the complexity
around bounds on the blanket impl by entirely removing the blanket impl,
and adding an additional method to precompute the digest.
I'm not entirely happy with this and think the method names are a bit
confusing and not descriptive enough, but it does have the following
rather nice properties:
- Easy to reason about: no blanket impls
- Allows the same type to impl both the `Digest` and non-`Digest` forms
of `Signer` and `Verifier` simultaneously.
There are a lot of potential directions this could go in order to
improve the API, potentially splitting it into two traits rather than
one (which gets us back to the `Sha*Signer`/`Sha*Verifier` traits which
Signatory used originally), however I think this is the MVP for actually
using the `signature` crate in Signatory, so I'd like to start with this
and then iterate towards a better API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
I am going to attempt to finish retrofitting signature into Signatory using this change, and if it works out, I'd like to merge this and cut another release, and then we can discuss paths forward which provide a nicer API. Perhaps we should revisit some of the approaches @newpavlov was originally proposing for layering an object-safe API on top of a concrete API.
@tarcieri
tarcieri
commented
Jun 5, 2019

Copy link


Copy Markdown

MemberAuthor
In other news, it seems our DigestSigner trait is incompatible with ed25519-dalek's sign_prehashed, since it takes a Digest instance as input:
https://docs.rs/ed25519-dalek/1.0.0-pre.1/ed25519_dalek/struct.Keypair.html#method.sign_prehashed
@tarcieri
tarcieri
commented
Jun 6, 2019

Copy link


Copy Markdown

MemberAuthor
It looks like this (and one additional PR) will be sufficient to get Signatory to compile against the signature crate.
Here is my tentative plan:
  • Merge this, PR the additional necessary changes (see DigestSigner comment above), merge that, and release v0.2.0-pre.1
  • Revisit the blanket impl. I think it will work if constrained to particular digests, which in practice for common signature algorithms is generally the case.
This API is bad and shouldn't go out in a final release, but Signatory is a great testbed for how this stuff actually works in practice, and I want to get it working with some released crate until we can discuss options for the blanket impl.
@tarcieri
tarcieri
merged commit 566002e
into
masterJun 6, 2019
@tarcieri
tarcieri
deleted the

replace-blanket-impls-with-trait-methods

branch
June 6, 2019 16:32
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
ca76118
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
6edecb6
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #16 does not permit
anything but the blanket impl.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
@tarcieritarcieri
mentioned this pull request
Jun 6, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Jun 6, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
559fe47
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Jun 7, 2019
@tarcieri
signature_derive: Custom derive support for Signer/Verifier
338dbb1
We've explored several different possible trait bounds for a blanket
impl of `Signer` for `DigestSigner` (and likewise for `Verifier`).
Unfortunately, the approach we netted out at in #12 does not permit
anything but the blanket impl, and was removed in #16.
It's definitely still worth exploring if there's a way to define the
bounds of the default impl that works, however there is one approach we
haven't explored yet: a procedural macro.
This approach feels like a bit of a hack, but gets us to where we
originally wanted to be with the blanket impl API-wise. The impl it
derives uses the same approach and bounds as the blanket impl did:
the `Digest` to use is sourced from an associated type of the
`DigestSignature` trait, which means the digest to use is both automatic
and ensures the type deriving the trait supports the expected `Digest`
for the given signature.
The implementation uses `synstructure` which simplifies both handling of
generics and testing the output of the proc macro.
Additionally, it includes a complete integration test of the derived
code which ensures it works as expected.
It's gated under a cargo feature and disabled-by-default. This should
make it unobtrusive for downstream crates which don't need its
functionality.
tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Remove DigestSignature
e7be249
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed. This commit removes it.
@tarcieritarcieri
mentioned this pull request
Oct 9, 2019
 Merged

tarcieri added a commit
that referenced
this pull request
Oct 9, 2019
@tarcieri
signature-crate: Replace DigestSignature with derive attr
48e33d8
The `DigestSignature` trait was originally used as the marker trait used
by a blanket impl of `Signer` for `DigestSigner` and `Verifier` for
`DigestVerifier` (#12, #16).
Unfortunately, this approach turned out to be too inflexible to cover
real-world use cases encountered and was replaced with a proc macro (#18)
The `DigestSignature` trait is leftover from this, and is no longer
needed.
This commit replaces it with a `#[digest(...)]` custom derive attribute
which can be used to specify the digest which should be used when
computing a signature.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@tarcieri