Stream: wg-secure-code

Topic: security badges


Tony Arcieri (Oct 19 2018 at 14:49, on Zulip):

any thoughts on a README badge like this?

Tony Arcieri (Oct 19 2018 at 14:50, on Zulip):

Screen-Shot-2018-10-19-at-7.49.16-AM.png

Tony Arcieri (Oct 19 2018 at 14:50, on Zulip):

I started using them on a few of my projects

Joshua Liebow-Feeser (Oct 19 2018 at 14:52, on Zulip):

Here's a copy-paste of the notes on this topic from the first meeting:

ET: Do we also want to name and shame projects that are using unsafe in a bad way? Or assuming that they need the performance, do it w/o unsafe.
BS: Instead of naming and shaming, show how things can be done better. Always propose an alternative, maybe even submit a patch.
SS: Could generate badges showing percent of unsafe code in a project in order to incentivize less unsafe.
TA: forbid(unsafe) could be an interesting metric. So the badge could be that you have no uses of unsafe at all.
BS: We should decide what the goals are. Be careful not to make core crates which enable safe functionality look bad.
GK: Make sure not to make it sound like “unsafe is only for experts.”
SS: I think the point of unsafe is to be a higher bar and to raise suspicion.
GK: I don’t want to make it seem like the next important unsafe-using crate should only be written by experts.
BS: There are other security considerations beyond unsafe (e.g., for crypto). Also not convinced that the crate is the right granularity for this. E.g.: What about unsafe hidden behind a safe API?
ET: An old idea was to add an audit annotation to unsafe code to declare that it’d been reviewed/checked. Might even go as far as a digital signature. Could add an audit flag/attribute, and have a badge for that.
BS: Use of dangerous constructs can be a metric of this group’s success.

Joshua Liebow-Feeser (Oct 19 2018 at 14:53, on Zulip):

I like the idea of having a badge for "all my unsafes are audited", which would be a superset of "I don't use unsafe".

Joshua Liebow-Feeser (Oct 19 2018 at 14:53, on Zulip):

So all crates w/o unsafe would get that badge automatically.

Joshua Liebow-Feeser (Oct 19 2018 at 14:54, on Zulip):

@Erick Tryzelaar might have thoughts on how to do the review annotations.

Zach Reizner (Oct 19 2018 at 16:20, on Zulip):

Isn't this an example of "Goodhart's law"?

Zach Reizner (Oct 19 2018 at 16:20, on Zulip):

If we measure how much unsafe is in a project, the unsafe will get moved to a place less visible.

Tony Arcieri (Oct 19 2018 at 16:20, on Zulip):

that's why I'm a fan of forbid :wink:

Zach Reizner (Oct 19 2018 at 16:25, on Zulip):

Does forbid mean that there is no unsafe code in any module in the dependency chain?

Tony Arcieri (Oct 19 2018 at 16:36, on Zulip):

unfortunately not :cry:

Tony Arcieri (Oct 19 2018 at 16:36, on Zulip):

a transitive forbid would be fantastic

Zach Reizner (Oct 19 2018 at 16:49, on Zulip):

I fear some crates will split into cool-crate-totally-safe which will depend on cool-crate-but-with-the-unsafe-parts.

Zach Reizner (Oct 19 2018 at 16:50, on Zulip):

Additionally, some crates will unwittingly depend on potentially exploitable unsafe code, but still proudly put on the "unsafe forbidden" badge, which I feel is sending the wrong message to clients of that crate.

Tony Arcieri (Oct 19 2018 at 17:02, on Zulip):

yeah, a README badge can always be a bit deceiving

Zach Reizner (Oct 19 2018 at 17:03, on Zulip):

Good point.

Zach Reizner (Oct 19 2018 at 17:03, on Zulip):

Maybe if a client clicks the badge, it links to a full audit chain of that package that will show the unsafe dependencies.

Zach Reizner (Oct 19 2018 at 17:04, on Zulip):

I appreciate that the goal is to nudge devs away from using unsafe where possible, and the badge would be a net good in that effort even if it can be abused sometimes.

Shnatsel (Oct 19 2018 at 17:05, on Zulip):

I just don't feel "some humans I've never heard of looked at it and said it's okay" is a security gurarantee worth pursuing. If anything, I'd rather have correctness proofs with tools such as SMACK, which are an actual assurance (under certain assumptions)

Zach Reizner (Oct 19 2018 at 17:06, on Zulip):

Shnatsel, is that with respect to the badging or to adding audit annotations?

Zach Reizner (Oct 19 2018 at 17:06, on Zulip):

Am I correct in assuming those are orthogonal efforts?

Shnatsel (Oct 19 2018 at 17:06, on Zulip):

Adding audit annotations

Shnatsel (Oct 19 2018 at 17:07, on Zulip):

While the tooling for automated verification has just been ported and so has some rough edges, it doesn't seem to be terribly hard to use. See http://soarlab.org/publications/atva2018-bhr.pdf for the porting story and some examples.

Zach Reizner (Oct 19 2018 at 17:08, on Zulip):

(Moved to correctness proofs stream)

Joshua Liebow-Feeser (Oct 19 2018 at 18:10, on Zulip):

I disagree that an annotation about human checking isn't good enough. I agree that proofs are cool and desirable, but the reality is that most people aren't going to write proofs, and if my only options are to choose between un-annotated unsafe and unsafe which a human has at least thought about pretty hard and written down their thoughts, I prefer the latter. I also think that we'll get a lot more milage out of encouraging that approach than encouraging verified proofs.

Shnatsel (Oct 19 2018 at 18:26, on Zulip):

I was under the impression that tools such as SMACK provide not quite as in-depth assurances as manual proofs with interactive proof assistants do, but are in the same ballpark in terms of usage difficulty as fuzzers, and provide greater assurance. If that is not the case I'd tend to agree, but I'm not yet convinced that is not the case :stuck_out_tongue_wink:

Tony Arcieri (Oct 21 2018 at 01:02, on Zulip):

haha, lazy_static breaks #[forbid(unsafe_code)]

Alex Gaynor (Oct 21 2018 at 01:03, on Zulip):

That's unfortunate. I have no proposal for how you could fix that, but this feels like it ought to be a bug somewhere.

Jake Goulding (Oct 21 2018 at 01:20, on Zulip):

That should have been covered by https://github.com/rust-lang/rust/issues/48855

Jake Goulding (Oct 21 2018 at 01:20, on Zulip):

well, it was for denyhttps://github.com/rust-lang/rust/issues/48385#issuecomment-367142273

briansmith (Oct 21 2018 at 05:43, on Zulip):

I personally think we should drop the security badge idea, deeming it out of scope. In particular, I think the design of unsafe as it exists now in Rust is highly questionable and I don't think I'm the only one. If the design of unsafe itself is unquestionable then IMO it's premature to gamify its use/non-use even if such gamification were otherwise a good idea. See https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=f2e8f93ce0ae2823b6de0e3f29b01b21 and https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=8ecb524f00ba696379853be7f0d2e479 for some examples of why I'm skeptical of the current design of unsafe as it stands today.

Tony Arcieri (Oct 22 2018 at 14:24, on Zulip):

haha, some stronger reactions than I was expecting. what I was getting at with these sorts of badges was all other things being equal, given a choice between a crate which uses unsafe and one that does not, I would prefer people pick the safe crate. the base64 crate is a relevant example

Tony Arcieri (Oct 22 2018 at 14:24, on Zulip):

and more generally, discourage the use of unsafe when it isn't necessary

Tony Arcieri (Oct 22 2018 at 16:23, on Zulip):

on a separate but somewhat related note, I have ideas for unsafe improvements, but that could probably use its own topic

Tony Arcieri (Oct 22 2018 at 16:23, on Zulip):

regarding this topic, any ideas for security-related badges other than unsafe?

Tony Arcieri (Oct 22 2018 at 16:24, on Zulip):

I could potentially do some sort of RustSec badge

Zach Reizner (Oct 22 2018 at 16:24, on Zulip):

Like a badge that says none of your deps have a known advisory?

Tony Arcieri (Oct 22 2018 at 16:30, on Zulip):

yep, ala many similar systems that do the same thing for other language-specific vuln databases

Zach Reizner (Oct 22 2018 at 16:39, on Zulip):

Sounds good to me.

Tony Arcieri (Oct 22 2018 at 16:40, on Zulip):

it would require RustSec-as-a-service which might be a bit tricky, heh

Zach Reizner (Oct 22 2018 at 16:41, on Zulip):

Shouldn't be too hard. We just have to find someone willing to donate us some infrastucture

Tony Arcieri (Oct 22 2018 at 17:15, on Zulip):

I could donate the infrastructure for something like that

Zach Reizner (Oct 22 2018 at 17:17, on Zulip):

That may not be necessary. I wonder if Mozilla would be willing to host something like that.

Zach Reizner (Oct 22 2018 at 17:17, on Zulip):

I have no idea how official this working group is though.

Joshua Liebow-Feeser (Oct 22 2018 at 18:16, on Zulip):

It's not official in the sense of not being able to speak on behalf of the Rust project. It's official in the sense of being sanctioned by the Rust project.

Joshua Liebow-Feeser (Oct 22 2018 at 18:17, on Zulip):

Also, wrt a RustSec badge, I'd be worried that it would just mean that crates that nobody looks at get the badge. If we had a high volume of vuln reports, it might give us meaningful data, but I think we get too few vuln reports to extract any meaningful signal from the noise.

Shnatsel (Oct 23 2018 at 09:09, on Zulip):

I don't think a badge is a good place for the "no dependencies have a known advisory" info. I'd expect cargo build to complain loudly if they do; perhaps crates.io notifying maintainers that their dependencies have known advisories; but a readme badge sounds a lot less useful and would require a great deal more infrastructure.

Zach Reizner (Oct 23 2018 at 17:00, on Zulip):

cargo build can only tell you about your security advisories if you regularly build your crate.

Zach Reizner (Oct 23 2018 at 17:01, on Zulip):

A notification seems like the key piece of the puzzle. The badge is nice because it's an external signal to clients of a crate that the maintainers care about security.

Joshua Liebow-Feeser (Oct 23 2018 at 17:34, on Zulip):

I still am concerned that badges are only helpful if a negative signal is helpful. Right now, we don't get enough vuln reports for "this crate doesn't have a vuln report" to mean anything.

Joshua Liebow-Feeser (Oct 23 2018 at 17:34, on Zulip):

At this point, "this crate has had vuln reports" basically just means "this crate is used enough that people bothered looking."

qmx (Oct 26 2018 at 13:20, on Zulip):

I could donate the infrastructure for something like that

I can check with my employer (DigitalOcean), I think we could get machines/credit donated for this effort.

Zach Reizner (Oct 26 2018 at 18:03, on Zulip):

I've been doing some brainstorming and I have a version of this working that generates the audits as part of a gitlab ci run.

Zach Reizner (Oct 26 2018 at 18:04, on Zulip):

It seems to be working pretty well. It can build and audit in about 5 minutes and I can schedule CI jobs using cron syntax, currently set for hourly.

Joshua Liebow-Feeser (Oct 26 2018 at 18:08, on Zulip):

Could we add cargo audit (or whatever tool you're working on) as a CI pass? So, e.g., in your .travis.yml, run a tool which fails the CI test if your dependency graph has any known vulns?

Zach Reizner (Oct 26 2018 at 18:09, on Zulip):

I'll defer to the @Tony Arcieri who made the cargo audit.

Zach Reizner (Oct 26 2018 at 18:09, on Zulip):

I'm making more of a crates-audit.

Zach Reizner (Oct 26 2018 at 18:10, on Zulip):

The thing I'm making generates a data structure like this:

#[derive(Serialize, Deserialize, PartialEq)]
struct CratesAudit {
    crates_index_commit: String,
    advisory_db_commit: String,
    // Map of crate name to list of RustSec advisory IDs.
    advisories: BTreeMap<String, Vec<String>>,
}
Joshua Liebow-Feeser (Oct 26 2018 at 18:13, on Zulip):

Gotcha

Zach Reizner (Oct 26 2018 at 18:16, on Zulip):

Another slight difference is that cargo audit uses a Cargo.lock file as opposed to crates-audit which does its own dependency resolution.

Shnatsel (Oct 26 2018 at 21:03, on Zulip):

Neat! Let me know when you publish the code, it would be very interesting to poke at it. Also, this has been on my "cool project I can't get around to" list for a long time, so thanks for actually stepping up and doing it!

Zach Reizner (Oct 26 2018 at 21:05, on Zulip):

Thanks. It was a right place right time kind of situation because I already had the crates indexing and dependency resolution code written but I no longer needed it for its original purpose.

Tony Arcieri (Oct 28 2018 at 15:36, on Zulip):

Yeah likewise, this has been suggested several times but I've never had time to work on it.

Tony Arcieri (Oct 28 2018 at 15:36, on Zulip):

and yeah, cargo audit is good to go for CI. Per @Alex Gaynor's issue I should document Travis at least

Tony Arcieri (Oct 28 2018 at 15:36, on Zulip):

I use it on Travis

Tony Arcieri (Oct 28 2018 at 15:36, on Zulip):

(and CircleCI, and Cloud Build, but that's a different story)

Alex Gaynor (Oct 28 2018 at 16:16, on Zulip):

Yeah, I don't think it's rocket science to set up, just want to drag that barrier down.

Stuart Small (Nov 03 2018 at 14:16, on Zulip):

Sorry I'd dropped off the radar for a bit. I actually just recently starting on a crate to measure unsafe coverage inside a crate. Before I dove too deep on it I wanted to check with the group to make sure one doesn't already exist.

Stuart Small (Nov 03 2018 at 14:17, on Zulip):

Plan is walking the crate with syn, measure unsafe usage and get a percentage than can be shown off in a badge. So far it looks fairly straight forward.

briansmith (Nov 03 2018 at 21:33, on Zulip):

@Stuart Small I'm curious how the uses of unsafe will be counted. Consider https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=61340cde2f564c4f9dbc9af0bf99e87c vs https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=ff104f86e8a21c7be6e2a0c5c097e6b5 vs https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=1235743a7a0bac91990f0eb252a77571. Would they have the same score or different scores?

Stuart Small (Nov 04 2018 at 00:01, on Zulip):

I'm still playing around with it. I'm new to syn. From what I've read so far it will be on the expression level, so the first two will be equal but the 3rd one will show a lower percentage of unsafe. I believe it's correct to have the 3rd example to have a better score because while the usage of unsafe is the same, the surface area to audit is smaller.

Stuart Small (Nov 04 2018 at 06:05, on Zulip):

A did a quick POC of my approach on this and included a couple of the case you mentioned @Brian Smith . It can be found here: https://github.com/stusmall/cargo-unsafe-coverage

I added a couple of the examples you'd mentioned in there are unit tests. To get this far it was pretty smooth sailing, itll just be the work of filling out implementation for different AST states and handling them. Something like this can encourage people to either advertise their lack of unsafe code or help encourage concentrating it in smaller, more central, audit-able locations. Like any metric, like code coverage, it isn't perfect but can help encourage good practices.

gnzlbg (Nov 04 2018 at 10:20, on Zulip):

I believe it's correct to have the 3rd example to have a better score because while the usage of unsafe is the same, the surface area to audit is smaller.

Any approach that takes into account how often the unsafe keyword appears in the rating beyond "it never appears" and "it appears at least once" is probably incorrect.

So I'm interested too into how this unsafe rating would work. Is there a document explaining it anywhere?

Shnatsel (Nov 04 2018 at 10:47, on Zulip):

I've toyed with the idea of measuring coverage of unsafe code already, discussed it with some folks, and arrived to the conclusion that it's simply impossible to produce a meaningful result. Here's an extreme example: https://github.com/WanzenBug/rust-fixed-capacity-vec at one point in its history had exactly one unsafe block with just one line it in. It was in creation of fixed-capacity vector view, so any conceivable test would enter that line; it would have 100% unsafe coverage by any conceivable metric. However, the safety of that line depended on the entire rest of the code in the module, all of which is safe, upholding a certain non-trivial invariant.
So such metrics would be often useless at best and wildly misleading at worst.

gnzlbg (Nov 04 2018 at 10:59, on Zulip):

Those are pretty much my thoughts too @Shnatsel . I think the only useful metric is whether the crate uses unsafe at all or not, and if you want something more fine grained, how many % of the modules in a crate use unsafe at all or not (where if a module uses unsafe, you have to count all its child modules as using unsafe as well).

Shnatsel (Nov 04 2018 at 11:01, on Zulip):

https://github.com/anderejd/cargo-geiger does that, also with dependencies and transitive dependencies

Stuart Small (Nov 04 2018 at 15:10, on Zulip):

No documentation yet. Last night was my first pass at setting it up. It looks for the amount of code covered by unsafe blocks. It isn't a count of unsafe blocks or the number of lines inside them, but the count of statements inside that block or method.

As for the any unsafe is enough, I'm trying to keep the actix case in mind. In the early days of the project it had a lot of unsafe usage in the crate. The community found it and help reduce it down to a few small places where it was needed for performance. Something like this could be a quick smoke test for heavy unsafe usage in where it doesn't make sense, but a little unsafe does.

Shnatsel (Nov 04 2018 at 15:21, on Zulip):

https://github.com/anderejd/cargo-geiger already counts the total amount of expressions under unsafe per crate, as well as number of unsafe impls, traits and methods. I.e. it seems to be already doing what you're trying to achieve.

gnzlbg (Nov 04 2018 at 15:23, on Zulip):

It isn't a count of unsafe blocks or the number of lines inside them, but the count of statements inside that block or method.

Yeah so this approach is incorrect, the count of statements inside an unsafe block isn't a measure for the amount of unsafe code.

Shnatsel (Nov 04 2018 at 15:25, on Zulip):

It would catch the Actix case though, which seems to be the design goal.

gnzlbg (Nov 04 2018 at 15:26, on Zulip):

For that goal, grep would arguably be enough?

Shnatsel (Nov 04 2018 at 15:27, on Zulip):

True. That's what I tend to use.

gnzlbg (Nov 04 2018 at 15:31, on Zulip):

I think if one is going to give crates a score based on unsafe, one should really think through what would happen if people would optimize for that goal. AFAICT given what @Stuart Small proposed, such a tool would encourage using minimally scoped unsafe blocks to minimize the number of "unsafe statements", but that's something that the std library explicitly avoids because it gives the impression that the unsafety is only present in those parts of the code, while in reality, one needs to inspect the whole function, module, child modules, etc. So under this model, optimizing to reduce such a score would actually be introducing anti-patterns that make the code more "unsafe".

For example, if you have a struct with a Vec, and a single unsafe block in the module doing a unsafe { self.vec.set_len(self.vec.len() + 1) }, that might have a tiny statement count, but in reality, everything that can directly or indirectly access self.vec becomes unsafe due to this, even though one doesn't need to add more unsafe blocks. So that ought to have a larger "danger" associated with it than maybe doing a raw pointer dereference, where either doing it succeeds or not, but is something that can be prevented fairly locally with an assert! without tainting the whole module.

Stuart Small (Nov 04 2018 at 16:38, on Zulip):

Oh wow. I hadn't caught that they had added that since the last time I looked at that crate. Nevermind

Stuart Small (Nov 04 2018 at 16:39, on Zulip):

Last time I had looked a geiger just gave a thumbs up/thumbs down on if it had unsafe.

Stuart Small (Nov 04 2018 at 16:49, on Zulip):

Hmmm. Now that at it I think I imagined it was only a yes or no. Looks like it's always gathered stats on the usage. Glad I brought this up with the group before I went to far on it.

briansmith (Nov 04 2018 at 18:16, on Zulip):

@gnzlbg If it is true that the stdlib intentionally avoids minimizing the scope of unsafe blocks "because it gives the impression that the unsafety is only present in those parts" then we should change that. I think minimizing the amount of code that is within unsafe makes the use of unsafe much clearer and also avoids unnecessary and accidental unsafe code.

gnzlbg (Nov 04 2018 at 18:21, on Zulip):

@Brian Smith Most functions in the std library using unsafe just wrap the whole function content in a big unsafe { ... } block. I personally disagree that minimally scoped unsafe blocks make anything clearer. When one uses minimally scoped unsafe blocks most undefined behavior related bugs start happening out of any unsafe block. Also people modifying code outside unsafe blocks pay less attention than those modifying unsafe blocks. Larger than minimal unsafe blocks are an indication that modifying anything inside the block has to be done with extra care.

And that's the root of the problem: once your crate/module has a single use of unsafe {}, no matter how minimally scoped, an error in "safe" Rust code can introduce undefined behavior. Its not "is this unsafe code correct", but "is all of this code correct given that unsafe is used somewhere".

Shnatsel (Nov 04 2018 at 18:24, on Zulip):

Well... on one hand, seeing which of the calls are to unsafe fn and which aren't at a glance would be helpful so I could look them all up, make a list of invariants that they require to be upheld, and then check that they're actually upheld. On the other hand, it could create a lot of noise. So sounds like highlighting calls to unsafe fn would be better solved with an IDE plugin.

gnzlbg (Nov 04 2018 at 18:27, on Zulip):

Highlighting calls to unsafe fn is a great idea, but there are things that require unsafe that are not unsafe fn (e.g. dereferencing raw pointers, creating a reference to a packed struct field, reading from an union, etc.) and all of these could be happening inside the same unsafe block, so ideally all of these would be "highlighted", underlined, or something.

Shnatsel (Nov 04 2018 at 18:28, on Zulip):

Wanna open a feature request against RLS or whatever should be handling this?

gnzlbg (Nov 04 2018 at 18:28, on Zulip):

RLS or the rust-analyzer should be the tools that expose this information

Shnatsel (Nov 04 2018 at 18:32, on Zulip):

Huh, I did not know about rust-analyzer. Thanks for pointing it out.

Shnatsel (Nov 04 2018 at 18:32, on Zulip):

Care to open feature requests against them?

gnzlbg (Nov 04 2018 at 18:35, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/issues/190

briansmith (Nov 04 2018 at 20:05, on Zulip):

@gnzlbg Sure, but in that case every Rust program is "unsafe" because they all depend on libstd/libcore which use unsafe. unsafe isn't meant to delimit the scope of what's affected by unsafe constructs; it delimits the direct use of unsafe constructs only. The argument that minimizing the scope of unsafe because it is confusing as to what the ultimate unsafe effect can be is targeting a mental model of unsafe that's just incorrect.

gnzlbg (Nov 04 2018 at 20:08, on Zulip):

Sure, but in that case every Rust program is "unsafe" because they all depend on libstd/libcore which use unsafe

Iff the public API of libstd/libcore is sound, then every Rust programs that only interacts with these via safe public APIs is sound too (not unsafe).

gnzlbg (Nov 04 2018 at 20:09, on Zulip):

The key difference is that code inside a module (and child modules) does not need to interact with the module its defined in through its public API. This code can, for example, use safe Rust code to modify private struct fields, potentially introducing undefined behavior because of interaction with some unsafe code somewhere else in the module that did not expect those modifications.

gnzlbg (Nov 04 2018 at 20:14, on Zulip):

Once unsafe appears once inside a module, modifying code anywhere in the module or child modules can introduce undefined behavior independently of whether the code being modified is inside an unsafe block or not. Minimizing the scope of unsafe blocks does not make anything safer per se, it just changes the region that whoever write the code wants to highlight to the reader as being "unsafe".

gnzlbg (Nov 04 2018 at 20:19, on Zulip):

Some people like to highlight the bare minimum, the std library likes to highlight whole functions, or largerish parts of functions.

gnzlbg (Nov 04 2018 at 20:20, on Zulip):

This all might be too abstract, but one example of this practice is the RawVec module in case someone is wondering how this all looks in the standard library: https://github.com/rust-lang/rust/blob/master/src/liballoc/raw_vec.rs#L90

gnzlbg (Nov 04 2018 at 20:21, on Zulip):

https://github.com/rust-lang/rust/blob/master/src/liballoc/raw_vec.rs#L239

gnzlbg (Nov 04 2018 at 20:22, on Zulip):

https://github.com/rust-lang/rust/blob/master/src/liballoc/raw_vec.rs#L359

Shnatsel (Nov 04 2018 at 20:23, on Zulip):

This RawVec is the code where CVE-2018-1000657 happened

gnzlbg (Nov 04 2018 at 20:24, on Zulip):

No, that CVE happened in VecDeque: https://github.com/rust-lang/rust/pull/44802/files

Shnatsel (Nov 04 2018 at 20:26, on Zulip):

Good catch, I stand corrected. Apparently I forgot the details since I applied for CVE

gnzlbg (Nov 04 2018 at 20:26, on Zulip):

VecDeque uses RawVec, and relies a lot in the exact behavior of some of RawVec's internals for correctness (exact allocation doubling behavior, etc.), but that's another story..

Shnatsel (Nov 04 2018 at 20:26, on Zulip):

I believe there was a safety regression this cycle in either VecDeque or RawVec, which was caught in beta or some such. I could look up the details if anyone's interested.

gnzlbg (Nov 04 2018 at 20:28, on Zulip):

haven't heard of that one, but having re-implemented most of VecDeque API in SliceDeque, it isn't hard to break safety with tiny mistakes while writing these types of data-structures

Shnatsel (Nov 04 2018 at 20:29, on Zulip):

huh, is that some kind of fixed-capacity double-ended queue?

gnzlbg (Nov 04 2018 at 20:31, on Zulip):

it is dynamically-resizable, but the elements always form a contiguous slice

Shnatsel (Nov 04 2018 at 20:33, on Zulip):

Ah, okay. I was hoping it could be a shortcut implementing a fixed-capacity view of Vec, because manually enforcing lack of reallocation in the undelying Vec is not fun, especially since Vec reallocation behavior is very loosely specified for methods that insert multiple elements.

Shnatsel (Nov 04 2018 at 20:34, on Zulip):

There is a prototype implementation that's even reasonably fast, but I'm pretty sure it still has some issues e.g. with panic safety for types implementing Drop

gnzlbg (Nov 04 2018 at 20:37, on Zulip):

I've seen that RFC but I had mixed feelings about it. I kind of wish that instead it would propose a &mut VecView that would also work with ArrayVec, SmallVec, Vec, etc. Having such a type only for Vec feels a bit "not widely-useful enough".

Shnatsel (Nov 04 2018 at 20:45, on Zulip):

That doesn't sound terribly hard to implement, actually. Currently we only have a constructor from Vec but there is no reason it wouldn't work with other types that have a properly aligned backing buffer with a known capacity and length.

gnzlbg (Nov 04 2018 at 20:46, on Zulip):

This View type only needs a (*mut T,usize,usize), and it cannot grow the underlying vector anyways because ArrayVec cannot grow beyond its capacity, and growing a SmallVec is non-trivial either, so it kind of is what you are looking for, but works for more cases.

Shnatsel (Nov 04 2018 at 20:47, on Zulip):

Post that to the thread. Sounds like a pretty good idea that's fairly easy to implement

Joshua Liebow-Feeser (Nov 05 2018 at 19:38, on Zulip):

Here's a different take on the issue: What we're really trying to do is figure out which code is in the TCB (i.e., the set of code which, if buggy, could cause unsoundness), and which code isn't. Can we think of a way to automatically figure out (or at least estimate the size of) that TCB? I suspect the answer is "no," but maybe we could get close with some code conventions?

Grant Husbands (Feb 12 2019 at 20:16, on Zulip):

So I'm late to this thread and just noted the "Most functions in the std library using unsafe just wrap the whole function content in a big unsafe { ... } block". I agree that that makes sense, given that unsafety 'leaks' to the wider scope, but should there then be a way of tagging the bits that need to be unsafe in order to compile? Maybe nested unsafe blocks could do that (if unused_unsafe warnings were off by defaut).

Tony Arcieri (Feb 14 2019 at 19:40, on Zulip):

sounds like what I proposed here https://internals.rust-lang.org/t/crate-capability-lists/8933/2

Last update: Nov 11 2019 at 22:00UTC