Comments (10)
Now in ring::signature we are using traits. And, of course, it creates a problem: We cannot always say &'static signature::Algorithm but instead have to say &'static (signature::Algorithm + Sync) when referencing algorithms from other statics, because of Rust type system weirdness.
And, it was so awkward I ended up implementing wrapper types to hide the traits.
Separately, I already had to explain this a bit on IRC:
briansmith> right now, you can use ring with "use ring;" or "use ring::{submodule, submodule, submodule};" and everything works.
20:30 But, as soon as you use traits, that stops working, because you need to import the traits too.
20:31 And also, in ring we usually use polymorphism to select between algorithms.
20:31 And so, usually, every implementation of each trait would only have one implementation, each.
20:32 So, instead, in ring I basically emulate per-object (vs per-trait) polymorphism.
20:34 IMO, it is something that should be fixed in the language: when a type implements a trait, it should be able to say "when I am in scope, the trait should also be in scope."
20:34 but, that's not the case yet.
briansmith
from ring.
Reconsider this after the placement box stuff is stable: rust-lang/rfcs#1228
from ring.
It looks like the whole placement new stuff is being tracked in rust-lang/rust#27779. I asked about how to resolve the issues that ring has run into with Traits in rust-lang/rust#27779 (comment).
from ring.
See also https://www.ralfj.de/blog/2015/10/12/formalizing-rust.html: Traits are not in the subset of Rust that they are hoping to define semantics for and/or prove correct.
from ring.
See https://internals.rust-lang.org/t/pre-rfc-thinness-as-a-property-of-the-data-rather-than-the-trait/2794, https://internals.rust-lang.org/t/blog-post-extended-enums-and-thin-traits/2755, https://internals.rust-lang.org/t/blog-post-extended-enums-and-thin-traits/2755, http://smallcultfollowing.com/babysteps/blog/2015/10/08/virtual-structs-part-4-extended-enums-and-thin-traits/.
from ring.
Now in ring::signature
we are using traits. And, of course, it creates a problem: We cannot always say &'static signature::Algorithm
but instead have to say &'static (signature::Algorithm + Sync)
when referencing algorithms from other statics, because of Rust type system weirdness.
from ring.
It looks like VerificationAlgorithm
extends Sync
now - doesn't that solve the problem with verbosity? And is the requirement to import traits separately really a show-stopper?
With function pointers, the algorithm structs become much larger than the double-pointer sized &'static Algorithm
, and it becomes difficult to add more trait implementations like Debug
in future, without introducing even more inefficiencies. It also prevents downstream crates from extending the set of possible algorithms.
From a security perspective, storing multiple function pointers in writable locations on the stack also seems much more dangerous than a reference to a vtable in read-only memory.
from ring.
It looks like VerificationAlgorithm extends Sync now - doesn't that solve the problem with verbosity?
Yes.
And is the requirement to import traits separately really a show-stopper?
It's a real usability problem. But, it's not worse in ring than it is in other APIs.
With function pointers, the algorithm structs become much larger
It doesn't matter, because there is only one copy of every Algorithm
, so I don't think it creates any bloat.
it becomes difficult to add more trait implementations like Debug in future
Not really, because the best implementation of Debug
for Algorithm
types is just to output the name of the algorithm and omit the details anyway.
It also prevents downstream crates from extending the set of possible algorithms.
True. OTOH, we don't have to worry about external crates' implementations when we refactor the code, because of this. People can contribute implementations of new algorithms to ring if they want more algorithms supported.
From a security perspective, storing multiple function pointers in writable locations on the stack also seems much more dangerous than a reference to a vtable in read-only memory.
Very true, but the compiler should be able to put them in read-only memory since they are all static
and not static mut
, just like trait vtables. I'm not sure if the compiler actually does this, though.
from ring.
There is an RFC somewhere to allow types to bring trait methods into scope. I forget where or what the syntax is, but maybe something like struct MyStruct: MyTrait+Sync where ..
. And no movement recently.
from ring.
It doesn't matter, because there is only one copy of every Algorithm, so I don't think it creates any bloat.
Ah, some of my arguments were based on the mistaken assumption that Algorithm
s were passed around by value.
from ring.
Related Issues (20)
- Unsupported architecture compiling for `aarch64-linux-android` using MacOS SDK 14.2 HOT 2
- evaluation of constant value failed -> assert!(cfg!(target_feature = "sse") && cfg!(target_feature = "sse2")) HOT 1
- Error: dangerous relocation: call8: call target out of range:(xtensa-esp32s3-espidf) HOT 1
- assert!(cfg!(target_feature = "sse") && cfg!(target_feature = "sse2")) panic at build on i386, i586, FreeBSD, or many target_os=none x86 targets. HOT 9
- error: failed to run custom build command for `ring v0.16.20` HOT 1
- Consider using `zeroize` crate for key materials HOT 1
- Build fails on i386: evaluation of constant value failed HOT 1
- failure to verify rsa signature on x509 csr HOT 2
- Fails to build on Linux SPARC HOT 10
- warning: [email protected]: aarch64-fslc-linux-gcc: error: unrecognized command-line option ‘-m64’ HOT 3
- Add riscv64 Support HOT 3
- Disclosure Policy HOT 3
- Attempted to use functionality that requires system randomness!! HOT 1
- warning: [email protected]: Compiler family detection failed due to error: ToolNotFound: Failed to find tool. Is `C:\Program` installed? HOT 2
- Ring compile error when trying to cross compile from windows 10 to x86_64-unknown-linux-gnu HOT 2
- Ring no longer builds with Rust 1.61 due to cc dependency HOT 1
- support for RISCV32 HOT 4
- `less-safe-getrandom-custom-or-rdrand` not working on target `x86_64-fortanix-unknown-sgx` HOT 1
- Add store/restore functionality to digest::Context HOT 2
- Build fails on target wasm32-wasi HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ring.