Talk:Carver 2.0 Planning Page
License: have we even discussed a license yet? Who chose it? I'm not terribly opposed to a 3-clause BSD, but...? - RB 00:39, 30 October 2008 (UTC)
Joachim I prefer the LPGL it's restricts the usage of the code somewhat more. When its integrated in other (closed source) tooling which is published, they must publish that the tool uses this code.
- .FUF 19:40, 31 October 2008 (UTC)
- Joachim GNU Library or "Lesser" General Public License (LGPL) (http://www.opensource.org/licenses/alphabetical)
- Agreed. I sit on the fence between BSD and GPL: the business half of me agrees that open licensing should place as few restrictions or qualifications as possible, whereas the idealist/OSS side wants to ensure the project's freedom. The LGPL is a more reasonable balance, encouraging widespread use but ensuring modifications' freedom. RB 16:59, 1 November 2008 (UTC)
We've got a lot of good ideas here, but in interest of not stepping on anyone's toes, it's getting rather disjointed and hard to read. Is anyone willing to (or allow me to) try to consolidate them into some sort of coherency? I'd like at least one of the admins (.FUF or Simsong to concur before anyone moves forward. I know the wiki way is to just let it grow, but even watching each addition I'm starting to have trouble visualizing where we are. RB
- One option could be to break each major section into its own page so it can be properly discussed without clutter, then transclude each to this page. A dedicated namespace would probably be overkill, but since we're throwing out ideas should at least be mentioned. --RB 19:03, 1 November 2008 (UTC)
- Joachim Separate the parts into topics. Have a discussion and an informational part per topic.
Capibara :Just noticed a presentation by Simson when looking for 'usable security' on google that included notes on designation nd authorization. From this I would gather that Simson has something of a background in capability security theory. This makes me feel we might have sufficient ground to discuss 'open file handles as capabilities' at the library level. AppArmor allows instances of executables to be confined to least privilege. Unix domain sockets allow open file handles to be passed around as capabilities. The combination of these two results in the possibility of using object capability based least authority at the process level of granularity. For such to work with libraries such as libaff, libewf and libtsk, these libraries must not insist on opening their own files. At the moment this rules out using libaff or libewf directly as such. CarvFs can provide a way around this, but it may be desirable to not have to use CarvFs in some cases. Given that the authors of both libaff and libewf are quite active here, It may be valid to discuss the possibility of extending the API of these libs so that the libs dont demand to open their own files, but could also be used by a confined carving tool that would get open file handles passed to it over a unix domain socket.