Stream: wg-secure-code

Topic: workgroup organization

DevQps (Mar 15 2019 at 13:20, on Zulip):

I am pretty new here so there's a high chance I am missing out on some stuff (forgive me in that case!), but I just wanted to raise the question just in case people agree. When I read through all the topics and blog posts and linked repo's I feel like there is a lot of great work that is currently happening, but it feels like there is not a single place where all the knowledge (or at least references to it) come together.

So I thought, maybe we could update the README of the rust-secure-code workgroup with security related projects/area's and work as well? We could also create a separate document for the repository if that would make it more clean. That way beginners / people that want to contribute something on the area of Rust security can get up to speed in a glance.

I think we should also put a link to our Twitter channel for example! (Didn't even knew it existed till today haha :P)

DevQps (Mar 15 2019 at 13:20, on Zulip):

Since I am new I kind of feel like I might be stepping out of my book here though....

DevQps (Mar 15 2019 at 13:23, on Zulip):

Maybe it would also be good to close some old topics in our stream as well, or archive them somehow maybe?

Shnatsel (Mar 15 2019 at 20:00, on Zulip):

That sounds like a good idea, we do have a bit of a problem with discoverability of work items.

DevQps (Mar 15 2019 at 23:12, on Zulip):

Mmmm maybe we should start with creating a list of related projects and add those to the README with a description? If you want I can get started with that tomorrow as well!

Gerardo Di Giacomo (Mar 15 2019 at 23:53, on Zulip):

yep this is a good idea - I would like to spend some time on some work items but I'm really not sure where to start, or who's on point on the tasks, if there's a work tracker for a specific task, etc

DevQps (Mar 16 2019 at 08:27, on Zulip):

@Gerardo Di Giacomo When I started somewhere this week, reading through all topics in this stream provided me with a lot of links! Most of the links themselves also often have links te interesting places :)

DevQps (Mar 16 2019 at 08:28, on Zulip):

I'll create an issue for it on the WG repo!

DevQps (Mar 16 2019 at 15:41, on Zulip):

I created an issue for this and I am currently working on collecting different projects that could aid in achieving our Roadmap goals. The issue can be seen here:

DevQps (Mar 16 2019 at 15:42, on Zulip):

If you guys all agree, I will leave it open for a week and then create a Pull Request merging the projects that people have mentioned in the issue. Any projects that should be added later then need their own PR.

Shnatsel (Mar 16 2019 at 15:46, on Zulip):

Work trackers for specific tasks are on the WG issue tracker. We should probably advertise that in the README

Shnatsel (Mar 16 2019 at 15:49, on Zulip):

I would rather keep the list problem-oriented than solution-oriented. I.e. I would rather list the issues we're trying to solve first, and potential solutions second. This leaves room for coming up with novel solutions and/or creating new projects

DevQps (Mar 16 2019 at 15:53, on Zulip):

I agree! If I understand you correctly, do you mean that you'd first want the README to list the potential problems that we are aiming to solve (For example under a "Problems" or "Topic/Area" heading) and then a list of potential projects that could solve these problems? Or aim to solve security issues in general?

DevQps (Mar 16 2019 at 15:53, on Zulip):

Or do I misunderstand?

Shnatsel (Mar 16 2019 at 16:59, on Zulip):

Actually, do we need another list if we have the bug tracker issues already listing the work items? I guess it would help with visibility if it were in the README

Shnatsel (Mar 16 2019 at 17:00, on Zulip):

I don't want to create too much duplication though. So perhaps list the problems we want to solve and link the relevant issues?

DevQps (Mar 16 2019 at 17:12, on Zulip):

I think that it is a good idea to list the work items in the README! So then the README would look something like:

Work Items (+ Mentioned issues)
Projects (+ Working Group/Security related projects)

Or should we merge Projects and Work Items together? I personally would prefer having the Work Items / Goals in the README because as an issue they are not really "solvable". For example take "Improve Clippy security lints": When would this really be solved? I think the issue then more or less serves more as an chat/big conversation then an actual issue. Maybe we could move the discussion to Zulip topics and use Github issues for more concretely solvable things? But it might be just a matter of preference however!

I just see now that Twitter was there in the contact section all along... My bad for that...

DevQps (Mar 16 2019 at 17:16, on Zulip):

EDIT: On a second hand, maybe a Github issue is actually a nice way to keep the discussion going. Maybe one of the challenges is to keep Zulip and Github in sync such that the more concrete topics emerging out of Zulip should get their own Github issue. But I am not sure what you guys think about this however.

DevQps (Mar 17 2019 at 19:39, on Zulip):

The list with security related projects I came up with is here:
I think maybe (in a shorter form, maybe a table per catagory) should be included to the README, such that security-oriented Rust programmers have a way to find all the tools they need which in turn hopefully improves the security ecosystem of Rust.

What do you think of this list? Do you have any other projects to add? Or some which we should exclude?

DevQps (Mar 17 2019 at 19:41, on Zulip):

Or do you guys think this list should be placed somewhere else? I think keeping all the security related projects / posts together such that newcomers + interested people can get up to speed is fairly important.

Shnatsel (Mar 17 2019 at 19:49, on Zulip):

Hmm. I would rather organize the README around the issue tracker items. For example, I want to be able to detect reads from uninitialized memory; libdiffuzz kind of does that, but it's also kind of a hack, and getting proper support for Memory Sanitizer would be much more important.
On the other hand, getting a list of all security-related Rust projects definitely would be helpful - AFAIK right now there is no such thing

DevQps (Mar 17 2019 at 19:54, on Zulip):

Mmm I can relate with your view. Do you have any idea's on what might be a good place to publish such a list?

DevQps (Mar 17 2019 at 19:55, on Zulip):

I can create a Pull Request with our work items if you want? Or would you like to do that yourself? EDIT: I get a permission denied when trying to push a branch? :)

Shnatsel (Mar 17 2019 at 20:54, on Zulip):

you need to fork your repo and push there, then create a pull request

Shnatsel (Mar 17 2019 at 20:55, on Zulip):

this is not bzr where the unit is a branch and you can do whatever you like with them. in git you need to make a copy of the entire repository with all the branches and only after that you can push changes. If you download the code you're also forced to download all branches.

DevQps (Mar 17 2019 at 20:56, on Zulip):

Ah thanks (Y)! I hope you don't mind me talking to much over here and Github though :) I feel motivated to push some work, but I hope you guys don't find it annoying. If you'd rather have me being silent and just working on some related project feel free :)

I cloned the repo btw, but I will fork it now and then do the pull request! Should be there in a few minutes!

DevQps (Mar 17 2019 at 21:02, on Zulip):

I opened the pull here:
Not quite satisfied though, some feedback would be welcome :)

Shnatsel (Mar 17 2019 at 21:03, on Zulip):

Thanks, I'll try to take a look tomorrow.

Shnatsel (Mar 17 2019 at 21:05, on Zulip):

At a glance, it's probably a good idea to extend verification beyond std... there are commonly used crates such as byteorder that are also critical to the ecosystem, there's no reason not to cover them as well.

DevQps (Mar 17 2019 at 21:06, on Zulip):

I think that would be nice as well. I read something about Libz Blitz today, but that was a post from 2017, I wonder if they are actually still doing the assessments.

Shnatsel (Mar 17 2019 at 21:21, on Zulip):

No, but we could organize something like that

Shnatsel (Mar 17 2019 at 21:21, on Zulip):

All we're missing is a clearly defined workflow, some examples and a reddit post announcing it

DevQps (Mar 18 2019 at 12:40, on Zulip):

We could do something like that I guess. I think it would be nice to have at least 2 people that put their efforts into this. I feel like we either need to do this for the whole 100% and invest time and effort into getting people to join and to organize everything or not to pursue this at all at this moment. Otherwise we would end up like Libz Blitz (or I don't know why it ended, but I guess it was because of a lack of time/participants). We could create an issue for this on the WG repository however. Someone could always pick it up if he/she truly feels like it.

Shnatsel (Mar 18 2019 at 14:14, on Zulip):

I think Libs Blitz ended because it has accomplished what it has set out to do

DevQps (Mar 25 2019 at 16:07, on Zulip):

I created a Pull Request for the list of projects.
I am wondering what you guys think.

Shnatsel (Mar 25 2019 at 23:36, on Zulip): deserves a mention

Shnatsel (Mar 25 2019 at 23:36, on Zulip):

TUF is not useful for crate developers, so I'd drop it

Shnatsel (Mar 25 2019 at 23:37, on Zulip):

I'd also add an encouragement for the readers to add their own projects there

Shnatsel (Mar 25 2019 at 23:38, on Zulip):

Angora currently doesn't work with Rust code, although we very much want that to change

Shnatsel (Mar 25 2019 at 23:39, on Zulip):

AFAIR the author of untrusted was moving away from that approach, so not sure if it's a good idea to promote it

Shnatsel (Mar 25 2019 at 23:40, on Zulip):

I'd categorize libdiffuzz as a dynamic analyzer, but that's debatable

Shnatsel (Mar 25 2019 at 23:40, on Zulip):

Otherwise looks solid to me

Shnatsel (Mar 25 2019 at 23:41, on Zulip):

Also sorry for the radio silence, I have a lot going on right now

briansmith (Mar 26 2019 at 00:12, on Zulip):

Shnatsel: AFAIR the author of untrusted was moving away from that approach, so not sure if it's a good idea to promote it

We have been enhancing untrusted recently and there's no intent to drop it. I'm planning to remove it from the public interface of ring, but ring and most of my other projects that do (binary) parsing will continue to use it.

briansmith (Mar 26 2019 at 00:15, on Zulip):

I think that it might make sense to decide whether (binary) parsing in general is a category that should be included; if so then zerocopy, nom, combine, scroll, etc. would also be things to consider.

DevQps (Mar 26 2019 at 05:54, on Zulip):

@Shnatsel I will change this things and report back! And no problem :)

@briansmith I do consider sanitizing the input / reading inputs securely an important area, but I am not sure what the others think about that :)

DevQps (Mar 26 2019 at 10:06, on Zulip):

I updated the Pull Request with the suggestions! I processed all suggestions except for removing the untrusted entry.

Judson Lester (Mar 26 2019 at 23:57, on Zulip):

I'm not sure I understand the assertion that TUF isn't useful to crate authors? They'd be able to sign crates as the author...

DevQps (Mar 27 2019 at 06:18, on Zulip):

Personally I do not know too much about TUF, so I'll leave that discussion up to you guys :)

Judson Lester (Mar 27 2019 at 18:51, on Zulip):

I mean, TUF is intended as a supply-chain mitigation for services like It's a parallel registry of artifact signatures. Library owners are one of the stakeholders and participants, since they sign their artifacts (crates) on submission and decide whether to accept unsigned crates.
But it does require a parallel service and maintenance thereof (i.e. someone needs to hold and protect root keys for a TUF registry.) So it's not something that a developer can use on their own.

Tony Arcieri (Mar 30 2019 at 15:43, on Zulip):

For what it's worth I made (or rather, modified) a proposal to use TUF to secure the index:

Last update: Apr 04 2020 at 03:25UTC