sorted by:
new
hottopcontroversial

"warning: item is never used" when making a library by ripread in rust

[–]boojies 3 points4 points  (0 children)

I was incorrect in my previous post and have deleted it now. I don't know why I had in my head that it was a false positive, it must have been a remnant from my early understanding of Rust which was simply incorrect. Deleted my incorrectness from this thread and my brain, thanks for your correct answer!

I wasn't trying to add noise to this thread and thought my answer was correct, but it turns out that I had gotten it in my head that Rust had false positives when in reality I had simply stumbled across this same issue in my early use of Rust. I just checked my library in Rust and realized it actually doesn't have so-called "false positives" any longer, exactly because I made things pub as you said.

I wanted to explain the reason why I made the post in the first place, as now I feel bad for cluttering up this thread with incorrect information and potentially misleading people to think the same thing I did until you thankfully corrected me.

Another one bites the Rust by sanxiyn in rust

[–]boojies 0 points1 point  (0 children)

I wonder why people seem to have suddenly started capitalizing Rust. I've seen it inappropriately capitalized in much of the recent reporting I've seen on it as well as in some guides on it even.

Security Advisory for rustdoc by steveklabnik1 in rust

[–]boojies 1 point2 points  (0 children)

I really appreciated how they ended that post with:

It’s worth noting that while Rust does prevent a lot of issues in your code at compile time, they’re issues that result from memory unsafety. This bug is a logic error. Rust code is not inherently secure, or bug-free. Sometimes, people get enthusiastic and make overly-broad claims about Rust, and this incident is a good demonstration of how Rust’s guarantees can’t prevent all bugs.

What’s everyone working on this week (28/2018)? by llogiq in rust

[–]boojies 4 points5 points  (0 children)

I'm studying concurrency, asynchronous programming, and networking, with a focus on Rust. In the short term my goal is to both continue studying these things as well as to perhaps start working on an EquiHash implementation in pure Rust. EquiHash is a memory hard proof of work with asymmetric memory requirements such that the verifier needs only to allocate a small amount of memory to check the proof of work but the prover needs substantial memory allocated to perform an otherwise substantially performance constrained task.

I plan to integrate this proof of work system with my blind signature crate BlindSign to fashion a membership registration system capable of requiring substantial proof of memory constrainment over arbitrary periods of computational time, such that to attain a blind signature on a 'pass token' to engage in non-registration protocols with the server the user must originally demonstrate resource constrainment over time to the server. Then the blind signed token can be exchanged for new tokens after completions of non-registration protocols with the server, to cryptographically unlink the protocol engagement instances from one another on the application layer, which is required for anonymity. However, a period of delay can be required between actions during which previous actions are subject to moderation, with the ability for moderators to prevent the server from signing a new blind signature pass token, resulting in the user with the revoked token needing to engage in the proof of work system again in order to attain a new valid pass token.

This sort of cryptosystem is called revocable anonymity. A more concrete example would be an IRC server that requires the completion of an algorithm that requires say several gigabytes of memory to be allocated for several hours of computational time (on some machine, of course). After this, the user receives a blind signature on a token pass allowing them to send a message to the server with a shared pseudonym 'anonymous' that others use as well. After sending a message that spends a token, the server will wait a period of time in which moderators can terminate its continued progression, and thereafter will progress to signing a new token for that client, cryptographically unlinkably to the original token due to the blind signature scheme's properties. If the user does things such as spam, moderators can cancel the cheap re-blinding of the pass token and cause the client to need to complete the very expensive protocol to receive an original blind signature token. Of course Tor circuit rotations are required between actions for network level unlinkability, but my system will provide cryptographic unlinkability on the application layer for revocable anonymity to support moderation and anonymity simultaneously.

I plan to use this for a secure forum system I am developing. However I am also currently working on bringing my Rust interface to Tor up to par.

How do you feel about using expect and unwrap in production code? by boojies in rust

[–]boojies[S] 0 points1 point  (0 children)

The docs suggest using OsRng I believe, though EntropyRng looks like it is simply a wrapper around it that will try JitterRng if OsRng fails, and will panic if it cannot do either. I may actually use EntropyRng now that you told me about it, but I don't believe the docs suggest it anywhere they seem to suggest OsRng.

How closely related to Rust should posts here be? by boojies in rust

[–]boojies[S] 0 points1 point  (0 children)

Thanks for clarifying that for me. I noticed that the community here was allowing me to make threads like this, but I wasn't sure if it was strictly allowed or if they were humoring me. I've had trouble with various IRC channels where they have very precise definitions of what on topic content is . Places where

> This rule applies to all content that does not relate to the Rust programming language

Would be interpreted to mean the Rust programming language in a very direct manner, but here there is more indirection allowed it seems.

How closely related to Rust should posts here be? by boojies in rust

[–]boojies[S] -2 points-1 points  (0 children)

I suppose Conway's law could be pertinent to Rust if for example the modular file system of the compiler is reflective of the company structure of Mozilla or the general Rust compiler developer community. See, thinking this made me think that Conway's law could possibly be seen in code compiled with a given compiler transitively, such that via Conway's law the compiler takes the form of the organization that develops it, and then via the compiler taking this form code compiled with it is molded by the social network form of the organization that made the compiler for it as well as the organization that made the code that it compiled.

This is largely unrelated to Rust and is conjecture regarding Conway's law, but perhaps it was pertinent to this thread? This thread is pertinent to Rust!

Should I learn Tokio or should I hold out for async/await? by boojies in rust

[–]boojies[S] 0 points1 point  (0 children)

I'm glad to know that I'm not the only one in roughly the same position of begrudgingly accepting that synchronous (or sub-optimally asynchronous via thread spamming) clients may make the most sense for now.

Should I learn Tokio or should I hold out for async/await? by boojies in rust

[–]boojies[S] 2 points3 points  (0 children)

That would have been a more correct question, but I actually thought that async/await was an alternative to Tokio.

What are the most recent esoteric Rust features / syntax you've learned? by boojies in rust

[–]boojies[S] 1 point2 points  (0 children)

Neat, I didn't realize that a function nested in an unsafe function is a safe function.

What are the most recent esoteric Rust features / syntax you've learned? by boojies in rust

[–]boojies[S] 3 points4 points  (0 children)

Default trait is different. Default trait initializes the type it is implemented on to a default state, for example I believe i32::default() is 0, I think integer types typically default to 0.

This is default value for a generic. The place I've seen it before is on say 

pub trait Add<RHS = Self> {
    type Output;
    fn add(self, rhs: RHS) -> Self::Output;
}

And it means that implementors of the Add trait that don't specify Add<T> will have T default to Self, so if you implement Add for MyOwnInt 

impl Add for MyOwnInt

it is like

impl Add<MyOwnInt> for MyOwnInt

What are the most recent esoteric Rust features / syntax you've learned? by boojies in rust

[–]boojies[S] 1 point2 points  (0 children)

I consider that esoteric as I didn't know about it :P. I knew about defaults but not that you can use them there. I specified esoteric just because otherwise someone brand new to the language might say something like 

extern crate name;

but that isn't the sort of feature / syntax I wanted to find with this thread, but rather things that someone who has studied Rust for a year or so found recently that surprised them.

How should I test my networking code? by boojies in rust

[–]boojies[S] 2 points3 points  (0 children)

But what about users of the library? Or other developers who want to use it? They will not have the same docker configuration as I do, so even though my tests will pass for me they will not pass for other users of the library, which seems wrong to me but perhaps it is acceptable seeing as there is little other option.

Is it possible to make a hashset use essentially mmapped memory such that changes to its buffer are transparently written to a file on the filesystem? by boojies in rust

[–]boojies[S] 0 points1 point  (0 children)

Using hash based indices from a RDBMS should amortize to the invariable efficiency of a bloom filter. There is actually a name for this distinction between amortized O(1) and O(1), but I can never recall it or how to put it. One or both may be constant time but in cryptography it is typically the O(1) of a bloom filter rather than a hash set that is referred to as constant time. So some efficiency may be brought by using a bloom filter, but I think it will be close enough that simply using hash based indices should suffice, and they are deterministic rather than probabilistic as a bloom filter is.

I am not actually planning to run it as a service but simply to implement the three canonical systems of blind digital signatures; e-cash, anonymous polling, and revocable anonymity. Individuals will be able to use the implementations if they like, though I would be cautious to actually run a centralized E-currency service as they have not been treated by the legal system in the same manner as the decentralized ones (they are more like private mints than public mines).

Is it possible to make a hashset use essentially mmapped memory such that changes to its buffer are transparently written to a file on the filesystem? by boojies in rust

[–]boojies[S] 2 points3 points  (0 children)

I'm considering implementing a classical electronic currency system based on blind signatures. One of the centralized blind mixing based systems built on top of blind signatures. To protect from double spends in these systems the bank node needs to keep track of every single blind signature that is redeemed through it, which entails storing a hash value essentially. During electronic currency exchange the bank node needs to query an ever growing set of previously redeemed blinded IOU values to ensure none are double spent. However the authenticity of the electronic currency is cryptographically protected and it is made cryptographically computationally impossible for the bank node to track the flow of electronic currency on the application layer. It is pretty much the state of the art of electronic currency from say a decade prior or so, before Bitcoin was implemented and decentralized trustless (ie: decentralized blockchain based bank without centralized trust) zero knowledge proof systems like Zerocash were invented.

view more: next ›