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)
Since I am new I kind of feel like I might be stepping out of my book here though....
Maybe it would also be good to close some old topics in our stream as well, or archive them somehow maybe?
That sounds like a good idea, we do have a bit of a problem with discoverability of work items.
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!
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
@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 :)
I'll create an issue for it on the WG repo!
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: https://github.com/rust-secure-code/wg/issues/30
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.
Work trackers for specific tasks are on the WG issue tracker. We should probably advertise that in the README
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
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?
Or do I misunderstand?
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
I don't want to create too much duplication though. So perhaps list the problems we want to solve and link the relevant issues?
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...
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.
The list with security related projects I came up with is here: https://github.com/rust-secure-code/wg/issues/30
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?
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.
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
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?
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? :)
you need to fork your repo and push there, then create a pull request
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.
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!
I opened the pull here: https://github.com/rust-secure-code/wg/pull/31
Not quite satisfied though, some feedback would be welcome :)
Thanks, I'll try to take a look tomorrow.
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.
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.
No, but we could organize something like that
All we're missing is a clearly defined workflow, some examples and a reddit post announcing it
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.
I think Libs Blitz ended because it has accomplished what it has set out to do
I created a Pull Request for the list of projects. https://github.com/rust-secure-code/wg/pull/32
I am wondering what you guys think.
https://github.com/japaric/rust-san deserves a mention
TUF is not useful for crate developers, so I'd drop it
I'd also add an encouragement for the readers to add their own projects there
Angora currently doesn't work with Rust code, although we very much want that to change
AFAIR the author of
untrusted was moving away from that approach, so not sure if it's a good idea to promote it
I'd categorize libdiffuzz as a dynamic analyzer, but that's debatable
Otherwise looks solid to me
Also sorry for the radio silence, I have a lot going on right now
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.
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.
@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 :)
I updated the Pull Request with the suggestions! I processed all suggestions except for removing the untrusted entry.
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...
Personally I do not know too much about TUF, so I'll leave that discussion up to you guys :)
I mean, TUF is intended as a supply-chain mitigation for services like crate.io. 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.