Dev Wik

DevWik is a wiki written in freepascal for editing source files and instantly running/compiling them inside a standard web browser. As an alternate interface, one can connect through a thin client and edit the files using RealSoftware (as opposed to just being able to use an html or web browser based program).

The original name for DevWik was "compile studio" and it was an early alpha release without many features - other than the wiki concept of editing and a compile/save button (instead of a just a save button as seen in this C2 wiki). The name "compile studio" was changed to DevWik and is pretty infamous if not completely unknown. Reason for changing the name: compile studio wasn't descriptive enough of the type of program it is.

Although it was designed to compile freepascal programs - it can also be modified to compile GCC files - I haven't worked on that yet. It could really be hooked up to any compiler - but more focus on only one right now. I suppose it could be hooked up to a scripting language too rather than a compiler. But again the focus and careful avoidance of A.D.D. means that only one compiler is hooked up to it to start with - which was and currently is freepascal.

I like the name. But a real WikiIde needs to do more than just edit and compile pages... it needs to link them, it needs to version them, and it needs to expose those links to the programmers.

It links to files (modules) in the "uses" clause but it is not super fancy yet. My intent is always to get out version 0.1 of software instead of implementing all the features. It does not link to functions though.. using #these #style links or anything like that (inner page links? I don't know the correct term..). The first version didn't have any syntax highlighting but later versions I have played with a javascript based syntax highlight edit component. Hack the sources with me when I release on here if you want and we can improve it. The fear I have is simply I don't have time to make it one of those multiple development environments where it supports every single language in the world.. so maybe it can focus on FPC and GCC only.. but for me I start off with FPC only to remain more focused. The syntax highlighter isn't even required and is just an extra gimmick.. but useful as I like syntax highlighting.

The coolest thing is that DevWik can compile itself online, and update itself as a wiki program itself (I just love recursion).. i.e. one of the pages that I edit is "DevWik.pas" itself ;-) As for working together, yeah it is laughable.. but still some ideas of ours collide. There are plenty of javascript widgets out there to make use of that are fully open source although some of the stuff I just code from scratch when they don't offer what I need. The DevWik is written in freepascal as a web program (i.e. written in itself) and I don't use PHP.. but.. it could use PHP as another front end. I personally hate php since it's module system is shit (lacking one), but I do have experience in it from the old days.

I wouldn't want PHP in the main code; if you can get all your server-side CGI working on any-old server-side host without touching it, that would be a good thing. Frankly, my experience with web development goes back about three weeks, starting with listening to all of Michael Mahemoff's AJAX lessons on softwareas.com. Just today I grabbed a PHP tutorial & manual and started reading. Before that, I haven't touched web stuff since the days frames and blinking text were popular... except for a very brief stint in writing a portal to an indexer application with Perl CGI, which was like ten lines long. I've always been deep systems and middleware - so I'm really not familiar with the 'rules of the road' when it comes to what hosts allow for CGI. On a typical webshare host, how much can you get away with just sticking to FreePascal? Does Apache or IIS run CGIs written in FreePascal?

A freepascal cgi program runs on Apache and virtually any server that allows cgi bin. The rare exception is some Microsoft Windows web hosts I've seen restrict their servers. I purchased Windows and Unix hosting before and asked the Windows host before buying from them whether they support cgi bin. On unix hosts I don't bother asking because every unix server supports cgi bin (virtually). I pay $4-$10/month for windows or unix hosting. Localhost I use apache to test.

Also, I must ask: valid security concerns were brought up wrgt. your RemoteCompiler. How do you plan on addressing these?

Unplug our computers from the internet... I have decided to do this. I won't be online any more.

I'm fairly certain that would qualify as a computer security violation (of the 'sabotage' and 'denial of service' variety) seeing as it would prevent access to the very services you're attempting to secure.

What is stopping someone from deleting all your source file pages, even if they can't do "rm"?

A versioning system, of course. That's the technical force (and you need at least one, due to the random assholes). Then there are the social forces: If it's easy to delete a page, and easy to repair it, then there isn't much fun to deleting it. Also importantly: pages of code don't exactly raise a bunch of emotional ire compared to discussion on politics, philosophy, and paradigms. Also, allowing people on doesn't mean anonymously. You can require people to sign up and take both social and legal responsibility for their own actions. Consistent minor offenders can be reprimanded or suspended while major and obviously malicious offenses can be taken to the judiciary - all of which would discourage offense.

i.e. anyone can write a bot to go through the entire wiki and delete all text content... This is why I think semi-private wikis are a better tool for development projects.

I disagree, of course. Almost all development projects depend on other people's code anyway... it would be much better if they were developed and refactored together in one massive cloud of software. Consider what a hassle it would be, today, too refactor a library interface then go make commits to every single SourceForge project that uses the library. Unless your library was unpopular, I expect you couldn't even find them all. Imagine how much easier it would be if you had backlinks and the ability to run a transform across the code reflecting the 'easy' parts of the refactoring (e.g. pagename changes), while already having backlinks so you can go find the others bin hand.

The wiki thing is a never ending security flaw.. just like ThisWikiHasIssues. I wouldn't want too many monkeys hacking my code and would advocate semi-private invitation.. just as I don't permit too many monkeys to my SVN servers. If the monkeys are truly not monkeys, they will show some proof that they are not monkeys first.

A chimp on a typewriter capable of buying stuff from e-bay and grabbing a pair from movietickets.com would never be able to prove he is from the ape family (and is certainly NOT a monkey). Why not? because he doesn't have permission to prove he isn't a monkey. The poor chimp is caught in a Catch-22.

It will be a pipe dream to have a reasonably secure purely public wiki.. just as C2 was a pipe dream which is no longer truly purely public anymore with all the passcodes/bots/protection systems in place... not to mention false names being shown in RecentChanges.

Trust, but verify. I believe a purely public WikiIde can be made very reasonably secure, possibly even more secure than the Military internets. This requires only that anonymity is sacrificed (at least in its more complete forms - checkpointed code needs to be associated with trusted usernames, and you can't allow spammers or child pornographers to abuse the WikiIde as a base for vile programs), and you use a good security model (in particular, a Certificate-based CapabilitySecurityModel).

Wikipedia works kind of in a way where your IP address is hidden once you log in. Ultimately, security is done through humans.. wikipedia checks every edit and they have people sitting on there monitoring each edit (i.e. the admins have no life ;-) I think the best security on a wiki is "human monitoring". Kind of like a hospital with mental patients.. like that GrammarVandal guy. Therefore I think security is relative.. and it is possible to implement in different ways. My worst fear is manual security, as opposed to automatic.

I'll readily agree that vigilance and repair is useful, even necessary, but I'm quite certain I'd never trust to it the sort of security and safety guarantees desired for the execution of user-developed content.

Well... here is my theory - user developed content is user developed.. meaning.. a user can do anything, including wiping out 30 pages. Some protection available is through detection systems.. like stopping people from deleting more than 5 pages within 6 hours, stopping people from editing more than 5 pages within 30 seconds.. What else can be done - we can have the person run the programs on his computer, not the server. The server only compiles the program and send it to his machine. The issue with this is if the working system is supposed to be on the server. It depends on the requirements I guess. Those extreme programming requirements card games might help at this point."

Users can't usually crash your system or delete CGIs whether on purpose or accident; and users can't truly delete pages, either - they can just remove all the content, creating yet another version of a page. The risk with user-developed executable content has to do with potential for rights elevation, such as the 'system' call mentioned above. Your 'theory' would accurately reflect the truth ONLY when you already have perfect security, such that the users cannot do anything with a program that they didn't have rights to do by hand anyway. However, that level of security is not something you should trust to a bunch of "human monitoring".

The executable is downloaded to their system and run on it. They edit the executable online, but they run it on their machine. Then they can run the delete command and it will delete the files from their PC, not the server. The issue is do we require it to even run on the server, or can we have everyone download the program and launch it inside his computer instead. We need some requirements cards. For example if I build you a console application and it can be immediately run with the click of a button.. through a browser plugin.. that means every time someone modifies the executable it is downloaded to their machine and ran on their machine.. yet the server is just the compiler of it.

That doesn't sound like any IDE I've ever heard of. No debugger, for one. What you describe would not qualify as a WikiIde; it would, rather, be a syntax-highlighting remote text-editor with an extra high-bandwidth button to compile and package up some code and/or binaries and send you a copy. It would certainly lack the convenience of a WikiIde. However, it would be doable without worrying as much about security.

I just thought about it more and actually that could create viruses easily. A bunch of developers working on the same project: someone downloads the project and little do they know another developer has inserted virus code into the project. So, not so secure depending on the style of security, since there are so many insecurities. One way to limit security is to only allow people to program in JavaScript and HTML which cannot call the "rm" command. But, this would still be insecure due to cross site scripting and such things. Programming in only HTML is no fun, but is fairly secure. A chroot jail permission system might be useful so that only known users with a good feedback rating or a good history could get out of their chroot jail and do more in the wiki after time. One way to limit them would be to create a safe module with limited functions in it.. and not allow them to call any system commands but only functions in that one module. Force what items they can place in their uses clause or module import section. In this sense, the language itself wouldn't need to be secure in order for the wiki to be secure.. because you could limit them through modular programming. Make a completely safe but interesting module that can generate widgets and do cool things, but without that module having any access to system commands and such. Maybe a new pattern: SecurityThroughLimitedModularity.

That new pattern is ObjectCapabilityModel. It's been around for some time.

Can we can defeat the strong typing when you get around to building DevWik and introduce something that gives us access to the Unix commands. ^_^

One can define an untyped pointer and use assembly and all sorts of dirty tricks that will have to be thoughtfully secured.

Technically, all I need to do to access Unix commands is manage an 'int 80h' assembler command with the correct trio of registers pointing at the right string and containing the correct strlen and containing the correct unix command number (from unistd.h). This drops me right into the kernel with whichever command I choose. Can I do this in ModernPascal? (I'm not very familiar with ModernPascal, obviously.)

You can embed assembly code right in your program, so I will have to disable assembly. Ultimately, a powerful language is insecure.. isn't it? The system will be installed on a free web server that supports CGI and several people will be able to try and break it, then. Actually this is the best way to find security flaws - have other crackers audit the system. On a free web server, it won't do any harm. Luckily there are several free servers that support cgi. Someone refactor this stuff into another page if you like, if I don't get to it first.

Languages not designed for security are rarely secure, though it is true that those with little power tend to be secure by virtue of not offering access to anything dangerous. For webserver work, I'd prefer to have an OS and language both designed for security than attempt to figure out what must be blacklisted from a language not designed for security.''