I’m a primary contributor to c2rust and I may be the person “stolen” away from corrode. I’d like to apologize if it feels like we ripped off ideas without giving due credit - the project wasn’t really supposed to “discovered” so soon. The website was a throwaway idea, a means of easily sharing our work in a limited circle while avoiding both the DARPA approval and the sub-par build process (you have to build a huge chunk of Clang).
So here is me acknowledging Jamey’s work: I personally did take inspiration from Corrode, and I was expecting to work on Corrode proper when I joined Galois (I even wrote a pure Haskell library to parse/pretty-print Rust code - with Corrode in mind). I’ve re-read the CFG module of Corrode several times (as well as the Mozilla paper, and some older literature).
All that said, I also want to point out that Corrode hasn’t had any activity at all since last April - and that’s not for want of PRs piling up. I’m not criticizing here, since I understand that managing an open source can be quite time-consuming and stressful, but I feel like this also does need to be mentioned. Also, c2rust can be freely forked. Once the DARPA funding runs out, it is my hope that the Rust community will become the maintainers.
Finally, regarding the many improvements that can be automated: that is next up on our plate!
Regarding idiomatic improvements, in case you missed, C2Eif is the most impressive research in this area in my opinion. It can create classes and methods based on function signature analysis. It can also mark methods as private based on call graph analysis.
It is also impressive in coverage. It handles Vim, it handles inline assembly, it translates long jumps to exceptions, it handles variadic functions (Eiffel doesn’t have them like Rust, they are translated to library calls), it translates printf format strings to Eiffel formatting, etc.
Ok, someone replied to me and deleted his reply yesterday about this. I’m guessing he wants privacy where only I saw it through email system. I looked at his publications and affiliations to find he’s smart as hell, worked with DARPA (among others), and maybe even did a project with Galois. So, the source is probably reliable on what can or can’t work with DARPA. Here’s a paraphrasing of his claims:
Program managers can set up programs so that pre-pub review isn’t required for the whole program or for specific projects.
He did that himself with the entire project not subject to pre-pub review. He had the whole thing in open repositories that people did the work in.
Another project had subject areas defined as “designated, unclassified, subject areas.” Anything in them didn’t have to be reviewed. This is where you’d put the FOSS part.
He believes the prepub requirement by default is program managers just being lazy. Defaulting on review is the safest approach to go. It requires putting no thought or effort into whether something needs secrecy in the first place. So, they just do it even though they don’t have to. It wastes a lot of people’s time.
So, in his view, Galois could definitely get exemption for whole projects or pieces of them that could be in a live repo. He also claimed to have done this at least two times: one a whole project, one pieces of a project. Maybe the Galois people interacting with DARPA should try to default on doing that for anything that will be published to begin with. If it’s possible at all at current time. And I thank them for all the neat stuff they FOSS’d for us up to this point since they didn’t even have to do that. Still a great company. :)
@harpocrates can you pass this along to them so they at least consider it? I’d appreciate it.
I don’t currently write proposals, but I’ll pass the message on.
Don’t hold your breath though - this sounds like something Galois would already have done (perhaps we have? I don’t know…) if possible. We really do make an effort to open-source when possible.
If the concern is leaks, defense contractors like Galois might be able to get DARPA to change that policy. My idea would be a split between stuff that will definitely be FOSS and stuff that might be sensitive. Like Compartmented Mode Workstations or with Qubes, they could even isolate them in VM’s whose border color, labels, and firewall policies reflect the difference. The sensitive one would be used in a new, custom project or derivative that pulls in the open one. Whereas, the security policy wouldn’t led sensitive stuff interact with the Internet at all.
Quite a few products on the market for this on top of free stuff like Qubes or Muen. One can also use multiple boxes with KVM switch if worried about breaks. Anyone with DARPA or Defense experience think this proposal has a good chance of working?
I think there’s often a fair amount of misinformation regarding the creation of OSS by government contractors.
Yes, contractors like Galois have to play by the rules the government sets for them, including classification. The concern of “leaks” is there, but it’s subtle: tight coupling of components that probably should be open sourced with other components that probably should be classified.
So there’s a tendency to “overclassify” and lump everything together. However, companies can still make a case for why things should be open sourced - after all, they worked on it, and if the development was separate enough, it won’t be “polluted.”
Galois has a history of trying to push things into the open source domain, and their reputation precedes them enough that they would probably not classify a C to Rust translator.
As for your idea, they’d much prefer to just use two separate computers.
As for your idea, they’d much prefer to just use two separate computers.
As much as I love OSS, I would do the same thing. The risk is that person that works on both classified and non-classified projects could make a mistake an do a git push containing classified info. The solutions to problems problems is better structure, not being more careful.
The CMW’s I mentioned specifically try to prevent that with labelled data and interfaces. You can’t mix them without a manual approval, reclassification, etc. One could do the same kind of thing with VM’s where a transfer required internal, human review.
I’m a primary contributor to c2rust and I may be the person “stolen” away from corrode. I’d like to apologize if it feels like we ripped off ideas without giving due credit - the project wasn’t really supposed to “discovered” so soon. The website was a throwaway idea, a means of easily sharing our work in a limited circle while avoiding both the DARPA approval and the sub-par build process (you have to build a huge chunk of Clang).
So here is me acknowledging Jamey’s work: I personally did take inspiration from Corrode, and I was expecting to work on Corrode proper when I joined Galois (I even wrote a pure Haskell library to parse/pretty-print Rust code - with Corrode in mind). I’ve re-read the CFG module of Corrode several times (as well as the Mozilla paper, and some older literature).
All that said, I also want to point out that Corrode hasn’t had any activity at all since last April - and that’s not for want of PRs piling up. I’m not criticizing here, since I understand that managing an open source can be quite time-consuming and stressful, but I feel like this also does need to be mentioned. Also, c2rust can be freely forked. Once the DARPA funding runs out, it is my hope that the Rust community will become the maintainers.
Finally, regarding the many improvements that can be automated: that is next up on our plate!
Hi, nice to see you here!
Regarding idiomatic improvements, in case you missed, C2Eif is the most impressive research in this area in my opinion. It can create classes and methods based on function signature analysis. It can also mark methods as private based on call graph analysis.
It is also impressive in coverage. It handles Vim, it handles inline assembly, it translates long jumps to exceptions, it handles variadic functions (Eiffel doesn’t have them like Rust, they are translated to library calls), it translates printf format strings to Eiffel formatting, etc.
Marco Tudel, the author of C2Eif, has a company called mtSystems that sells a C to Java translator.
Very cool! This is the sort of tool I wish was open source, but probably won’t be because nobody has any financial incentive to do so.
I didn’t see it in search. That project would’ve been a good submission for Lobsters. :)
Ok, someone replied to me and deleted his reply yesterday about this. I’m guessing he wants privacy where only I saw it through email system. I looked at his publications and affiliations to find he’s smart as hell, worked with DARPA (among others), and maybe even did a project with Galois. So, the source is probably reliable on what can or can’t work with DARPA. Here’s a paraphrasing of his claims:
Program managers can set up programs so that pre-pub review isn’t required for the whole program or for specific projects.
He did that himself with the entire project not subject to pre-pub review. He had the whole thing in open repositories that people did the work in.
Another project had subject areas defined as “designated, unclassified, subject areas.” Anything in them didn’t have to be reviewed. This is where you’d put the FOSS part.
He believes the prepub requirement by default is program managers just being lazy. Defaulting on review is the safest approach to go. It requires putting no thought or effort into whether something needs secrecy in the first place. So, they just do it even though they don’t have to. It wastes a lot of people’s time.
So, in his view, Galois could definitely get exemption for whole projects or pieces of them that could be in a live repo. He also claimed to have done this at least two times: one a whole project, one pieces of a project. Maybe the Galois people interacting with DARPA should try to default on doing that for anything that will be published to begin with. If it’s possible at all at current time. And I thank them for all the neat stuff they FOSS’d for us up to this point since they didn’t even have to do that. Still a great company. :)
@harpocrates can you pass this along to them so they at least consider it? I’d appreciate it.
I don’t currently write proposals, but I’ll pass the message on.
Don’t hold your breath though - this sounds like something Galois would already have done (perhaps we have? I don’t know…) if possible. We really do make an effort to open-source when possible.
Thanks!
If the concern is leaks, defense contractors like Galois might be able to get DARPA to change that policy. My idea would be a split between stuff that will definitely be FOSS and stuff that might be sensitive. Like Compartmented Mode Workstations or with Qubes, they could even isolate them in VM’s whose border color, labels, and firewall policies reflect the difference. The sensitive one would be used in a new, custom project or derivative that pulls in the open one. Whereas, the security policy wouldn’t led sensitive stuff interact with the Internet at all.
Quite a few products on the market for this on top of free stuff like Qubes or Muen. One can also use multiple boxes with KVM switch if worried about breaks. Anyone with DARPA or Defense experience think this proposal has a good chance of working?
I think there’s often a fair amount of misinformation regarding the creation of OSS by government contractors.
Yes, contractors like Galois have to play by the rules the government sets for them, including classification. The concern of “leaks” is there, but it’s subtle: tight coupling of components that probably should be open sourced with other components that probably should be classified.
So there’s a tendency to “overclassify” and lump everything together. However, companies can still make a case for why things should be open sourced - after all, they worked on it, and if the development was separate enough, it won’t be “polluted.”
Galois has a history of trying to push things into the open source domain, and their reputation precedes them enough that they would probably not classify a C to Rust translator.
As for your idea, they’d much prefer to just use two separate computers.
As much as I love OSS, I would do the same thing. The risk is that person that works on both classified and non-classified projects could make a mistake an do a git push containing classified info. The solutions to problems problems is better structure, not being more careful.
The CMW’s I mentioned specifically try to prevent that with labelled data and interfaces. You can’t mix them without a manual approval, reclassification, etc. One could do the same kind of thing with VM’s where a transfer required internal, human review.