Hacker News Reader

Are you talking about the crate `crypto` or `rust-crypto`? Both have not been updated in a couple of years.

The `ring` library is a bit more modern, but still requires a bit of a run around. Here's an example of encrypting a cookie: https://github.com/alexcrichton/cookie-rs/blob/master/src/se...

Why does everyone leap to suggesting that 2016 was some kind of dark age of Rust when no one could be expected to do anything right? You're not the first [1].

I'm reminded of the Onion article about "Stating current year still the leading argument for reform" [2] (e.g. "It's 2019, people!")

I guess the corollary is, "That was 3 years ago" still leading excuse for shoddy work :-p

[1] https://news.ycombinator.com/item?id=18943056

[2] https://www.theonion.com/report-stating-current-year-still-l...

I don't believe that's what the comment you're replying to stated. The fact that `rust-crypto`, for example, has not been updated since 2016 doesn't imply that the code was necessarily bad in 2016, but that the project itself may not be maintained anymore. Static, perfect code is rare.

I know they didn't state it. I said they suggested it. Which they, and the linked comment, did.

When your immediate reply is to dismiss the dominant rust crypto library in 2016 as being understandably bad because the development ended in 2016, you're suggesting that the year (and before) was some kind of dark age for rust.

>Static, perfect code is rare.

My criticism isn't "hey, there's a lingering bug that no one fixed and which broke my use case". My criticism is, "The design of the exposed interface to the core library functionality forces me to care about irrelevant implementation details and enable attributes (mutability) that my use case doesn't need."

When you say that a project developed in 2016 can be expected to fail on that front, what you're saying is, 2016 was too early to expect developers of a major project (in a hot language followed by a lot of smart people) to understand the concept of separation of concerns and abstraction of irrelevant details.

Do you see why I might be skeptical of the relevance of the year of development?

There's a similar point to be made about (the lack of) clear examples, a concept that didn't spring into existence in 2017.

> When your immediate reply is to dismiss the dominant rust crypto library in 2016 as being understandably bad because the development ended in 2016, you're suggesting that the year (and before) was some kind of dark age for rust.

I was there and it actually was.

Rust 1.0 was just released and the ecosystem was mostly maturing at that point.

You're talking about version 0.2.36 of a library that had been in development for less than two years during a quite tempestuous time in Rust. I'm sure they were more concerned with making the code work, making it secure, etc.

When somebody says "have not been updated in a couple of years," they are really just saying that the code is unmaintained. Unmaintained code is bad code, no matter what year it is from.

Unmaintained code can explain edge-case bugs.

Lack of clear examples is not an edge case bug, it's failing to think about your user.

Breaking separation of concerns is not an edge-case bug.

I'm old, so I can assure you that, as of 2016, developers were well aware of the concepts of separation of concerns and abstraction. It being 2016 does not address the criticism I made. See also my longer reply.

https://news.ycombinator.com/item?id=19109660

For a security library to have no updates in a couple of years, I would consider it to be unmaintained and a huge risk.

I don't doubt that 2016 had some great libraries in rust, of which a lot are still used today. But most of them are updated to use new language features like `?` instead of `try!`, new macros system, async libraries, etc..

Take a look at a library like `serde`, which has been around since 2015 (https://crates.io/crates/serde/versions) and is awesome.

Rust 1.0 was in May 2015. No one's saying 2016 was a dark age, but the language has been moving quite fast since then. Even fundamental concepts like error handling have seen a major generation or two go by in that time (e.g. error-chain and failure). Many libraries from 2016 are still going strong, but a Rust library that hasn't gotten a commit in a couple years is much deader than the C++ equivalent.

> I had the simple task[2] of encrypting bytes with AES using the library. But (as detailed in the post), they didn't expose a simple, "give us plaintext bytes, give us key bytes, give us options, we'll spit back the ciphertext bytes". Instead, you have to delve into the irrelevant details of constructing mutable buffers (which require special care in Rust), so it can read from and write to them, and without even any good examples in the docs for how to construct those buffers.

That is a surprisingly uncommon API for a crypto library. It's far more common that they make you do a lot of the setup that really should be under the hood and that if you get wrong your security will be ruined. Plus the docs won't explain what any of the values mean because obviously you wouldn't be using crypto unless you already took a college course in it.

It's far too rare that the docs even explain what an IV is, or what you should set it to, or if it needs to be kept secret, or even what the initials mean. I think it is on purpose to scare off developers that have not studied the field extensively, but in reality they have a job to do so they set it to 0 and then ship 84 million appliances where this code is baked into the firmware update system.

I hear you. But, in fairness, tptacek mentioned a Go library in that thread that worked the way I was expecting, and provided good examples:

https://golang.org/pkg/crypto/cipher/#NewGCM

We also had a discussion about it here https://news.ycombinator.com/item?id=18943056, if you recall.

Yes, which is why I linked it in the thread, and your comment specifically. Did you see this comment? https://news.ycombinator.com/item?id=19109418

Why do you think rust developers weren’t aware of separation of concerns or good examples in 2016?

Which writeups were "poor"?

Not the Cryptopal writeups -- I mean every explanation of the Mersenne Twister I found, how the values were scattered all over the place and it was difficult to get the expected result. Wikipedia's, example, is a mess to sort through:

https://en.wikipedia.org/wiki/Mersenne_Twister#Pseudocode

(I use the plural because I'm lumping that in with the difficulty of getting openssl to yield the expected results for AES encryption.)